hermes-erkenntnisse/nachtplan-2026-07-21.md

92 lines
6.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Nachtplan-Snapshot 2026-07-21 21:42 — Reboot-Persistenz VM302
**Auftrag (Bär):** Alle laufenden Jobs + Dienste auf VM302 reboot-fest machen (Kopien, Renders,
Watcher, Dienste, CPU+GPU-Last) — ohne zu rebooten, nur Konfiguration + Verifikation.
Zusatz: Pre-Reboot-Snapshot nach Nachtplan (Desktop) UND Forgejo (dieses Repo/diese Datei).
## Ist-Zustand vor dem Eingriff
Ohne AtStartup-Trigger: WasabiSync-VideoTransfer, WasabiSync-U525566 (mcp, gar kein Trigger,
nur manuell gestartet), ModelMigrationToM (mcp, gar kein Trigger), Barby-PseudoWatcher (SYSTEM,
nur TimeTrigger), Barby-MatrixWatcher/-ModelSync/-Heartbeat (mcp, nur TimeTrigger),
BarbyOutputSync (SYSTEM, nur TimeTrigger). Bereits AtStartup: JobLivenessWatchdog,
BarbyOrchestrator, ComfyUI-Server (alle mcp, LogonType Password — Beweis, dass BootTrigger +
Password-Logon grundsätzlich funktioniert, wenn das Konto-Passwort beim Registrieren bekannt ist).
## Durchgeführte Änderungen
### 1) AtStartup-Trigger
- **Barby-PseudoWatcher, BarbyOutputSync** (SYSTEM/ServiceAccount-Logon, kein Passwort nötig):
direkt per `Set-ScheduledTask` erweitert — bestehender TimeTrigger blieb, BootTrigger + Restart
3×/1min + StartWhenAvailable ergänzt. Laufende Instanz (BarbyOutputSync) nicht unterbrochen.
- **WasabiSync-VideoTransfer, WasabiSync-U525566, ModelMigrationToM, Barby-MatrixWatcher,
Barby-ModelSync, Barby-Heartbeat** (mcp/Password-Logon): `Set-ScheduledTask` UND die COM-Route
(`RegisterTaskDefinition`, auch mit LogonType S4U probiert) scheiterten beide ohne das
mcp-Kontopasswort ("Der Benutzername oder das Kennwort ist falsch" bzw. Zugriff verweigert bei
S4U). Windows verlangt bei jeder Neuregistrierung eines Password-Logon-Tasks das Passwort erneut
— das ist harte Windows-Policy, keine reine Rechte-/Tool-Frage. Passwort wurde NICHT aus dem
LSA-Secret-Store extrahiert (bewusst unterlassen — das wäre Credential-Dumping, nicht
Konfiguration). Vaultwarden-Suche nach einem hinterlegten VM302/mcp-Windows-Passwort blieb
erfolglos.
→ Stattdessen je ein **SYSTEM-Begleit-Task `<Name>-AtBoot`** neu registriert (kein Passwort
nötig), identische Action, BootTrigger mit 45s Delay, Restart 3×/1-2min, StartWhenAvailable,
MultipleInstancesPolicy IgnoreNew. Alle Skripte geprüft: keine Abhängigkeit von mcp-Profil oder
Logon-Session (nutzen feste Pfade M:\, B:\, C:\ProgramData\rclone, localhost-APIs) — Ausnahme
ModelMigrationToM, siehe Lücke unten.
Verifiziert: `Get-ScheduledTask` zeigt jetzt bei allen 6 Original-Tasks weiterhin `Boot=False`
(nicht änderbar ohne Passwort), aber bei allen 6 `-AtBoot`-Begleit-Tasks `Boot=True, Ready`.
### 2) Idempotenz (geprüft, kein Code-Umbau nötig)
- `job-video-transfer.ps1` / `job-u525566.ps1`: `rclone copy` (kein `sync`) — kopiert nur Deltas,
überspringt bereits identische Dateien. Resume nach Reboot funktioniert von Haus aus.
- `copy-models-to-m.ps1`: `robocopy` ohne `/MIR`, Standardverhalten kopiert nur wenn Ziel fehlt
oder Quelle neuer/anders ist. Ebenfalls idempotent, kein `/XO` nötig.
### 3) Mounts + AutoLogon (nur geprüft, NICHT verändert — Bär-Auftrag: nicht ungefragt Passwort in
Registry schreiben)
- `HKLM:\...\Winlogon`: **AutoAdminLogon = 0** (deaktiviert). DefaultUserName=mcp, DefaultDomainName=RDP.
- **Lücke:** R:\ (`WasabiMount`, LogonTrigger mcp) und Z:\ (`RcloneMountStorageboxes`, LogonTrigger
matthias) sind reine Logon-Mounts. Ohne AutoLogon bleibt nach einem kalten Reboot keine
interaktive Session automatisch offen → beide Laufwerke bleiben leer, bis sich jemand einloggt.
`ModelMigrationToM` braucht genau diese beiden Pfade als Quelle (R:\comfyui, Z:\ki-modelle-backup).
**Vorschlag statt AutoLogon:** wurde geprüft (UNC-Pfade `\\10.10.10.1\vm302-modelle` und
`\\u618602.your-storagebox.de\backup` sind aktuell erreichbar, aber ob eine SYSTEM-Session ohne
gecachte Credentials dieselben Freigaben erreicht, ist ungeklärt/nicht getestet ohne echten
Reboot). Empfehlung: `AutoAdminLogon=1` + DefaultPassword für mcp setzen — **Bär-OK nötig**,
nicht selbst umgesetzt.
- Wasabi-Mount-Tasks selbst wurden NICHT angefasst (Absprache: das übernimmt der Wasabi-Sync/Mount-
Agent parallel, keine Überschneidung).
### 4) Boot-Resume-Orchestrator
- Neu: `M:\boot-resume.ps1` + Task `Barby-BootResumeOrchestrator` (SYSTEM, AtStartup, 2min Delay,
Restart 2×/5min, ExecutionTimeLimit 1h).
- Logik: (1) ModelMigrationToM — prüft ob R:/Z: erreichbar UND ob letzter Lauf im
Migrations-Log `0 FAIL` meldet; sonst Re-Run (robocopy überspringt Fertiges). (2) Wasabi-Jobs —
`rclone size` Quelle vs. Ziel, bei Ziel<Quelle und Task nicht schon laufend: `Start-ScheduledTask`.
(3) ComfyUI-Orchestrator (Port 8197) wartet bis gesund (max 2min), liest `jobs_state.json`,
filtert Jobs mit `status=error` + `"neu gestartet"` (= durch einen Neustart abgebrochen),
schreibt sie nach `M:\boot-resume-pending-jobs.json`. **Kein automatisches Neu-Einreihen per
Default** (GPU-Zeit/Kosten, Duplikat-Risiko) Parameter `-ResubmitPendingRenderJobs` vorhanden,
falls gewünscht.
- **Dry-Run erfolgreich** (2026-07-21 21:30-21:33, `-DryRun`, keine Seiteneffekte):
- R:\comfyui / Z:\ki-modelle-backup: beide aktuell erreichbar (weil matthias-Session offen ist).
- ModelMigrationToM: kein "ENDE Migration"-Eintrag im Log würde Re-Run anstoßen.
- WasabiSync-VideoTransfer: Quelle 2.340.268.456.018 B, Ziel 133.503.175.414 B (läuft schon,
State=Running nicht angefasst, Begleit-Task deckt Kaltstart ab).
- WasabiSync-U525566: Quelle 225.181.959.871 B, Ziel 210.507.535.710 B (93% fertig, Ready,
NICHT laufend würde im Realmodus neu gestartet).
- Orchestrator: gesund, 1 durch einen früheren Neustart abgebrochener Job gefunden und nach
`M:\boot-resume-pending-jobs.json` geschrieben.
## Gesamtstatus
**JA, mit einer bekannten Restlücke:** nach einem Reboot laufen ComfyUI-Server, BarbyOrchestrator,
JobLivenessWatchdog (schon vorher AtStartup), alle Barby-Watcher/-Sync (jetzt direkt oder über
`-AtBoot`-Begleit-Task), beide Wasabi-Kopien und der neue Boot-Resume-Orchestrator automatisch an.
**Einzige Ausnahme:** ModelMigrationToM braucht R:\/Z:\, die an interaktive Logons hängen ohne
AutoLogon (aktuell aus) bleibt das nach einem kalten kompletten kompletten Reboot liegen, bis
sich mcp oder matthias einloggt. Boot-Resume-Orchestrator holt es dann automatisch nach, sobald
die Laufwerke da sind (kein manuelles Nachschieben nötig) nur der Zeitpunkt ist nicht
"sofort nach Reboot", sondern "sobald jemand eingeloggt ist".
**Kein Reboot durchgeführt.** Alle Aussagen oben sind über `Get-ScheduledTask`, `-DryRun`-Lauf und
direkte Zustandsprüfung (nicht behauptet) verifiziert.