Beim Commander live aufgetreten: Der Installer meldete
"FEHLER: FEHLER: Zugriff verweigert" samt dem Tipp, die IP koenne falsch sein -
und das, NACHDEM Worker-Code, Abhaengigkeiten und HandBrake schon fertig waren.
Die IP war also nie das Problem.
URSACHE: schtasks /create mit /tn "RippyWorker" legt die Aufgabe im
WURZELORDNER der Aufgabenplanung an, und das verlangt Administratorrechte. Der
Installer laeuft normal ohne. schtasks schrieb "FEHLER: Zugriff verweigert."
nach stderr, und weil im Skript $ErrorActionPreference = "Stop" steht, machte
PowerShell daraus einen TERMINIERENDEN Fehler - der catch-Block riss damit die
komplette Installation ab, obwohl nur der Autostart fehlte. Das doppelte
"FEHLER: FEHLER:" war der Hinweis: der aeussere Handler setzt sein Praefix vor
eine Meldung, die selbst schon mit "FEHLER:" begann, also aus schtasks kam.
FIX, zwei Teile:
1. Autostart ueber den Autostart-ORDNER statt schtasks. Eine Verknuepfung in
[Environment]::GetFolderPath("Startup") braucht NIE Adminrechte - und der
Nutzer kann sie dort selbst sehen und loeschen. Auf diesem Windows-PC
gegengeprueft: Verknuepfung angelegt (1047 Bytes) mit Admin=False.
2. Ein Fehlschlag beim Autostart ist jetzt eine WARNUNG in eigenem try/catch,
kein Abbruch. Der Worker ist zu dem Zeitpunkt fertig und startbar, und der
Text sagt das auch - plus den Handweg (shell:startup).
In BEIDEN Installern (install-gui.ps1 und install.ps1, dort mit -Autostart) -
der CLI-Weg hatte denselben Fehler. uninstall.ps1 raeumt jetzt die
Verknuepfung weg UND versucht weiter schtasks /delete, damit aeltere
Installationen sauber verschwinden.
RippyWorkerSetup.exe neu gebaut (50688 -> 52736 Bytes): die GUI ist in der .exe
eingebettet, ohne Rebuild wirkt der Fix beim Nutzer nicht.
Nebenbei: build-exe.ps1 hatte zwei Gedankenstriche. Ausgelieferte .ps1 muessen
reines ASCII sein (PowerShell 5.1 liest sie als ANSI) - jetzt sind alle drei
Skripte ASCII-rein und parsen fehlerfrei.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Commander-Einwand: .vbs ist abgekuendigt (Win11 24H2 Feature-on-Demand) und
wird oft als gefaehrlich geflaggt. Loesung: echte .exe.
- RippyWorkerSetup.exe (50 KB): install-gui.ps1 via ps2exe kompiliert —
eingebettetes Rippy-Disc-Icon (deploy/worker-windows/rippy.ico), kein
Konsolenfenster (-noConsole), WinForms (-STA). E2E getestet: Fenster
oeffnet, conhost-Zaehler unveraendert (kein Konsolenfenster).
Vorgebaut auf Windows (build-exe.ps1) + committet — eine Windows-.exe
kann nicht von Linux (Rippy-Host) gebaut werden. WICHTIG: friert KEINE
Versionen ein — HandBrake wird zur Laufzeit (GitHub latest) und der
Worker-Code live von Rippy geholt; nur bei GUI-Aenderungen neu bauen.
- API: GET /worker-setup/windows-exe (FileResponse); Dockerfile kopiert die
.exe ins Image. .gitattributes: *.exe/*.ico als binary.
- UI (Worker -> Windows): 'Installer herunterladen (.exe)' als Haupt-Weg
(generisch, GUI fragt Adresse ab; die einzutragende IP wird als Hinweis
angezeigt). .vbs-Erzeugung entfernt. CLI bleibt Profi-Alternative.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Hitonabi