Dienstag, Juli 14, 2026

Netbox - Erstellen von Geräten (Devices) und Zuordnung von IP Adressen

Netbox sagt über sich selbst es könne als eine sogenannte “Single Source of Truth” fungieren. Man kann Netbox in diesem Kontext als Dokumentationswerkzeug für Geräte mit irgendeiner Art von Anschluss verstehen. Idealerweise steht dabei in Netbox die “Wahrheit” geschrieben, beispielsweise über das lokale Netzwerk und diese “Wahrheit” wird immer entsprechend an die verantworlichen Geräte/Dienste (z.B. Technitium) ausgerollt. Man kann so beispielsweise das gesamte Netzwerk in aller Ruhe vorab in Netbox planen und muss die so geplante Topologie dann nur noch an die verantwortlichen Dienste (DHCP, DNS usw.) ausrollen. Ab einer gewissen Komplexität und Größe macht so ein Vorgehen auch absolut Sinn. Dabei geht Netbox aber weit über bloße Netzwerkkonnektivität auf IP Ebene hinaus. Die Detailtiefe reicht bis zur konkreten Aderanzahl der Kabel und wenn man will sogar deren Farbe und Länge. Wie tief man gehen will kann man selbst entscheiden, passionierte Hobbybuchhalter können sich jedenfalls freuen…

Bildschirmfoto_20260714_164419.png

Netbox prüft die eingetragenen Werte dabei stets auf Plausibilität, eine IP kann bei Netbox beispielsweise nicht doppelt vergeben werden.
Was die Sache dabei aber noch wesentlich interessanter macht, ist der Umstand, dass sich Netbox via API abfragen lässt und die Daten wahlweise als CSV oder JSON (soweit ich bisher weiß) geliefert werden. Solche Abfragen kann man via Plugin dann mit Ansible Playbooks verknüpfen. Man kann aber auch externe Daten via Ansible in Netbox bringen, womit einer Automatisierung vieler Aufgaben fast keine Grenzen mehr gesetzt sind.
Es gibt z.B. bei Youtube bereits zahlreiche gute Anleitungen, die zeigen wie man in Netbox Geräte einrichtet und an selbige eine oder mehrere IP Adressen vergibt. Ich werde nur beschreiben, welche Punkte ich selbst bei Netbox verwende (die wenigsten brauchen vermutlich die volle Detailtiefe) und diesen Part auch recht kurz halten.
Bei Netbox muss man zunächst die eigene Organisation definieren. Hier ist die oberste hierarchische Ebene die Region. Wenn man ein oder mehrere VPS in einem US Rechenzentrum stehen hat, würde es bereits Sinn machen hier zwischen Deutschland und USA eine Unterscheidung zu machen. Die nächste Ebene sind für mich Standorte, hier habe ich in D aktuell zwei. Die Lokationen sind in meinem Fall die konkreten Räume an den beiden Standorten. Wenn man sich in der Hierarchie von oben nach unten durcharbeitet, hat man in der nächsten Ebenen meist die notwendigen Dinge in den Dropdown Menüs zur Auswahl. Sollte ein nowendiges (die mit *) Dropdown Menü keine Auswahl bieten, so muss man zunächst die entsprechenden Auswahlmöglichkeiten eine Ebene höher anlegen. Man braucht sich wegen den anderen Werten absolut keinen Stress machen, alles lässt sich natürlich nachträglich ändern und die Änderungen werden rekursiv überallhin übernommen.
Ähnlich verhält es sich beim Anlegen neuer Geräte. Zunächst braucht man einen Hersteller (Z.B. Apple), als nächstes braucht man einen Gerätetyp (z.B. Mac Mini M1) und eine passende Geräterolle. Geräterolle ist zwingend vorgeschrieben, da die Vorauswahl scheinbar nicht passt, habe ich zwei neue Geräterollen in bestem Denglish als “Mobile User Endgerät” (Wifi) und “Static User Endgerät” (LAN Kabel) angelegt. (Wird sich vermutlich noch zeigen, ob das so richtig/sinnvoll ist) Erst nach diesen Vorarbeiten konnte ich ein neues physisches Gerät anlegen. (Beispiel)

