Update audit follow-up documentation

HOMELAB_ARCHITECTURE_MASTER_V2.md

@@ -571,7 +571,7 @@ Mutable Tags wie `latest`, `stable`, `release` oder reine Major-Tags wurden auf
 ### Authelia ohne Redis-Session-Backend (2026-05-04)
 - Authelia nutzt PostgreSQL fuer persistente Storage-Daten, aber bewusst kein Redis-Session-Backend.
 - Das haelt den Tier-1-Auth-Pfad einfacher; nach einem Authelia-Restart muessen aktive Sessions neu aufgebaut werden.
-- `infra/redis` bleibt shared Cache fuer Dienste wie Paperless, ist aber keine Authelia-Abhaengigkeit.
+- `infra/redis` ist historisch als "shared Cache" angelegt, wird aber faktisch nur von Paperless als App-Cache genutzt. Immich, Nextcloud und Mealie betreiben jeweils eigene Redis-Instanzen in ihren App-internen Netzen; Authelia laeuft bewusst ohne Redis. Eine spaetere Konsolidierung in `apps/paperless/` (analog zu Mealie/Immich/Nextcloud) bleibt fachlich denkbar, ist aber kein priorisierter Schritt.
 
 ### ddns-updater — Netz-Ausnahme
 Bleibt bewusst in `frontend_net` statt `backend_net`, weil `backend_net` `internal: true` ist und ddns-updater die Cloudflare-API erreichen muss.

docs/AUDIT_2026-05-25_TODO.md

@@ -2,29 +2,35 @@
 
 Quelle: `docs/AUDIT_2026-05-25.md`
 
-Status: Arbeitsliste fuer die Umsetzung. Authelia-2FA/OIDC bleibt bewusst spaet, weil die Ziel-Policy noch nicht final entschieden ist.
+Status: Arbeitsliste fuer die Umsetzung. Authelia-2FA/OIDC, CrowdSec und Nextcloud-2FA-Haertung bleiben ganz hinten und werden bewusst nicht in diesem Audit-Zyklus angefasst.
 
 ## Leitplanken
 
-- Keine Authelia-2FA-ACL-Aenderungen in den ersten Sprints.
+- Authelia-2FA-ACL, Authelia-OIDC und CrowdSec werden in diesem Audit-Zyklus **nicht** umgesetzt (Operator-Vorgabe 2026-05-26).
 - Keine Live-riskanten Bind-/Port-Aenderungen ohne vorher erfasste Host-Werte, insbesondere Tailscale-IP.
-- Erst Inventar und Baseline, dann Aenderungen.
+- Hermes-Agent ist geparkt, nicht entfernt; Review-Deadline 2026-07-25.
+- USV-Anschaffung ist verschoben; Power-Loss-Risiko ist als Operator-Entscheidung 2026-05-26 bewusst akzeptiert.
+- Borg-Passphrase ist offline gesichert (bestaetigt 2026-05-26).
+- H:/ ist evaluiert als zweite lokale Nearline-Kopie, nicht als Offsite-Ersatz (siehe `docs/CAPACITY_AND_LIFECYCLE.md`).
+- Familien-Einladung ist fuer das Wochenende **nach** Erreichen des finalen Stands geplant; Family-Onboarding muss familienverstaendlich werden, nicht technisch.
 - Jede produktive Aenderung bekommt Validierung und Rollback-Hinweis.
 
 ## Naechster Startpunkt 2026-05-26
 
 Kontext bewusst gesichert, bevor weitere Live-Aenderungen passieren:
 
-1. Host-Schedule/Trockenlauf fuer Gitea-Bundles und Restore-Freshness pruefen.
-2. Netzwerk-/Storage-Inventar finalisieren.
-3. Authelia 2FA/OIDC weiterhin nicht anfassen; das bleibt bewusst der letzte Block.
+1. Host-Schedule fuer Gitea-Bundles und Restore-Freshness pruefen.
+2. FRITZ!Box-Portfreigaben (UI) gegen Repo-Soll abgleichen (`443/tcp` + `222/tcp`).
+3. H:/ Pull-Workflow festlegen.
+4. Family-Onboarding-Doku familienverstaendlich umarbeiten, vor der Wochenend-Einladung.
+5. Authelia 2FA/OIDC und CrowdSec weiterhin nicht anfassen; bleibt bewusst der letzte Block.
 
 ## Sprint 0 - Inventar und Baseline
 
 | Status | Aufgabe | Ergebnis |
 |---|---|---|
 | erledigt | Hardware-Inventar ausfuellen | CPU, RAM, Mainboard, BIOS, NIC, Controller, Disks, SMART und Capacity-Baseline erfasst; USV ist als nicht validiert dokumentiert |
-| in Arbeit | Netzwerk-Inventar ausfuellen | Host-IP, Gateway, Tailscale-IP und AdGuard-Bind erfasst; Router-/VLAN-Details offen |
+| erledigt | Netzwerk-Inventar ausfuellen | Host-IP, Gateway, Tailscale-IP, AdGuard-Bind und FRITZ!Box-Baseline (7590, FRITZ!OS 8.21, Telekom DSL 87/36, 36 Geraete, Gast-WLAN inaktiv, Ausfallschutz inaktiv, 2 Portfreigaben aktiv) erfasst; IPv6 und FRITZ!OS-Update bleiben Operator-Folgeaufgaben |
 | erledigt (Baseline) | Externe Abhaengigkeiten dokumentieren | `docs/EXTERNAL_DEPENDENCIES.md` enthaelt bekannte Provider, Kritikalitaet, Ausfallplaene; Account-Recovery-Codes/Zahlungswege bleiben Off-Repo-Operatorcheck |
 | erledigt (Baseline) | Services-Recovery-Pfade beschreiben | `docs/SERVICES_RECOVERY.md` enthaelt Gitea-/Komodo-/Secrets-Sonderpfade; Gitea-Bundle-/Mirror-Mechanik bleibt als Umsetzungsentscheidung offen |
 | erledigt | Baseline-Tag setzen | `audit-2026-05-25-baseline` ist lokal und remote vorhanden |
@@ -47,7 +53,7 @@ Kontext bewusst gesichert, bevor weitere Live-Aenderungen passieren:
 |---|---|---|
 | offen | `docs/STORAGE_LAYOUT.draft.md` finalisieren | Datei wird als `docs/STORAGE_LAYOUT.md` Active gefuehrt |
 | offen | Disk- und Share-TBDs eintragen | Modelle, Groessen, Seriennummern, Filesysteme und Cache-Settings sind dokumentiert |
-| erledigt (Skript) | Gitea-Repo-Mirror-Mechanik definieren | `ops/borg-ui/scripts/gitea-bundle-mirror.sh` erzeugt verifizierte Bundles unter `/mnt/user/backups/git-bundles/gitea`; Host-Schedule/Trockenlauf bleibt offen |
+| erledigt (Skript + Host-Test) | Gitea-Repo-Mirror-Mechanik definieren | `ops/borg-ui/scripts/gitea-bundle-mirror.sh` erzeugt verifizierte Bundles unter `/mnt/user/backups/git-bundles/gitea`; Host-Erstlauf 2026-05-26: 4 Bundles, Checksums OK, `homelab-infra.bundle` klonbar und `git fsck` sauber; Schedule bleibt offen |
 | offen | Komodo-Bootstrap-Pfad beschreiben | Kaltstart ohne laufendes Komodo ist dokumentiert |
 | offen | Immich-Restore-Test planen | Testumfang, Datenpfade und Smoke-Test-Kriterium stehen fest |
 
@@ -65,17 +71,40 @@ Kontext bewusst gesichert, bevor weitere Live-Aenderungen passieren:
 
 | Status | Aufgabe | Ergebnis |
 |---|---|---|
