HomelabNerds

HOME LAB · SELFHOSTING · NETZWERK

Schlagwort: Homelab

  • Uptime Kuma + Status Pages: Monitoring intern und extern trennen

    Uptime Kuma + Status Pages: Monitoring intern und extern trennen

    Schwierigkeit: Mittel · Dauer: 35–65 Min · Ziel: Uptime Kuma + Status Pages: Monitoring intern und extern trennen

    Kurzproblem und Zielbild

    In vielen Homelabs funktioniert die Erstinstallation, aber der Dauerbetrieb wird schnell unübersichtlich. Dieses Tutorial zeigt einen reproduzierbaren Ablauf für Uptime Kuma + Status Pages mit Fokus auf Stabilität, klare Checks und einfache Fehlerbehebung.

    Ziel ist ein Setup, das nicht nur heute läuft, sondern auch nach Updates und Änderungen beherrschbar bleibt.

    Voraussetzungen

    • Aktuelles Debian/Ubuntu oder kompatible Appliance
    • Administrative Rechte und Wartungsfenster
    • Backup- oder Snapshot-Möglichkeit vor Änderungen

    Schnellstart (funktionierende Basis)

    # Basisprüfung
hostnamectl
ip a
# Dienste prüfen
systemctl --failed
# Logs kurz prüfen
journalctl -p 3 -xb --no-pager | tail -n 30

    Was macht das? Du prüfst erst den Grundzustand und vermeidest, dass Altfehler in neue Änderungen hineinwirken.

    Schritt-für-Schritt Umsetzung

    1) Ausgangszustand dokumentieren

    date -Iseconds
uname -a
# versions/relevante configs sichern

    Erklärung: Mit einer kurzen Bestandsaufnahme lassen sich spätere Fehler schneller eingrenzen.

    2) Kernkonfiguration sauber setzen

    docker run -d --name uptime-kuma -p 3001:3001 -v uptime-kuma:/app/data --restart unless-stopped louislam/uptime-kuma:1
# In der UI: Monitor-Gruppen internal/external trennen
# Status Page nur mit externen Checks veröffentlichen

    Erklärung: Änderungen gezielt umsetzen, danach direkt den Dienst-/Funktionszustand prüfen.

    3) Dienst kontrolliert neu laden

    sudo systemctl daemon-reload
sudo systemctl restart 
sudo systemctl status  --no-pager

    4) Betriebsgrenzen testen

    docker ps --filter name=uptime-kuma
docker logs --tail 100 uptime-kuma
curl -I http://127.0.0.1:3001

    Validierung / Checks

    docker inspect uptime-kuma --format "{{json .HostConfig.RestartPolicy}}"
# UI-Check: Nur externe Gruppe auf Status Page sichtbar

    Troubleshooting

    Konfiguration wird nicht übernommen

    Ursache: Syntax-, Reload- oder Parameterfehler.

    # Monitor-Visibility und Public Group in Uptime-Kuma prüfen
# interne Monitore auf private setzen

    Dienst läuft, Funktion aber fehlerhaft

    Ursache: Abhängigkeiten, Routing oder Berechtigungen sind inkonsistent.

    dig your-service.example.com
docker logs --tail 200 uptime-kuma

    Fazit

    Mit einem klaren Ablauf für Uptime Kuma + Status Pages reduzierst du Ausfälle und erhöhst die Wartbarkeit deutlich. Der wichtigste Hebel ist die Kombination aus kleiner Änderung, sofortigem Check und dokumentiertem Ergebnis.

    Nächster Schritt: den Ablauf als monatliche Betriebsroutine einplanen und regelmäßig gegen echte Störfälle testen.

    Quellen

  • Uptime Kuma Alerts sinnvoll aufsetzen: weniger Lärm, bessere Signale

    Uptime Kuma Alerts sinnvoll aufsetzen: weniger Lärm, bessere Signale

    Schwierigkeit: Leicht · Dauer: 30–50 Min · Ziel: Uptime-Kuma-Checks und Benachrichtigungen so konfigurieren, dass echte Störungen schnell sichtbar werden.

    Kurzproblem und Zielbild

    Zu aggressive Monitoring-Defaults erzeugen Alarmrauschen. Ziel ist ein stabiles Signal-Rausch-Verhältnis mit klaren Intervallen, Timeouts und sauberen Notification-Profilen.

    Voraussetzungen

    • Laufende Uptime-Kuma-Instanz
    • Mindestens ein Notification-Channel (Mail/Discord/Telegram)
    • Liste kritischer Dienste

    Schnellstart (funktionierende Basis)

    docker ps | grep uptime-kuma
# UI öffnen und 3 kritische Monitore anlegen
# Intervall 60s, Retry 2, Timeout 16s

    Schritt-für-Schritt Umsetzung

    1) Monitore nach Kritikalität gruppieren

    # Kritisch: Auth, Reverse Proxy, DNS
# Wichtig: Medien/Tools
# Nice-to-have: Nebenservices

    2) Timeouts/Retry je Diensttyp

    # HTTP intern: timeout 10-16s
# Extern über WAN: timeout 20-30s
# retry sparsam nutzen, sonst Alarmflut

    3) Wartungsfenster definieren

    # Geplante Updates als Maintenance in Kuma eintragen

    4) Alert-Routing trennen

    # Kritisch -> sofort Push
# Nicht-kritisch -> gesammelt / zeitversetzt

    Validierung / Checks

    # 1) Kuma-Container und Health prüfen
docker ps --filter name=uptime-kuma
curl -fsS http://127.0.0.1:3001 >/dev/null && echo "Kuma UI erreichbar"

