chore(deps): update ghcr.io/starosdev/scrutiny:latest-omnibus docker digest to 41c5fae

Switch Paperless GPT to OpenAI API
Enable Vaultwarden SMTP invites
2026-06-01 14:38:15 +00:00 · 2026-06-01 16:18:58 +02:00 · 2026-06-01 15:52:31 +02:00 · 2026-06-01 15:25:48 +02:00 · 2026-06-01 15:16:56 +02:00 · 2026-06-01 15:09:37 +02:00
15 changed files with 393 additions and 55 deletions
@@ -15,15 +15,18 @@ services:
      PAPERLESS_API_TOKEN: "${PAPERLESS_API_TOKEN}"
      MANUAL_TAG: "paperless-gpt"
      AUTO_TAG: "paperless-gpt-auto"
-      LLM_PROVIDER: "ollama"
-      LLM_MODEL: "qwen3:8b"
-      OLLAMA_HOST: "http://192.168.178.103:11434"
-      OLLAMA_CONTEXT_LENGTH: "4096"
-      TOKEN_LIMIT: "1500"
+      LLM_PROVIDER: "openai"
+      LLM_MODEL: "gpt-5.4-mini"
+      OPENAI_API_KEY: "${OPENAI_API_KEY}"
+      OPENAI_BASE_URL: "https://api.openai.com/v1"
+      TOKEN_LIMIT: "12000"
+      LLM_REQUESTS_PER_MINUTE: "30"
      LLM_LANGUAGE: "German"
      OCR_PROVIDER: "llm"
-      VISION_LLM_PROVIDER: "ollama"
-      VISION_LLM_MODEL: "minicpm-v:latest"
+      VISION_LLM_PROVIDER: "openai"
+      VISION_LLM_MODEL: "gpt-5.4-mini"
+      VISION_LLM_TEMPERATURE: "1.0"
+      VISION_LLM_REQUESTS_PER_MINUTE: "20"
      OCR_PROCESS_MODE: "image"
      CREATE_NEW_TAGS: "true"
      AUTO_GENERATE_TITLE: "true"
@@ -48,8 +48,6 @@ Authoritativ: `docs/AUDIT_2026-05-25_TODO.md`.
 Kurzfassung:

 - Alt-Volumes fruehestens ab 2026-06-02 freigeben
- Hetzner-Account-Hygiene und Borg `append-only` pruefen
- FRITZ!Box-Servicefenster fuer Update, Config-Backup und IPv6-Exposure planen
 - Auth-/OIDC-/CrowdSec-/Hermes-Themen bewusst geparkt

 Letzte Bestaetigung:
@@ -58,3 +56,8 @@ Letzte Bestaetigung:
 - H:/ Nearline-Pull 2026-06-01 repariert: Borg-Dumps werden kuratiert kopiert, Gitea-Bundles aktuell.
 - Family-Status-Dashboard liegt als `monitoring/grafana/dashboards/family-status.json` im Repo.
 - Alt-Volume-Freigabe ist per `ops/maintenance/release-alt-volumes.sh` vorbereitet; `--execute` nicht vor 2026-06-02.
+- Family-Onboarding ist auf drei Nutzungsziele fokussiert: Vaultwarden, Immich und Mealie; praktischer Ablauf in `docs/FAMILY_ONBOARDING.md`.
+- Externer Betreibercheck: `ops/maintenance/check-external-operator.sh`; FRITZ!Box 7590 meldet FRITZ!OS `154.08.25`, DNS fuer Public Apps hat keine AAAA-Records, Host hat keine globale Provider-IPv6.
+- FRITZ!Box-UI 2026-06-01: Remote-HTTPS auf FRITZ!Box-UI aus, FTP/FTPS auf Speichermedien aus, WAN-Freigabe nur `443/tcp`, keine aktive IPv6-Freigabe sichtbar, UPnP-Selbstfreigaben aus.
+- FRITZ!Box-Konfig-Backup 2026-06-01 extern/off-system in Vaultwarden abgelegt; Datei und Kennwort bleiben ausserhalb des Repos.
+- Hetzner-Account-Hygiene 2026-06-01 erledigt: 2FA aktiv, Recovery Key offline gedruckt, Zahlung ok; Storage Box SSH-only, Maintenance-Key in Vaultwarden. Append-only forced-command brach Key-Auth und wurde per Passwort-Recovery zurueckgesetzt; Operator-Entscheidung: fuer dieses Homelab bewusst nicht umsetzen.
@@ -8,10 +8,7 @@ Audit-Snapshots wurden aus der Arbeitskopie entfernt; Detailhistorie liegt in Gi
 | Prioritaet | Punkt | Naechster Schritt |
 |---|---|---|
 | P0 | Alt-Volumes nach Burn-in freigeben | Ab 2026-06-02 `ops/maintenance/release-alt-volumes.sh --dry-run` pruefen, danach nur bei sauberem Ergebnis mit `--execute` freigeben |
-| P1 | Hetzner-Account-Hygiene | Starkes einzigartiges Passwort, Backup-Zahlungsweg und Login-Benachrichtigungen extern bestaetigen |
-| P1 | Borg `--append-only` fuer Hetzner pruefen | Rollback-faehigen Test fuer `borg serve --append-only` in Hetzner `authorized_keys` planen |
-| P1 | FRITZ!Box-Servicefenster | FRITZ!OS-Update, FRITZ!Box-Konfig-Backup und IPv6-Exposure-Pruefung gemeinsam erledigen |
-| P2 | Family-Onboarding praktisch starten | Familienkonten, Vaultwarden-Organisation und Immich-Mobile-Backup gemeinsam einrichten |
+| P2 | Family-Onboarding praktisch starten | Fokus: Vaultwarden als Passwortbasis, Immich-Mobile-Backup auf jedem Handy, Mealie mit erstem Rezept/Einkaufsliste; Ablauf steht in `docs/FAMILY_ONBOARDING.md` |

 ## Bewusst geparkt

@@ -24,9 +21,15 @@ Audit-Snapshots wurden aus der Arbeitskopie entfernt; Detailhistorie liegt in Gi
 | Hermes-Agent | NAS-Stack bleibt deaktiviert; Review-Deadline 2026-07-25 |
 | USV | Anschaffung verschoben; Power-Loss-Risiko bewusst akzeptiert |
 | Zweites Off-site-Ziel | Bewusst nicht umgesetzt; neu bewerten bei Hetzner-Problemen, stark wachsendem Datenwert oder geaenderter Betreiber-Praeferenz |
+| Borg `append-only` auf Hetzner | Operator-Entscheidung 2026-06-01: nicht umgesetzt. Der forced-command-Test auf der Storage Box brach Key-Auth und wurde per Passwort-Recovery zurueckgesetzt; Nutzen steht fuer dieses Homelab nicht im Verhaeltnis zum Betriebsrisiko. |

 ## Zuletzt geschlossen