-| offen | Familien-Onboarding schreiben | Nextcloud, Immich, Vaultwarden, 2FA-Verlust, Ausfallverhalten kurz erklaert |
-| erledigt (Baseline) | Capacity-/Lifecycle-Review erstellen | Cache 6 %, Array/User-Shares 33 %, lokale Backups 2.2G; externe Backup-/Cold-Storage-Groessen bleiben offen |
+| in Arbeit | Familien-Onboarding schreiben | Familienverstaendlich (kein Tech-Jargon); deckt Nextcloud, Immich, Vaultwarden, Mealie, Paperless, Plex, Passwort-/2FA-Verlust und WAN-/DNS-Stoerungen ab; finaler Stand vor Wochenend-Einladung |
+| erledigt (Baseline) | Capacity-/Lifecycle-Review erstellen | Cache 6 %, Array/User-Shares 33 %, lokale Backups 2.2G; H:/-Nearline-Bewertung ergaenzt; externe Cold-Storage-Groessen bleiben offen |
 | erledigt | USV-Test oder USV-Entscheidung | Operator-Entscheidung 2026-05-26: aktuell keine USV-Anschaffung; Power-Loss-Risiko wird bewusst akzeptiert und dokumentiert |
+| erledigt (Baseline) | H:/ als zusaetzliches lokales Backupziel bewerten | Als zweite Nearline-Kopie und Freeze-Sicherung sinnvoll; kein Offsite-Ersatz, kein CIFS-Hard-Mount am Unraid; Pull-Modell vom Windows-PC ist der getestete Weg (siehe `docs/CAPACITY_AND_LIFECYCLE.md`) |
+| in Arbeit | H:/ Groesse und Pull-Schedule festschreiben | Groesse erfasst: 8.0T NTFS, 3.91T belegt, 4.10T frei, `Healthy`; Pull der Borg-Dumps, Gitea-Bundles und Flash-Backups noch planen |
+| offen | FRITZ!Box-Portfreigaben gegen Repo-Soll abgleichen | UI -> Internet -> Freigaben pruefen; nur `443/tcp -> 192.168.178.58` und `222/tcp -> 192.168.178.58` sollten aktiv sein |
 
 ## Sprint 5 - Auth und Frontdoor, bewusst zuletzt
 
-| Status | Aufgabe | Ergebnis |
+In diesem Audit-Zyklus werden diese Punkte **nicht** umgesetzt. Sie sind dokumentiert, damit sie bei einer kuenftigen Policy-Entscheidung sofort priorisiert werden koennen.
+
+| Status | Aufgabe | Begruendung der Parkung |
 |---|---|---|
-| geparkt | Authelia 2FA fuer Operator-UIs erweitern | Erst nach finaler Policy-Entscheidung |
-| geparkt | Authelia OIDC fuer Apps pruefen | Erst nach Familien-/Client-Auswirkungsanalyse |
-| geparkt | CrowdSec vor Traefik pruefen | Nach stabiler Auth-/Monitoring-Basis |
+| geparkt | Authelia 2FA fuer Operator-UIs erweitern (F-04) | Operator-Vorgabe 2026-05-26: keine Auth-Aenderungen in diesem Zyklus |
+| geparkt | Authelia OIDC fuer Apps pruefen (F-13) | Operator-Vorgabe 2026-05-26: keine Auth-Aenderungen in diesem Zyklus |
+| geparkt | CrowdSec vor Traefik pruefen (F-14) | Operator-Vorgabe 2026-05-26: erst nach finaler Auth-Policy |
+| geparkt | Nextcloud-2FA-/Brute-Force-Haertung dokumentieren (F-18) | beruehrt Auth-Policy fuer Familien-Konten; gemeinsam mit OIDC-Entscheidung |
+
+## Sprint 6 - Geparkte Apps und Folgeentscheidungen
+
+| Status | Aufgabe | Naechster Pruefschritt |
+|---|---|---|
+| geparkt | Hermes-Agent (F-06) — Operator-Entscheidung produktiv vs. entfernen | Review-Deadline **2026-07-25**; bis dahin bleibt der NAS-Stack deaktiviert, das Repo-Verzeichnis erhalten, Dashboard-Domain und ACL-Eintrag unveraendert |
+| offen | paperless-gpt / BentoPDF Nutzungsentscheidung | Mit Wochenend-Einladung Familienprobelauf, danach Operator-Entscheidung |
+| offen | Plex Remote Access in UI deaktivieren falls nur LAN/Tailscale (F-17) | Plex-UI -> Settings -> Remote Access -> deaktivieren, falls nicht aktiv genutzt |
+| erledigt | `infra/redis` Doku-Etikett korrigieren (F-16) | SERVICE_CATALOG, REPO_MAP, MASTER (Sektion 13) und DISASTER_RECOVERY Bootstrap-Stufe 2 auf "primaer Paperless-Redis" praezisiert; keine Compose-Aenderung |
+| erledigt | Paperless-DBPass DR-Restore-Reihenfolge in DR-Doc (F-20) | DISASTER_RECOVERY 6.2.1 (Restore-Quellen fuer Stack-ENV-Werte) ergaenzt; SECRETS_MAP um Abschnitt "Stack-ENV-only Secrets - Restore-Wege" mit Reihenfolge Komodo-Mongo-Dump -> Vaultwarden -> externe Notiz erweitert; Paperless, Immich, Mail-Archiver, Speedtest, Komodo, Hermes und Glance je mit Restore-Quelle dokumentiert |
+
+## Sprint 7 - Off-site und 3-2-1 (offen)
+
+| Status | Aufgabe | Bemerkung |
+|---|---|---|
+| offen | Zweites echtes Off-site (F-03) | H:/ ersetzt das **nicht**; rsync.net / BorgBase EU2 / Cold-Wechselplatte mit fester Rotation pruefen |
+| offen | Restore-Lab-Drill quartalsweise dokumentieren | Routine festlegen, nicht ad-hoc |
 
 ## Offene Host-Werte
 

docs/CAPACITY_AND_LIFECYCLE.md

@@ -1,6 +1,6 @@
 # Capacity and Lifecycle - KalliLab CORE
 
-Status: Initiale Capacity-Baseline 2026-05-26; externe Backup-/Cold-Storage-Groessen offen.
+Status: Initiale Capacity-Baseline 2026-05-26; H:/-Nearline-Bewertung 2026-05-26; externe Cold-Storage-Groessen offen.
 
 ## Zweck
 
@@ -49,6 +49,49 @@ du -sh /mnt/user/documents /mnt/user/photos /mnt/user/media /mnt/user/backups 2>
 | SMART-Warnung | Ersatz planen, Restore-/Backup-Frische pruefen |
 | Keine USV-Abschaltung | Risiko ist per Operator-Entscheidung 2026-05-26 bewusst akzeptiert; bei Stromausfaellen/Datenkorruption neu bewerten |
 