Bildschirmfoto_20260714_170335.png

Das neue Gerät hat mehrere Schnittstellen u.a. Wifi, LAN, USB, Bluetooth usw., in dem konkreten Beispiel gehe ich nur auf die LAN Schnittstellen ein, weitere Schnittstellen kann man bedarfsweise jederzeit auch noch nachträglich anlegen. Die neue Schnittstelle nenne ich schlicht LAN. Es kann bei den Schnittstellen durchaus mehrere namensgleiche Schnittstellen geben, unterschieden werden solche Schnittstellen dann anhand des zugeordneten physischen Gerätes und der ebenfalls zugeordneten MAC Adresse der jeweiligen Schnittstelle. Die MAC Adresse(n) bestimmter Geräte lassen sich zwar ändern (LXCs, VMs, Handies als Anti Tracking Maßnahme usw.) und sind vermutlich deswegen kein “Netbox Pflichtfeld”, ich nutze aber fast ausschließlich feste MAC Adressen und daher ist die MAC Adresse bei der Schnittstelle für mich persönlich ebenfalls ein “Pflichtfeld”. Ausserdem benötige ich die MAC Adresse später, wenn ich die IP Adressvergabe über Ansible/Netbox steuern will.

Bildschirmfoto_20260714_172818.png

Zu guter Letzt kann man über den Punkt IPAM nun beim Unterpunkt IP Adressen eine neue IP Adresse anlegen (CIDR Notation ist Pflicht) und diese mit der soeben erstellten Schnittstelle verknüpfen.

Bildschirmfoto_20260714_172955.png

Man kann einer Schnittstelle auch mehrere IP Adressen zuordnen, das benötigt man beispielsweise, wenn man auf dieser Schnittstelle zusätzlich ein VPN mit eigener IP nutzt o.ä.

Zentrale Verwaltung und Dokumentation der Netzwerkinfrastruktur mit Netbox und Ansible (TBC…)

Im Laufe der letzten Jahre ist mein “IT Fuhrpark” erheblich angewachsen. Inzwischen werkeln an zwei Standorten, die miteinander via Tailscale verbunden sind, 4 PVE-Instanzen mit knapp 40 LXCs und diversen VMs in meinen beiden Subnetzen. Eventuell kommt Ende des Jahres sogar noch ein weiteres Subnetz mit zusätzlichen physischen und virtuellen Geräten hinzu.
Aktuell nutze ich zur Dokumentation meiner Netzwerktopologie ein lokales Wiki mit diversen Tabellen, was sehr unübersichtlich ist und wegen dem rein deklarativen Charakter auch fehleranfällig. Ich musste also eine zentrale Lösung finden, die zum einen meine Netzwerktopologie besser dokumentiert/abbildet und idealerweise gleichzeitig diese Topologie auf logische Fehler prüft. Tatsächlich gibt es so etwas bereits… 😃 s. u.
Ein großer Teil der Verwaltung der PVE- und Proxmox-Backup-Server-(PBS)-Instanzen lässt sich mit dem Proxmox Data Manager konsolidieren. Die IP-Adressen-Verwaltung (IPAM) und Pflege der beiden Technitium-DNS-&-DHCP-Server ist jedoch bei so vielen physischen und virtuellen Geräten inzwischen in richtige Arbeit ausgeartet, und bei einer Fehlkonfiguration (z. B. IP versehentlich doppelt vergeben) warnt einen Technitium nicht wirklich. Man kann zwar via Ansible die Technitium-Server mit den PVE-Instanzen „zusammenbringen“, aber das ist nicht unbedingt intuitiv, und dokumentieren muss man es dann trotzdem noch irgendwo.
Nach entsprechender Recherche bin ich schließlich bei dem Duo Netbox/Ansible gelandet. Ich teste derzeit beide Tools im Zusammenspiel und weiß bereits, dass man damit sogar noch wesentlich mehr tun kann, als nur IPAM und DNS zentral zu steuern. Ich werde daher den beiden Tools demnächst diverse Beiträge widmen, um die Einrichtung und die Möglichkeiten zu dokumentieren. Da ich dabei vermutlich Fehler machen werde, sollte man wie immer bei meinen Anleitungen etwas auf der Hut sein. Für Hinweise bei Fehlern meinerseits bin ich wie immer sehr dankbar.
Netbox und Ansible gibt es erfreulicherweise bei den community-scripts.org (ehemals Proxmox Helper Scripts). Ansible ist dabei Teil des Pakets Semaphore UI, einer praktischen GUI für Ansible.
TBC…

