Doku 2026-07-21 21:42: Reboot-Persistenz VM302 (AtStartup-Trigger, Boot-Resume-Orchestrator, AutoLogon-Luecke, Dry-Run-Beweis)

nachtplan-2026-07-21.md

@@ -0,0 +1,91 @@
+# 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.