platform-docs/adr/0006-kiosk-ui-zurueck-zu-epiphany.md

ADR-0006: Zurück zu Epiphany für den Kiosk-Modus

Status: Beschlossen Datum: 21.07.2026

Kontext

ADR-0005 entschied sich für Chromium statt Epiphany, weil Epiphany im Application-Mode kein wirklich chromeloses Fenster lieferte (Adressleiste und Fenstermenü blieben sichtbar).

Die Umsetzung von Chromium erwies sich als Sackgasse: Vier reale Boot-Tests in Proxmox scheiterten nacheinander an vier unterschiedlichen Fehlerklassen, jedes Mal in einer anderen Schicht der Lösung:

1. dnf --installroot direkt ins Live-Payload installiert → hätte /etc/passwd überschrieben (liveuser wäre verschwunden).
2. Fix (nur usr/ kopieren) reichte nicht → usr/ enthält alle ~350 Basis-Pakete → Kernel Panic beim Boot, weil systemd/bash/glibc des Live-Systems überschrieben wurden.
3. Fix (Isolation unter /opt/tuxflotte/chromium) behob den Absturz, aber der Dracut-Hook kopierte hunderttausende lose Dateien vor dem Pivot — mehrere Minuten Bootzeit, zusätzlicher RAM-Druck.
4. Fix (Auslieferung als SquashFS-Image, gemountet statt kopiert) behob die Bootzeit, aber Chromium startete gar nicht (Invalid file descriptor to ICU data received — /proc/self/exe zeigte auf den falschen Pfad wegen des eigenen Loader-Aufrufs).

Der vierte Fix behob das ICU-Problem nachweislich (lokal per strace verifiziert), aber der reale Boot-Test zeigte danach immer noch kein laufendes Chromium — vermutlich der beim vierten Fix bereits vermutete chrome_crashpad_handler-Folgefehler, aber nicht mehr im Detail untersucht, weil zu diesem Zeitpunkt das Muster selbst zur Entscheidungsgrundlage wurde: vier verschiedene, jeweils erst durch einen echten Boot-Test sichtbare Fehlerklassen in Folge sind kein Zufall, sondern strukturell — ein komplettes, fremdes Chromium-Paket samt ~350 transitiven Abhängigkeiten in eine laufende, andere Live-Umgebung zu verpflanzen, kämpft gegen die Art, wie Chromium gebaut und paketiert ist.

Entscheidung

Zurück zu Epiphany im Application-Mode (epiphany --application-mode --profile=/home/liveuser/.local/share/tuxflotte-kiosk, wie ursprünglich in ADR-0004 beschrieben), trotz sichtbarer Adressleiste und Fenstermenü.

Korrigiert (23.08.2026, bei der Gegenlese gefunden): Der hier genannte Befehl wurde so nie ausgeliefert. ADR-0004s eigene, einen Tag später datierte Folgeuntersuchung (Fund 2, 22.07.2026) stellte fest, dass --application-mode für eine rein skriptgesteuerte Einrichtung unbrauchbar ist (verlangt eine nur per GUI erzeugbare Webapp-Registrierung) — der tatsächlich funktionierende und bis heute unverändert ausgelieferte Befehl (live-updates/opt/tuxflotte/kiosk/start-kiosk.sh, seit dem allerersten Commit vom 22.07.2026) ist epiphany --profile=/home/liveuser/.local/share/tuxflotte-kiosk ..., ganz ohne --application-mode. Dieses Dokument wurde nie mit diesem am selben Tag gewonnenen Fund nachgezogen — die grundsätzliche Entscheidung dieses ADRs (zurück zu Epiphany, sichtbare Adressleiste bewusst in Kauf genommen) bleibt davon unberührt, nur der zitierte Befehl war falsch.

Das ist explizit kein Kompromiss unter Zeitdruck, sondern eine bewusste Neubewertung des ursprünglichen Ablehnungsgrundes: die sichtbare Adressleiste ist in der Praxis kaum relevant, weil

• der angezeigte Inhalt zentral vom Provisioning Server bereitgestellt wird, nicht hartkodiert auf der ISO liegt — es gibt keine sensiblen, auf dem Medium gespeicherten Inhalte, die ein Benutzer über die Adressleiste erreichen könnte,
• die Live-Umgebung ohnehin eine Wegwerf-Sitzung ohne persistente Nutzerdaten ist,
• ein Benutzer, der während der Installation z.B. Nachrichten liest, kein Sicherheitsproblem darstellt, nur ein kosmetisches.

Als möglicher künftiger Baustein (nicht jetzt umgesetzt): ein Watchdog-Prozess, der die Prozessliste beobachtet und bei geschlossenem Browser einen Reboot auslöst — würde ein versehentliches oder absichtliches Verlassen des Kiosk-Kontexts abfangen, unabhängig von der Adressleiste.

Die kosmetische Frage (Epiphany doch noch vollständig chromelos bekommen, z.B. per GTK-CSS-Override der Header-Bar-Widgets) ist explizit zurückgestellt, keine offene Anforderung für die aktuelle Version.

Konsequenzen

scripts/build.sh: install_chromium() und ihr Aufruf entfernt, check_dependencies() verlangt wieder nur xorriso, kein Root/dnf/Internetzugriff mehr nötig für den Build. tuxflotte-installer/build-deps/ (Fedora-GPG-Key) entfernt, da nicht mehr referenziert.

tuxflotte-installer.desktop: wieder epiphany --profile=... wie vor ADR-0005 (siehe Korrektur oben zum tatsächlichen Befehl — ohne --application-mode).

ADR-0005 bleibt als historischer Datensatz stehen (git-loses Repo — das ist die einzige Quelle für die dort dokumentierten, tatsächlich funktionierenden Techniken: Isolation unter /opt, Loader-Relokation für /proc/self/exe, SquashFS-Verpackung), gilt aber als überholt/verworfen.

Weitere Installer-ISO-Optimierung (inklusive einer möglichen erneuten Chromium-Bewertung, oder ob z.B. eine Ubuntu-basierte Live-ISO denselben EROFS-Bug hat) wird explizit auf eine spätere, dedizierte Überarbeitung der ISO verschoben — nicht Teil der aktuellen Arbeit. Priorität verschiebt sich zurück auf die eigentliche Provisionierungslogik (Runtime Blueprint u.a.).

Noch offen, unverändert seit ADR-0004: wie die Web-Oberfläche mit den bestehenden Bash-Modulen kommuniziert (Zustand lesen, Aktionen auslösen).