13 KiB
13 KiB
Master To-do - KalliLab CORE
Stand: 2026-06-06 (Wochenend-Sprint, nach Status-Kategorien sortiert)
Diese Liste ist die zentrale Arbeitsliste fuer offene operative Punkte im Homelab. Detailentscheidungen bleiben in den verlinkten Runbooks; diese Datei haelt Status, naechsten konkreten Schritt und Quelle zusammen.
Status-Kategorien
- Aktiv dieses Wochenende - soll jetzt vorankommen (Claude, Codex oder Operator); konkreter naechster Schritt steht.
- Operator-Entscheidung - wartet auf eine bewusste Entscheidung des Betreibers (ja/nein/welche Option).
- Geparkt - bewusst nicht jetzt, mit klarem Review-Trigger.
- Extern blockiert - wartet auf ein externes Ereignis oder eine Abhaengigkeit (Nachtlauf, zweite Hardware, Geraetebeschaffung).
Owner-Aufteilung fuer das Wochenende: baerchen/Veeam/Backup-Verifikation liegt
bei Codex; Doku-/Inventar-/Onboarding-Arbeit liegt bei Claude;
Host-/Entscheidungsaufgaben beim Operator.
Aktiv dieses Wochenende
| Thema | Owner | Naechster konkreter Schritt | Quelle |
|---|---|---|---|
| DR-Workstation Bare-Metal-Kit | Operator | Auf dem Gaming-PC wsl --install -d Ubuntu, dann sudo apt install borgbackup, dann Smoke borg list ssh://u565255@u565255.your-storagebox.de/./hetzner_borg_appdata_critical mit offline gesichertem Key + Passphrase |
docs/AUDIT_2026-05-25_TODO.md, docs/DR_WORKSTATION_SETUP.md, docs/EXTERNAL_DEPENDENCIES.md |
| Family-Onboarding erster Termin | Operator | Checkliste ist fertig (docs/FAMILY_ONBOARDING.md Abschnitt "Erster Onboarding-Termin"). Operator legt fest, welche Personen/Geraete real verfuegbar sind, und arbeitet die Reihenfolge Vaultwarden -> Immich -> Mealie pro Person ab |
docs/FAMILY_ONBOARDING.md, docs/AUDIT_2026-05-25_TODO.md |
| Restore-Test Unraid OS Flash (Stick-Boot) | Operator | Artefakt-Validierung am 2026-06-05 erledigt (ops/maintenance/check-unraid-flash-backup.sh, sha256 OK, 8 Kern-Configs). Verbleibt: physischer Ersatzstick-Boot-Test, wenn ein Wegwerf-Stick bereitliegt |
docs/RESTORE_MATRIX.md Abschnitt "Unraid OS Flash" |
| Restore-Test Tailscale | Operator | Runbook-Stub abarbeiten: State-Validierung + Reconnect nur auf Wegwerf-Host/VM, danach Geraet in Tailscale-Admin entfernen | docs/RESTORE_MATRIX.md Abschnitt "Tailscale" |
Manuelle App-/Lizenzchecks baerchen |
Codex/Operator | Passwortmanager/2FA-Recovery-Codes, Banking4, WISO, Microsoft/M365/OneDrive im laufenden System bestaetigen | ops/windows-reinstall/docs/windows-neuaufsetzen-masterplan.md |
Operator-Entscheidung
| Thema | Entscheidungsfrage | Quelle |
|---|---|---|
BitLocker-Entscheidung baerchen |
C: (und ggf. D:) aktivieren oder bewusst deaktiviert lassen? Bei Ja: Recovery-Key vorher nach D:\30_Finanzen\..., Vaultwarden und physisch sichern. (Claude fasst BitLocker bewusst nicht an.) |
docs/SECRETS_MAP.md, ops/windows-reinstall/docs/laufwerks-neustruktur-2026-06-04.md |
Veeam Storage Encryption baerchen |
Reicht der erste unverschluesselte Full-Lauf, oder soll Veeam Storage Encryption aktiviert werden? Bei Ja: Passwort in Vaultwarden anlegen, Job umstellen und neues Full-Backup erzeugen | ops/windows-reinstall/docs/windows-image-backup-baseline.md, docs/SECRETS_MAP.md |
| Stromverbrauch messen | Messgeraet/Smart-Plug beschaffen? Ohne Geraet bleiben Idle/Normal/Backup/Last bewusst offen. Status 2026-06-05: kein Geraet vorhanden. | docs/HARDWARE_INVENTORY.md Abschnitt "Stromverbrauch" |
| Tailscale ACL-Policy | Entwurf final abgestimmt 2026-06-05 (grants-Syntax), noch nicht angewendet. Ist-Policy gesichtet = unveraenderter Default (allow-all, grants-Schema). Erster Rollout nur tag:server+tag:operator (kallilabcore=server, baerchen-1+iphone-14=operator); tag:family vorbereitet/schlafend bis erstes Familiengeraet. Verbleibt (mit Operator, je Schritt bestaetigt): lockout-sichere Tagging-Reihenfolge ausfuehren, dann Allow-all entfernen, dann Smoke-Tests. Familien-Dienste erst bei realem Familiengeraet konkretisieren |
docs/NETWORK_INVENTORY.md Abschnitt "ACL-Policy — Entwurf und Rollout-Plan" |
| Nextcloud 2FA / Brute-Force-Haertung | Operator-TOTP (twofactor_totp) jetzt aktivieren? Familien-/OIDC-weite Policy separat |
docs/AUDIT_2026-05-25_TODO.md |
| Authelia Rest-2FA | Weitere Admin-UIs (monitoring, glances, glance, speedtest, pdf, mail, sp ...) von one_factor auf two_factor heben oder bewusst belassen? |
docs/AUDIT_2026-05-25_TODO.md |
| Authelia OIDC fuer Apps | App-uebergreifendes SSO einfuehren - haengt an Familien-/SSO-Grundsatzentscheidung | docs/AUDIT_2026-05-25_TODO.md |
| Gast-/IoT-Netz | Bewusst kein Gast-WLAN/IoT-Netz aktivieren, solange nicht gebraucht. Vorbedingung bei spaeterer Aktivierung: LAN-Admin-Ports vorher per FRITZ!Box-Filter gegen das Gastsegment sperren | docs/NETWORK_INVENTORY.md |
Geparkt
Bewusst nicht jetzt - mit Review-Trigger.
| Thema | Entscheidung / Trigger | Quelle |
|---|---|---|
| USV-Anschaffung | Auf Q3/2026 geparkt (2026-06-05). Power-Loss bleibt akzeptiertes Risiko. Trigger: Hardware-Upgrade, realer Stromausfall mit Datenfolge, oder Q3-Review ab 2026-07-01 | docs/HARDWARE_INVENTORY.md |
| Cold-Backup-Rotation | Bewusst Hetzner-only (2026-06-05). Keine zweite rotierende Cold-Kopie. Trigger: stark wachsender Datenwert, wiederholte Hetzner-Probleme, geaenderte Praeferenz | docs/HARDWARE_INVENTORY.md |
| WAN-Ausfallschutz | Spaeter evaluieren (2026-06-05). Mobilfunk-Failover inaktiv; lokale Apps laufen bei WAN-Ausfall weiter. Trigger: haeufigere/laengere DSL-Ausfaelle oder kritischer Remote-Zugang | docs/NETWORK_INVENTORY.md |
| Docker Critical Events Watcher | Aktiviert 2026-06-05: Unraid User Script docker-critical-events-at-start nutzt den Supervisor und steht in schedule.json auf frequency: start; Watcher manuell gestartet, Status running. Optionaler ntfy-Smoke wurde nachts bewusst nicht gesendet und kann spaeter mit docker-critical-events-supervisor.sh smoke nachgeholt werden |
docs/SERVICE_CATALOG.md, services/posture-check/docker-critical-events.sh, services/posture-check/unraid-user-scripts.md |
| Negativ-Test Backup-Frische | Quartalsweise: bewusst kaputten/fehlenden Dump in Testpfad simulieren, pruefen ob homelab-alerts feuert |
docs/AUDIT_2026-05-25_TODO.md |
| End-to-end-DR-Drill | Komplett-Bootstrap Phase 1-5 auf Wegwerf-Host; realistisch erst mit zweiter Hardware (siehe auch Extern blockiert) | docs/AUDIT_2026-05-25_TODO.md, docs/DISASTER_RECOVERY.md |
| Wiederkehrende Restore-Drills | Vaultwarden, Gitea, Authelia, Komodo, Paperless, Immich, Traefik, PostgreSQL, Mongo, Nextcloud, Mealie, Mail-Archiver nach Matrix-Intervallen rotieren | docs/RESTORE_MATRIX.md, docs/RESTORE_HANDBOOK.md |
Dedizierter SMB-User veeam-baerchen |
Optional spaeter, nur wenn Unraid-User-/Share-Rechte bewusst angefasst werden | ops/windows-reinstall/docs/windows-image-backup-baseline.md |
| CrowdSec vor Traefik | Bewusst nicht umgesetzt; einzige WAN-Tuer ist 443/tcp, Authelia regulation: deckt Brute-Force ab. Neu bewerten bei breiterer Attack Surface |
docs/AUDIT_2026-05-25_TODO.md |
| Hermes-Agent | NAS-Stack bleibt deaktiviert; Review-Deadline 2026-07-25 | docs/AUDIT_2026-05-25_TODO.md, docs/SERVICE_CATALOG.md |
| Filebrowser-Mounts | Bei zukuenftigem Hardening-Sprint Mount-Scope reduzieren | docs/SERVICE_CATALOG.md |
| Scrutiny Privileged-Ausnahme | Nur mit klarer Begruendung aendern; sonst dokumentierte Ausnahme beibehalten | docs/SERVICE_CATALOG.md |
| Immich Redis named volume | Anonymes Volume bei passender Wartung auf named volume umstellen oder Ausnahme dokumentieren | docs/SERVICE_CATALOG.md |
| Storage-Wachstum | Zweite NVMe, ZFS/BTRFS-Optionen, zweite Array-Disk nur bei Triggern aus Capacity-Doku | docs/STORAGE_LAYOUT.md, docs/CAPACITY_AND_LIFECYCLE.md |
| Zweites Off-site-Ziel | Bewusst nicht umgesetzt; neu bewerten bei Hetzner-Problemen oder wachsendem Datenwert | docs/AUDIT_2026-05-25_TODO.md |
Borg append-only auf Hetzner |
Operator-Entscheidung 2026-06-01: nicht umgesetzt (forced-command brach Key-Auth, Nutzen/Risiko unguenstig) | docs/AUDIT_2026-05-25_TODO.md |
Extern blockiert
Wartet auf ein externes Ereignis oder eine Abhaengigkeit.
| Thema | Blockiert durch | Naechster Schritt sobald entblockt | Quelle |
|---|---|---|---|
baerchen Recovery-Test ohne Restore |
Haengt am physischen USB-Boot-Test | Von USB VEEAMRE booten, SMB-Ziel mounten, Restore Point anzeigen, vor echtem Restore abbrechen. Owner: Codex/Operator |
ops/windows-reinstall/docs/windows-image-backup-baseline.md, docs/RESTORE_MATRIX.md |
| End-to-end-DR-Drill (Hardware-Teil) | Keine zweite Wegwerf-Hardware verfuegbar | Sobald zweite Hardware da ist: Komplett-Bootstrap Phase 1-5 fahren | docs/DISASTER_RECOVERY.md |
| Stromverbrauch-Messwerte | Kein Messgeraet beschafft | Nach Beschaffung einer schaltbaren Mess-Steckdose einen Messdurchlauf Idle/Normal/Backup/Last fahren | docs/HARDWARE_INVENTORY.md |
Erledigt im Wochenend-Sprint (2026-06-05)
- Restore-Matrix "Naechste Restore-Test-Kandidaten" bereinigt: 5 am 2026-06-03 abgeschlossene Kandidaten entfernt, durch die 4 real offenen Pfade ersetzt; Stand-Datum aktualisiert.
- Restore-Test-Runbook-Stubs fuer Unraid Flash / AdGuard / Tailscale / Redis 8 in
docs/RESTORE_MATRIX.mdergaenzt. - Alte Windows-Doku bereinigt: WinRE-/Admin-Check-To-dos in
boot-cleanup-plan-2026-06-04.mdundlaufwerks-neustruktur-2026-06-04.mdals erledigt markiert. docs/HARDWARE_INVENTORY.md: USV (Q3-Park), Cold-Backup (Hetzner-only) und Stromverbrauch (Operator-Entscheidung offen) von diffusen TBDs auf bewusste Entscheidungen mit Review-Triggern gehoben.docs/NETWORK_INVENTORY.md: Tailscale-Inventar am 2026-06-05 real per read-only SSH gemessen und eingetragen: IPv6fd7a:115c:a1e0::2c01:62b2, Exit Nodenein, Subnet-Router fuer192.168.178.0/24aktiv (widerlegt fruehere Vermutung), Tailnettaild9fcf2.ts.net, Geraete-Snapshot + Dubletten-Hinweis. WAN-Failover und Gast-/IoT geschaerft.zu messen-Platzhalter entfernt.Tailscale-Inventar messendamit geschlossen.ops/maintenance/check-unraid-flash-backup.shneu: read-only Validierung des Flash-Artefakts (sha256, Frische, Kern-Configs, keine Extraktion). Am 2026-06-05 gegen den Host getestet: Exit 0, sha256 OK, 390 Eintraege, 8/8 Kern-Configs.docs/RESTORE_MATRIX.mdmit Testdatum/Ergebnis aktualisiert. Artefakt-Validierung des Unraid-Flash-Backups damit erledigt; nur Stick-Boot-Test offen.docs/FAMILY_ONBOARDING.md: Michi-Checkliste in eine echte Erste-Termin-Checkliste (Vorbereitung, Reihenfolge, Erfolgskriterium, bewusst spaeter) umgebaut.docs/MASTER_TODO.mdin vier Status-Kategorien (Aktiv / Operator-Entscheidung / Geparkt / Extern blockiert) umstrukturiert.baerchenVeeam-Erstbackup: erster Full-Lauf 2026-06-05 erfolgreich geschrieben (Veeam-GUI 53,8 GB, Dauer 0:11:31, MetaCheck 0 Fehler/0 Warnungen, VSSjob: success). Beleg inops/windows-reinstall/docs/windows-image-backup-baseline.md; Veeam Storage Encryption war im ersten Lauf nicht aktiv und ist als Operator-Entscheidung nachgezogen.- Docker Critical Events Watcher auf Unraid aktiviert: Host-Clone auf Commit
2f3d184aktualisiert, User Script/boot/config/plugins/user.scripts/scripts/docker-critical-events-at-start/scriptauf den Supervisor umgestellt, altes Script alsscript.bak-20260605-232621gesichert,schedule.jsonzeigtfrequency: start, Watcher laeuft mit PID1681168. ntfy-Smoke am 2026-06-06 erfolgreich beim Operator angekommen. - Restore-Test AdGuard Home: automatisierter Test
ops/restore-tests/adguard-restore-test.sherstellt und am 2026-06-06 auf Unraid erfolgreich ausgefuehrt. Ergebnis: Borg-Config-Restore aus ArchivTaegliche-Sicherung-2026-06-06T04:30:05.910, isolierter Containerrestoretest-adguard, HTTP/control/status=401, DNS-Smokegit.kaleschke.info -> 192.168.178.58, 7 Filterlisten-Eintraege, Report/mnt/user/backups/restore-reports/adguard-2026-06-06.md. - Restore-Test Redis 8: automatisierter Test
ops/restore-tests/redis-restore-test.sherstellt und am 2026-06-06 auf Unraid erfolgreich ausgefuehrt. Ergebnis: Restore aus/mnt/user/backups/borg/dumps/latest/shared-redis-pre-redis8-20260531-185011, isolierter Containerrestoretest-redis,PING=PONG, Redis8.8.0, AOF1,DBSIZE=1, Report/mnt/user/backups/restore-reports/redis-2026-06-06.md.
Pflege-Regel
- Neue operative To-dos zuerst hier eintragen oder aus Detaildokumenten hierher uebernehmen, immer mit Status-Kategorie.
- Wenn ein Punkt erledigt ist, in der Detaildoku den Beleg/Report eintragen und diese Liste aktualisieren.
- Keine vagen "pruefen"-Eintraege ohne Kommando oder Entscheidung.
- Historische Drill-Reports bleiben Belegmaterial, aber nicht die fuehrende Arbeitsliste.