+- Externer Betreibercheck vorbereitet: `docs/EXTERNAL_OPERATOR_RUNBOOK.md` und `ops/maintenance/check-external-operator.sh`; Live-Baseline am 2026-06-01: FRITZ!OS `154.08.25`, keine Public-AAAA-Records fuer `*.kaleschke.info`, Host ohne globale Provider-IPv6, WAN `443/tcp` offen und `80/tcp`/`222/tcp` geschlossen.
+- FRITZ!Box-Servicefenster UI-seitig abgeschlossen: FRITZ!Box-Dienste aus dem Internet sind aus (HTTPS auf FRITZ!Box-UI, FTP/FTPS auf Speichermedien), aktive WAN-Freigabe bleibt nur `443/tcp -> 192.168.178.58`, keine aktive IPv6-Freigabe sichtbar, UPnP-Selbstfreigaben aus.
+- FRITZ!Box-Konfig-Backup exportiert und extern/off-system in Vaultwarden abgelegt: `Einstellungen_FRITZ.Box_7590_154.08.25_01.06.26_1318.export`; Kennwort und Datei bleiben ausserhalb des Repos.
+- Hetzner-Account-Hygiene erledigt: externe Kontakt-/Rechnungs-Mail bestaetigt, Zahlung ok, 2FA mit Google Authenticator aktiv, Recovery Key offline ausgedruckt.
+- Hetzner Storage Box geprueft: `storage-box-1`, `u565255.your-storagebox.de`, SSH-Port `23`, SSH aktiv, SMB/WebDAV aus, 64,94 GB / 1 TB belegt; Borg-UI-Key und separater Maintenance-Key funktionieren wieder nach Passwort-Recovery. Borg `append-only` ist bewusst nicht umgesetzt.
 - Family-View Dashboard ist repo-seitig gebaut: `monitoring/grafana/dashboards/family-status.json` zeigt Family-App-Uptime, Backup-Alter, TLS-Restlaufzeit, Critical-Container und Image-Drift.
 - Alt-Volume-Freigabe ist vorbereitet: `ops/maintenance/release-alt-volumes.sh --dry-run` validiert aktive Pfade, Container-Health, Restore-Freshness und gemountete Altpfade; Test am 2026-06-01 fand vier Kandidaten und keine Blocker, Ausfuehrung bleibt wegen Cutoff bis 2026-06-02 gesperrt.
 - Borg-Nachlauf nach dem 2026-05-31-Sprint ist belegt: Archiv `Taegliche-Sicherung-2026-06-01T04:30:26.913`, 101669 Dateien, `rc=0`; Freshness-Check am 2026-06-01: Critical 0, Warnings 0.
@@ -1,6 +1,6 @@
 # External Dependencies - KalliLab CORE

-Status: Initiale Betreiber-Baseline 2026-05-26; konkrete Account-Recovery-Codes und Besitznachweise muessen ausserhalb des Repos bestaetigt werden.
+Status: Betreiber-Baseline 2026-06-01; Account-Recovery, Schluessel und Besitznachweise bleiben ausserhalb des Repos.

 ## Zweck

@@ -11,13 +11,14 @@ 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 |
+| 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-Backup vom 2026-06-01 liegt extern/off-system in Vaultwarden; Reset-Pin und Account-Pfad bereithalten; Remote-HTTPS/FTP/FTPS aus dem Internet sind aus |
 | 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 | Borg-Passphrase ist offline gesichert; Account-Hygiene und Borg `--append-only` als Haertung pruefen |
+| Hetzner Storage Box | Off-site Borg Backup | kritisch | Restore aus Off-site ggf. nicht moeglich | Hetzner-Konto / Storage-Box-Zugang ausserhalb Repo | Borg-Passphrase ist offline gesichert; Hetzner 2FA/Recovery/Zahlung sind bestaetigt; Storage Box ist SSH-only, Maintenance-Key liegt in Vaultwarden; Borg `append-only` wird per Operator-Entscheidung nicht umgesetzt |
 | GitHub Mirror | Externer Repo-Mirror `michaelkaleschke-spec/homelab-infra` | mittel/hoch | Gitea-Verlust abfederbar, Repo-Bootstrap bleibt moeglich | GitHub-Konto; PAT liegt in Gitea-Mirror-Settings, nicht im Repo | Mirror-Status regelmaessig pruefen; lokalen Clone als zweite Kopie behalten |
 | Tailscale | Remote-/Operator-Zugang | hoch | Remote-Zugriff erschwert, lokale Bedienung bleibt | Tailnet-Konto; Node `Kallilabcore`, IPv4 `100.80.98.33` | Break-glass per LAN und physischem Zugriff; Tailnet-Recovery-Codes sichern |
-| GMX SMTP | Authelia Notifier | mittel | Mail-Notifier faellt aus, Login selbst nicht zwingend | GMX-Konto; SMTP-Secret liegt hostseitig | ntfy/zweiter SMTP als Fallback pruefen |
+| GMX SMTP | Authelia Notifier, Vaultwarden-Einladungen, Ops-Report-Mail | mittel | Mail-Notifier und Vaultwarden-Einladungen fallen aus; Login selbst nicht zwingend | GMX-Konto; SMTP-Secrets liegen hostseitig | ntfy/zweiter SMTP als Fallback pruefen |
+| OpenAI API | Paperless-GPT LLM und Vision-OCR | mittel | Automatische Dokument-Titel, Tags, Korrespondenten und LLM-OCR fallen aus; Paperless selbst laeuft weiter | OpenAI-Projekt/API-Key ausserhalb Repo | Key in Vaultwarden/Komodo sichern, bei Offenlegung rotieren; Kosten/Usage im OpenAI-Projekt beobachten |
 | Let's Encrypt | TLS-Zertifikate | hoch | Cert-Erneuerung faellt aus | automatisch via Traefik und Cloudflare DNS-Challenge | Cert-Expiry Alert einrichten; Cloudflare-Token und Traefik-Storage pruefen |
 | Container Registries | Image Pulls von Docker Hub, GHCR, LSCR, Gitea Registry u. a. | mittel | Redeploy/Update blockiert | ueberwiegend oeffentlich; keine produktiven Registry-Tokens im Repo | Gepinnte Digests und lokale Runtime helfen kurzfristig; Updates geplant und einzeln deployen |
 | Plex Konto/Remote Access | Plex native Auth, ggf. Remote Access und Claim | mittel | Plex-Clients/Remote-Funktionen koennen ausfallen | Plex-Konto ausserhalb Repo; `PLEX_CLAIM` nur fuer Setup | LAN-Medienpfade bleiben lokal; Konto-Recovery separat sichern |
@@ -33,9 +34,10 @@ Authoritativ ist `docs/SECRETS_MAP.md`. Diese Liste markiert nur externe Abhaeng
 | Cloudflare DNS API Token | ACME DNS-Challenge | Token-Rotation und Scope pruefen |
 | GitHub Mirror Token | Push-Mirror | In Gitea/GitHub verwaltet, nicht im Repo |
 | Tailscale Account Recovery | Tailnet-Zugang | Account-2FA/Recovery Codes sichern |
-| SMTP Passwort | Authelia Mail | In Host-Secret, Fallback pruefen |
+| SMTP Passwort | Authelia Mail, Vaultwarden-Einladungen, Ops-Report-Mail | In Host-Secrets, Fallback pruefen |
 | Domain-Registrar Recovery | Domain-Besitz und Zahlung | Account, 2FA und Zahlungsweg ausserhalb des Homelabs sichern |
-| Hetzner Storage Box Zugang | Off-site Backup-Ziel | SSH-/Web-Zugang und Zahlungsweg extern sichern |
+| Hetzner Storage Box Zugang | Off-site Backup-Ziel | Account 2FA aktiv, Recovery Key offline gedruckt, Zahlungsweg ok; Maintenance-Key und Storage-Box-Passwort in Vaultwarden |
+| OpenAI API Key | Paperless-GPT GPT-Zugriff | Als Stack ENV / Vaultwarden-Eintrag sichern; bei Verdacht auf Leak rotieren |

 ## Ausfall-Szenarien

@@ -64,7 +66,7 @@ Authoritativ ist `docs/SECRETS_MAP.md`. Diese Liste markiert nur externe Abhaeng
 - 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.
+- FRITZ!OS ist am 2026-06-01 auf 8.25 (`154.08.25`) beobachtet; weitere Updates nur in einem geplanten Service-Fenster einspielen, weil Reboot WAN/Tailscale-Aufbau unterbricht.

 ### Domain verloren oder Registrar-Zugriff verloren

