HomelabNerds

HOME LAB · SELFHOSTING · NETZWERK

Kategorie: Tutorials

Schritt-für-Schritt Anleitungen für Homelab und Selfhosting.

CrowdSec auf Debian produktiv betreiben: Collections, Bouncer, saubere Regeln
Schwierigkeit: Mittel · Dauer: 35–65 Min · Ziel: CrowdSec auf Debian produktiv betreiben: Collections, Bouncer, saubere Regeln

Kurzproblem und Zielbild
In vielen Homelabs funktioniert die Erstinstallation, aber der Dauerbetrieb wird schnell unübersichtlich. Dieses Tutorial zeigt einen reproduzierbaren Ablauf für CrowdSec auf Debian produktiv betreiben 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
```
# hier die zentrale CrowdSec auf Debian produktiv betreiben-Konfiguration umsetzen
# Konfigdatei bearbeiten, nur notwendige Werte ändern
```
Erklärung: Ändere nur das Nötigste und halte die Konfiguration nachvollziehbar.

3) Dienst kontrolliert neu laden
```
sudo systemctl daemon-reload
sudo systemctl restart 
sudo systemctl status  --no-pager
```
4) Betriebsgrenzen testen
```
# Healthcheck/Endpoint prüfen
# Logs und Fehlerraten beobachten
```
Validierung / Checks
```
systemctl status  --no-pager
journalctl -u  -n 150 --no-pager
# funktionaler End-to-End Check
```
Troubleshooting
Konfiguration wird nicht übernommen
Ursache: Tippfehler oder veralteter Service-Reload.
```
sudo  --check
sudo systemctl daemon-reload
sudo systemctl restart 
```
Dienst läuft, Funktion aber fehlerhaft
Ursache: Abhängigkeit, DNS oder Routing nicht konsistent.
```
dig example.org
ip route
journalctl -u  -n 200 --no-pager
```
Fazit
Mit einem klaren Ablauf für CrowdSec auf Debian produktiv betreiben 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
16.02.2026
Home Assistant Updates ohne Ausfallstress: Compose-Workflow mit Rollback
Schwierigkeit: Mittel · Dauer: 35–60 Min · Ziel: Home-Assistant-Updates reproduzierbar ausrollen und bei Problemen schnell zurückrollen.

Kurzproblem und Zielbild
Home Assistant wächst schnell mit Integrationen. Unkontrollierte Updates führen oft zu Ausfällen oder kaputten Add-ons. Ziel ist ein klarer Update-Workflow mit Backup, Check und Rollback.

Voraussetzungen
- Home Assistant via Docker Compose
- Persistente Config unter ./config
- Backup-Möglichkeit vor Update
Schnellstart (funktionierende Basis)
```
cd ~/stacks/homeassistant
tar -czf backup-ha-$(date +%F-%H%M).tar.gz ./config
docker compose pull
docker compose up -d
```
Schritt-für-Schritt Umsetzung
1) Pre-Update Snapshot
```
tar -czf backup-ha-$(date +%F-%H%M).tar.gz ./config
cp compose.yml backup-compose-$(date +%F-%H%M).yml
```
2) Update kontrolliert ausrollen
```
docker compose pull
docker compose up -d --remove-orphans
docker compose ps
```
3) Kernfunktionen prüfen
```
docker compose logs --tail=180 homeassistant
# Login/UI, Automationen, Integrationen testen
```
4) Rollback bei Fehlern
```
docker compose down
cp backup-compose-YYYY-MM-DD-HHMM.yml compose.yml
# ggf. config-backup zurückspielen
docker compose up -d
```
Validierung / Checks
```
docker compose ps
docker compose logs --tail=200 homeassistant
curl -I http://localhost:8123
```
Troubleshooting
Container startet, UI bleibt unzuverlässig
```
docker compose logs homeassistant --tail=250
# fehlerhafte custom components prüfen
```
Integrationen nach Update fehlerhaft
```
# letzte stabile Version pinnen und erneut deployen
```
Fazit
Mit klarer Update-Routine wird Home Assistant deutlich berechenbarer. Nächster Schritt: festen Wartungstermin + Checkliste pro Update einführen.

Quellen
16.02.2026
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
```
# Testausfall simulieren (Dienst stoppen)
# Prüfen: Alert kommt 1x, Recovery-Message folgt
# Danach Dienst wieder starten
```
Troubleshooting
Zu viele Fehlalarme
```
# Timeout erhöhen, Retry reduzieren, DNS prüfen
```
Recovery-Meldung fehlt
```
# Notification-Integration + Event-Typen prüfen
```
Fazit
Gutes Monitoring ist nicht „mehr Monitore“, sondern bessere Priorisierung. Nächster Schritt: monatlich die noisiesten Checks identifizieren und nachschärfen.