+## H:/ als zusaetzliches lokales Backup-Ziel
+
+Operator-Befund 2026-05-26: das Windows-Laufwerk `H:/` laeuft dauerhaft am Arbeits-PC und wurde bereits als `H:-Freeze-Backup` waehrend der Disk1 NTFS->XFS Phase 2 erfolgreich genutzt (siehe `docs/MIGRATION_LOG.md`).
+
+### Eigenschaften von H:/
+
+| Eigenschaft | Wert | Konsequenz |
+|---|---|---|
+| Anbindung | Windows-PC, dauerhaft verbunden | kein Air-Gap, kein Hardware-Trenn-Schutz |
+| Standort | gleicher physischer Standort wie Unraid-Host | kein Off-site, kein Schutz gegen Brand/Diebstahl/Wasser |
+| Schreibzugriff | dauerhaft moeglich | Ransomware oder Operator-Fehler koennen Original und Kopie gleichzeitig treffen |
+| Filesystem (Windows) | typischerweise NTFS | fuer Borg-Ziel ueber CIFS/SMB ungeeignet als Hard-Mount auf Unraid (STORAGE_LAYOUT §12.6) |
+| Reproduzierbar nutzbar | ja, bewaehrt durch Disk1-Phase-2-Freeze-Backup | Pull-Modell vom Windows-PC ist der getestete Weg |
+
+### Bewertung
+
+H:/ ist **keine echte Offsite-/Airgap-Kopie und kein Ersatz fuer Hetzner**. Es ist aber sinnvoll als:
+
+- **Zweite lokale Nearline-Kopie** fuer kritische Restore-Quellen (Borg-Dumps, Repo-Bundles, Flash-Backup). Schnellster Restore-Pfad bei Hetzner-Stoerung, weil kein Off-site-Download noetig ist.
+- **Cold-Storage-Vorstufe**: wenn H:/ kuenftig periodisch (z. B. monatlich) physisch getrennt und durch eine zweite Platte ersetzt wird, wuerde sich daraus ein echtes Air-Gap-Rotationsschema ableiten lassen.
+- **Freeze-Sicherung** vor strukturellen Eingriffen (Disk-Tausch, Pool-Umzug, Format), wie bereits 2026-05-25 praktiziert.
+
+### Empfohlene Nutzung
+
+| Nutzung | Umsetzung | Hinweis |
+|---|---|---|
+| Pull von `/mnt/user/backups/borg/dumps/latest` auf H:/ | Windows-seitiger Scheduled Task per `robocopy` oder `rclone` von einem SMB-Read-Share | keine CIFS-Hard-Mounts auf Unraid; STORAGE_LAYOUT-Konstitution bleibt erhalten |
+| Pull der Gitea-Bundles aus `/mnt/user/backups/git-bundles/gitea` | identisch | Bundles sind klein und schnell synchronisiert |
+| Pull des Unraid-Flash-Artefakts `unraid-flash-config.tar.gz` | identisch | wie Secret behandeln, Windows-seitig nicht in geteilten Ordnern ablegen |
+| **Nicht** als Ersatz fuer Hetzner-Off-site | — | 3-2-1 bleibt mit Hetzner als einzigem Off-site weiterhin unerfuellt; siehe `docs/AUDIT_2026-05-25.md` F-03 |
+| **Nicht** als zweites Borg-Repo am Unraid | — | dauerhafte CIFS-Verbindung im Borg-Lauf verletzt Hard Rule §12.6 |
+
+### Kapazitaets-Eintrag
+
+| Bereich | Groesse | Belegt | Schwellwert | Bewertung |
+|---|---:|---:|---:|---|
+| H:/ (Windows-Arbeitsplatz, `Externe HDD`) | 8.0T | 3.91T belegt / 4.10T frei | Review wenn > 70 % | NTFS, `Healthy`; Pull-Ziel fuer Borg-Dumps, Gitea-Bundles und Flash-Backup |
+
+### Naechste Schritte
+
+- Pull-Script (Operator-Aufgabe, kein Repo-Pflichtteil) etablieren; alternativ ueber Filebrowser/Nextcloud-Sync abdecken.
+- Review-Intervall: quartalsweise. Bei jeder grossen Strukturaenderung (Disk-Tausch, Pool-Umzug) Freeze-Pull manuell ausloesen.
+
 ## Restore-Zeitziele
 
 | Tier | Beispiel | Zielzeit | Status |
@@ -63,3 +106,5 @@ du -sh /mnt/user/documents /mnt/user/photos /mnt/user/media /mnt/user/backups 2>
 | Datum | Befund | Entscheidung |
 |---|---|---|
 | 2026-05-26 | Cache 6 %, Array/User-Shares 33 %, lokale Backups 2.2G; keine validierte USV-Abschaltung | Capacity gruen; USV wird aktuell nicht angeschafft, Power-Loss-Risiko bewusst akzeptiert; externe Backup-/Cold-Storage-Groessen bleiben offen |
+| 2026-05-26 | H:/ als dauerhaft verbundenes Windows-Laufwerk evaluiert | als zweite lokale Nearline-Kopie und Freeze-Sicherung sinnvoll; nicht als Offsite-Ersatz und nicht als Borg-CIFS-Hard-Mount am Unraid; Pull-Modell vom Windows-PC bleibt der getestete Weg |
+| 2026-05-26 | H:/ Kapazitaet erfasst: 8.0T NTFS, 3.91T belegt, 4.10T frei, `Healthy` | genug Reserve fuer Nearline-Pull der kritischen Restore-Artefakte; Pull-Schedule bleibt offen |

docs/DISASTER_RECOVERY.md

@@ -173,6 +173,28 @@ Diese Werte sind vor dem Start der betroffenen Dienste zu pruefen bzw. wieder in
 - `KOMODO_PERIPHERY_PASSKEY`
 - `APP_KEY` und `ADMIN_PASSWORD` fuer `speedtest-tracker`
 
+Zusaetzlich rebuildbar (keine kritische Recovery-Quelle, koennen aus Provider-/App-UIs neu erzeugt werden):
+
+- `GLANCE_IMMICH_API_KEY`, `GLANCE_ADGUARD_USERNAME`, `GLANCE_ADGUARD_PASSWORD`, `GLANCE_SPEEDTEST_API_KEY` fuer `glance` Community-/Live-Widgets
+
+### 6.2.1 Restore-Quellen fuer Stack-ENV-Werte
+
+Stack-ENV-Werte liegen **nicht im Repo** und **nicht als Datei-Secret** unter `/mnt/user/appdata/secrets/`. Sie sind nur an drei Stellen erreichbar; bei Recovery in dieser Reihenfolge pruefen:
+
+1. **Komodo-Mongo-Dump** `komodo-mongo.archive.gz` unter `/mnt/user/backups/borg/dumps/latest/`. Solange Komodo selbst noch nicht laeuft, ist der Mongo-Dump die kanonische Quelle. Restore in eine Test-Mongo-Instanz, anschliessend Werte aus der `stack`-Collection lesen. **Niemals** Werte in andere Dokumente kopieren.
+2. **Vaultwarden** Eintrag "Komodo Stack ENV / KalliLab CORE" (bzw. der entsprechende Eintrag pro Stack). Voraussetzung: Vaultwarden ist bereits restauriert (`docs/RESTORE_MATRIX.md`).
+3. **Externe Operator-Notiz** (versiegelter Umschlag, Bankschliessfach, oder analoge Sicherung neben der Borg-Passphrase). Nur als Notfall-Quelle, wenn weder Komodo-Mongo noch Vaultwarden verfuegbar sind.
+
+**Reihenfolge-Konsequenz fuer den Bootstrap-Pfad in Phase 4 (Stufe 4 weiter unten):**
+
+- Vor dem Start von `apps/paperless/`, `apps/immich/`, `apps/mail-archiver/` und `ops/speedtest/` muessen die jeweiligen Stack-ENV-Werte in Komodo wieder hinterlegt sein.
+- Wenn `komodo-mongo.archive.gz` frisch ist, koennen die Werte beim Komodo-Restart aus dem Dump zurueckgespielt werden, ohne dass jemand sie sieht.
+- Wenn Vaultwarden vor Komodo restauriert wird (was hier nicht der Standardweg ist), kann auch von dort gelesen werden.
+
+**Paperless ist die wichtigste bewusste Ausnahme:** `PAPERLESS_DBPASS` und `PAPERLESS_REDIS` sind seit der Hardening-Phase bewusst Stack-ENV (Paperless unterstuetzt `_FILE` fuer DB-Pass nicht). Ein Komodo-Mongo-Dump-Verlust ist daher fuer Paperless gleichbedeutend mit Re-Initialisierung der App-DB; in diesem Fall hilft nur ein Restore aus Vaultwarden oder externer Notiz.
+
+**Regel:** Konkrete Werte werden **nirgendwo** im Repo, in Logs, in Doku-Kommentaren oder in ntfy-Meldungen wiedergegeben. Auch dieses Dokument haelt nur Variablennamen, Quellen und Reihenfolge fest, keine Werte.
+
 ### 6.3 Rechte
 
 Nach einem Restore oder manuellem Rueckkopieren:
@@ -249,7 +271,7 @@ Ziel:
 - gemeinsame DB verfuegbar
 - zentrale Auth laeuft; Authelia nutzt bewusst kein Redis-Session-Backend
 - Authelia SMTP-Notifier kann GMX erreichen
-- Redis als shared Cache fuer abhaengige Apps verfuegbar
+- Redis verfuegbar als App-Cache fuer Paperless (`infra/redis` ist historisch als "shared" angelegt, wird faktisch nur von Paperless genutzt)
 - Git-Zugriff wiederhergestellt
 
 ### Stufe 3 - Deploy-System