Dienstag, Juli 7, 2026

NUT Server mit Watchdog Script auf PVE

Nachtrag 22.07.26: nut-watchdog Script gefixt, ich hatte ein “/” vergessen und noch etwas ergänzt. Ich lade alle Scripte in Zukunft bei Github hoch. Man findet die aktuellste Version hier

Ich habe für diesen Beitrag teilweise einem älteren Beitrag aus dem alten Discordchannel gefleddert. Daher liest es sich evtl etwas seltsam, entscheidend ist jedoch der Inhalt und die Lösung am Ende.

Hintergrund war, dass der NUT Server, ohne erkennbares Muster, immer wieder die USB Verbindung zur USV verloren hatte. Leider hatte ich den NUT Dienst selbst bisher nicht auf durchgehende Funktionstüchtigkeit überwacht….

Es kam in den PVE Logs diese Fehlermeldung

usbhid-ups[1558]: libusb1: Could not open any HID devices: insufficient permissions on everything

die sich fortlaufend wiederholt. Interessanterweise ließ sich das Problem mit einem simplen

systemctl restart nut-driver@usv-giesing.service

beheben. Der Fehler wurde ein paar Mal in ähnlicher Form im Proxmoxforum berichtet. Er scheint spontan gekommen und wieder verschwunden zu sein. Evtl ist eines der Kernelupdates schuld, es hat ein Jahr ohne Probleme funktioniert und bereits einen Stromausfall erfolgreich abgefangen.

Jemand im Proxmoxforum hatte den entscheidenden Hinweis:

@elvito das insufficient permissions on everything ist meist gar kein Rechteproblem, sondern ein USB-Reenumerations-Ding. Die USV meldet sich (oft nach nem Glitch am USB) mit neuer Bus-/Device-Nummer wieder an, der usbhid-ups hängt aber noch am alten Handle und kommt nicht von selbst zurück. Ein Restart vom nut-driver hilft da sofort. Manchmal kann man den Treiber per Vendor:Product-ID statt port=auto binden, aber ganz weg kriegt man das nicht immer.

Ich hatte zu Beginn der Probleme mit der USV, die Software Nutwatch in einer VM installiert. Es hat einen gewissen Charme die NUT/USV Überwachung in einer Backup- und Clonebaren VM zu haben, zum Preis des anfallenden Ressourcenverbrauchs. Das hat gut funktioniert, wer Nutwatch auch als NUT Server einsetzen will, sollte unbedingt einen API Key setzen, sonst könnte diese VM zu einem hochgefährlichen Angriffsvektor werden. Den Schlüssel kann man zB mit

openssl rand -base64 32

in einer Shell erzeugen und hier eintragen –> /etc/nutwatch/nutwatch.env danach das obligatorische

systemctl daemon-reload
systemctl restart nutwatch

Ich habe im weiteren Verlauf aber eine, zumindest aus meiner Sicht, bessere/sicherere Lösung für das Problem gefunden.

Das Paket nut muss auf PVE installiert werden, falls noch nicht bereits geschehen.

apt install nut

Zunächst habe ich sicher gestellt dass die systemd Dienste nut-monitor.service und nut-server.service bei Hängern oder Abstürzen neu gestartet werden. Das geht einfach mit einem override und somit mit systemd Bordmitteln:

systemctl edit nut-monitor.service

hier muss man an der richtigen Stelle folgendes eintragen

### Editing /etc/systemd/system/nut-monitor.service.d/override.conf
### Anything between here and the comment below will become the contents of the drop-in file
[Unit]
StartLimitIntervalSec=0
[Service]
Restart=on-failure
RestartSec=5s
### Edits below this comment will be discarded

genau das Gleiche auch noch bei

systemctl edit nut-server.service

und

### Editing /etc/systemd/system/nut-server.service.d/override.conf
### Anything between here and the comment below will become the contents of the drop-in file
[Unit]
StartLimitIntervalSec=0
[Service]
Restart=on-failure
RestartSec=5s
### Edits below this comment will be discarded

und systemd bekanntgeben sowie die beiden Dienste mit den overrides neu starten

systemctl daemon-reload
systemctl restart nut-monitor nut-server

man sollte den aktiven override jetzt als Drop-In im Status beider Dienste sehen

root@pve03:~# systemctl status nut-server
● nut-server.service - Network UPS Tools - power devices information server
     Loaded: loaded (/usr/lib/systemd/system/nut-server.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/nut-server.service.d
             └─override.conf
     Active: active (running) since Wed 2026-07-08 10:19:44 CEST; 2h 27min ago

Jetzt noch ein Script anlegen, das den NUT Driver überwacht und bei Bedarf neu startet. Bei dem Script wird eine Nachricht, je nach Ereignis, per sendmail an root geschickt. Das PVE Notification System fängt solche Nachrichten ab und sendet sie an das eingestellte Ziel (meine Email Adresse in diesem Fall) weiter. Das versenden solcher Emails kann man zB mit

echo "Testinhalt" | sendmail root

testen. Nun das Script anlegen mit dem der NUT Driver überwacht werden soll, dies braucht leider ein bisschen mehr Logik.

nano /root/watchdog.sh

mit folgendem Inhalt (hier gehts zur aktuellen Version bei Github

#!/bin/bash
#
# /root/nut-watchdog.sh
set -euo pipefail
UPSNAME="usv-giesing"
HOST="localhost"
DRIVER_SERVICE="nut-driver@${UPSNAME}.service"
TIMEOUT_SEC=5
LOCKFILE="/var/run/nut-watchdog.lock"
STATEFILE="/var/run/nut-watchdog.laststart"
STATUSFILE="/var/run/nut-watchdog.status"
COOLDOWN_SEC=300
exec 9>"$LOCKFILE"
flock -n 9 || exit 0
log() {
    logger -t nut-watchdog "$1"
}
notify_pve() {
    local subject="$1"
    local body="$2"
    {
        echo "To: root"
        echo "Subject: ${subject}"
        echo
        echo "${body}"
    } | /usr/sbin/sendmail -t
}
last_status="ok"
[ -f "$STATUSFILE" ] && last_status=$(cat "$STATUSFILE") || true
mark_ok() {
    if [ "$last_status" = "fail" ]; then
        log "INFO: RECOVERY - ${UPSNAME}@${HOST} ist wieder erreichbar"
        notify_pve "NUT Watchdog: ${UPSNAME} auf $(hostname) wieder erreichbar" 
            "upsc kann ${UPSNAME}@${HOST} wieder erfolgreich abfragen. Problem ist behoben."
    fi
    echo "ok" > "$STATUSFILE"
}
mark_fail() {
    echo "fail" > "$STATUSFILE"
}
# Erster Check
if timeout "$TIMEOUT_SEC" upsc "${UPSNAME}@${HOST}" ups.status >/dev/null 2>&1; then
    mark_ok
    exit 0
fi
log "WARN: upsc konnte ${UPSNAME}@${HOST} nicht abfragen - zweiter Versuch in 5s"
sleep 5
# Zweiter Check
if timeout "$TIMEOUT_SEC" upsc "${UPSNAME}@${HOST}" ups.status >/dev/null 2>&1; then
    log "INFO: zweiter Versuch erfolgreich, kein Neustart nötig"
    mark_ok
    exit 0
fi
mark_fail
now=$(date +%s)
last=0
[ -f "$STATEFILE" ] && last=$(cat "$STATEFILE") || true
if [ $((now - last)) -lt "$COOLDOWN_SEC" ]; then
    log "ERROR: ${UPSNAME} weiterhin nicht erreichbar, Cooldown aktiv - kein erneuter Neustart"
    notify_pve "NUT Watchdog: ${UPSNAME} auf $(hostname) weiterhin down" 
        "Der Treiber ${DRIVER_SERVICE} antwortet seit dem letzten Neustart-Versuch weiterhin nicht. Cooldown aktiv, manuelle Prüfung nötig."
    exit 1
fi
log "ERROR: ${UPSNAME} antwortet nicht, starte ${DRIVER_SERVICE} neu"
systemctl restart "$DRIVER_SERVICE"
echo "$now" > "$STATEFILE"
notify_pve "NUT Watchdog: ${UPSNAME} auf $(hostname) neu gestartet" 
    "upsc konnte ${UPSNAME}@${HOST} nicht abfragen, ${DRIVER_SERVICE} wurde automatisch neu gestartet."

Man muss bei dem Script lediglich der Wert für UPSNAME anpassen. Das Script wird bei mir als cronjob alle 2 Minuten ausgeführt. Man trägt dazu einfach das Script in der crontab ein. Der NUT Driver wird nun, zumindest bei mir, zuverlässig neu gestartet. Aktuell verliert PVE ca. 2-3x/Tag die Verbindung. Ich bekomme aber nun endlich mit, wann das immer passiert und finde evtl. so raus, womit das zusammenhängt.

Freitag, Juli 3, 2026

Flatpress Anpassungen: HSTS für Subdomains abschalten

Das neue Blog hat mir auch gleich ein erstes Problem beschert 😃 Ich nutze traefik um einige Dienste (z.B. immich und navidrome) unter einer leicht zu merkenden Adresse via Tailscale verfügbar zu machen. Dazu habe ich bereits vor Längerem traefik zusammen mit Tailscale in einem LXC installiert. Bei All-inkl. habe ich unter der Domain elvito.de einen zusätzlichen DNS a Record gesetzt (*.ts.elvito.de), der auf die Tailscale IP des LXC mit traefik zeigt. In traefik kann ich nun je nach vorangestelltem Namen den Netzwerkverkehr an die Dienste im LAN weiterleiten inkl. Loadbalancing etc. Ziemlich praktisch bisher und man kann das ganz leicht beliebig skalieren.

Seit heute nutze ich die Doimain nun auch für dieses Blog und auf einmal waren die traefik Dienste nicht mehr über den Browser erreichbar. Ich habe für den Blog natürlich SSL aktiviert und habe hier das Problem vermutet, traefik lief bisher mit http und das soll nach Möglichkeit auch so bleiben. Eine kurze Recherche hat gezeigt, dass in einem Flatpress Plugin (FlatPress Protect), welches zur Absicherung der Seite dient, das Problem lokalisiert ist.
Es muss nur eine Zeile in der /fp-plugins/fpprotect/plugin.fpprotect.php angepasst werden:

Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"

muss zu

Header always set Strict-Transport-Security "max-age=15552000"

geändert werden, damit Flatpress im Browser für *.ts.elvito.de nicht ebenfalls https zu erzwingen versucht. Die Sicherheit des Blogs wird dadurch nicht kompromitiert und auf/über die Domain läuft sonst nichts anderes.

Bei Vivaldi musste ich noch die Domain Security Policy löschen, man erreicht diese Einstellungsmöglichkeit bei Vivaldi über die Adresse vivaldi:net-internals/#hsts. Bei allen chromebasierten Browsern wäre auch chrome:net-internals/#hsts möglich.

Passt, nun sind Navidrome & Co. auch wieder über den Browser unter http erreichbar.

Bildschirmfoto_20260703_200923-1.png

Umzug auf ein Blog

Hallo zusammen,
ich habe bisher einen kleinen Dokumentationsfundus zu FOSS und im Speziellen zu Proxmox auf diversen Ugreen-NAS-Geräten aufgebaut. Ich habe bisher einen Discord-Server mit Tagebuchcharakter dazu genutzt. Ich schaue oft in den Channels nach, wie ich gewisse Dinge eingerichtet habe, da ich sowas nach einer erfolgreichen Einrichtung schnell wieder vergesse. Bei Discord wird es nun leider immer unübersichtlicher, und es gibt diverse Limitierungen (z. B. maximale Nachrichtenlänge, schlechte Verlinkungsmöglichkeiten zwischen den Beiträgen usw.). Außerdem ist der Umgang mit den Nutzerdaten bei Discord eigentlich vollkommen inakzeptabel, von daher habe ich schon länger überlegt, auf einen (selbstgehosteten) Blog umzuziehen.
Der Blog dient dabei primär meiner persönlichen Gedächtnisstütze, und ich mache ihn öffentlich, damit das eine oder andere evtl. irgendjemandem ebenfalls weiterhilft. Ich mache IT nicht beruflich, bin aber seit meinem ersten C64 begeistert dabei. Manche Dinge löse ich vermutlich eher unkonventionell, und ich bin ja – wie schon gesagt – kein Profi, von daher sind die Anleitungen immer mit Vorsicht zu genießen. Über Verbesserungshinweise freue ich mich immer sehr.
Ich nutze für Softwareprojekte, Analysen und zur Recherche häufig KIs; meine Favoriten sind Mistral (Recherche und datenschutzsensible Dinge) und Anthropic Claude (für Codeanalyse und kleine Programmierprojekte). Im richtigen Leben arbeite ich als Selbstständiger im Gesundheitsbereich und wohne mit meiner Familie in der Nähe von München.
Natürlich möchte ich in meinem ersten Beitrag auch gleich ein paar Funktionen des neuen Blogs testen, daher zeige ich zwei Fotos von meinem „Homelab“ in der Waschküche.

signal-2026-07-03-141630.jpeg
signal-2026-07-03-141626.jpeg

Ich habe zwei Geräte mit PVE (Proxmox Virtual Environment): einmal ein refurbished ThinkCentre mit Intel i7-7700T und 32 GB RAM sowie ein Ugreen DXP 8800 Plus. Das Ugreen ist aktuell mit 64 GB RAM und 2×1 TB SSD ZFS Mirror für VMs und LXCs und 6×6 TB HDDs bestückt. Die beiden Controller, an denen die HDDs hängen, werden per PCI-Passthrough an eine TrueNAS-VM durchgereicht.
Aktuell laufen auf beiden Geräten insgesamt 29 LXCs und 2 VMs. Auf dem zweiten Foto sieht man meinen Router, ein OpenWRT One.
Für meine Computeraktivitäten nutze ich einen Desktop-PC mit wassergekühlter Nvidia GTX 3080 12 GB DDRAM und einem AMD Ryzen 9 7900X als CPU. Als Laptops nutze ich einen Framework 13” mit 32 GB RAM und dem AMD Ryzen 5 7640U-Board und dem ausgezeichneten 2,8k-Display. Auf beiden Geräten läuft als Betriebssystem Arch Linux. Für die Arbeit nutze ich ein MacBook Air M2.
Ach ja, ich tracke natürlich niemanden, der hier liest (zumindest nicht wissentlich), und schicke auch alle Bots, die vorbeikommen, in die Wüste (soweit ich das technisch kann/hinkriege). Das Blog ist aktuell bei All-inkl, also in Deutschland gehostet. Meine Datenschutzerklärung findet ihr hier. Ich schalte weder Werbung, noch nutze ich Affiliatelinks auf dieser Seite. Ich habe keinen Account bei Patreon o. ä. und ich akzeptiere keine Spenden. Dies ist also ein rein privates Blog, in dem andere einfach mitlesen können. Solche Details werden ja leider immer wichtiger.