@@ -76,5 +78,8 @@ 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 | FRITZ!OS-Update im Service-Fenster pruefen |
-| 2026-05-28 | FRITZ!Box-Portfreigaben bereinigt: aktiv bleibt nur `443/tcp`; `80/tcp` entfernt, `222/tcp` bewusst nicht angelegt; UPnP-Recht fuer VONETS-Bridge deaktiviert | IPv6-Exposure bei naechstem WAN-/Router-Review pruefen |
+| 2026-05-26 | Telekom-DSL und FRITZ!Box 7590 (damals FRITZ!OS 8.21) als WAN-/Router-Abhaengigkeit aufgenommen; Ausfallschutz nicht eingerichtet | FRITZ!OS-Update am 2026-06-01 als `154.08.25` beobachtet |
+| 2026-05-28 | FRITZ!Box-Portfreigaben bereinigt: aktiv bleibt nur `443/tcp`; `80/tcp` entfernt, `222/tcp` bewusst nicht angelegt; UPnP-Recht fuer VONETS-Bridge deaktiviert | IPv6-/Dienste-Review am 2026-06-01 nachgezogen |
+| 2026-06-01 | Externer Betreibercheck vorbereitet: `docs/EXTERNAL_OPERATOR_RUNBOOK.md` und `ops/maintenance/check-external-operator.sh`; FRITZ!Box meldet per TR-064 FRITZ!OS `154.08.25`, Public DNS hat keine AAAA-Records, Host hat keine globale Provider-IPv6 | Account-Hygiene am 2026-06-01 nachgezogen |
+| 2026-06-01 | FRITZ!Box-UI gegengeprueft und Konfig-Backup extern/off-system in Vaultwarden abgelegt; Remote-HTTPS auf FRITZ!Box-UI aus, FTP/FTPS auf Speichermedien aus, nur `443/tcp -> 192.168.178.58`, keine aktive IPv6-Freigabe sichtbar, UPnP-Selbstfreigaben aus | Bei naechstem Router-Update erneut exportieren |
+| 2026-06-01 | Hetzner-Account-Hygiene erledigt: externe Mail ok, Zahlung ok, 2FA aktiv, Recovery Key offline gedruckt. Storage Box: SSH aktiv, SMB/WebDAV aus, Maintenance-Key in Vaultwarden, Borg-Repo-Zugriff nach Recovery geprueft. Borg `append-only` wird bewusst nicht umgesetzt. | Keine Folgeaktion |
@@ -0,0 +1,143 @@
+# External Operator Runbook
+
+Stand: 2026-06-01
+
+Dieses Runbook schliesst die Betreiber-Aufgaben, die nicht vollstaendig aus dem
+Repo automatisierbar sind: Hetzner-Account-Hygiene, Borg-Append-Only und
+FRITZ!Box-Servicefenster. Keine Secret-Werte ins Repo schreiben.
+
+## 1. Vorher pruefen
+
+Auf dem Unraid-Host:
+
+```bash
+bash /mnt/user/services/homelab-infra/ops/maintenance/check-external-operator.sh
+```
+
+Erwarteter Stand vom 2026-06-01:
+
+- FRITZ!Box 7590 meldet FRITZ!OS `154.08.25`.
+- FRITZ!Box IPv6-Firewall meldet `FirewallEnabled=1`; `InboundPinholeAllowed=1` bedeutet, dass IPv6-Freigaben technisch moeglich sind und in der UI gegengeprueft werden muessen.
+- Public DNS fuer `*.kaleschke.info` liefert A-Records auf `217.249.115.154`, keine AAAA-Records.
+- Host hat keine globale Provider-IPv6-Adresse; sichtbar ist nur Tailscale-IPv6 `fd7a:115c:a1e0::2c01:62b2`.
+- WAN-Smoke gegen die Public-IP: `443/tcp` offen, `80/tcp` und `222/tcp` geschlossen.
+- FRITZ!Box-UI-Gegencheck vom 2026-06-01: Remote-HTTPS auf die FRITZ!Box ist aus, FTP/FTPS auf Speichermedien ist aus, nur `443/tcp -> 192.168.178.58` ist als WAN-Freigabe sichtbar, keine aktive IPv6-Freigabe sichtbar, UPnP-Selbstfreigaben aus.
+- FRITZ!Box-Konfig-Backup vom 2026-06-01 ist extern/off-system in Vaultwarden abgelegt; Datei und Kennwort nicht ins Repo schreiben.
+- Borg UI nutzt `borg 1.4.x`; Repository `appdata-critical` liegt auf Hetzner Storage Box `ssh://...your-storagebox.de:23/./hetzner_borg_appdata_critical`.
+- Hetzner-Account-Hygiene vom 2026-06-01: 2FA aktiv, Recovery Key offline gedruckt, Zahlung ok.
+- Storage Box vom 2026-06-01: SSH aktiv, SMB/WebDAV aus, separater Maintenance-Key in Vaultwarden, produktiver Borg-UI-Key und Maintenance-Key nach Passwort-Recovery getestet.
+- Restore-Freshness: `Critical 0`, `Warnings 0`.
+
+## 2. Hetzner Account-Hygiene
+
+Im Hetzner-/Storage-Box-Konto pruefen und extern/off-system dokumentieren:
+
+| Punkt | Soll |
+|---|---|
+| Passwort | stark, eindeutig, im Passwortmanager |
+| 2FA | aktiv, Recovery Key offline auffindbar |
+| Kontakt-E-Mail | aktuell und ohne Homelab-Abhaengigkeit erreichbar |
+| Zahlungsweg | gueltig, Fallback bekannt |
+| Storage Box | Produkt, Benutzer und Rechnungsstatus sichtbar |
+| SSH/SFTP/WebDAV/SMB | nur benoetigte Protokolle aktiv |
+| Recovery | Kundennummer, Login-Pfad und Support-Pfad extern notiert |
+
+Im Repo nur das Datum der Bestaetigung dokumentieren, nie Zugangsdaten.
+
+## 3. Borg Append-Only
+
+Status: **bewusst nicht umgesetzt**.
+
+Ziel der Haertung waere gewesen: Der produktive Backup-Client darf neue Archive
+schreiben, aber nicht normal prune/delete/compact als unbeschraenkter Client
+ausfuehren.
+
+Hetzner dokumentiert Borg-Zugriff auf Storage Boxen inklusive `--remote-path`
+fuer Borg-Versionen; fuer Borg 1.4 wird `--remote-path=borg-1.4` empfohlen.
+Hetzner bestaetigt auch, dass append-only moeglich ist. Borg selbst setzt
+append-only pro SSH-Key typischerweise ueber einen forced command in
+`authorized_keys` um.
+
+Getestetes Zielmodell, aber **nicht auf der produktiven Storage Box aktiv**:
+
+```text
+command="borg-1.4 serve --append-only --restrict-to-repository /home/hetzner_borg_appdata_critical",restrict ssh-ed25519 <backup-public-key> borg-ui-append-only
+ssh-ed25519 <maintenance-public-key> borg-maintenance
+```
+
+Hinweise:
+
+- Stand 2026-06-01: Ein forced-command-Versuch auf der produktiven
+  Storage-Box-`authorized_keys` brach die Key-Authentifizierung. Recovery
+  erfolgte per Storage-Box-Passwort und Upload einer bereinigten
+  `authorized_keys` mit Borg-UI-Key und Maintenance-Key.
+- Operator-Entscheidung 2026-06-01: Append-only wird fuer dieses Homelab nicht
+  umgesetzt. Der zusaetzliche Schutz steht hier nicht im Verhaeltnis zum
+  Betriebsrisiko und zur Komplexitaet.
+- Pfad auf der Storage Box vor dem Eintragen pruefen. Bei Hetzner werden Pfade
+  im Borg-Repo haeufig relativ als `./repo-name` verwendet; in
+  `authorized_keys` muss der serverseitige Pfad zur Storage-Box-Home-Struktur
+  passen.
+- Der produktive Borg-UI-Key bleibt bewusst uneingeschraenkt, damit die
+  produktiven Backups laufen.
+- Ein separater Maintenance-Key bleibt fuer bewusste Retention/Prune/Compact
+  noetig und liegt in Vaultwarden; lokale temporare Key-Dateien wurden geloescht.
+- Append-only verhindert nicht, dass ein kompromittierter Client Archive als
+  geloescht markiert; es verhindert die unmittelbare physische Entfernung.
+  Nach einem Vorfall keine unbeschraenkte Schreiboperation ausfuehren, bevor
+  die Borg-Transaktionen bewertet wurden.
+
+Nach Aenderung:
+
+1. Einen regulaeren Borg-Lauf abwarten oder manuell starten.
+2. `check-external-operator.sh` ausfuehren.
+3. In `docs/AUDIT_2026-05-25_TODO.md` nur das Ergebnis dokumentieren.
+
+## 4. FRITZ!Box-Servicefenster
+
+Vor dem Fenster:
+
+1. Familie informieren: Internet/Telefonie koennen kurz weg sein.
+2. Aktuellen Repo-Stand und Borg-Freshness pruefen.
+3. FRITZ!Box-Konfig exportieren: `System -> Sicherung -> Sichern`.
+4. Sicherungsdatei nicht ins Repo legen; im Passwortmanager/off-system ablegen.
+
+In der FRITZ!Box:
+
+| Bereich | Soll |
+|---|---|
+| `System -> Update` | FRITZ!OS aktuell; am 2026-06-01 per TR-064 `154.08.25` beobachtet |
+| `Internet -> Freigaben -> Portfreigaben` | nur `443/tcp -> 192.168.178.58:443` |
+| `Internet -> Freigaben -> FRITZ!Box-Dienste` | Remote-HTTPS auf FRITZ!Box-UI aus; FTP/FTPS auf Speichermedien aus |
+| IPv6-Portfreigaben | keine aktiven Freigaben; insbesondere kein `222/tcp`, kein Admin-Port |
+| Selbststaendige Portfreigaben/UPnP | fuer `Kallilabcore` aus; neue Geraete nur bewusst erlauben |
+| Gastnetz | bleibt aus, solange keine Gastnetz-Policy gepflegt wird |
+| Ausfallschutz | bewusst aus; nur neu bewerten, wenn ein Mobilfunk-Fallback gewuenscht ist |
+
+Nach dem Fenster:
+
+```bash
+bash /mnt/user/services/homelab-infra/ops/maintenance/check-external-operator.sh
+```
+
+Dann in `docs/NETWORK_INVENTORY.md` aktualisieren:
+
+- FRITZ!OS-Version
+- IPv6-Status
+- aktive Portfreigaben
+- FRITZ!Box-Dienste aus dem Internet
+- Datum der Konfig-Sicherung
+
+## Quellen
+
+- Hetzner Docs: Storage Box Zugriff mit SSH/rsync/BorgBackup, inklusive
+  Borg-Versionen, `--remote-path` und Append-Only-Hinweis:
+  <https://docs.hetzner.com/storage/storage-box/access/access-ssh-rsync-borg/>
+- BorgBackup Docs: `borg serve --append-only` und forced commands in
+  `authorized_keys`:
+  <https://borgbackup.readthedocs.io/en/stable/deployment/pull-backup.html>
+- AVM FRITZ!Box Hilfe: IPv6-Portfreigaben werden separat verwaltet; eingehende
+  Zugriffe sind standardmaessig nicht offen:
+  <https://help.avm.de/fritzbox.php?hardware=145&language=en&oem=avme&set=009&topic=hilfe_internet_freigabe_ipv6>
+- AVM FRITZ!Box Hilfe: Sicherung der FRITZ!Box-Einstellungen:
+  <https://help.avm.de/fritzbox.php?hardware=145&language=en&oem=avme&set=009&topic=hilfe_system_export>
@@ -1,6 +1,6 @@
 # Familien-Willkommen - KalliLab CORE