docs/EXTERNAL_DEPENDENCIES.md

@@ -10,6 +10,8 @@ Dieses Dokument beschreibt externe Anbieter und Konten, von denen Betrieb, Recov
 
 | Anbieter / System | Zweck | Kritikalitaet | Recovery-Auswirkung | Zugang / Besitz | Notfallplan |
 |---|---|---:|---|---|---|
+| Telekom DSL | Internet-Uplink | hoch | Public Apps, ACME, DDNS, Hetzner-Off-site und Tailscale-Initial-Verbindung fallen aus | Telekom-Kundenkonto | Kein WAN-Failover am Standort eingerichtet (FRITZ!Box-Ausfallschutz inaktiv); lokale LAN-Dienste laufen weiter; Hotspot-Behelf nur fuer Operator-Arbeit, nicht fuer Public Apps |
+| FRITZ!Box 7590 | Router, DHCP, Telefonie, WAN | hoch | LAN ohne DHCP/Routing; auch lokale Inter-Subnet-Kommunikation kann brechen | Operator-Login auf `192.168.178.1` | FRITZ!Box-Konfig regelmaessig sichern (FRITZ!OS-Backup), Reset-Pin und Account-Pfad bereithalten |
 | Domain-Registrar | Besitz `kaleschke.info` | hoch | Ohne Domain brechen Public URLs/TLS-Erneuerung | Operator-Konto ausserhalb Repo, konkreten Registrar im Account pruefen | Registrar-Zugang, 2FA-Recovery und Zahlungsweg analog/off-system sichern |
 | Cloudflare DNS | Authoritative DNS, ACME DNS-Challenge, DDNS | hoch | Neue Zertifikate/DNS-Aenderungen blockiert | Cloudflare-Konto; API-Token liegt als Host-Secret | API-Token rotierbar halten, Account-Recovery und Zone-Besitz pruefen |
 | Hetzner Storage Box | Off-site Borg Backup | kritisch | Restore aus Off-site ggf. nicht moeglich | Hetzner-Konto / Storage-Box-Zugang ausserhalb Repo | Zweites Off-site-Ziel oder Cold-Platte etablieren; Borg-Passphrase extern sichern |
@@ -56,6 +58,13 @@ Authoritativ ist `docs/SECRETS_MAP.md`. Diese Liste markiert nur externe Abhaeng
 - AdGuard-Admin-Bind muss so geplant werden, dass ein lokaler Break-glass-Weg bekannt ist.
 - Seit 2026-05-26 ist AdGuard Admin nur ueber `100.80.98.33:8082` gebunden; bei Tailnet-Ausfall ist lokaler Host-/Compose-Zugriff der Break-glass-Weg.
 
+### Telekom-DSL / FRITZ!Box gestoert
+
+- Lokale LAN-Apps (Plex, AdGuard-DNS, lokales Borg-Dump-Repository) bleiben verfuegbar, solange Host und Switch laufen.
+- Tailscale-Sessions, die bereits stehen, koennen ueber DERP/Relays kurzzeitig weiterlaufen; neue Verbindungen koennen ausfallen.
+- ACME-/DDNS-/Hetzner-Backup-Laeufe pausieren bis WAN zurueck ist.
+- FRITZ!OS 8.21 Update wird bewusst nur in einem geplanten Service-Fenster eingespielt, weil Reboot WAN/Tailscale-Aufbau unterbricht.
+
 ### Domain verloren oder Registrar-Zugriff verloren
 
 - Gitea/GitHub Mirror und lokale IP/Tailscale-Pfade fuer Recovery nutzen.
@@ -66,3 +75,4 @@ Authoritativ ist `docs/SECRETS_MAP.md`. Diese Liste markiert nur externe Abhaeng
 | Datum | Ergebnis | Naechste Aktion |
 |---|---|---|
 | 2026-05-26 | Bekannte externe Abhaengigkeiten aus Repo-/Betriebsdoku dokumentiert; keine Secret-Werte aufgenommen. Borg-Passphrase ist laut Operator offline gesichert. | Account-Besitz, 2FA-Recovery-Codes und Zahlungswege extern bestaetigen |
+| 2026-05-26 | Telekom-DSL und FRITZ!Box 7590 (FRITZ!OS 8.21) als WAN-/Router-Abhaengigkeit aufgenommen; Ausfallschutz nicht eingerichtet; 2 Portfreigaben aktiv (Soll: 443/tcp + 222/tcp) | FRITZ!OS-Update im Service-Fenster pruefen; Portfreigaben-UI gegen Repo-Soll abgleichen |

docs/FAMILY_ONBOARDING.md

@@ -1,38 +1,142 @@
-# Family Onboarding - KalliLab CORE
+# Familien-Willkommen - KalliLab CORE
 
-Status: Entwurf. Zielgruppe sind Familienmitglieder, nicht Operatoren.
+Status: Entwurf 2026-05-26. Zielgruppe: Familie. Kein Technik-Wortschatz noetig.
 
-## Zweck
+Diese Seite richtet sich an alle, die zuhause unsere eigenen Apps nutzen wollen. Du brauchst kein Technikwissen. Wenn etwas unklar ist, frag Michi.
 
-Diese Datei soll spaeter kurz und alltagstauglich erklaeren, wie die wichtigsten Dienste genutzt werden und was bei Problemen zu tun ist. Keine Restore-Matrix, keine Docker-Begriffe.
+Wir laden die Familie am Wochenende ein, sobald alles fertig ist. Bis dahin ist diese Seite **Entwurf** — Details koennen sich noch aendern.
 
-## Dienste
+---
 
-| Dienst | URL | Zweck | Konto / Login | Notiz |
-|---|---|---|---|---|
-| Nextcloud | `https://cloud.kaleschke.info` | Dateien, Kalender, Kontakte | TBD | Mobile App/WebDAV/CardDAV |
-| Immich | `https://immich.kaleschke.info` | Fotos und Smartphone-Backup | TBD | Backup-App pro Handy |
-| Vaultwarden | `https://vault.kaleschke.info` | Passwoerter | TBD | Familien-Organisation pruefen |
-| Mealie | `https://mealie.kaleschke.info` | Rezepte und Einkauf | TBD | TBD |
-| Paperless | `https://paperless.kaleschke.info` | Dokumente | TBD | Scan-/Inbox-Prozess beschreiben |
-| Plex | intern/App | Medien | TBD | TBD |
+## Was wir zuhause selbst betreiben
 
-## Was tun bei Problemen?
+Wir haben einen eigenen kleinen Server im Haus. Auf dem laufen ein paar Programme, die wir alle gemeinsam nutzen koennen, statt sie bei Google, Apple oder Dropbox liegen zu haben. Vorteile: Unsere Fotos und Dokumente bleiben bei uns. Wir entscheiden, wer was sehen darf. Es kostet uns kein Abo.
 
-| Situation | Verhalten |
-|---|---|
-| Webseite nicht erreichbar | 10 Minuten warten, dann Operator informieren |
-| Passwort vergessen | Operator informieren, nicht selbst neue Konten anlegen |
-| Handy-Foto-Backup stoppt | App oeffnen, WLAN/Batteriesparmodus pruefen, Operator informieren |
-| 2FA verloren | Operator informieren; Recovery-Prozess wird separat festgelegt |
-| Warnmeldung vom Browser | Nicht weiterklicken, Screenshot machen, Operator informieren |
+Nachteile, ehrlich gesagt: Wenn der Server zuhause aus ist, sind die Apps weg, bis er wieder laeuft. Das passiert selten — meistens nur, wenn Michi etwas umbaut oder der Strom weg ist. Und es gibt keine Hotline, die Passwoerter zuruecksetzt. Das macht Michi.
 
