Micha 7d87698715 docs(dr): Hetzner Storage Box DR-SSH-Key offline gesichert (2026-06-03)
Dritte der vier P1-Operator-Aufgaben aus dem DR-Tabletop teil-erledigt.
Die SSH-Schicht der DR-Workstation steht; verbleibend ist die
WSL2+Borg-Installation auf dem Gaming-PC.

Was passiert ist:
- ed25519-Keypair `dr-hetzner-2026-06-03` (Passphrase-frei) lokal erzeugt
- Public Key per `install-ssh-key` auf der Hetzner Storage Box autorisiert
- Smoke `ssh -p23 ... ls` passwortlos erfolgreich, vier Borg-Repos
  sichtbar (`backup`, `backup2`, `hetzner_borg_appdata`,
  `hetzner_borg_appdata_critical`)
- Private Key offline neben KOMODO_*-Notiz und GitHub-Deploy-Key gelegt
- Arbeitsplatz-Kopie nach USB-Transfer geloescht

EXTERNAL_DEPENDENCIES.md:
- DR-Workstation-Kit-Tabelle: SSH-Key-Zeile auf "offline gesichert"
- Review-Zeile 2026-06-03 erweitert mit Smoke-Ergebnis

AUDIT_2026-05-25_TODO.md:
- P1-Eintrag DR-Workstation umformuliert: SSH-Key ist erledigt,
  Verbleibend ist nur noch WSL2 + Borg-Client-Installation
- Eintrag unter "Zuletzt geschlossen" mit Wirkung

Stand der DR-Bare-Metal-Pillars:
1. KOMODO_*-Notiz offline                                       erledigt
2. GitHub-Mirror Read-Only Deploy-Key offline                   erledigt
3. Hetzner Storage Box DR-SSH-Key offline                       erledigt
4. WSL2 + Borg-Client auf DR-Workstation installiert            offen
5. Nextcloud-Restore-Test als letzte Tier-2-Luecke schliessen   offen
2026-06-03 19:10:01 +02:00
2026-05-25 14:44:46 +02:00
2026-05-23 11:29:08 +02:00
2026-05-31 22:53:10 +02:00
2026-05-06 19:13:52 +02:00
2026-05-31 22:53:10 +02:00

Homelab Infrastructure (KalliLab CORE)

Dieses Repository ist die zentrale Quelle ("Single Source of Truth") fuer die komplette Infrastruktur meines Homelabs.

WICHTIG - Einstieg

Vor jeder Aenderung lesen:

  1. HOMELAB_ARCHITECTURE_MASTER_V2.md
  2. docs/WORKFLOW.md
  3. docs/README.md

Bei Restore-, Host-Ausfall- oder Wiederanlauf-Fragen zusaetzlich:

  1. docs/DISASTER_RECOVERY.md
  2. docs/RESTORE_MATRIX.md
  3. docs/SERVICES_RECOVERY.md

Bei Hardware-, Netzwerk-, Provider- oder Kapazitaetsfragen zusaetzlich:

  1. docs/HARDWARE_INVENTORY.md
  2. docs/NETWORK_INVENTORY.md
  3. docs/EXTERNAL_DEPENDENCIES.md
  4. docs/CAPACITY_AND_LIFECYCLE.md

Architektur

  • Host: Unraid
  • Container: Docker Compose
  • Reverse Proxy: Traefik v3 (Service-Routing via Docker-Labels, File-Provider nur fuer zentrale Dynamic-Config)
  • Zugriff: Tailscale (VPN)
  • DNS: AdGuard Home + Unbound
  • GitOps: Gitea + Komodo

Grundprinzipien

  • Gitea Online ist der operative Sollzustand.
  • Der lokale Clone ist die Arbeitskopie.
  • Komodo deployed automatisch aus Gitea und ist kein Bearbeitungsort.
  • Keine produktiven Container ausserhalb von Compose.
  • Traefik ist der einzige oeffentliche Einstiegspunkt.
  • Secrets werden niemals im Repository gespeichert.

Repository-Struktur

  • core/ -> Basisdienste (Gitea)
  • security/ -> sicherheitskritische Dienste
  • infra/ -> Datenbanken und technische Services
  • apps/ -> Anwendungen
  • ops/ -> operative Tools
  • monitoring/ -> zentraler Observability-Stack
  • host-services/ -> Dienste mit Host-Netz
  • traefik/ -> Reverse Proxy Konfiguration
  • docs/ -> Dokumentation und Prozesse
  • env/ -> Beispiel-Umgebungsvariablen

Kurz-Workflow

  1. In GitHub Desktop Fetch origin.
  2. Wenn noetig Pull origin.
  3. Lokal aendern.
  4. Commit erstellen.
  5. Push origin.
  6. Komodo-Webhook und Ergebnis pruefen.
  7. Doku bei Bedarf aktualisieren.

Status

  • Komodo ist der primaere und einzige produktive Stack-Manager.
  • Komodo bleibt bewusst bei nativer Authentifizierung; zentrale Traefik-Auth wird dort nicht pauschal vorgeschaltet.
  • Portainer CE ist abgeschaltet und kein Teil des aktiven Betriebs mehr.
  • Glance ist das aktive produktive Homelab-Dashboard.
  • Traefik dynamic/ bleibt eine dokumentierte manuelle Host-Sync-Ausnahme ausserhalb des normalen Komodo-Deployments.
  • Mutable Image-Tags sind auf die aktuell laufenden Digests eingefroren; echte Versions-Upgrades erfolgen bewusst separat.
  • Disaster-Recovery und dienstspezifische Restore-Quellen sind in docs/DISASTER_RECOVERY.md und docs/RESTORE_MATRIX.md beschrieben.
  • Recovery-kritische Services-Pfade wie Gitea-Repositories, Komodo-Workspaces und Host-Automation sind in docs/SERVICES_RECOVERY.md beschrieben.
  • Hardware-, Netzwerk-, Provider- und Capacity-Inventare sind als operative Audit-Dokumente unter docs/HARDWARE_INVENTORY.md, docs/NETWORK_INVENTORY.md, docs/EXTERNAL_DEPENDENCIES.md und docs/CAPACITY_AND_LIFECYCLE.md vorbereitet.
  • Der verbindliche Detailablauf steht in docs/WORKFLOW.md.
  • Der Doku-Index mit aktiven und archivierten Dokumenten steht in docs/README.md.
  • nextcloud, bentopdf und monitoring folgen dem dokumentierten Netz-/Secret-/Traefik-Modell; der zentrale Monitoring-Stack buendelt Prometheus, Loki, Promtail, Grafana und InfluxDB 3 Core.
S
Description
Meine NAS-Architektur
Readme 2.4 MiB
Languages
Shell 73.2%
PowerShell 21.5%
Python 3.5%
CSS 1.3%
JavaScript 0.3%
Other 0.2%