# 2) Gezielten Ausfall simulieren (Beispielservice)
docker stop reverse-proxy
sleep 90

# 3) Prüfen: genau 1 Alert + Recovery nach Wiederanlauf
docker start reverse-proxy
sleep 90

# 4) Kuma-Logs auf Flapping/Fehler prüfen
docker logs --since 10m uptime-kuma | tail -n 120

    Troubleshooting

    Zu viele Fehlalarme

    # DNS/Latenz prüfen
dig +short example.local
ping -c 4 example.local

# Host-Antwortzeit testen
curl -o /dev/null -s -w "HTTP:%{http_code} TIME:%{time_total}\n" https://example.local

# Danach in Kuma: Timeout +5s, Retry -1

    Recovery-Meldung fehlt

    # Notification-Test in Kuma auslösen
# Settings -> Notifications -> Test

# Container-Logs nach Sendefehlern durchsuchen
docker logs --since 30m uptime-kuma | grep -Ei "notify|telegram|discord|smtp|error" | tail -n 80

    Fazit

    Gutes Monitoring ist nicht „mehr Monitore“, sondern bessere Priorisierung. Nächster Schritt: monatlich die noisiesten Checks identifizieren und nachschärfen.

    Quellen

  • OPNsense Regeln sauber aufbauen: Segmentierung, NAT und Wartbarkeit

    OPNsense Regeln sauber aufbauen: Segmentierung, NAT und Wartbarkeit

    Schwierigkeit: Mittel · Dauer: 45–75 Min · Ziel: OPNsense-Regeln konsistent aufbauen, damit Netzwerkzugriffe nachvollziehbar und sicher bleiben.

    Kurzproblem und Zielbild

    Viele OPNsense-Setups wachsen mit Einzelregeln und verlieren schnell die Übersicht. Ziel ist ein klarer, wiederholbarer Regelaufbau mit Segmentierung, nachvollziehbarem NAT und sauberen Checks.

    Voraussetzungen

    • OPNsense mit administrativem Zugriff
    • Definierte Netze/VLANs
    • Wartungsfenster und Backup vor Regeländerungen

    Schnellstart (funktionierende Basis)

    cp /conf/config.xml /conf/config.xml.bak.$(date +%F-%H%M)
pfctl -sr
configctl filter status

    Schritt-für-Schritt Umsetzung

    1) Regelmodell festlegen

    # Prinzip: erst erlaubte Flows definieren, dann default deny
# Beispielzonen: LAN, SERVER, IOT, MGMT

    2) Aliases für Dienste/Netze

    # in OPNsense GUI: Firewall > Aliases
# z.B. RFC1918_INTERNAL, DNS_SERVERS, MGMT_HOSTS

    3) NAT konsistent halten

    # Outbound NAT auf Hybrid/Manual nur wenn nötig
# Portforwards nur mit zugehöriger Filterregel

    4) Logging für kritische Regeln

    # Block-/Allow-Regeln für sensible Segmente mit Logging aktivieren

    Validierung / Checks

    pfctl -sr
pfctl -sn
configctl filter status
clog -f /var/log/filter/filter.log

    Troubleshooting

    Traffic bricht nach Regeländerung

    pfctl -sr | less
# Reihenfolge prüfen, pass/quick beachten

    Portforward greift nicht

    pfctl -sn
# zugehörige Filterregel und Zielhost prüfen

    Fazit

    Mit Alias-basiertem Regelwerk und klarer Segmentierung bleibt OPNsense langfristig wartbar. Nächster Schritt: monatlicher Regel-Review mit Cleanup veralteter Ausnahmen.

    Quellen

  • Proxmox Backup richtig prüfen: Restore-Tests statt Backup-Illusion

    Proxmox Backup richtig prüfen: Restore-Tests statt Backup-Illusion

    Schwierigkeit: Mittel · Dauer: 40–70 Min · Ziel: Proxmox-Backups regelmäßig verifizieren und Restore-Pfade praktisch testen.

    Kurzproblem und Zielbild

    Backups ohne Restore-Test geben trügerische Sicherheit. Ziel ist ein kurzer, reproduzierbarer Prüfprozess mit klaren Kriterien: Backup vorhanden, konsistent, in vertretbarer Zeit wiederherstellbar.

    Voraussetzungen

    • Proxmox VE + Backup-Storage/PBS
    • Mindestens eine VM/CT für Test-Restore
    • Wartungsfenster

    Schnellstart (funktionierende Basis)

    vzdump --all 1 --mode snapshot --compress zstd --storage <STORAGE>
pvesm status
qm list
pct list

    Schritt-für-Schritt Umsetzung

    1) Backup-Jobs und Logs prüfen

    grep -R "vzdump" /etc/pve/jobs.cfg
journalctl -u pvedaemon -n 200 --no-pager

    2) Test-VM wiederherstellen

    qmrestore /path/to/backup.vma.zst 9001 --storage <TARGET>
qm start 9001

    3) Funktions-Check

    qm status 9001
# optional: service checks in restored VM

    4) Ergebnis dokumentieren

    echo "$(date -Iseconds) restore test OK" >> /root/restore-tests.log

    Validierung / Checks

    pvesm status
qm status 9001
ls -lh /var/log/ | head

    Troubleshooting

    Restore bricht mit Storage-Fehler ab

    pvesm status
# Storage online/space prüfen

    VM bootet nach Restore nicht

    qm config 9001
qm terminal 9001

    Fazit

    Restore-Tests machen aus Backups einen verlässlichen Betriebsprozess. Nächster Schritt: monatlichen Restore-Drill fix im Kalender verankern.

    Quellen