-## Offene Inhalte
+---
+
+## Die Apps in einem Satz
+
+| App | Was sie kann | Wie du sie nutzt |
+|---|---|---|
+| **Nextcloud** | Dateien und Ordner teilen, Kalender, Adressbuch | Web `cloud.kaleschke.info` oder Nextcloud-App auf dem Handy |
+| **Immich** | Fotos und Videos automatisch vom Handy sichern, gemeinsam durchblaettern | Immich-App auf dem Handy einrichten lassen |
+| **Vaultwarden** | Passwoerter sicher speichern und auf jedem Geraet nachschauen | Bitwarden-App (kostenlos), beim ersten Start Server-URL auf `vault.kaleschke.info` aendern lassen |
+| **Mealie** | Rezepte sammeln, Wochenplan, Einkaufsliste | Web `mealie.kaleschke.info` oder Mealie-App |
+| **Paperless** | Briefe und wichtige Dokumente scannen, durchsuchen, ablegen | Web `paperless.kaleschke.info`; Scan-Workflow erklaert Michi |
+| **Plex** | Filme und Musik auf Fernseher, Handy und Tablet | Plex-App auf dem Geraet, mit Konto anmelden |
+
+> Wenn du eine App auf dem Handy installierst und sie fragt nach einer Server-URL, ist das immer eine `...kaleschke.info`-Adresse. Wenn du dir nicht sicher bist, frag bevor du etwas eintippst.
+
+---
+
+## Wie du dich anmeldest
+
+Beim ersten Mal bekommst du von Michi:
+
+- deinen Benutzernamen (in der Regel dein Vorname klein geschrieben)
+- ein Start-Passwort, das du beim ersten Login aenderst
+- bei einigen Apps spaeter zusaetzlich einen **Zweitfaktor** (eine kleine 6-stellige Zahl aus einer App)
+
+**Bitte:**
+
+- Speichere alle Passwoerter im Vaultwarden, nicht im Browser.
+- Schreibe Passwoerter nicht auf Zettel.
+- Gib dein Passwort niemandem, auch nicht "kurz mal".
+
+---
+
+## Foto-Backup vom Handy einrichten (Immich)
+
+Das ist die App, die deinen Eltern wahrscheinlich am meisten bringt.
+
+1. App **Immich** im App-Store / Play Store installieren.
+2. Beim ersten Start nach Server fragen lassen: `https://immich.kaleschke.info`.
+3. Mit deinem Login anmelden.
+4. In den App-Einstellungen "Hintergrund-Backup" aktivieren — am besten nur ueber WLAN.
+5. Fertig. Neue Fotos landen automatisch zuhause auf dem Server.
+
+> Wenn dein Handy 4 Wochen nicht im Haus-WLAN war, sind die Fotos noch in der Handy-Galerie, aber noch nicht zuhause. Sobald du wieder im WLAN bist und die App startest, holt sie alles nach.
+
+---
+
+## Was tun, wenn etwas nicht geht
+
+### "Die Webseite oeffnet nicht."
+
+1. 10 Minuten warten — Michi macht vielleicht gerade etwas am Server.
+2. Anderes Geraet ausprobieren (Handy statt PC oder umgekehrt).
+3. Wenn es danach immer noch nicht geht: Michi schreiben. Bitte schreib dazu, was du genau aufgerufen hast (`cloud.kaleschke.info` / `immich.kaleschke.info` / ...).
+
+### "Ich habe mein Passwort vergessen."
+
+- Nicht selbst neu registrieren. Das geht in den Apps gar nicht.
+- Michi schreiben. Er setzt dir ein neues Start-Passwort. Du aenderst es beim ersten Login.
+
+### "Ich habe mein 2FA verloren (neues Handy, App geloescht)."
+
+- Michi schreiben. Er kann den Zweitfaktor zuruecksetzen, sobald er dich persoenlich identifiziert.
+- Wir richten den Zweitfaktor dann neu auf dem neuen Handy ein.
+
+### "Das Handy-Foto-Backup ist stehen geblieben."
+
+1. Immich-App oeffnen, ist sie noch eingeloggt?
+2. Bist du im Haus-WLAN? Mobilfunk ist meistens nicht aktiviert.
+3. Akkusparmodus pruefen — wenn er aktiv ist, kann die App pausieren.
+4. App schliessen, wieder oeffnen, ein paar Minuten warten.
+5. Wenn das nicht hilft: Michi schreiben.
+
+### "Der Browser warnt vor der Seite."
+
+- **Nicht weiterklicken.**
+- Screenshot machen.
+- Michi schicken.
+- Wahrscheinlich ist gerade ein Zertifikat abgelaufen — das ist normalerweise schnell behoben, aber Michi muss kurz draufschauen.
+
+### "Mein Familien-Mitglied sagt, sein Konto sei gesperrt."
+
+- Manchmal sperren die Apps Konten nach mehreren falschen Passwoertern fuer ein paar Minuten. Das ist Absicht. Einfach 10 Minuten warten und nochmal versuchen.
+- Wenn es laenger dauert: Michi schreiben.
+
+---
+
+## Was du **nicht** musst
+
+- Du musst nichts installieren, einrichten oder warten.
+- Du musst keine Updates pruefen.
+- Du musst nicht wissen, wo die Daten genau liegen — sie liegen auf dem Server zuhause und werden automatisch gesichert.
+- Du musst dir keine Adressen merken — alle Apps sind ueber `...kaleschke.info` erreichbar und Michi schickt dir den Direktlink, wenn du einen brauchst.
+
+## Was wir uns gemeinsam wuenschen
+
+- Bitte nutze Vaultwarden fuer alle Familien-Passwoerter. Das schuetzt uns alle.
+- Bitte sag Bescheid, wenn etwas komisch wirkt (seltsame E-Mail, Login-Aufforderung an der falschen Stelle). Lieber einmal zu oft fragen.
+- Wenn dir eine App fehlt oder du eine Idee hast, was wir gemeinsam besser machen koennten: ansprechen, nicht selbst herumprobieren.
+
+---
+
+## Wenn der Server zuhause mal komplett aus ist
+
+Das kommt selten vor. In dem Fall:
+
+- Webseiten von `...kaleschke.info` oeffnen nicht.
+- Foto-Backup von Immich pausiert automatisch — neue Fotos bleiben auf dem Handy und werden nachgeholt, sobald der Server wieder da ist.
+- Plex-App zeigt "Server offline" — Filme sind weiterhin da, sobald der Server zurueck ist.
+- Vaultwarden: gespeicherte Passwoerter sind weiterhin in der Bitwarden-App offline verfuegbar.
+- Es geht **nichts kaputt**, nur weil der Server kurz aus ist.
+
+Michi laesst es dich wissen, wenn ein Wartungsfenster geplant ist.
+
+---
+
+## Offene Inhalte (Operator-Notiz)
 
 | Status | Aufgabe |
 |---|---|
-| offen | Pro Dienst kurze Schritt-fuer-Schritt-Anleitung schreiben |
-| offen | Konto-/2FA-Policy final entscheiden |
-| offen | Immich Mobile Backup fuer alle Geraete testen |
-| offen | Vaultwarden Familienorganisation pruefen |
-
+| offen | Pro Familien-Konto Benutzernamen und Start-Passwort an die Person uebergeben |
+| offen | 2FA-App-Empfehlung pro Person festlegen (z. B. 2FAS / Aegis / Bitwarden Authenticator) |
+| offen | Vaultwarden Familien-Organisation einrichten und Mitglieder einladen |
+| offen | Immich Mobile Backup mit jedem Familien-Geraet testen |
+| offen | Scan-/Inbox-Anleitung fuer Paperless ergaenzen, sobald der Workflow final ist |
+| offen | Einladungstermin Wochenende mit konkretem Datum festlegen |

docs/MIGRATION_LOG.md

@@ -17,6 +17,22 @@ Dieses Dokument ist nur noch ein historischer Verlauf. Der aktuelle operative Ab
 
 ## Historische Meilensteine
 