Quellen
16.02.2026
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
16.02.2026
WireGuard Site-to-Site im Homelab: stabile Basis mit systemd und Checks
Schwierigkeit: Mittel · Dauer: 35–55 Min · Ziel: Zwei Netze per WireGuard stabil verbinden und den Betrieb mit systemd absichern.

Kurzproblem und Zielbild
Site-to-Site-Setups sind oft instabil durch fehlende Keepalive-/Routing-Checks. Ziel: stabiler Tunnel mit definierten AllowedIPs, sauberem Autostart und reproduzierbarer Prüfung.

Voraussetzungen
- Zwei Linux-Systeme mit WireGuard
- Öffentlich erreichbarer Endpoint auf mindestens einer Seite
- Firewall-Freigabe UDP 51820
Schnellstart (funktionierende Basis)
```
sudo systemctl enable wg-quick@wg0.service
sudo systemctl start wg-quick@wg0.service
sudo wg show
```
Schritt-für-Schritt Umsetzung

1) Schlüssel erstellen
```
umask 077
wg genkey | tee privatekey | wg pubkey > publickey
```
2) Minimal-Konfig setzen
```
[Interface]
Address = 10.10.10.1/24
PrivateKey = <PRIVATE_KEY>
ListenPort = 51820

[Peer]
PublicKey = <PEER_PUBLIC_KEY>
AllowedIPs = 10.10.10.0/24, 192.168.50.0/24
Endpoint = vpn.example.tld:51820
PersistentKeepalive = 25
```
3) Start + Persistenz
```
sudo systemctl daemon-reload
sudo systemctl enable wg-quick@wg0.service
sudo systemctl restart wg-quick@wg0.service
```
4) Routing/Erreichbarkeit prüfen
```
ip route
ping -c 3 10.10.10.2
wg show
```
Validierung / Checks
```
systemctl status wg-quick@wg0 --no-pager
wg show
journalctl -u wg-quick@wg0 -n 120 --no-pager
```
Troubleshooting
Kein Handshake
```
sudo ss -lunp | grep 51820
sudo wg show
```
Handshake da, aber keine Route
```
ip route
# AllowedIPs/Forwarding prüfen
```
Fazit
Mit klarer Minimal-Konfig + systemd + festen Checks wird Site-to-Site-WireGuard im Homelab deutlich stabiler. Nächster Schritt: Monitoring auf Handshake-Alter und Paketzähler.

Quellen
16.02.2026
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
16.02.2026
Docker Compose Deployments robust machen: Struktur, Healthchecks, Rollback
Schwierigkeit: Mittel · Dauer: 45–60 Min · Ziel: Docker-Compose-Stacks reproduzierbar deployen, validieren und sicher zurückrollen.

Kurzproblem und Zielbild
Viele Compose-Setups funktionieren initial, brechen aber bei Updates oder Neustarts durch fehlende Checks und unsaubere Struktur. Ziel ist ein Ablauf, der auch unter Last stabil bleibt und im Fehlerfall schnell zurückgerollt werden kann.

Voraussetzungen
- Debian/Ubuntu Host mit Docker + Compose Plugin
- Sudo-Zugriff
- Freie Volumes/Backups vor Änderungen
Schnellstart (funktionierende Basis)
```
mkdir -p ~/stacks/app && cd ~/stacks/app
nano compose.yml
docker compose pull
docker compose up -d
docker compose ps
```
Was macht das? Erzeugt einen reproduzierbaren Stack-Ordner, zieht Images und startet den Stack kontrolliert.

Schritt-für-Schritt Umsetzung

1) Struktur und Variablen trennen
```
mkdir -p ~/stacks/app/{config,data,backup}
cp compose.yml compose.yml.bak
nano .env
```
Erklärung: Trennung reduziert Fehler bei Upgrades und vereinfacht Restore.

2) Healthchecks definieren
```
services:
  app:
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 30s
      timeout: 5s
      retries: 5
```
3) Update-Fenster mit Validierung
```
docker compose pull
docker compose up -d --remove-orphans
docker compose ps
docker compose logs --tail=120
```
4) Rollback vorbereiten
```
cp compose.yml backup/compose-$(date +%F-%H%M).yml
# im Fehlerfall:
cp backup/compose-YYYY-MM-DD-HHMM.yml compose.yml
docker compose up -d
```
Validierung / Checks
```
docker compose ps
curl -fsS http://localhost:8080/health
journalctl -u docker -n 120 --no-pager
```
Troubleshooting
Healthcheck bleibt „unhealthy“
Ursache: Falscher Endpoint oder Startdauer zu kurz.
```
docker compose logs app --tail=200
# retries/timeout erhöhen
```
Update startet, Service nicht erreichbar
Ursache: Inkompatibles Image/Config.
```
docker compose down
cp backup/compose-*.yml compose.yml
docker compose up -d
```
Fazit
Mit sauberer Struktur, Healthchecks und Rollback-Plan werden Compose-Deployments deutlich robuster. Nächster Schritt: Monitoring für Containerzustände ergänzen.

