pixel
Select Page

NETWAYS Blog

Icinga for Windows – Performance Boost mittels REST-Api

Seit dem ersten Release von Icinga for Windows hat sich eine Menge getan, um sowohl die Funktionalitäten, die Usability als auch die Sicherheit der Lösung zu erhöhen. Ein großer Fokus lag parallel jedoch auch immer auf der Performance, was sowohl auf den Aufbau des Icinga Agenten als auch der PowerShell oder generell der Plugins zurückzuführen ist.

Warum ist die Performance “schlecht”?

Der große flexible Ansatz von Icinga erlaubt es, beliebige Plugins in einer Vielzahl von Programmier- oder Skriptsprachen auszuführen – unter anderem auch PowerShell. Das bedeutet jedoch, dass Icinga sich keine Libraries, Inhalte oder sonstigen Informationen merkt. Stattdessen ist – im Beispiel von PowerShell – für jeden einzelnen Aufruf eine PowerShell zu starten. Hierfür müssten dann zuerst die notwendigen Bibliotheken geladen werden und gegebenenfalls umgebungsspezifische Informationen.

Zu guter letzt muss dann noch Icinga for Windows geladen werden, also das Framework und die Plugins, welche wir ausführen wollen. Das kostet nicht nur Zeit, sondern auch CPU-Ressourcen. Bis zu diesem Punkt haben wir aber auch das Plugin noch nicht ausgeführt – je nach Plugin, kommen dann noch WMI Handler und sonstige Themen hinzu, welche das Plugin abfragen und laden muss, bis man schließlich sein Ergebnis erhält.

Gibt es Lösungsansätze für dieses Problem?

Über paar Jahre in welchen Icinga for Windows entwickelt wurde, gab es mehrschichtige Ansätze, um die Performance zu verbessern. Zum einen wird von Icinga for Windows ein Cache-File für alle Komponenten des Frameworks angelegt und als “ein großes Modul” geladen. Dadurch entfallen Lade- und CPU-Zeiten für das Einbinden von Sub-Modulen oder Skripten.

Der größte und wichtigste Ansatz ist jedoch die Nutzung des Icinga for Windows Service. Dieses kleine Service Binary erlaubt es, eine PowerShell im Hintergrund über die Windows Dienste zu starten und zu verwalten. Dadurch können über das Icinga PowerShell Framework dann sogenannte Background Daemons registriert werden, welche im Hintergrund Ihren Dienst verrichten.

Einer dieser Background Daemons, welche normalerweise als separate Komponenten installiert werden, ist in den letzten Versionen direkt in das Icinga PowerShell Framework eingezogen: Die REST-Api

Eine REST-Api für Plugin Ausführung

Mittels der REST-Api und einer entsprechenden Funktion im Icinga PowerShell Framework können Plugin-Ausführungen über die REST-Api innerhalb des Icinga for Windows Dienstes ausgeführt werden. Das hat mehrere Vorteile, da man zum einen andere Wege finden könnte, seine Plugins auszuführen, zum anderen aber die Last von Icinga for Windows komplett anders verteilt wird.

Zwar startet der Icinga Agent im Standardverhalten zwar weiterhin eine PowerShell, diese führt aber den eigentlichen Plugin Code nicht mehr aus, sondern prüft, ob die REST-Api sowie das entsprechende Feature aktiviert sind. Falls ja, wird ein Versuch gestartet, den Plugin Aufruf über die REST-Api einzustellen. Das bedeutet, dass innerhalb der Daemons und der REST-Api zwar auch Bibliotheken geladen werden müssen, diese aber persistent verfügbar und beim erneuten Aufruf des Plugins bereits vorhanden sind. Das bringt nicht nur einen Performance-Boost für die Ausführungszeit, sondern reduziert auch die CPU last deutlich.