+### 2026-05-26 - Audit F-16 und F-20 abgeschlossen (Doku-only)
+
+- F-16: `infra/redis`-Etikett auf die Realitaet abgeglichen. `docs/SERVICE_CATALOG.md`, `docs/REPO_MAP.md`, `HOMELAB_ARCHITECTURE_MASTER_V2.md` Sektion 13 und `docs/DISASTER_RECOVERY.md` Bootstrap-Stufe 2 beschreiben Redis jetzt als "primaer Paperless-Redis (App-Cache); historisch als shared angelegt, faktisch nur von Paperless genutzt". Immich, Nextcloud, Mealie eigene Redis-Instanzen; Authelia bewusst ohne Redis. Keine Compose-Aenderung.
+- F-20: Restore-Wege fuer Stack-ENV-only Secrets explizit gemacht. Neuer Abschnitt `6.2.1 Restore-Quellen fuer Stack-ENV-Werte` in `docs/DISASTER_RECOVERY.md` (Reihenfolge Komodo-Mongo-Dump -> Vaultwarden -> externe Notiz, Komodo-Sonderfall, Paperless als Hauptanwendung). Neuer Abschnitt `Stack-ENV-only Secrets - Restore-Wege` in `docs/SECRETS_MAP.md` mit Tabelle je Stack (Paperless, Immich, Mail-Archiver, Speedtest, Komodo, Hermes, Glance). Glance-Widget-Tokens explizit als rebuildbar markiert. Konkrete Werte werden nirgendwo dokumentiert.
+- `docs/AUDIT_2026-05-25_TODO.md` Sprint 6 entsprechend auf "erledigt" gestellt.
+- Kein Eingriff in `ops/borg-ui/scripts/gitea-bundle-mirror.sh`, kein Gitea-Bundle-Trockenlauf, keine SSH-/Host-Pruefung.
+
+### 2026-05-26 - FRITZ!Box-/H:/-/Family-Onboarding-Doku-Update
+
+- `docs/NETWORK_INVENTORY.md` mit FRITZ!Box-Baseline gefuellt: FRITZ!Box 7590, FRITZ!OS 8.21 (Update gemeldet, nicht eingespielt), Telekom DSL ~87/36 Mbit/s, 36 aktive Heimnetz-Geraete, LAN 1-4 verbunden, WLAN `Fritzi`, Gast-WLAN inaktiv, Telefonie/DECT aktiv, Ausfallschutz nicht eingerichtet, USB nicht verbunden, 2 Portfreigaben aktiv. Soll fuer Portfreigaben: nur `443/tcp` und `222/tcp` auf `192.168.178.58`.
+- `docs/EXTERNAL_DEPENDENCIES.md` um Telekom-DSL und FRITZ!Box 7590 als WAN-/Router-Abhaengigkeit erweitert; Ausfall-Szenario "Telekom-DSL / FRITZ!Box gestoert" ergaenzt.
+- `docs/CAPACITY_AND_LIFECYCLE.md` um Abschnitt "H:/ als zusaetzliches lokales Backup-Ziel" ergaenzt. Bewertung: H:/ ist als zweite lokale Nearline-Kopie und Freeze-Sicherung sinnvoll, aber bewusst **kein** Offsite-Ersatz und **kein** CIFS-Hard-Mount am Unraid (STORAGE_LAYOUT §12.6). Pull-Modell vom Windows-PC bleibt der getestete Weg (vgl. Disk1 Phase 2 Freeze 2026-05-25).
+- `docs/FAMILY_ONBOARDING.md` von Tabellen-Entwurf auf familienverstaendlichen Begruessungstext umgestellt: kurze App-Erklaerungen, konkrete Was-tun-Wenn-Anleitungen (Webseite weg, Passwort vergessen, 2FA verloren, Foto-Backup haengt, Browser-Warnung), "Was du nicht musst"-Block, Hinweis fuer geplante Wochenend-Einladung.
+- `docs/AUDIT_2026-05-25_TODO.md` Leitplanken aktualisiert: Authelia 2FA/OIDC/CrowdSec und Nextcloud-2FA-Haertung werden in diesem Zyklus nicht angefasst (Operator-Vorgabe). Hermes-Agent geparkt mit Review-Deadline 2026-07-25. USV-Risiko bewusst akzeptiert. Sprint 4 um H:/-Bewertung und FRITZ!Box-Portfreigaben-Abgleich erweitert. Neue Sprints 6 (geparkte Apps) und 7 (Off-site) ergaenzt.
+- Keine Live-/Compose-Aenderung in diesem Commit; nur Doku.
+
 ### 2026-05-26 - USV-Risiko bewusst akzeptiert
 
 - Operator-Entscheidung: aktuell wird keine USV angeschafft.
@@ -32,6 +48,7 @@ Dieses Dokument ist nur noch ein historischer Verlauf. Der aktuelle operative Ab
 - `ops/borg-ui/scripts/gitea-bundle-mirror.sh` ergaenzt: erstellt verifizierte `git bundle`-Artefakte fuer alle bare Gitea-Repositories, schreibt Checksums und einen Markdown-Report.
 - Zielpfad ist `/mnt/user/backups/git-bundles/gitea`; dieser Pfad muss in den Borg/off-site Scope aufgenommen und hostseitig geplant werden.
 - `docs/SERVICES_RECOVERY.md` und `docs/RESTORE_MATRIX.md` dokumentieren Bundles jetzt als zweite Repo-Bootstrap-Schicht neben dem GitHub-Mirror.
+- Host-Erstlauf nach Skript-Fix erfolgreich: 4 Bundles erzeugt (`homelab-infra`, `homelab`, `homepage`, `smart-home-kalli`), Checksums OK, `homelab-infra.bundle` in Restore-Lab geklont und `git fsck` sauber. Offen bleibt die dauerhafte Schedule-Einbindung.
 
 ### 2026-05-26 - Audit-Baseline-Tag gesetzt
 

docs/NETWORK_INVENTORY.md

@@ -1,6 +1,6 @@
 # Network Inventory - KalliLab CORE
 
-Status: Initialer Host-Audit erfasst, Router-/VLAN-Details offen.
+Status: Host-Audit erfasst; Router-Baseline aus FRITZ!Box-UI ergaenzt; VLAN/IPv6-Details offen.
 Letzte Pruefung: 2026-05-26
 
 ## Zweck
@@ -11,14 +11,26 @@ Dieses Dokument beschreibt Router, DNS, Tailscale, Portfreigaben und Netztrennun
 
 | Feld | Wert |
 |---|---|
-| Anschluss / Provider | TBD |
-| Router-Modell | TBD |
-| Firmware | TBD |
+| Anschluss / Provider | DSL, Telekom |
+| Bandbreite (FRITZ!Box-UI) | ca. 87,3 Mbit/s Download, ca. 36 Mbit/s Upload |
+| Router-Modell | FRITZ!Box 7590 |
+| Firmware | FRITZ!OS 8.21 (Update gemeldet, nicht eingespielt) |
 | Router-IP | 192.168.178.1 |
-| DHCP-Server | vermutlich Router, zu pruefen |
+| DHCP-Server | FRITZ!Box (Standardannahme, Override durch Operator nicht dokumentiert) |
 | Lokales Subnetz | 192.168.178.0/24 |
-| IPv6 aktiv | TBD |
-| DynDNS / DDNS | Cloudflare via `ddns-updater`, Details TBD |
+| IPv6 aktiv | TBD (FRITZ!Box-UI separat pruefen) |
+| DynDNS / DDNS | Cloudflare via `ddns-updater` (kein FRITZ!Box-DynDNS in Nutzung) |
+| Heimnetz-Geraete (FRITZ!Box-UI) | 36 aktive Geraete |
+| LAN-Ports belegt | LAN 1-4 verbunden |
+| Telefonie / DECT | aktiv |
+| USB an FRITZ!Box | nicht verbunden |
+| Ausfallschutz (FRITZ!Box) | nicht eingerichtet (Mobilfunk-Stick-Failover nicht aktiv) |
+
+### Beobachtungen
+
+- Telekom-DSL ist Single-WAN; ohne Ausfallschutz ist Internet-Ausfall = kein DDNS-Update, keine ACME-Erneuerung, keine externen Push-Quellen.
+- Upload 36 Mbit/s ist die effektive Obergrenze fuer Off-site-Backup-Geschwindigkeit nach Hetzner und fuer Plex-Remote-Streaming.
+- FRITZ!OS 8.21 hat ein angezeigtes Update; Einspielung ist Betreiber-Aufgabe und nicht Teil des Repos.
 
 ## DNS
 
