Bekanntermaßen nutze ich zum Monitoring der von mir verwalteten Server seit geraumer Zeit die Open-Source-Software Zabbix. Seit dem letzten Serverwechsel, an dem ich die Gelegenheit genutzt und den Monitoring-Stack komplett frisch aufgesetzt hatte, erhielt ich trotz korrekt konfigurierter Maintenance im Zabbix weiter Notifications der betroffenen Hosts.
Nach einiger Verwunderung kam ich dann aber auf die simple und doch so versteckte Lösung. Die Trigger Action ist von Haus aus nicht darauf konfiguriert, während einer aktiven Maintenance, Notifications zu unterdrücken.
Die Problemlösung ist einfach und geht schnell von der Hand. Im Menü wählt man Configuration -> Actions -> Trigger Actions und bearbeitet dort die Conditions der Action.
Konfiguration der Trigger-Action
Nach dem Speichern der neuen Einstellung ist Zabbix nun ruhig, wenn ein Trigger bei einem Host auslöst, der gerade in einem Wartungsfenster ist.
Irgendwann ist bei jedem System der Zeitpunkt gekommen, es in Rente zu schicken – sei es aus Alters- oder Performancegründen oder einfach, weil man beispielsweise in die Cloud umziehen möchte. So war auch für meinen Monitoring-Server basierend auf Zabbix der Zeitpunkt gekommen, in Rente zu gehen. Die Migration gestaltete sich überraschend einfach, dennoch möchte ich kurz aufzeigen, wie ich es gemacht habe.
Diese Anleitung richtet an sich technisch versierte Leser. Ein Grundverständnis von Netzwerken, Subnetzen, Routing und IP-Adressen ist notwendig, um diese Anleitung durchzuarbeiten.
Nachdem mein Artikel über die Konfiguration einer Router-VM (OPNSense, pfSense) basierend auf Proxmox aus dem Jahr 2017 noch immer durch die Decke geht, ich aber immer mehr Rückfragen zum Artikel erhalte, möchte ich heute eine aktualisierte Version veröffentlichen.
Ich habe seit einiger Zeit in meinem Home Office eine Unifi Dream Machine und diverse Access Points der gleichen Firma. Natürlich möchte ich auch von unterwegs manchmal auf mein Heimnetz zugreifen, weshalb ich einen dynamischen DNS benötigte.
Was ist ein DynDNS?
Die meisten Internetanschlüsse sind nicht mit einer festen IP-Adresse ausgestattet. Die öffentliche IP-Adresse des Anschlusses wechselt also – manchmal in definierten Abständen (z.b. täglich), manchmal auch nur bei Neuverbindung des Routers.
Will man nun von außen auf sein Heimnetz zugreifen, ohne die gerade zugewiesene IP-Adresse zu kennen, benötigt man einen dynamischen DNS – kurz DynDNS oder DDNS. Ein DNS-Eintrag übersetzt eine bestimmte (Sub-)Domain wie z.B. dominicpratt.de in eine IP-Adresse.
Ein dynamischer DNS sorgt also dafür, dass bei einem IP-Adress-Wechsel der zugehörige DNS-Eintrag entsprechend abgeändert wird.
Es gibt verschiedene kostenpflichtige und kostenlose Anbieter für DynDNS-Einträge – AVM z.B. bietet für FRITZ!Boxen den DDNS-Dienst MyFritz an. Ich möchte eine Subdomain meiner eigenen Domain dominicpratt.de dafür nutzen und diese ist bei INWX registriert, weshalb ich auch den dort angebotenen DDNS-Service nutze.
Konfiguration der Dream Machine
Nachdem man im INWX-Kundencenter die entsprechende Subdomain und den zugehörigen Account angelegt hat, kann man im Unifi-Controller die Konfiguration vornehmen.
Hierzu wechselt man in die Einstellungen, dort auf den Punkt Services und den Tab Dynamic DNS.
Dort legt man nun einen neuen DynDNS-Eintrag an mit folgenden Einstellungen:
Interface
WAN
Service
dyndns
Hostname
sub@domain.de
Username
DynDNS-Username
Password
DynDNS-Passwort
Server
dyndns.inwx.com/\/nic/update?hostname=%h&myip=%i
Der Hostname sieht zwar falsch aus, allerdings benötigt der Hostname bei Unifi eine spezielle Syntax – der Punkt zwischen Subdomain und Domain muss durch ein @ ersetzt werden. Lautet die gewünschte DynDNS-Subdomain also sub.domain.de, muss hier sub@domain.de angegeben werden.
Ich hoffe, ich habe mit diesem Artikel wieder ein paar Menschen geholfen und freue mich über Anregungen, Ideen und Fragen.
Manchmal passiert es und eine Festplatte im RAID-Verbund steigt aus, davor ist kein Server gefeit – Glück gehabt, wenn man einen entsprechend gespiegelten RAID-Verbund hat und das Monitoring früh genug Alarm geschlagen hat.
Natürlich hat Hetzner für den Festplattentausch eine Anleitung, was aber, wenn man das Wichtigste vergessen hat: den Bootloader neu schreiben. Das System fährt nicht mehr hoch und langsam bricht Panik aus – völlig unbegründet! Ruhe bewahren und das Rescue-System von Hetzner booten – dann folgen ein paar einfache Schritte zum Erfolg.
Überprüfung des RAID-Verbunds
Mit einem einfachen cat /proc/mdstat prüfen wir den Zustand des RAID-Verbunds. Eine saubere Ausgabe sollte ungefähr so aussehen:
Ist hier alles in Ordnung, der Verbund synchron und alle Partitionen sauber eingebunden, schreiben wir den Bootloader nun neu.
Bootloader-Reparatur
Mit folgenden Befehlen schreiben wir den Bootloader auf beide Festplatten bzw. SSDs. Natürlich müssen eventuell die Gerätenamen (/dev/sda, /dev/sdb) angeepasst werden – wie immer gilt: nichts einfach nur kopieren, sondern vorher nachdenken und verstehen!
mount /dev/md2 /mnt
mount /dev/md1 /mnt/boot
mount -o bind /dev /mnt/dev
mount -o bind /sys /mnt/sys
mount -t proc /proc /mnt/proc
cp /proc/mounts /mnt/etc/mtab
chroot /mnt /bin/bash
grub-install /dev/sda
grub-install /dev/sdb
grub-install --recheck /dev/sda
grub-install --recheck /dev/sdb
mkdir /run/lock
cp /proc/mounts /etc/mtab
update-grub
Nach einem Neustart sollte das System nun wieder sauber starten. Falls das System noch immer nicht sauber startet, kontaktieren Sie mich gerne!
Neueste Kommentare