-Status: **Final-Stand vor Wochenend-Einladung** (2026-05-27). Zielgruppe: Familie. Kein Technik-Wortschatz noetig.
+Status: **Praxis-Onboarding** (2026-06-01). Zielgruppe: Familie. Kein Technik-Wortschatz noetig.

 Diese Seite richtet sich an alle, die zuhause unsere eigenen Apps nutzen. Du brauchst kein Technikwissen. Wenn etwas unklar ist: einfach Michi fragen.

@@ -31,6 +31,38 @@ Nachteile, ehrlich gesagt: Wenn der Server zuhause aus ist, sind die Apps weg, b

 ---

+## Unser erster gemeinsamer Ablauf
+
+Wir richten nicht alles auf einmal perfekt ein. Wichtig ist, dass drei Dinge
+wirklich benutzt werden:
+
+1. **Vaultwarden**: Passwoerter landen dort, nicht im Browser.
+2. **Immich**: Handy-Fotos werden automatisch gesichert.
+3. **Mealie**: Rezepte und Einkaufsliste werden gemeinsam ausprobiert.
+
+Wenn diese drei Dinge laufen, ist das Familien-Onboarding praktisch erfolgreich.
+
+## Vaultwarden zuerst
+
+Vaultwarden ist die Grundlage fuer alle anderen Logins.
+
+1. App **Bitwarden Passwortmanager** auf Handy und ggf. PC installieren.
+2. Beim ersten Start die Server-URL auf `https://vault.kaleschke.info` setzen.
+3. Mit dem persoenlichen Konto anmelden.
+4. Master-Passwort gemeinsam festlegen und merken. Das Master-Passwort wird
+   nicht bei Michi gespeichert.
+5. Browser-Passwortspeicher fuer neue Homelab-Passwoerter nicht verwenden.
+6. Test: Einen neuen Eintrag "Test KalliLab" anlegen und wiederfinden.
+
+Was in Vaultwarden gehoert:
+
+- Homelab-App-Passwoerter
+- wichtige Familien-Logins
+- Recovery-Codes, wenn eine App welche zeigt
+- keine losen Passwort-Zettel und keine Screenshots von Passwoertern
+
+---
+
 ## Wie du dich anmeldest

 Beim ersten Mal bekommst du von Michi:
@@ -57,13 +89,40 @@ 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.
+4. In den App-Einstellungen "Hintergrund-Backup" aktivieren - am besten nur
+   ueber WLAN.
+5. Das richtige Album / die normale Kamera-Galerie auswaehlen.
+6. App einmal offen lassen, bis erste Fotos hochgeladen wurden.
+7. Test: In der Weboberflaeche `https://immich.kaleschke.info` pruefen, ob die
+   ersten Fotos sichtbar sind.
+8. 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.

 ---

+## Rezepte und Einkaufsliste einrichten (Mealie)
+
+Mealie soll nicht nur "auch da" sein, sondern wirklich genutzt werden.
+
+1. `https://mealie.kaleschke.info` oeffnen.
+2. Mit dem persoenlichen Konto anmelden.
+3. Gemeinsam ein erstes echtes Rezept anlegen oder importieren.
+4. Rezept mindestens einer Kategorie geben, z. B. `Alltag`, `Schnell`,
+   `Wochenende`, `Vegetarisch`.
+5. Aus dem Rezept Zutaten auf die Einkaufsliste setzen.
+6. Test: Einkaufsliste auf dem Handy oeffnen und einen Eintrag abhaken.
+7. Optional: Einen Wochenplan fuer die naechsten 2-3 Tage anlegen.
+
+Start-Regeln fuer Mealie:
+
+- Rezepte nur dann speichern, wenn wir sie wirklich kochen wuerden.
+- Namen schlicht halten: `Chili`, `Bolognese`, `Kartoffelsuppe`.
+- Zutaten so eintragen, dass sie beim Einkaufen verstaendlich sind.
+- Wenn ein Rezept nicht schmeckt: loeschen oder klar als "nicht wieder" markieren.
+
+---
+
 ## Was tun, wenn etwas nicht geht

 ### "Die Webseite oeffnet nicht."
