Rebel Home Base: Status Quo

Hier seht ihr als Ergänzung die technischen Eckdaten meines kleinen Homelabs. Diese Seite aktualisiere ich regelmäßig und bringe sie auf den aktuellen Stand. Den Weg dahin findet ihr wie gehabt in den üblichen Blog-Artikeln unter https://www.pandolin.io/tag/rebelhomebase/ beschrieben.

Vision: Eine vollständig souveräne, auf Linux basierende IT-Infrastruktur. „Linux Only“, keine Cloud-Abhängigkeiten für Core-Services, echte Hochverfügbarkeit (HA). Verzicht auf nicht souveräne Hyperscaler-Dienste.

---

Update 01.02.2026
Stand: https://www.pandolin.io/projekt-homebase-exkurs-backup-stage-2/

Update 24.01.2026
Stand: https://www.pandolin.io/project-rebel-homebase-teil-5-es-werde-kubernetes/

Update: 22.01.2026
Stand: https://www.pandolin.io/project-rebel-homebase-teil-4-ntp-gravity-sync/

---

1. Architektur & Philosophie

• Kern-Philosophie: Unabhängigkeit von Hyperscalern (Microsoft/Google/AWS) für Basisdienste soweit möglich.
• Netzwerk-Strategie: Physische Trennung von Control-Plane (DNS/NTP) und Application-Plane (Kubernetes Apps).
• Namenskonvention: Split-Horizon DNS. Die Domain pandolin.online wird intern und extern genutzt, um Zertifikatsmanagement (Let's Encrypt) und Routing zu vereinfachen.

---

2. Netzwerk-Topologie

2.1 Adressierung (IPAM)

Subnetz: 192.168.1.0/24 | Gateway: 192.168.1.1 (UDW)

IP	Hostname	Gerät / Rolle	Erklärung	Kommentar
.1	gateway	Unifi Dream Wall	Router & DHCP Server
.3	dns1	Blade 01 (CM4)	Master DNS/NTP
.4	dns2	Blade 02 (CM4)	Backup DNS/NTP
.5	v-dns	Cluster VIP	Virtuelle IP via Keepalived
.6	switch-core	USW Pro XG 8	10 GbE Backbone
.7	switch-poe	USW flex 2.5G PoE	2.5 GbE PoE
.10	unas	Unifi UNAS2	Backup Target	ersetzt durch .99
.15	k3s-master	Blade 03 (CM4)	Kubernetes Control Plane
.21	k3s-w01	Blade 04 (CM5)	Worker Node (Infanterie)
.22	k3s-w02	Blade 05 (CM5)	Worker Node (Infanterie)
.23	k3s-w03	Blade 06 (CM5)	Worker Node (Infanterie)
.24	k3s-w04	Blade 07 (CM5)	Worker Node (Infanterie)
.99	wintermute	DXP2800	Backup Target Stage 2

2.2 Client-Konfiguration

Der DHCP-Server (UDW) verteilt ausschließlich die VIP .5 als DNS-Server.

• Vorteil: Clients merken nicht, wenn ein Node gewartet wird.
• Ziel: "Echte" Redundanz statt nur "zwei Server im DHCP" (was oft zu Timeouts führt).

---

3. Server Hardware

3.1 Infrastruktur-Cluster (The "Brain")

Für die kritischen Basisdienste (DNS, NTP) werden dedizierte, energiesparende Ressourcen genutzt, getrennt vom späteren Applikations-Cluster.

• Hardware: 3x Raspberry Pi Compute Module 4 (CM4) auf Compute Blades.
• Specs: 8 GB RAM, NVMe Storage.
• OS: Ubuntu Server 24.04 LTS.
• Rolle:
  • Blade 01 (dns1): Primary Pi-hole + Unbound + Chrony.
  • Blade 02 (dns2): Secondary Pi-hole + Unbound + Chrony.
  • Blade 03 (k3s-master): Kubernetes Control Plane (Master).

3.2 Kubernetes Application Cluster (The "Muscle")

Die Arbeitslast (Container, Services) wird von leistungsstärkeren CM5-Modulen getragen.

• Hardware: 4x Raspberry Pi Compute Module 5 (CM5).
• Specs: 8-16 GB RAM, 256 GB NVMe pro Blade (keine SD-Karten!).
• OS: Ubuntu Server 24.04.3 LTS (Noble Numbat).
• Rolle: K3s Worker Nodes für Microservices.

3.3 Storage

• Hostname: wintermute.pandolin.online
• IP-Adresse: 192.168.1.99
• Hardware: Ugreen DXP2800CPU: Intel N100 (x86, 4 Kerne)RAM: 8 GB DDR5Boot-Medium: 32 GB interne eMMC
• Betriebssystem: TrueNAS SCALE (Fangtooth)
• Speicher-Konfiguration (ZFS Pool "tank"):Data VDEV: 2 x 12 TB HDD (Mirror) – Das „Gedächtnis“ für Massendaten.Special VDEV: 2 x 1 TB NVMe (Mirror) – Metadaten & Small Blocks (< 128 KB).
• Besonderheiten: * In-Place Upgrade Pfad von Dragonfish zu Fangtooth zur eMMC-Aktivierung.System-Dataset auf den HDD-Pool ausgelagert zur Schonung der eMMC.Monitoring via nativem Node Exporter (Binärdatei).
• Rolle: Primäres Backup-Ziel (Stage 2) der Homebase, zentraler Daten-Tresor.

3.4 Heavy Lifting

Für ressourcenintensive Workloads, die über die Kapazität der kleinen ARM-meisen basierten Blades hinausgehen, auch als als zentraler Storage-Server für den K3s-Cluster.

Hostname: continuity.pandolin.online
IP-Adresse: 192.168.1.100
Hardware: Minisforum N5 Pro

• CPU: AMD Ryzen AI 9 HX PRO 370 (12 Kerne / 24 Threads)
• RAM: 96 GB DDR5
• Netzwerk: 10 GbE (MTU 9000)

Betriebssystem: Proxmox VE 9.1

Speicher-Konfiguration (Tiered ZFS Storage):

Pool	Konfiguration	Kapazität	Zweck
rpool	1× Samsung 990 Pro 2 TB (Single)	~1.8 TB	Proxmox System
goldpool	2× Samsung 990 Pro 4 TB (Mirror, Partition 1)	~3.3 TB	VMs, K3s Persistent Volumes
datapool	5× WD Red 6 TB (RAIDZ2)	~16 TB	Medien, Backups, Archive

Special VDEV (Turbo für datapool):

• 2× Samsung 990 Pro 4 TB (Mirror, Partition 2, je ~326 GB)
• special_small_blocks=128K – Metadaten und kleine Dateien landen auf NVMe statt HDD.
• Effekt: Echt blitzschnelle Directory-Listings trotz HDD-Backend.

Dienste:

• NFS-Server: Stellt Storage für den gesamten K3s-Cluster bereit (nfs-gold, nfs-bulk, nfs-backup ).
• Node Exporter: Prometheus-Metriken auf Port 9100.

Besonderheiten:

• Alle ZFS-Pools mit autotrim=on für SSD-Langlebigkeit.
• Netzwerk durchgängig mit Jumbo Frames (MTU 9000) konfiguriert.
• Backup Level 1: Lokale ZFS-Snapshots via Sanoid, Replikation zu wintermute via Syncoid (geplant).

Rolle: Zentraler Storage-Server, Virtualisierungshost für Heavy Workloads, NFS-Backend für Kubernetes Persistent Volumes.

---

4. Clients & Workstations

Die Endgeräte der Nutzer.

• Workstation (Desktop):
  • CPU/GPU: AMD Ryzen 9 9950X3D / Radeon RX 9070 XT.
  • OS: Dual Boot (Kubuntu 25.10 / Windows 11 Pro (wegen Fusion 360)).
  • Ziel: Windows asap entfernen.
• Mobile Workstation:
  • Modell: HP zBook G1a.
  • Specs: Ryzen AI Max+ 395, 128GB RAM.
  • OS: Kubuntu 25.10.
• MacBook Pro:
  • Modell: 16 Zoll M4 (macOS).
  • Überlegung: Ersatz durch Framework 13 oder Framework 16.
• Lenovo Laptop
  • Modell T14s Snapdragon, Windows 11 (leider nicht diskutabel/Arbeitgeber)
• Mobile:
  • Google Pixel 10 Pro XL (Android).
  • Google Pixel 9 Pro XL (Testgerät für GrapheneOS).
  • iPhone 15 (leider nicht diskutabel/Arbeitgeber)
  • iPad Pro 13 (auf der Suche nach einer Alternative)
• Peripherie:
  • Dell U4021QW (5K2K Monitor).

---

5. Implementation Guide: High-Availability DNS & NTP Stack

Dies ist der technische Kern der „Rebel Homebase“. Ziel ist eine Ausfallsicherheit, die Enterprise-Niveau erreicht.

5.1 Der Software-Stack

Pro Node läuft folgender Stack:

1. Chrony: Stratum-1/2 NTP Server (Zeitbasis für Logs/Auth).
2. Unbound: Rekursiver DNS-Resolver (Port 5335). Fragt Root-Server oder Quad9 (9.9.9.9) via DoT.
3. Pi-hole: Werbeblocker & DNS-Filter (Port 53). Nutzt lokalen Unbound als Upstream.
4. Keepalived: VRRP-Daemon zur Bereitstellung der VIP 192.168.1.5.
5. Gravity-Sync (v4.0.7): Synchronisiert die Pi-hole-Datenbanken (Blocklisten, Local DNS, CNAMEs) zwischen dns1 (Master) und dns2 (Backup).

5.2 Kritische Konfigurationen & "Lessons Learned"

A) Persistenter Hostname in Ubuntu 24.04 (Cloud-Init Fix)