@@ -50,13 +62,26 @@ tailscale ip -6
 
 ## Portfreigaben und Exposure
 
+### FRITZ!Box (WAN -> Host)
+
+Die FRITZ!Box-UI meldet "Portfreigabe aktiv, 2 Portfreigaben eingerichtet". Die zwei aktiven Freigaben muessen mit den im Repo dokumentierten Public-Ports konsistent sein:
+
+| Erwartete Freigabe | Ziel | Zweck | Konsistenz-Check |
+|---|---|---|---|
+| 443/tcp -> 192.168.178.58:443 | Traefik HTTPS | Public Apps via Traefik | Soll exakt diesen Eintrag in FRITZ!Box-UI haben |
+| 222/tcp -> 192.168.178.58:222 | Gitea SSH | Git Push/Pull via SSH | Soll exakt diesen Eintrag in FRITZ!Box-UI haben |
+
+**Wichtig:** Port 80/tcp ist im Cloudflare-DNS-Challenge-Modell **nicht** erforderlich; eine 80er-Freigabe waere ein unnoetiger Angriffsvektor. Wenn die FRITZ!Box-UI mehr oder andere Eintraege zeigt als die zwei oben, muss das im naechsten Operator-Review abgeglichen werden (siehe "Offene Entscheidungen").
+
+### Host (lokal beobachtbar)
+
 | Port | Ziel | Zweck | Bewertung |
 |---:|---|---|---|
-| 80/tcp | Traefik | HTTP->HTTPS / ACME | erwartet |
-| 443/tcp | Traefik | HTTPS | erwartet |
-| 222/tcp | Gitea SSH | Git SSH | dokumentierte Ausnahme |
-| 53/tcp+udp | AdGuard | DNS | dokumentierte Ausnahme |
-| 8082/tcp | AdGuard Admin | Admin UI | Repo-Soll: nur `100.80.98.33:8082`, DNS-Port 53 unveraendert |
+| 80/tcp | Traefik | HTTP->HTTPS / ACME | nur LAN, keine WAN-Freigabe noetig |
+| 443/tcp | Traefik | HTTPS | WAN-Freigabe in FRITZ!Box erwartet |
+| 222/tcp | Gitea SSH | Git SSH | WAN-Freigabe in FRITZ!Box erwartet, dokumentierte Ausnahme |
+| 53/tcp+udp | AdGuard | DNS | LAN-only, dokumentierte Ausnahme |
+| 8082/tcp | AdGuard Admin | Admin UI | Bind nur `100.80.98.33:8082` (Tailscale), nicht im LAN exponiert |
 | 8181/tcp | InfluxDB 3 Core | LAN Writer fuer Home Assistant | LAN-only, Bind-IP pruefen |
 
 Pruefkommando:
@@ -70,11 +95,12 @@ docker ps --format "{{.Names}}: {{.Ports}}" | sort
 
 | Netz | Status | Bemerkung |
 |---|---|---|
-| LAN | 192.168.178.0/24 | Hauptnetz, Host `192.168.178.58` |
-| Gast-WLAN | TBD | Zugriff auf AdGuard Admin muss ausgeschlossen sein |
-| IoT-Netz | TBD | Zugriff auf AdGuard Admin muss ausgeschlossen sein |
+| LAN | 192.168.178.0/24 | Hauptnetz, Host `192.168.178.58`, FRITZ!Box meldet 36 aktive Geraete |
+| WLAN 2,4 / 5 GHz | aktiv, SSID `Fritzi` | Standard-WLAN, im LAN-Adressbereich, kein eigener Adressraum |
+| Gast-WLAN | **inaktiv** (FRITZ!Box-UI) | Solange inaktiv: kein Gast-Pfad zu LAN-Diensten; AdGuard-Admin-Trennung primaer ueber Tailscale-Bind statt Netzsegmentierung |
+| IoT-Netz | nicht existent | Keine VLAN-Trennung dokumentiert |
 | Tailscale | aktiv | Operator-Zugang, Host-IP `100.80.98.33` |
-| VLANs | TBD | Router-/Switch-Faehigkeit pruefen |
+| VLANs | nicht in Nutzung | FRITZ!Box 7590 kann VLAN-Tagging an einzelnen LAN-Ports; aktuell nicht konfiguriert |
 
 ## Docker-Netze
 
@@ -101,6 +127,9 @@ docker network inspect backend_net | jq '.[0].Internal'
 | Thema | Status | Naechster Schritt |
 |---|---|---|
 | AdGuard Admin nur via Tailscale | live validiert 2026-05-26 | Compose bindet Admin-Port auf `100.80.98.33:8082`; DNS auf Port 53 funktioniert, LAN-Zugriff auf `192.168.178.58:8082` schlaegt fehl |
-| Gast-/IoT-Zugriff auf Admin-Ports | offen | Router-Regeln pruefen |
-| IPv6 Exposure | offen | Router und Traefik/Cloudflare pruefen |
+| FRITZ!Box-Portfreigaben mit Repo-Soll abgleichen | offen | UI -> Internet -> Freigaben pruefen; nur `443/tcp -> 192.168.178.58` und `222/tcp -> 192.168.178.58` sollten aktiv sein; andere Eintraege dokumentieren oder entfernen |
+| FRITZ!OS 8.21 Update | gemeldet | Operator-Aufgabe; vor Update kurzes Service-Fenster planen, weil Reboot WAN/Tailscale-Aufbau unterbricht |
+| Gast-/IoT-Zugriff auf Admin-Ports | aktuell entschaerft | Gast-WLAN ist inaktiv; bei Aktivierung muessen `192.168.178.58:8082`, `192.168.178.58:8181` und ggf. weitere LAN-Ports per FRITZ!Box-Kindersicherung/Netzwerk-Filter abgesichert werden |
+| IPv6 Exposure | offen | Router und Traefik/Cloudflare pruefen; Telekom-DSL liefert in der Regel IPv6, FRITZ!Box-Standard-Verhalten klaeren |
+| WAN-Ausfallschutz | bewusst nicht eingerichtet | Mobilfunk-Stick-Failover an FRITZ!Box ist nicht aktiv; Internet-Ausfall = ACME/DDNS pausieren, lokale Apps laufen weiter |
 | Home Assistant InfluxDB Bind | offen | Effektive Listener-Adresse pruefen |

docs/REPO_MAP.md

@@ -93,7 +93,7 @@ Secret-Werte werden hier nicht dokumentiert. Aufgefuehrt werden nur Variablennam
 | Vaultwarden | `security/vaultwarden/docker-compose.yml` | `vaultwarden` -> `vaultwarden/server:latest@sha256:...` | `vault.kaleschke.info` | `frontend_net` | keine | Datei-Persistenz, `ADMIN_TOKEN_FILE` |
 | ddns-updater | `infra/ddns-updater/docker-compose.yml` | `ddns-updater` -> `ghcr.io/qdm12/ddns-updater:latest@sha256:...` | keine | `frontend_net` | keine | Cloudflare/API-Internetbedarf |
 | PostgreSQL 17 | `infra/postgresql17/docker-compose.yml` | `postgresql17` -> `postgres:17.9@sha256:...` | keine | `backend_net` | keine | shared DB-Cluster |
-| Redis | `infra/redis/docker-compose.yml` | `Redis` -> `redis:7.4-alpine@sha256:...` | keine | `backend_net` | keine | shared Cache, Passwort-Datei |
+| Redis | `infra/redis/docker-compose.yml` | `Redis` -> `redis:7.4-alpine@sha256:...` | keine | `backend_net` | keine | primaer Paperless-Redis (App-Cache); historisch als "shared" angelegt, faktisch nur von Paperless genutzt; Passwort-Datei |
 
 ### Host Services
 

docs/SECRETS_MAP.md

@@ -103,8 +103,43 @@ Weitere dokumentierte Secret-Pfade:
 
 ---
 