@@ -134,18 +193,20 @@ Michi laesst es dich wissen, wenn ein Wartungsfenster geplant ist.

 ---

-## Offene Inhalte (Operator-Notiz)
+## Onboarding-Checkliste fuer Michi

-Diese Punkte gehoeren in das Wochenend-Onboarding-Gespraech und sind nicht Teil dieser Familien-Seite:
+Diese Punkte gehoeren in das erste echte Familien-Onboarding. Keine Secret-Werte
+in diese Datei schreiben.

 | Status | Aufgabe |
 |---|---|
-| offen | Pro Familien-Konto Benutzernamen und Start-Passwort persoenlich uebergeben (Vaultwarden Familien-Organisation als Uebergabeweg) |
-| offen | 2FA-App-Empfehlung pro Person festlegen (zum Beispiel Bitwarden Authenticator, Aegis, 2FAS) |
-| offen | Vaultwarden Familien-Organisation einrichten und Mitglieder einladen |
-| offen | Immich Mobile Backup mit jedem Familien-Geraet einmal gemeinsam ausprobieren |
-| offen | Scan-/Inbox-Anleitung fuer Paperless ergaenzen, sobald der Workflow final ist |
-| offen | Einladungstermin Wochenende mit konkretem Datum festlegen |
+| offen | Pro Familienmitglied Konto/Start-Passwort persoenlich uebergeben |
+| offen | Vaultwarden/Bitwarden-App auf Handy einrichten |
+| offen | Testeintrag in Vaultwarden anlegen |
+| offen | Immich-App auf jedem Familien-Handy einrichten |
+| offen | Immich-Backup mit ersten Fotos sichtbar pruefen |
+| offen | Mealie mit erstem Rezept und Einkaufsliste praktisch ausprobieren |
+| offen | Danach entscheiden, ob Nextcloud/Paperless/Plex direkt mitkommen oder spaeter |

 ## Bewusst nicht versprochen

@@ -1,7 +1,7 @@
 # Network Inventory - KalliLab CORE

-Status: Host-Audit erfasst; Router-Baseline und Portfreigaben-UI bereinigt; VLAN/IPv6-Details offen.
-Letzte Pruefung: 2026-05-28
+Status: Host-Audit erfasst; Router-Baseline und Portfreigaben-UI bereinigt; FRITZ!Box-Remote-Dienste aus; IPv6-Exposure technisch und per UI entschaerft.
+Letzte Pruefung: 2026-06-01

 ## Zweck

@@ -14,13 +14,13 @@ Dieses Dokument beschreibt Router, DNS, Tailscale, Portfreigaben und Netztrennun
 | 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) |
+| Firmware | FRITZ!OS 8.25 (`154.08.25` per TR-064 am 2026-06-01) |
 | Router-IP | 192.168.178.1 |
 | DHCP-Server | FRITZ!Box (Standardannahme, Override durch Operator nicht dokumentiert) |
 | Lokales Subnetz | 192.168.178.0/24 |
-| IPv6 aktiv | TBD (FRITZ!Box-UI separat pruefen) |
+| IPv6 aktiv | Windows-Client hat Provider-IPv6; Host hat keine globale Provider-IPv6, nur Tailscale-ULA |
 | DynDNS / DDNS | Cloudflare via `ddns-updater` (kein FRITZ!Box-DynDNS in Nutzung) |
-| Heimnetz-Geraete (FRITZ!Box-UI) | 36 aktive Geraete |
+| Heimnetz-Geraete (FRITZ!Box-UI) | 35 aktive Geraete |
 | LAN-Ports belegt | LAN 1-4 verbunden |
 | Telefonie / DECT | aktiv |
 | USB an FRITZ!Box | nicht verbunden |
@@ -30,7 +30,8 @@ Dieses Dokument beschreibt Router, DNS, Tailscale, Portfreigaben und Netztrennun

 - 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.
+- FRITZ!OS ist am 2026-06-01 per TR-064 auf `154.08.25` beobachtet; FRITZ!Box-Konfig-Backup `Einstellungen_FRITZ.Box_7590_154.08.25_01.06.26_1318.export` wurde extern/off-system in Vaultwarden abgelegt.
+- `Internet -> Freigaben -> FRITZ!Box-Dienste` ist am 2026-06-01 geprueft: Internetzugriff auf die FRITZ!Box per HTTPS ist aus, FTP/FTPS-Zugriff auf Speichermedien ist aus.

 ## DNS

@@ -64,7 +65,7 @@ tailscale ip -6

 ### FRITZ!Box (WAN -> Host)

-Aktiver Soll-Stand nach Operator-Bereinigung 2026-05-28:
+Aktiver Soll-Stand nach Operator-Bereinigung und UI-Gegencheck 2026-06-01:

 | Aktive Freigabe | Ziel | Zweck | Bemerkung |
 |---|---|---|---|
@@ -82,7 +83,7 @@ Bewusst **nicht** freigegeben:
 | Geraet | UPnP-Selbstfreigabe-Recht | Begruendung |
 |---|---|---|
 | `Kallilabcore` (192.168.178.58) | nicht erlaubt | Repo-managed; alle benoetigten Public-Ports sind explizite Freigaben |
-| `PC-192-168-178-71` / VONETS-Adapter (192.168.178.71, MAC 00:17:13:2F:61:96) | **2026-05-28 deaktiviert** | wahrscheinlich VONETS-WiFi-Bridge fuer SolarEdge-Wechselrichter; SolarEdge-Cloud-Sync ist ausschliesslich outbound, eingehende Ports sind nicht erforderlich |
+| `PC-192-168-178-71` / VONETS-Adapter (192.168.178.71, MAC 00:17:13:2F:61:96) | **2026-06-01 erneut geprueft und deaktiviert** | wahrscheinlich VONETS-WiFi-Bridge fuer SolarEdge-Wechselrichter; SolarEdge-Cloud-Sync ist ausschliesslich outbound, eingehende Ports sind nicht erforderlich |

 Sollten neue Geraete UPnP-Selbstfreigaben anfordern, wird das hier als bewusste Ausnahme dokumentiert oder pro Geraet wieder deaktiviert.