Quellen
16.02.2026
WireGuard Autostart mit systemd auf Debian/Ubuntu
Schwierigkeit: Leicht · Dauer: 10–20 Min · Ziel: WireGuard unter Linux via systemd zuverlässig beim Boot starten und sauber prüfen.

Kurzproblem und Zielbild

Viele WireGuard-Setups funktionieren nach manueller Aktivierung, starten aber nach einem Reboot nicht automatisch. Das führt zu Ausfällen bei Remote-Zugriffen oder Routing-Setups im Homelab.

Ziel in diesem Tutorial: Deine bestehende wg0.conf wird als systemd-Service eingebunden, automatisch gestartet und mit klaren Checks verifiziert.

Voraussetzungen
- Linux-Host (Debian/Ubuntu) mit installierten Paketen wireguard und wireguard-tools
- Funktionierende Konfiguration unter /etc/wireguard/wg0.conf
- Sudo-Rechte und Zugriff auf System-Logs
Schnellstart (funktionierende Basis)
```
sudo systemctl enable wg-quick@wg0.service
sudo systemctl daemon-reload
sudo systemctl start wg-quick@wg0.service
sudo systemctl status wg-quick@wg0.service --no-pager
```
Was macht das? Der Dienst wird im Autostart registriert, geladen und sofort gestartet. Danach siehst du direkt, ob wg0 sauber hochkommt.

Schritt-für-Schritt Umsetzung

1) Konfigurationsdatei prüfen
```
sudo ls -l /etc/wireguard/wg0.conf
sudo grep -E '^(\[Interface\]|Address|PrivateKey|ListenPort|\[Peer\]|PublicKey|AllowedIPs|Endpoint|PersistentKeepalive)' /etc/wireguard/wg0.conf
```
Erklärung: Stelle sicher, dass die Datei existiert und zentrale Felder gesetzt sind. Falsche Pfade oder Tippfehler sind die häufigste Ursache für Startprobleme.

2) Service im Autostart aktivieren
```
sudo systemctl enable wg-quick@wg0.service
sudo systemctl daemon-reload
```
Erklärung: enable erstellt die Boot-Verknüpfung. Mit daemon-reload stellst du sicher, dass systemd den aktuellen Stand nutzt.

3) Service starten und Zustand prüfen
```
sudo systemctl start wg-quick@wg0.service
sudo systemctl status wg-quick@wg0.service --no-pager
sudo wg show
ip a show wg0
```
Erklärung: Du prüfst sowohl Service-Status als auch Interface-/Peer-Status. So erkennst du, ob der Tunnel nur „läuft“ oder wirklich aktiv kommuniziert.

4) Reboot-Test (entscheidend)
```
sudo reboot
# nach dem Login
systemctl is-enabled wg-quick@wg0.service
systemctl status wg-quick@wg0.service --no-pager
wg show
```
Erklärung: Erst der Reboot-Test bestätigt den echten Autostart und vermeidet böse Überraschungen bei ungeplanten Neustarts.

Validierung / Checks
```
# 1) Service ist enabled
systemctl is-enabled wg-quick@wg0.service

# 2) Service läuft ohne Fehler
systemctl status wg-quick@wg0.service --no-pager

# 3) WireGuard Interface + Handshake
wg show

# 4) Letzte Logs
journalctl -u wg-quick@wg0 -n 120 --no-pager
```
Troubleshooting

Fehlerbild 1: „Unit wg-quick@wg0.service not found“

Ursache: Paket fehlt oder Service-Name passt nicht zur Config-Datei.
```
sudo apt update
sudo apt install -y wireguard wireguard-tools
ls /etc/wireguard/
# wenn Datei z. B. wg-homelab.conf heißt:
sudo systemctl enable wg-quick@wg-homelab.service
```
Fehlerbild 2: Service startet, aber kein Handshake

Ursache: Endpoint/Firewall/Port oder Routing passt nicht.
```
sudo wg show
sudo ss -lunpt | grep 51820
sudo journalctl -u wg-quick@wg0 -n 200 --no-pager
# ggf. UFW/iptables prüfen
```
Fazit

Mit wg-quick@wg0 im systemd-Autostart wird WireGuard im Homelab deutlich zuverlässiger betrieben – besonders bei Router-/Gateway-Szenarien oder Remote-Administration.

Nächster Schritt: ergänze ein kleines Monitoring (z. B. periodischer Check via Cron/Health-Script), damit Ausfälle früh erkannt werden.

Quellen
16.02.2026