Ubuntu setzt den Hostnamen bei jedem Reboot zurück, wenn man nur /etc/hosts editiert.

• Lösung: Bearbeiten des Templates /etc/cloud/templates/hosts.debian.tmpl.

B) Pi-hole Reverse DNS Fix (Der "pi.hole" Bug)

Standardmäßig antwortet Pi-hole auf die Frage "Wer ist 192.168.1.3?" mit pi.hole.

• Fix: In /etc/pihole/pihole.toml den Eintrag piholePTR = "HOSTNAMEFQDN" setzen.

C) NTP Konfliktlösung (Chrony vs. Pi-hole)

Pi-hole FTL versucht Port 123 zu binden, was Chrony blockiert.

• Fix: In /etc/pihole/pihole-FTL.conf den Eintrag NTP_SERVER= leer lassen.

D) Keepalived & Unifi ARP Caches (Das Timeout-Problem)

Wenn die VIP schwenkt, behalten Unifi-Gateways oft die alte MAC im ARP-Cache.

• Lösung: Aggressives GARP (Gratuitous ARP) in der keepalived.conf (garp_master_refresh etc.).

E) Firewall/NAT für NTP

Damit Clients NTP-Antworten von der VIP .5 akzeptieren, ist eine SNAT-Regel notwendig:

iptables -t nat -A POSTROUTING -p udp --sport 123 -d 192.168.1.0/24 -j SNAT --to-source 192.168.1.5

F) Gravity-Sync Berechtigungs-Fix

Damit der Sync-User (z. B. axel) die Datenbank validieren kann, sind Gruppenrechte erforderlich.

Lösung: sudo usermod -aG pihole $USER und sudo chmod 664 /etc/pihole/gravity.db.

G) Automatisierung via Systemd-Timer:

In Version 4.0.7 wird kein cron mehr genutzt. Die Automatisierung erfolgt über systemd-timer, was die Zuverlässigkeit erhöht.

Check: systemctl list-timers | grep gravity-sync.

5.3 Health-Check Skript

Keepalived darf nicht nur prüfen, ob der Pi "an" ist, sondern ob DNS antwortet.

• Skript: /usr/local/bin/check_dns.sh führt einen lokalen dig aus.
• NTP-Check: /usr/local/bin/check_ntp.sh stellt sicher, dass die VIP nur auf einem Node bleibt, der auch eine valide Zeitquelle hat.

#!/bin/bash
chronyc tracking > /dev/null 2>&1
exit $?

(Ausführbar machen mit sudo chmod +x /usr/local/bin/check_ntp.sh nicht vergessen!)