@@ -94,7 +95,7 @@ Historischer UI-Befund vor Bereinigung vom 2026-05-27 (`Internet -> Freigaben ->
 | `HTTPS-Server`, TCP, extern `443/tcp` auf `192.168.178.58` | entspricht Repo-Soll |
 | Keine `222/tcp`-Freigabe sichtbar | entspricht seit 2026-05-28 dem Soll: Gitea-SSH bleibt Tailscale-only |
 | Kallilabcore: keine selbststaendige Portfreigabe, kein IPv4-/IPv6-Exposed-Host sichtbar | entspricht Sicherheitsziel |
-| `PC-192-168-178-71`: selbststaendige Portfreigabe erlaubt, `0 aktiv` | **2026-05-28 deaktiviert** |
+| `PC-192-168-178-71`: selbststaendige Portfreigabe erlaubt, `0 aktiv` | **2026-06-01 deaktiviert**; danach nur noch `Kallilabcore` in der Portfreigabenliste sichtbar |

 ### Host (lokal beobachtbar)

@@ -118,7 +119,7 @@ docker ps --format "{{.Names}}: {{.Ports}}" | sort

 | Netz | Status | Bemerkung |
 |---|---|---|
-| LAN | 192.168.178.0/24 | Hauptnetz, Host `192.168.178.58`, FRITZ!Box meldet 36 aktive Geraete |
+| LAN | 192.168.178.0/24 | Hauptnetz, Host `192.168.178.58`, FRITZ!Box meldet 35 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 |
@@ -150,9 +151,10 @@ 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 |
-| FRITZ!Box-Portfreigaben mit Repo-Soll abgleichen | **erledigt 2026-05-28** | Bereinigt: `80/tcp` entfernt (Cloudflare-DNS-Challenge ersetzt HTTP-01; Mobilfunk-Test bestaetigt Timeout auf `http://`, `https://` weiter ok). `222/tcp` bleibt bewusst nicht eingerichtet (Tailscale-only-Linie). UPnP-Selbstfreigabe-Recht fuer VONETS-Bridge (SolarEdge) deaktiviert. Aktiver Soll-Stand: ausschliesslich `443/tcp -> 192.168.178.58`. |
-| FRITZ!OS 8.21 Update | gemeldet | Operator-Aufgabe; vor Update kurzes Service-Fenster planen, weil Reboot WAN/Tailscale-Aufbau unterbricht |
+| FRITZ!Box-Portfreigaben mit Repo-Soll abgleichen | **erledigt 2026-06-01** | Bereinigt: `80/tcp` entfernt (Cloudflare-DNS-Challenge ersetzt HTTP-01; Mobilfunk-Test bestaetigt Timeout auf `http://`, `https://` weiter ok). `222/tcp` bleibt bewusst nicht eingerichtet (Tailscale-only-Linie). UPnP-Selbstfreigaben sind aus. Aktiver Soll-Stand: ausschliesslich `443/tcp -> 192.168.178.58`. |
+| FRITZ!Box-Dienste aus dem Internet | **erledigt 2026-06-01** | `Internet -> Freigaben -> FRITZ!Box-Dienste`: HTTPS-Zugriff auf die FRITZ!Box aus dem Internet aus; FTP/FTPS auf Speichermedien aus. |
+| FRITZ!OS Update und Konfig-Backup | **erledigt 2026-06-01** | TR-064 meldet `154.08.25`; Konfig-Export liegt extern/off-system in Vaultwarden, Kennwort und Datei bleiben ausserhalb des Repos. |
 | 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 |
+| IPv6 Exposure | technisch und per UI entschaerft | Public DNS liefert keine AAAA-Records fuer `*.kaleschke.info`; Host hat keine globale Provider-IPv6. TR-064 meldet IPv6-Firewall aktiv und Pinholes grundsaetzlich erlaubt; FRITZ!Box-UI zeigt keine aktiven IPv6-Freigaben, keine Admin-/SSH-Freigaben. |
 | 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 | validiert 2026-05-31 | `docker-proxy` bindet `127.0.0.1:8181`; keine LAN-Exposure. Wenn Home Assistant nicht lokal auf dem Host schreibt, braucht das eine bewusste Bind-Aenderung. |
@@ -1,6 +1,6 @@
 # Documentation Index

-Stand: 2026-05-31
+Stand: 2026-06-01

 Diese Datei trennt aktive Betriebsdokumentation von historischer Arbeitsdoku. Neue operative Dokumente duerfen nur in `docs/` liegen, wenn sie heute als Einstieg, Runbook, Inventar oder offene Arbeitsliste gebraucht werden. Erledigte Audits, Chat-Handoffs, Prompt-Dateien und abgeschlossene Plaene bleiben in der Git-Historie, aber nicht als dauerhafte Arbeitskopie.

@@ -34,6 +34,7 @@ Diese Datei trennt aktive Betriebsdokumentation von historischer Arbeitsdoku. Ne
 | `HARDWARE_INVENTORY.md` | Host-, Disk-, SMART-, USV- und Power-Baseline |
 | `NETWORK_INVENTORY.md` | Router, DNS, Tailscale, Portfreigaben und Netzthemen |
 | `EXTERNAL_DEPENDENCIES.md` | Provider, Konten und externe Abhaengigkeiten |
+| `EXTERNAL_OPERATOR_RUNBOOK.md` | Hetzner-/Borg-/FRITZ!Box-Betreibercheck |
 | `CAPACITY_AND_LIFECYCLE.md` | Kapazitaet, Wachstum und Upgrade-Trigger |

 ## Monitoring und Automatisierung
@@ -51,7 +51,7 @@ Sie ist die fachliche Ergaenzung zu `docs/DISASTER_RECOVERY.md`.
 | Nextcloud | Borg + Dump | `/mnt/user/appdata/nextcloud/html`, `/mnt/user/documents/nextcloud-data`, `/mnt/user/appdata/nextcloud/postgres18` (Rollback-Altstand: `/mnt/user/appdata/nextcloud/postgres`), `/mnt/user/appdata/nextcloud/redis` | `nextcloud.dump`; Redis-Backup vor Redis-8-Cutover unter `/mnt/user/backups/borg/dumps/latest/nextcloud-redis-pre-redis8-<ts>` | `nextcloud_admin_user.txt`, `nextcloud_admin_password.txt`, `nextcloud_postgres_password.txt`; produktive DB-Rolle laut `config.php` ist `oc_admin` | `nextcloud-postgres`, `nextcloud-redis`, Traefik | Web-UI startet, Login funktioniert, Dateien sichtbar; `occ status` zeigt `maintenance: false` |
 | Glance | Git / Borg-Repo | Repo-Konfiguration unter `ops/glance/config/glance.yml`; keine kritische Datenpersistenz | keine | `GLANCE_IMMICH_API_KEY`, `GLANCE_ADGUARD_USERNAME`, `GLANCE_ADGUARD_PASSWORD`, `GLANCE_SPEEDTEST_API_KEY` | Traefik, Authelia, optional interne API-Ziele | Dashboard startet, Widgets laden, Docker-Status laeuft nur ueber `glance-docker-socket-proxy` |
 | ntfy | Borg / Share | `/mnt/user/appdata/ntfy` | keine | keine besonderen Secret-Dateien dokumentiert | Traefik | UI und Push-Endpunkt erreichbar |
-| Paperless-GPT | Borg / Share | `/mnt/user/appdata/paperless-gpt` | keine eigene DB | `PAPERLESS_API_TOKEN` | Traefik, Paperless | UI startet, Konfiguration vorhanden |
+| Paperless-GPT | Borg / Share | `/mnt/user/appdata/paperless-gpt` | keine eigene DB | `PAPERLESS_API_TOKEN`, `OPENAI_API_KEY` | Traefik, Paperless, OpenAI API | UI startet, Konfiguration vorhanden; LLM-Provider zeigt `openai` / `gpt-5.4-mini` |

 ---

@@ -17,6 +17,7 @@ Dieses Dokument listet sensible Daten, deren Ablageorte und die vorgesehene Einb
 | Service | Secret | Datei / Methode | Status |
 |---|---|---|---|
 | Vaultwarden | `ADMIN_TOKEN` | `/mnt/user/appdata/secrets/vaultwarden_admin_token.txt` -> `ADMIN_TOKEN_FILE` | aktiv |
+| Vaultwarden | SMTP Password | `/mnt/user/appdata/secrets/homelab_smtp_password.txt` -> `SMTP_PASSWORD_FILE` fuer Einladungen/Benachrichtigungen | aktiv |
 | Traefik | Cloudflare DNS API Token | `/mnt/user/appdata/traefik/secrets/cloudflare_dns_api_token` -> Docker Secret `cloudflare_dns_api_token` | aktiv |
 | PostgreSQL 18 | DB Password | `/mnt/user/appdata/secrets/postgres_password.txt` -> `POSTGRES_PASSWORD_FILE` | aktiv |
 | Redis | Passwort | `/mnt/user/appdata/secrets/redis_password.txt` -> Datei-Mount + Startkommando in `infra/redis/docker-compose.yml` | aktiv |
@@ -24,6 +25,7 @@ Dieses Dokument listet sensible Daten, deren Ablageorte und die vorgesehene Einb
 | mealie-postgres | DB Password | `/mnt/user/appdata/secrets/mealie_postgres_password.txt` -> `POSTGRES_PASSWORD_FILE` | aktiv |
 | Paperless-ngx | DB Password | Stack ENV `${PAPERLESS_DBPASS}` | aktiv |
 | Paperless-ngx | Redis URL | Stack ENV `${PAPERLESS_REDIS}` | aktiv |
+| Paperless-GPT | OpenAI API Key | Stack ENV `${OPENAI_API_KEY}`; nicht im Repo, nicht in Logs | aktiv |
 | code-server | Passwort | `/mnt/user/appdata/code-server/secrets/password` -> `FILE__PASSWORD` | aktiv |
 | Filebrowser | Admin Password | `/mnt/user/appdata/secrets/filebrowser_admin_password.txt` -> initialisierte SQLite-DB | aktiv |
 | Immich (server) | DB Password | Stack ENV `${IMMICH_DB_PASSWORD}` | aktiv |
@@ -89,6 +91,7 @@ Dieses Dokument listet sensible Daten, deren Ablageorte und die vorgesehene Einb
 |-- borg_repo_passphrase.txt
 |-- influxdb3_admin_token.json
 |-- filebrowser_admin_password.txt
+|-- homelab_smtp_password.txt
 `-- vaultwarden_admin_token.txt
 ```

@@ -109,8 +112,7 @@ Weitere dokumentierte Secret-Pfade:
 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).
