admin/platform-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
platform-docs/adr/0006-kiosk-ui-zurueck-zu-epiphany.md
Thomas Stallinger 2f1300940c docs: record kiosk-UI journey, WLAN autoprovisioning model, and TUXFLOTTE ISO label 
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>
2026-07-22 12:16:25 +02:00

4.4 KiB
Raw Blame History

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).