---

6. Implementation Guide: Kubernetes Cluster (K3s)

Der Applikations-Layer. Leichtgewichtig, aber robust.

6.1 Software-Stack (K8s)

• Distribution: K3s (Rancher/SUSE) – optimiert für Edge/ARM.
• Installation: Via curl Skript, Master ohne Traefik/ServiceLB.
• Storage: NVMe only (etcd Performance!).

6.2 Kritische Configs & "Lessons Learned" (K3s)

A) Kernel-Tuning für Cgroups (Der Boot-Fix)

K3s startet nicht oder wirft Speicher-Fehler, wenn Cgroups nicht aktiviert sind.

• Fix: In /boot/firmware/cmdline.txt am Ende der Zeile anfügen: cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory

B) Metriken sichtbar machen (Metrics Server Patch)

Der Metrics-Server scheitert oft an selbstsignierten Zertifikaten und falschen IPs.

• Fix: Deployment patchen, um insecure-tls und InternalIP zu erzwingen: kubectl patch deployment metrics-server -n kube-system ... --kubelet-insecure-tls

C) IP-Konflikte beheben (Der "Copy-Paste" Unfall)

Wenn ein Worker versehentlich mit der IP eines anderen registriert wurde:

1. Master: kubectl delete node <name>
2. Worker: sudo /usr/local/bin/k3s-agent-uninstall.sh
3. Neu: Sauberer Re-Join mit korrektem Token und IP.

---

6. Roadmap & Offene Punkte

• [x] Basis-Infrastruktur: CM4 Blades für DNS/NTP bestellt und konfiguriert.
• [x] HA-Setup: Keepalived mit GARP-Tuning erfolgreich getestet (Stecker-zieh-Test).
• [x] RAID1 für Backup: Zweite identische Festplatte beschaffen.
• [x] Application Cluster: Beschaffung der CM5 Blades für Kubernetes.
• [x] Kubernetes Core: K3s Cluster (1 Master, 4 Worker) ist READY.
• [x] Stresstest: Cluster erfolgreich mit 50 Nginx-Replikas getestet.
• [x] Migration: Umzug der Clients auf die VIP .5 (DHCP Anpassung in UDW).
• [ ] Monitoring: Aufbau eines Dashboards (Grafana), um den Sync-Status beider Pi-holes zu überwachen.
• [ ] Monitoring: Prometheus/Grafana Stack auf dem Cluster deployen.
• [ ] Client-Souveränität 1: MacBook bei eBay verkaufen. Bei Alternatice auch das M4 iPad 13.
• [ ] Client-Souveränität 2: Windows-Partition loswerden. Wie ersetzen wir Fusion 360?
• [ ] Services-Souveränität 1: Eine Matrix-Instanz wäre schön.
• [ ] Services-Souveränität 2: Ein NAS im LAN wäre nett.
• [ ] Services-Souveränität 3: Ein Medienstreamer im netz wäre nett... OpenMediaVault? Vielleicht hat man dann damit auch dass Thema NAS erledigt?
• [ ] Services-Souveränität 3: Eine Immich-Instanz wäre schön.
• [ ] Services-Souveränität 4: Eine Castopod-Instanz wäre schön.
• [ ] Services-Souveränität 5: Eine Peertube-Instanz wäre schön.
• [ ] Services-Souveränität 6: Wie ist es mit Home Automate?
• [ ] Services-Souveränität 7: Sowas wie Spotify mit meiner eigenen CD-Sammlung. Ja, ich habe sowas noch im Keller ...