Thomas Stallinger
2f1300940c
Kiosk UI: Chromium was evaluated as an Epiphany alternative (ADR-0005) after ADR-0004's application-mode approach turned out unusable end-to-end, then abandoned after four distinct real-boot failures in a row (ADR-0006) in favor of a hardened plain --profile Epiphany launch. ADR-0004 amended with the actual fix history (profile directory creation, application-mode's undocumented web-app requirement, --private-instance/--profile conflict on the target's Epiphany 50.1 vs. the 43.1 used for local testing). ADR-0007 resolves ADR-0004's open question: the kiosk web UI and installer.sh never talk directly, only via the provisioning server. WLAN autoprovisioning: customer profile gets an "Autoprovisionierung" flag plus WLAN credentials, driving self-service generation of a personalized ISO with the credentials baked in as a NetworkManager profile — works from device one, no persistent on-stick state needed. Personalizing the build this way also motivated giving the ISO its own volume label (TUXFLOTTE) instead of the source Fedora label. Also folds in the EROFS root-cause writeup and the Ubuntu-live-medium alternative noted for a future ISO rework, and brings roadmap/installer-roadmap.md's checkboxes in line with actual status. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
44 lines
4.4 KiB
Markdown
44 lines
4.4 KiB
Markdown
# 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ü.
|
|
|
|
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 --application-mode --profile=...` wie vor ADR-0005.
|
|
|
|
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).
|