+2. **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.

@@ -119,6 +121,7 @@ Einige Secrets liegen bewusst nur als Komodo Stack Environment Variables vor, we
 | 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 |
+| `paperless-gpt` | `PAPERLESS_API_TOKEN`, `OPENAI_API_KEY` | Komodo-Mongo-Dump -> Vaultwarden -> externe Notiz | Paperless-Token kann in Paperless neu erzeugt werden; OpenAI-Key muss im OpenAI-Projekt rotiert/neu erstellt werden |
 | `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 |
@@ -21,7 +21,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 |
 |---|---|---|---|---|---|---|---|---|
 | `authelia` | ForwardAuth / zentrale Auth fuer Admin-UIs | `security/authelia/docker-compose.yml`, `security/authelia/configuration.yml` | `https://auth.kaleschke.info` | PostgreSQL 18, Traefik, GMX SMTP | `/mnt/user/appdata/authelia/config`, Authelia Secret-Dateien | Tier 1, config + DB + secrets | ja | Bewusst ohne Redis-Session-Backend; SMTP-Notifier via GMX und `authelia_smtp_password.txt`; explizite DNS-Server fuer SMTP/NTP; Repo-Baseline muss manuell in die Host-Config gemerged werden, OIDC/Secrets bleiben hostseitig; Access-Control und Compose-Middleware bei Aenderungen abgleichen |
-| `vaultwarden` | Passwort-Tresor | `security/vaultwarden/docker-compose.yml` | `https://vault.kaleschke.info` | Traefik, `frontend_net` | `/mnt/user/appdata/vaultwarden` | Tier 1, `vaultwarden.sqlite.dump` + Share | ja | `ADMIN_TOKEN_FILE`; keine direkten Ports |
+| `vaultwarden` | Passwort-Tresor | `security/vaultwarden/docker-compose.yml` | `https://vault.kaleschke.info` | Traefik, `frontend_net`, GMX SMTP | `/mnt/user/appdata/vaultwarden` | Tier 1, `vaultwarden.sqlite.dump` + Share | ja | `ADMIN_TOKEN_FILE`; SMTP ueber `homelab_smtp_password.txt` fuer Einladungen/Benachrichtigungen; keine direkten Ports |

 ## Shared Infrastructure

@@ -36,7 +36,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 |
 |---|---|---|---|---|---|---|---|---|
 | `paperless-ngx` | Dokumentenmanagement | `apps/paperless/docker-compose.yml` | `https://paperless.kaleschke.info` | PostgreSQL 18, Redis 8, Traefik | `/mnt/user/appdata/paperless-ngx/data`, `/mnt/user/documents/paperless`, `/mnt/user/documents/scans_inbox` | Tier 2, Borg + `postgresql17-paperless.dump` | ja | DB/Redis Secrets bleiben bewusst Stack ENV; Dump-Dateiname behaelt den historischen Cluster-Namen |
-| `paperless-gpt` | KI-Ergaenzung fuer Paperless | `apps/paperless-gpt/docker-compose.yml` | `https://paperless-gpt.kaleschke.info` | Paperless API, LLM/Ollama, Traefik | `/mnt/user/appdata/paperless-gpt/data`, `/mnt/user/appdata/paperless-gpt/prompts` | Tier 2 | ja + Authelia | API Token als Stack ENV; OCR/LLM-Konfig bei Aenderungen pruefen. **Behalten-Entscheidung 2026-05-28:** Container bleibt aktiv, auch wenn aktuell keine Traefik-Zugriffe in der Woche; Ablouseplanung erst mit Paperless-NGX 3.0 (eigene KI-Features erwartet) - dann neu bewerten. |
+| `paperless-gpt` | KI-Ergaenzung fuer Paperless | `apps/paperless-gpt/docker-compose.yml` | `https://paperless-gpt.kaleschke.info` | Paperless API, OpenAI API, Traefik | `/mnt/user/appdata/paperless-gpt/data`, `/mnt/user/appdata/paperless-gpt/prompts` | Tier 2 | ja + Authelia | `PAPERLESS_API_TOKEN` und `OPENAI_API_KEY` als Stack ENV; LLM und Vision-OCR laufen ueber `gpt-5.4-mini`, kein Zugriff mehr auf lokale Ollama-VM. **Behalten-Entscheidung 2026-05-28:** Container bleibt aktiv, auch wenn aktuell keine Traefik-Zugriffe in der Woche; Ablouseplanung erst mit Paperless-NGX 3.0 (eigene KI-Features erwartet) - dann neu bewerten. |
 | `immich_server` | Foto-/Video-App | `apps/immich/docker-compose.yml` | `https://immich.kaleschke.info` | Immich Postgres, Immich Redis, ML, Traefik | `/mnt/user/photos/immich`, `/mnt/user/photos/family_archive` | Tier 2, Borg + `immich.dump` | ja | native App-Auth; externes Fotoarchiv gemountet |
 | `immich_postgres` | Immich-Datenbank | `apps/immich/docker-compose.yml` | intern | `immich_default` | `/mnt/user/appdata/immich_postgres_vectorchord`, Rollback-Altstand `/mnt/user/appdata/immich_postgres`, `immich_postgres_password.txt` | Dump `immich.dump`; Restore braucht ein Image mit VectorChord/pgvector | nein | PG14 bleibt bewusst; Immich-DB-Image `ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0`; nie ins `frontend_net` |
 | `immich_redis` | Immich Cache | `apps/immich/docker-compose.yml` | intern | `immich_default` | kein kritischer Pfad dokumentiert | rebuildbar | nein | Redis 8.8; Architektur nennt anonymes Volume -> named volume als offenes Thema |
@@ -231,8 +231,8 @@ services:
    data_paths:
      - /mnt/user/appdata/paperless-gpt/data
      - /mnt/user/appdata/paperless-gpt/prompts
-    first_check: "Paperless API erreichbar? LLM/Ollama erreichbar? API Token gesetzt?"
-    notes: "API Token als Stack ENV; abhaengig von laufendem Paperless"
+    first_check: "Paperless API erreichbar? OpenAI API Key gesetzt? Provider/Model auf openai/gpt-5.4-mini?"
+    notes: "PAPERLESS_API_TOKEN und OPENAI_API_KEY als Stack ENV; kein lokaler Ollama-Zugriff"

  immich_server:
    description: Foto-/Video-App