Am Ende wird nur das Ergebnis zurückgegeben, von unserem Plugin-Handler ausgewertet und an den Icinga Agent weitergereicht. Sollte in diesem Prozess etwas schief gehen, gibt es immer noch den Fallback auf die automatische lokale Ausführung. Im EventLog von Icinga for Windows sind dann einige Details zu finden: Ob es ein Fehler bei der Ausführung des Plugins war oder ob die Ausführung zu lange gedauert hat und deshalb auf lokale Ausführung zurückgegriffen wurde.

Kann man dieses Feature einfach aktivieren?

Ja! Die einzigen Voraussetzungen für dieses Feature sind das Icinga for Windows Service Binary und der installierte Icinga Agent mit einem Zertifikat, das von der Icinga CA signiert wurde. Anschließend kann man das Feature über die IMC einfach aktivieren. Da wir nur einen HTTPS Socket anbieten, der per Default auf localhost läuft, ist weder eine externe Kommunikation möglich noch eine Nutzung der REST-Api ohne TLS.

Zuerst müssten wir den Icinga for Windows Service installieren, sofern nicht vorhanden:

Install-IcingaComponent -Name ‘service’ -Confirm;

Anschließend öffnen wir die Icinga Management Console mittels dem Befehl icinga in einer administrativen PowerShell und navigieren zu folgenden Punkten:

* [2] Settings
* [6] Icinga for Windows Features
* [0] Api-Check Forwarder

Mittels der IMC kann das Api-Check Forwarder Feature dann einfach aktiviert oder deaktiviert werden. Der jeweilige Status ist direkt neben dem Eintrag zu finden. Wenn alles aktiviert ist, starten wir zur Sicherheit noch den Icinga Agent sowie Icinga for Windows Dienst neu und alles sollte funktionieren!

Restart-Service -Name ‘icinga2’;
Restart-IcingaWindowsService;

Und jetzt?

Wenn die Ausführungszeit der Plugins von Icinga Seite schneller und die Last auf dem System reduziert ist, sollte alles funktionieren. Natürlich kann man jetzt noch das EventLog parallel beobachten, während man Checks ausführt, ob im Icinga for Windows EventLog Probleme auftreten:

Read-IcingaForWindowsLog;

Sofern Fragen hierzu sind, es Probleme gibt oder wir bei der Einrichtung helfen können, freuen wir uns natürlich über eure Kontaktaufnahme!

Viel Spaß mit Icinga for Windows und der neu gewonnenen Performance!

Christian Stein
Christian Stein
Lead Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Der NETWAYS Support Collector

Dem ein oder anderen unserer Support Kunden ist unser neuer Support Collector vielleicht schon über den Weg gelaufen. Aber was ist das überhaupt? Und was bringt er?

Der NETWAYS Support Collector ist eines unserer neuesten Kreationen. Inspiriert von, dem mehr verbreiteten, icinga2-diagnostics ist die Aufgabe des Support Collectors, Daten über laufende Systeme und deren Komponenten zu sammeln.
So ist es möglich mittels eines einzelnen Aufrufes alle essentiellen Daten über das System zu sammeln.

Anhand dieser Daten können beispielsweise Support Abläufe effizienter gemacht werden oder sogar aussagekräftige Statistiken erstellt werden.

Der Support Collector kann neben den vorstellbar gängigen Daten wie Icinga 2 und Icinga Web 2 weit aus mehr.
Der aktuelle Rahmen, welcher durch das Tool abgedeckt wird, ist folgender:

  • Allgemeine System Informationen
  • Icinga 2
  • Icinga Web 2
  • Icinga Director
  • Mysql / MariaDB
  • PostgreSQL
  • Ansible
  • Puppet
  • InfluxDB
  • Grafana
  • Graphite

Für den User ist es selber wählbar, welche “Module” durch den Support Collector alle gesammelt werden sollen. Standartmäßig werden alle “Module” gesammelt, welche auf dem System gefunden werden.