+## Stack-ENV-only Secrets - Restore-Wege
+
+Einige Secrets liegen bewusst nur als Komodo Stack Environment Variables vor, weil das Image kein `_FILE` unterstuetzt oder ein laufender stabiler Produktionsstand nicht fuer eine reine Mechanik-Migration geopfert werden soll. Diese Werte existieren **ausschliesslich** an folgenden Stellen:
+
+1. **Komodo Mongo** (Runtime und Backup-Dump `komodo-mongo.archive.gz` unter `/mnt/user/backups/borg/dumps/latest/`).
+2. **Vaultwarden** (Operator-Eintrag pro Stack, sofern dort gepflegt).
+3. **Externe Operator-Notiz** (analoge Sicherung, vergleichbar mit der Borg-Passphrase).
+
+**Bei Komodo-Restore aus kaltem Zustand wird immer in dieser Reihenfolge gesucht.** Konkrete Werte werden im Repo, in Logs, in Doku-Kommentaren und in ntfy-Meldungen niemals wiedergegeben.
+
+### Stacks und ihre Stack-ENV-only Secrets
+
+| Stack | Stack-ENV-Variablen | Restore-Quelle (Reihenfolge) | Folgen bei Verlust aller Quellen |
+|---|---|---|---|
+| `paperless-ngx` | `PAPERLESS_DBPASS`, `PAPERLESS_REDIS` | Komodo-Mongo-Dump -> Vaultwarden -> externe Notiz | App-DB ist im Postgres-Cluster, Passwort muss in Postgres und Stack-ENV synchron neu gesetzt werden; Redis-URL ist deterministisch rekonstruierbar (Host, Port, Passwort), wenn Redis-Passwort-Datei vorliegt |
+| `immich-server` | `IMMICH_DB_PASSWORD` | Komodo-Mongo-Dump -> Vaultwarden -> externe Notiz | analog Paperless: Postgres-User-Passwort in `immich_postgres` und Stack-ENV gemeinsam zuruecksetzen |
+| `mail-archiver` | `MAILARCHIVER_DB_CONNECTION`, `MAILARCHIVER_AUTH_PASSWORD` | Komodo-Mongo-Dump -> Vaultwarden -> externe Notiz | DB-Connection-String enthaelt Postgres-Pass; App-Auth-Password fuer Web-UI |
+| `speedtest-tracker` | `APP_KEY`, `ADMIN_PASSWORD` | Komodo-Mongo-Dump -> Vaultwarden -> externe Notiz | `APP_KEY` ist verschluesselungsrelevant; bei echtem Verlust App-State frisch initialisieren |
+| `komodo-core` | `KOMODO_SECRET_KEY`, `KOMODO_WEBHOOK_SECRET`, `KOMODO_JWT_SECRET`, `KOMODO_MONGO_PASSWORD`, `KOMODO_PERIPHERY_PASSKEY` | Vaultwarden -> externe Notiz (Henne-Ei: Komodo-Mongo-Dump ist hier **nicht** Restore-Quelle, weil Komodo dafuer schon laufen muesste) | siehe `docs/SERVICES_RECOVERY.md` Komodo-Bootstrap; ohne diese Werte ist der Self-Stack nicht reproduzierbar |
+| `hermes-agent` | `HERMES_DASHBOARD_HOST` plus Provider-/API-/Home-Assistant-Tokens in Host-`.env` | Vaultwarden -> externe Notiz | Stack ist aktuell geparkt (Review 2026-07-25); ohne Werte bleibt der Stack deaktiviert, kein Schaden am Rest |
+| `glance` | `GLANCE_IMMICH_API_KEY`, `GLANCE_ADGUARD_USERNAME`, `GLANCE_ADGUARD_PASSWORD`, `GLANCE_SPEEDTEST_API_KEY` | Provider-UIs (Immich, AdGuard, Speedtest-Tracker) neu erzeugen | rebuildbar; Widgets bleiben leer bis Tokens neu erzeugt sind, kein kritischer Datentopf |
+
+### Komodo-Sonderfall
+
+Komodos eigene Secrets (`KOMODO_*`) sind die kritischste Untermenge dieser Liste, weil sie nicht aus dem eigenen Mongo-Dump rekonstruierbar sind, solange Komodo nicht laeuft. Sie gehoeren entweder
+
+- in Vaultwarden (sobald Vaultwarden produktiv ist) **und**
+- in eine analoge Operator-Notiz neben der Borg-Passphrase.
+
+Details und Bootstrap-Reihenfolge stehen in `docs/SERVICES_RECOVERY.md` und werden in `docs/DISASTER_RECOVERY.md` Abschnitt 6.2.1 als Pflicht-Pruefung vor Phase 4 Stufe 4 referenziert.
+
+---
+
 ## Regel
 
 Wenn `_FILE` nicht unterstuetzt wird -> Stack Environment Variable in Komodo verwenden.
 
 Secrets niemals direkt in die Compose-Datei schreiben.
+
+Stack-ENV-Werte niemals im Repo, in Logs oder in Doku-Kommentaren ablegen — nur Variablennamen und Restore-Quellen.

docs/SERVICES_RECOVERY.md

@@ -36,6 +36,8 @@ Empfohlener Start:
 3. Job alle 6 Stunden oder mindestens vor Borg ausfuehren.
 4. Stichprobe: ein Bundle in Wegwerfpfad klonen.
 
+Erstlauf 2026-05-26: 4 Gitea-Bundles erzeugt, Checksums OK, `homelab-infra.bundle` in Restore-Lab geklont und `git fsck` sauber. Offen bleibt die dauerhafte Host-Zeitplanung.
+
 Erfolgskriterium:
 
 ```bash
@@ -94,7 +96,7 @@ Authoritativ ist `docs/SECRETS_MAP.md`. Fuer den Kaltstart ist diese Reihenfolge
 
 | Status | Aufgabe |
 |---|---|
-| erledigt (Skript) | Gitea-Bundle- oder Mirror-Mechanik final entscheiden |
+| erledigt (Skript + Host-Test) | Gitea-Bundle- oder Mirror-Mechanik final entscheiden |
 | erledigt | Komodo-Bootstrap-Quelle finalisieren |
 | offen | Restore-Kommandos nach erstem Trockenlauf mit echten Pfaden ergaenzen |
 | erledigt | Services-Recovery in `docs/DISASTER_RECOVERY.md` verlinken |

docs/SERVICE_CATALOG.md

@@ -28,7 +28,7 @@ Secret-Werte sind nicht enthalten. Es werden nur Secret-Namen, Env-Key-Namen und
 | Service | Zweck | Autoritativer Pfad | URL / Zugang | Abhaengigkeiten | Datenpfade | Backup / Restore | Traefik | Besonderheiten / TODOs |
 |---|---|---|---|---|---|---|---|---|
 | `postgresql17` | shared PostgreSQL Cluster | `infra/postgresql17/docker-compose.yml` | intern | `backend_net` | `/mnt/user/appdata/postgresql17`, `postgres_password.txt` | Tier 1; Dumps unter `/mnt/user/backups/borg/dumps/latest` | nein | keine Host-Ports; raw DB nicht primaerer Restore-Weg |
-| `Redis` | shared Redis Cache | `infra/redis/docker-compose.yml` | intern | `backend_net` | `/mnt/user/appdata/redis`, `redis_password.txt` | transiente Daten, bewusst nicht kritisch | nein | Passwort-Datei; optional named volume offen |
+| `Redis` | primaer Paperless-Redis (App-Cache); historisch als "shared" angelegt, faktisch nur von Paperless genutzt | `infra/redis/docker-compose.yml` | intern | `backend_net` | `/mnt/user/appdata/redis`, `redis_password.txt` | transiente Daten, bewusst nicht kritisch | nein | Passwort-Datei; optional named volume offen. Immich, Nextcloud und Mealie nutzen jeweils eigene Redis-Instanzen; Authelia laeuft bewusst ohne Redis-Session-Backend. Bei Wegfall ist Paperless der einzige betroffene Stack. |
 | `ddns-updater` | Cloudflare/DDNS Aktualisierung | `infra/ddns-updater/docker-compose.yml` | intern | Internetzugang, `frontend_net` | `/mnt/user/appdata/ddns-updater` | rebuildbar | nein | bleibt bewusst in `frontend_net`, weil `backend_net` internal ist |
 
 ## Public / User Apps