@@ -0,0 +1,106 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+HOST_IP="${HOST_IP:-192.168.178.58}"
+FRITZBOX_URL="${FRITZBOX_URL:-http://192.168.178.1:49000/tr64desc.xml}"
+BORG_DB="${BORG_DB:-/mnt/user/appdata/borg-ui/data/borg.db}"
+REPO_ROOT="${REPO_ROOT:-/mnt/user/services/homelab-infra}"
+
+section() {
+  printf '\n## %s\n\n' "$1"
+}
+
+section "FRITZBox"
+if fritz_xml="$(curl -fsS --max-time 5 "$FRITZBOX_URL")"; then
+  printf '%s\n' "$fritz_xml" | grep -E '<friendlyName>|<modelName>|<Display>' | sed -E 's/^[[:space:]]+//'
+else
+  echo "FRITZBox TR-064 descriptor not reachable at $FRITZBOX_URL"
+fi
+
+if ipv6_fw="$(
+  curl -fsS --max-time 5 \
+    -H 'Content-Type: text/xml; charset="utf-8"' \
+    -H 'SOAPACTION: "urn:schemas-upnp-org:service:WANIPv6FirewallControl:1#GetFirewallStatus"' \
+    --data '<?xml version="1.0"?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:GetFirewallStatus xmlns:u="urn:schemas-upnp-org:service:WANIPv6FirewallControl:1" /></s:Body></s:Envelope>' \
+    http://192.168.178.1:49000/igd2upnp/control/WANIPv6Firewall1
+)"; then
+  firewall_enabled="$(printf '%s\n' "$ipv6_fw" | sed -n 's:.*<FirewallEnabled>\(.*\)</FirewallEnabled>.*:\1:p')"
+  pinhole_allowed="$(printf '%s\n' "$ipv6_fw" | sed -n 's:.*<InboundPinholeAllowed>\(.*\)</InboundPinholeAllowed>.*:\1:p')"
+  echo "IPv6 FirewallEnabled: ${firewall_enabled:-unknown}"
+  echo "IPv6 InboundPinholeAllowed: ${pinhole_allowed:-unknown}"
+else
+  echo "FRITZBox IPv6 firewall status not reachable via TR-064."
+fi
+
+section "Host IPv6"
+global_ipv6="$(
+  ip -6 addr show scope global \
+    | awk '/inet6 / {print $2}' \
+    | grep -Ev '^(fd|fe80:)' || true
+)"
+if [[ -n "$global_ipv6" ]]; then
+  echo "Provider/global IPv6 addresses present:"
+  printf '%s\n' "$global_ipv6"
+else
+  echo "No provider/global IPv6 address on host; only ULA/link-local/Tailscale may be present."
+fi
+tailscale ip -4 2>/dev/null | sed 's/^/Tailscale IPv4: /' || true
+tailscale ip -6 2>/dev/null | sed 's/^/Tailscale IPv6: /' || true
+
+section "DNS"
+for name in \
+  kaleschke.info \
+  vault.kaleschke.info \
+  git.kaleschke.info \
+  cloud.kaleschke.info \
+  traefik.kaleschke.info; do
+  echo "$name"
+  dig +short @1.1.1.1 "$name" A | sed 's/^/  public A    /' || true
+  dig +short @1.1.1.1 "$name" AAAA | sed 's/^/  public AAAA /' || true
+done
+
+section "Host Listeners"
+ss -ltnp | awk '
+  /:(80|443|222|53|8082|8181)[[:space:]]/ ||
+  /100\.80\.98\.33:8082/ ||
+  /127\.0\.0\.1:8181/ {print}
+' | sort -k4
+
+section "External Port Smoke"
+public_ipv4="$(curl -4 -fsS --max-time 5 https://ifconfig.co 2>/dev/null || true)"
+if [[ -z "$public_ipv4" ]]; then
+  public_ipv4="$(dig +short @1.1.1.1 kaleschke.info A | tail -n 1)"
+fi
+
+for check in \
+  "$public_ipv4 443 expected-open" \
+  "$public_ipv4 80 expected-closed" \
+  "$public_ipv4 222 expected-closed"; do
+  set -- $check
+  target="$1"
+  port="$2"
+  expected="$3"
+  if timeout 5 bash -c "cat < /dev/null > /dev/tcp/$target/$port" 2>/dev/null; then
+    result="open"
+  else
+    result="closed"
+  fi
+  printf '%s:%s %s (%s)\n' "$target" "$port" "$result" "$expected"
+done
+
+section "Borg UI Repository"
+if [[ -f "$BORG_DB" ]]; then
+  sqlite3 -header -csv "$BORG_DB" \
+    "select name,repository_type,path,remote_path,last_backup,last_check,borg_version,custom_flags from repositories order by id;"
+  sqlite3 -header -csv "$BORG_DB" \
+    "select id,repository,status,archive_name,started_at,completed_at,nfiles from backup_jobs order by id desc limit 3;"
+else
+  echo "Borg UI database not found: $BORG_DB"
+fi
+
+section "Restore Freshness"
+if [[ -x "$REPO_ROOT/ops/restore-tests/run-restore-checks.sh" ]]; then
+  "$REPO_ROOT/ops/restore-tests/run-restore-checks.sh" freshness
+else
+  echo "Restore freshness script not executable: $REPO_ROOT/ops/restore-tests/run-restore-checks.sh"
+fi
@@ -1,6 +1,6 @@
 services:
  scrutiny:
-    image: ghcr.io/starosdev/scrutiny:latest-omnibus@sha256:a79cd67878a797bc9412e9a9a3e330cd1062f78bd98dc28e2654e655196b8743
+    image: ghcr.io/starosdev/scrutiny:latest-omnibus@sha256:41c5faefb96766d27d58a829fa19b3f4f27da4160926de3255cf142a85a90c12
    container_name: scrutiny
    restart: unless-stopped
    privileged: true
@@ -11,12 +11,20 @@ services:
      SIGNUPS_ALLOWED: "false"
      INVITATIONS_ALLOWED: "false"
      ADMIN_TOKEN_FILE: /run/secrets/admin_token
+      SMTP_HOST: smtp.gmx.net
+      SMTP_PORT: "587"
+      SMTP_SECURITY: starttls
+      SMTP_USERNAME: michideheld@gmx.de
+      SMTP_PASSWORD_FILE: /run/secrets/smtp_password
+      SMTP_FROM: michideheld@gmx.de
+      SMTP_FROM_NAME: KalliLab Vaultwarden
      ROCKET_PORT: 80
      ROCKET_ADDRESS: 0.0.0.0

    volumes:
      - /mnt/user/appdata/vaultwarden:/data
      - /mnt/user/appdata/secrets/vaultwarden_admin_token.txt:/run/secrets/admin_token:ro
+      - /mnt/user/appdata/secrets/homelab_smtp_password.txt:/run/secrets/smtp_password:ro

    networks:
      - frontend_net
Author	SHA1	Message	Date
renovate	4507271ac2	chore(deps): update ghcr.io/starosdev/scrutiny:latest-omnibus docker digest to 41c5fae	2026-06-01 14:38:15 +00:00
Micha	eeebeec804	Switch Paperless GPT to OpenAI API	2026-06-01 16:18:58 +02:00
Micha	55fdb13532	Enable Vaultwarden SMTP invites	2026-06-01 15:52:31 +02:00
Micha	8709fe8239	Focus family onboarding on core apps	2026-06-01 15:25:48 +02:00
Micha	89114b1b12	Record append-only operator decision	2026-06-01 15:16:56 +02:00
Micha	3da19421d0	Document hetzner account hygiene	2026-06-01 15:09:37 +02:00
Micha	16e661be87	Document fritzbox config backup	2026-06-01 14:19:13 +02:00
Micha	12c05376d0	Close fritzbox service window docs	2026-06-01 13:02:03 +02:00
Micha	dfd0ccbb9a	Refine external IPv6 operator check	2026-06-01 12:51:16 +02:00
Micha	ae5d4aedfc	Prepare external operator checks	2026-06-01 12:48:00 +02:00