Um den Sicherheitsaspekt zu beachten, werden alle Passwörter / IP Adressen / Token innerhalb der gesammelten Daten entfernt, bevor diese zu einen ZIP verpackt werden.
Die generierte ZIP Datei kann dann durch Support Kunden an unseren Support weitergeleitet werden, sobald ein Support Fall eintrifft.

Wer selber einen Blick auf den Support Collector werfen möchte, kann dies in dem GitHub Repository machen oder sich das Tool mit den durch uns bereit gestellten Paketen auf packages.netways.de/extra installieren.
Die –help Übersicht liefert einige Konfigurations Möglichkeiten, welche optional mitgegeben werden können.

Tobias Bauriedel
Tobias Bauriedel
Systems Engineer

Tobias ist ein offener und gelassener Mensch, dem vor allem der Spaß an der Arbeit wichtig ist. Bei uns hat er seine Ausbildung zum Fachinformatiker für Systemintegration abgeschlossen und arbeitet nun im NETWAYS Professional Services - Team Operations und entwickelt nebenbei Projekte für die NPS. In seiner Freizeit engagiert er sich ehrenamtlich aktiv bei der Freiwilligen Feuerwehr als Atemschutzgerätetrager und Maschinist, bereist die Welt und unternimmt gerne etwas mit Freunden.

LUKS LVM Resizing

Ever tried to create a Dual Boot Ubuntu AFTER you encrypted your whole hard drive already?
Well don’t worry we got you covered!

My Problem:

I want to shrink my encrypted Ubuntu installation to make room for another OS, which I need for my video editing.
For that I have a SSD 512GB, which is encrypted with LUKS, uses LVM and ist partitioned in ext 4 fs.
But I also have an encrypted LUKS Swap called “vgubuntu-swap_1”, who also uses LVM and is formated in swap fs.

My partition had a size around 475 GiB before shrinking. The swap volume helps to demonstrate that shrinking may lead to gaps between logical LVM volumes.
The plan is to shrink the file system, its volume, the volume group and also the encrypted partition.
I used a Live Ubuntu System from a USB stick, since I could not just take the hard drive out. If you have just one computer available, use either a Live System from a USB stick or a DVD.

Disclaimer: PLEASE MAKE A BACKUP of the whole disk first.
Please read carefully through the steps first before you do anything.
If you are unsure about the commands and what they mean or what consequences they have, do some research on the Internet ahead. Likewise in case of trouble or error messages. It definitely helps to be familiar with partitioning, LVM, dm-crypt and LUKS.

My Solution:

Resizing was a sequence of 14 steps – following the disk layout in reverse order, I started resizing from the filesystem to the LVM structure down to the partition.
You open an encrypted partition with LVM on LUKS just as any dm-crypt/LUKS-partition by:

cryptsetup open /dev/Disk-MAPPING-Name cryptdisk

For the mapping name I used “cryptdisk“. Note that closing the encrypted device requires to deactivate the volume groups in the kernel first; in our case:

vgchange -a n vg1;

cryptsetup close cryptdisk

Otherwise you may not be able to close your device.

 

Step 1: Take a look at your Block Devices

With lsblk you take a look at you partitions

lsblk

For instance for me the disk appeared as “/dev/nvme0n1” – the encrypted partition was located on “/dev/nvme0n1p3”.

 

Step 2: Opening the encrypted partition

ubuntu@ubuntu:~$ cryptsetup open /dev/nvme0n1p3 cryptdisk

Review it so you know the mapping is done correctly by “ls -la /dev/mapper”
Take a look at the “cryptdisk”-device, but keep a close eye on the LVM-volumes inside the encrypted partition. They should appear automatically as distinct devices.

 

Step 3: Let’s take a look at the LVM Structure

Next up we have:

pvdisplay
vgdisplay
lvdisplay

Pvdisplay and vgdisplay show you the PV device:  “/dev/mapper/cryptdisk” and the volume group, like in my case “vgubuntu”.
With lvdisplay you can take a look at the logical volumes, so the path to the devices and LV Size. In this case it was: “/dev/vgubuntu/root” and “/dev/vgubuntu/swap_1”

 

Step 4: Filesystem Integrity check

With fsck we can make sure the filesystem is clean:

ubuntu@ubuntu:~$ sudo fsck /dev/vgubuntu/root
fsck from util-linux 2.36.1
e2fsck 1.46.3 (27-Jul-2021)
/dev/mapper/vgubuntu-root: clean, 530426/13107200 files, 14946582/52428800 blocks

That seems fine, let’s move on!

 

Step 5: Review  filesystem physical block size and used space

Since we need to take a look at the phyisical block size, we can use “fdisk -l”.
There were also a lot of loop devices in my case, but the last entry showed my encrypted drive.

ubuntu@ubuntu:~$ sudo fdisk -l

Disk /dev/mapper/cryptdisk: 475.71 GiB, 510787584000 bytes, 997632000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Inode count:              13107200
Block count:              52428800
Reserved block count:     2621439
Free blocks:              37482218
Free inodes:              12576774

 

Step 6: Reducing the Volume and filesystem size

For the reduced filesystem I went with 210G, since it should be about 200GiB size at the end.
With lvreduce we work with GiB, so the filesystem size should be 5-10% smaller than the logical volume size. Then we would get 200 * 1024 * 1024 * 1024 Bytes = 214.748.364.800 Bytes.

 

Step 7: Actually shrinking the filesystem

Please check first if the filesystem is mounted somewhere and then proceed with:

ubuntu@ubuntu:~$ sudo resize2fs /dev/mapper/vgubuntu-root 210G
resize2fs 1.46.3 (22-Dez-2021)
Resizing the filesystem on /dev/mapper/vgubuntu-root to <pre style="padding:8px;"> (4k) blocks.
The filesystem on /dev/mapper/vgubuntu-root is now 52428800 (4k) blocks long.

 

Step 8: Shrink the logical volume

With “lvreduce” we can resize the LVM volume, the option parameter “L” together with a “size” determines how big the volume will become.

ubuntu@ubuntu:~$  lvreduce -L 200G /dev/vgubuntu/root
WARNING: Reducing active logical volume to 200 GiB.
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce vgubuntu/root? [y/n]: y
Size of logical volume vgubuntu/root changed from 210 GiB (20480 extents) to 200.00 GiB (15360 extents).
Logical volume vgubuntu/root successfully resized.

Since we got the confirmation that it worked, we can now proceed.

 

Step 9: Check for gaps between the volumes of your LVM volume group

That was the trickiest part for me at least since I had a swap with my Ubuntu. The first thing I did was to scan for the Swap, on which Blocks it was located.

I then used “pvmove” to get the swap from the last blocks to the ones after my root volume.

As you can see, my swap moved over and my free space had no further volumes in between.

 

Step 10: Resize/reduce the physical LVM

Next I had to resize and reduce the physical LVM to 200G

ubuntu@ubuntu:~$ sudo pvresize --setphysicalvolumesize 200.96G /dev/mapper/cryptdisk
/dev/mapper/cryptdisk: Requested size <200.96 GiB is less than real size <475.71 GiB. Proceed?  [y/n]: y
WARNING: /dev/mapper/cryptdisk: Pretending size is 421443665 not 997632000 sectors.
Physical volume "/dev/mapper/cryptdisk" changed
1 physical volume(s) resized or updated / 0 physical volume(s) not resized

Since the resize worked, I wanted to make sure everything was fine.

ubuntu@ubuntu:~$ sudo pvdisplay
--- Physical volume ---
PV Name               /dev/mapper/cryptdisk
VG Name               vgubuntu
PV Size               <200.96 GiB / not usable <2.04 MiB
Allocatable           yes (but full)
PE Size               4.00 MiB
Total PE              51445
Free PE               0
Allocated PE          51445
PV UUID               KpzZm…

 

Step 11: Setting up the encrypted regions size

First make sure which Block Size the current drive has:

ubuntu@ubuntu:~$ sudo cryptsetup status cryptdisk
/dev/mapper/cryptdisk is active and is in use.
type:    LUKS2
cipher:  aes-xts-plain64
keysize: 512 bits
key location: keyring
device:  /dev/nvme0n1p3
sector size:  512
offset:  32768 sectors
size:    997632000 sectors
mode:    read/write

Then I had to calculate the new blocksize for the encrypted disk, I used the formula on the Arch Wiki: NEW_LUKS_SECTOR_COUNT = PV_EXTENT_COUNT * PV_EXTENT_SIZE / LUKS_SECTOR_SIZE

From Step 10 (pvdisplay) and the cryptdisk status you can gather all the information needed to get:
(53880 extent + 1 unusable extent) * 4 MiB/extent /512 B/sector = 441393152 sectors

ubuntu@ubuntu:~$  sudo cryptsetup -b 441393152 resize cryptdisk
Enter passphrase for /dev/nvme0n1p3:
ubuntu@ubuntu:~$ sudo cryptsetup status cryptdisk
/dev/mapper/cryptdisk is active and is in use.
type:    LUKS2
cipher:  aes-xts-plain64
keysize: 512 bits
key location: keyring
device:  /dev/nvme0n1p3
sector size:  512
offset:  32768 sectors
size:    441393152 sectors
mode:    read/write

And now we have a smaller LUKS Partition. You came this far, now don’t stop!

 

Step 12: Reduce the size of the physical partition

Here I used parted to get an overview of my drives and resize it to the desired size:

ubuntu@ubuntu:~$ sudo parted /dev/nvme0n1
GNU Parted 3.4
Using /dev/nvme0n1
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: PM9A1 NVMe Samsung 512GB (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number  Start   End     Size   File system  Name                  Flags
1      1049kB  538MB   537MB  fat32        EFI System Partition  boot, esp
2      538MB   1305MB  768MB  ext4
3      1305MB  512GB   511GB

(parted) resizepart

Partition number? 3
End?  [512GB]? 211GB
Warning: Shrinking a partition can cause data loss, are you sure you want to continue?
Yes/No? y
(parted) print
Model: PM9A1 NVMe Samsung 512GB (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number  Start   End     Size   File system  Name                  Flags
1      1049kB  538MB   537MB  fat32        EFI System Partition  boot, esp
2      538MB   1305MB  768MB  ext4
3      1305MB  211GB   210GB

(parted) q

Information: You may need to update /etc/fstab.

I checked with print in between, to see if the parted resize worked.

 

Step 13: Set new size of the encrypted region

Now we just need to make sure we also have use the full partition size:

ubuntu@ubuntu:~$ sudo cryptsetup resize cryptdisk
ubuntu@ubuntu:~$ sudo cryptsetup status cryptdisk
/dev/mapper/cryptdisk is active.
type:    LUKS2
cipher:  aes-xts-plain64
keysize: 512 bits
key location: keyring

device:  /dev/nvme0n1p3
sector size:  512
offset:  32768 sectors
size:    409526848 sectors
mode:    read/write

 

Step 14: Reset the PV size to the full partition size

Next up we have to use pvresize so the cryptdisk gets also adjusted and then we can take a look at the volumes.

ubuntu@ubuntu:~$ pvresize  /dev/mapper/cryptdisk
Physical volume "/dev/mapper/cryptdisk" changed
1 physical volume(s) resized / 0 physical volume(s) not resized
ubuntu@ubuntu:~$ sudo pvdisplay
--- Physical volume ---
PV Name               /dev/mapper/cryptdisk
VG Name               vgubuntu
PV Size               210.47 GiB / not usable 2.00 MiB
Allocatable           yes
PE Size               4.00 MiB
Total PE              53880
Free PE               2435
Allocated PE          51445
PV UUID               Kpz...

ubuntu@ubuntu:~$ sudo vgdisplay
--- Volume group ---
VG Name               vgubuntu
System ID
Format                lvm2
...
VG Size               <210.47 GiB
PE Size               4.00 MiB
Total PE              53880
Alloc PE / Size       51445 / <200.96 GiB
Free  PE / Size       2435 / 9.51 GiB
VG UUID               dz0...

That’s it!

You can also do a checkup with gparted/disks, but apart from that I was just happy that I had more space for a second OS while also maintaining the encryption for Ubuntu!
(Now I will create another backup, just in case I break something with the new OS Installation.)

 

 

Your own Mini-NAS – Einfach umgesetzt mit Raspberry Pi und OpenMediaVault

Als Auszubildender zum Fachinformatiker für Systemintegration im ersten Lehrjahr bei NETWAYS darf ich regelmäßig neue Projekte bearbeiten. Das Ziel der Projekte: Wissensaufbau und Verständnis für die zugrunde liegende Technik und Software entwickeln.
Im Rahmen meines aktuellen Projektes setze ich mich mit der Einsatzmöglichkeit eines Raspberry Pi 4 als Network-attached storage (NAS) auseinander. Um sich als Einsteiger mit dem Konzept NAS und den Konfigurationsmöglichkeiten vertraut zu machen, ist die Open Source Software OpenMediaVault (OMV) eine sehr gute Einstiegsmöglichkeit. Mit ihrer Hilfe lässt sich unkompliziert und innerhalb kurzer Zeit ein voll funktionstüchtiges NAS installieren und konfigurieren.

Was ist OpenMediaVault?

OpenMediaVault ist eine moderne, auf Debian basierende NAS-Lösung. Die Software unterstützt mit FTP, TFTP, SMB/Samba, NFS, SNMP und SSH die gängigsten Protokolle für den Fernzugriff. Dadurch kann von (fast) jedem Gerät auf die gespeicherten Daten zugegriffen werden, egal ob PC, Laptop oder Smartphone.

Eine besonders wichtige Rolle spielt dabei Samba. Das dazugehörige SMB-Protokoll wird von Linux, Microsoft Windows, macOS sowie Android unterstützt und ist somit das ideale Protokoll für den Cross-Platform-Zugriff.

Die Datensicherung kann unter anderem mit RSync durchgeführt werden. Dafür müssen lediglich ein Quell- sowie ein Zielordner angegeben werden.
Neben den von Haus aus vorhandenen Funktionen lässt sich OMV mit unterschiedlichen Plug-ins erweitern und an die eigenen Bedürfnisse anpassen.

Zusätzlich zu seiner Funktionalität ist OpenMediaVault zudem äußerst einsteiger- und bedienerfreundlich. Diese Nutzerfreundlichkeit zeigt sich unter anderem an der grafischen Weboberfläche, die es allen Nutzer:innen, unabhängig vom IT-Wissen, erlaubt mit dem Browser auf OMV zuzugreifen und die Software zu konfigurieren.

Die Entwickler:innen selbst bezeichnen OMV als eine “Out-of-the-box-Lösung die es jeder Person, auch ohne technisches Vorwissen, möglich macht ein NAS zu installieren und zu verwalten.”

Technische Voraussetzungen

Damit ein NAS mithilfe von OMV installiert und konfiguriert werden kann, gibt es einige technische Voraussetzungen die erfüllt werden müssen.
Man benötigt:

  • Raspberry Pi 4 mit Raspberry Pi OS Full oder Raspberry Pi OS lite (Versionen ab Raspberry Pi 2B sind ebenfalls möglich)
  • microSD-Karte (idealerweise 8GB Speicherkapazität)
  • Aktive Ethernet- oder WiFi-Verbindung des Raspberry Pi
  • Externes Speichermedium (z.B. Festplatte, USB-Stick) mit dem gewünschten Speicherplatz
  • Raspberry Pi HDMI-Kabel (falls der Pi mit einem Bildschirm verbunden werden muss)

Installation von OpenMediaVault

–HINWEIS–
Nach der Installation von OpenMediaVault kann der Raspberry Pi problemlos ohne Monitor betrieben werden. Da für den Zugriff auf die Weboberfläche jedoch die IP-Adresse des Pi benötigt wird, sollte für die Dauer des Installationsvorgangs ein Monitor angeschlossen sein.

Das Versprechen der Nutzerfreundlichkeit hält OpenMediaVault ebenfalls bei der Installation ein. Sie beinhaltet lediglich fünf Schritte, wovon vier der Aktualisierung bzw. der Informationsfindung dienen.

  • Update und Aktualisierung der bereits auf dem Raspberry Pi installierten Softwarepakete
sudo apt update
sudo apt upgrade
  • Installation des OpenMediaVault – Softwarepakets
wget -O - https://raw.githubusercontent.com/OpenMediaVault-Plugin-Developers/installScript/master/install | sudo bash
  • Nach Abschluss der Installation ist ein Neustart des Raspberry Pi empfehlenswert
sudo reboot
  • Abfragen der IP-Adresse des Pi
hostname -I

oder

ip -a
  • Aufrufen der IP-Adresse im Browser der Wahl
    Wenn das folgende Eingabefenster erscheint, war die Installation erfolgreich:

Die standardmäßigen Anmeldedaten von OpenMediaVault lauten: username –> admin , password –> openmediavault ; (aus Sicherheitsgründen sollte das Passwort direkt nach dem ersten Login in ein sicheres Passwort geändert werden.)

Damit ist die Installation von OpenMediaVault auf dem Raspberry Pi abgeschlossen. Welche Konfigurationsmöglichkeiten bestehen, auf welche Art und Weise auf das NAS zugegriffen wird und vieles mehr, bleibt dem Nutzer selbst überlassen.

Die folgenden Guides behandeln eine Erstkonfiguration der Software:

Wenn du einen Ausbildungsplatz als Fachinformatiker:in für Systemintegration suchst, Lust auf spannende und abwechslungsreiche Projekte hast (die stets auf deinen persönlichen Wissensstand abgestimmt sind) und Teil eines modernen IT-Unternehmens werden willst, bist du du bei NETWAYS an der richtigen Adresse.

Marc Rupprecht
Marc Rupprecht
Junior Consultant

Nach seinem Bachelorabschluss im Fach Technikjournalismus und zweieinhalb Jahren als Online-Redakteur hat Marc sich entschieden, die Medienwelt hinter sich zu lassen und den Wechsel in die IT vollzogen. Als Auszubildender zum Fachinformatiker für Systemintegration verstärkt er nun seit September 2021 das Team der NETWAYS Professional Services. In seiner Freizeit ist er seit vielen Jahren begeisterter Volleyballspieler und hat vor Kurzem das Scuba Diving für sich entdeckt. Ansonsten versucht er regelmäßig neue Länder auf seiner Weltkarte frei zu rubbeln und verbringt gerne auch den einen oder anderen Abend beim Zocken am PC.

Wireguard mit dynamischen DNS Namen

Seit einiger Zeit bin ich großer Fan von Wireguard als VPN Lösung um meine Server und Notebooks zu verbinden. Auch Patrick hatte schon mal über DNS Privacy mit Wireguard geschrieben.

Dabei ist mir ein kleines Problem begegnet, Wireguard hat kein automatisches Handling wenn sich Endpoint Adressen über DNS ändern. In meinem Fall verbinde ich:

  • Server im Rechenzentrum mit fester IP Adresse
  • Notebook irgendwo unterwegs, muss sich zu allen anderen Verbinden
  • Server zuhause, Verbindung nur über DynDNS möglich

Auf dem Bild kann man in etwa die aufgebauten Verbindungen erkennen, nun besteht das Hauptproblem darin, dass der Server zuhause nur über die Auflösung des dynamischen DNS Namens erreichbar ist. Wireguard löst DNS Namen nur beim laden der Konfiguration auf. Sollte sich die IP Adresse ändern funktioniert die Verbindung nicht mehr.

Ein Beispiel meiner Konfiguration:

[Interface]
# Notebook
Address = 10.99.0.3/24
PrivateKey = BASE64
ListenPort = 51820

[Peer]
# Server at home
PublicKey = BASE64
AllowedIPs = 10.99.0.1/32
Endpoint = home.example.com:51820

[Peer]
# hosted VM
PublicKey = BASE64
AllowedIPs = 10.99.0.2/32
Endpoint = server.example.com:51820

#[Peer]
## Notebook Entry on other nodes
#PublicKey = BASE64
#AllowedIPs = 10.99.0.3/32
## No endpoint defined for this peer

Nachdem Wireguard noch keine eingebaute Lösung dafür hat, braucht man ein Script, welches DNS Namen neu auflöst und dann anwendet. Ich verwende das Beispielskript reresolve-dns.sh aus den contrib Skripten.

Die Installation ist relativ einfach:

curl -LsS -o /usr/local/bin/wireguard-reresolve-dns https://github.com/WireGuard/wireguard-tools/raw/master/contrib/reresolve-dns/reresolve-dns.sh
chmod 0755 /usr/local/bin/wireguard-reresolve-dns

Im Anschluss kann das Skript manuell oder per Cron (als root) ausgeführt werden:

wireguard-reresolve-dns wg0

Oder was ich bevorzuge, als Systemd Service und Timer wie folgt.

/etc/systemd/system/wireguard-reresolve-dns.service

[Unit]
Description=Wireguard Re-Resolve DNS of endpoints

[Service]
Type=oneshot
ExecStart=/usr/local/bin/wireguard-reresolve-dns wg0

/etc/systemd/system/wireguard-reresolve-dns.timer

[Unit]
Description=Runs Wireguard Re-Resolve DNS every 5 Minutes

[Timer]
OnUnitActiveSec=300s
OnActiveSec=300s

[Install]
WantedBy=multi-user.target

Anschließend muss man den Timer nur aktivieren und kann den Status des Service jederzeit checken:

# systemctl daemon-reload
# systemctl enable wireguard-reresolve-dns.timer
# systemctl status wireguard-reresolve-dns.timer
* wireguard-reresolve-dns.timer - Runs Wireguard Re-Resolve DNS every 5 Minutes
Loaded: loaded (/etc/systemd/system/wireguard-reresolve-dns.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Thu 2021-12-30 15:40:09 CET; 6 days ago
Trigger: Wed 2022-01-05 15:50:48 CET; 3min 1s left
Triggers: * wireguard-reresolve-dns.service

Dec 30 15:40:09 notebook systemd[1]: Started Runs Wireguard Re-Resolve DNS every 5 Minutes.

# systemctl status wireguard-reresolve-dns.service
* wireguard-reresolve-dns.service - Wireguard Re-Resolve DNS of endpoints
Loaded: loaded (/etc/systemd/system/wireguard-reresolve-dns.service; static)
Active: inactive (dead) since Wed 2022-01-05 15:45:48 CET; 2min 1s ago
TriggeredBy: * wireguard-reresolve-dns.timer
Process: 3600033 ExecStart=/usr/local/bin/wireguard-reresolve-dns wg0 (code=exited, status=0/SUCCESS)
Main PID: 3600033 (code=exited, status=0/SUCCESS)
CPU: 17ms

Jan 05 15:45:48 notebook systemd[1]: Starting Wireguard Re-Resolve DNS of endpoints...
Jan 05 15:45:48 notebook systemd[1]: wireguard-reresolve-dns.service: Succeeded.
Jan 05 15:45:48 notebook systemd[1]: Finished Wireguard Re-Resolve DNS of endpoints.

Ich wünsche viel Spaß beim Ausprobieren.

Wer gerne automatisiert, dem kann ich die Ansible Rolle von githubixx empfehlen, so spart man sich das müssige Erstellen und Verteilen von Keys. Leider habe ich noch keine fertige Rolle für reresolve DNS. 😉️