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>
3.3 KiB
ADR-0007: Web-Kiosk und Bash-Module kommunizieren ausschließlich über den Provisioning Server
Status: Beschlossen Datum: 22.07.2026
Kontext
ADR-0004 hat die Frage, wie die Web-Oberfläche (Kiosk-Browser) mit den bestehenden Bash-Modulen (installer.sh und seine Module) kommuniziert, ausdrücklich offengelassen ("Zustand aus /run/tuxflotte/*.json lesen, Aktionen auslösen — ist noch nicht entschieden").
Die Kiosk-Seite soll, konsistent mit dem Grundprinzip aus ADR-0003 (Inhalte kommen zur Laufzeit aus dem Netz, nicht vom Medium), von anode.tuxflotte.de (dem Provisioning Server) geladen werden — nicht von der lokalen Platzhalter-Datei, die aktuell in live-updates/opt/tuxflotte/kiosk/index.html liegt.
Damit entfällt eine naheliegende, aber technisch nicht tragfähige Idee: dass die im Browser laufende Seite selbst eine lokale JSON-Datei schreibt, die installer.sh dann liest. Eine Webseite läuft im Browser-Sandbox und kann nicht auf beliebige lokale Dateipfade schreiben.
Entscheidung
Die Web-Oberfläche und die Bash-Module kommunizieren nie direkt miteinander. Beide sprechen unabhängig voneinander mit dem Provisioning Server per HTTP:
- Die Kiosk-Seite (vom Server selbst ausgeliefert) übermittelt Nutzerentscheidungen (Workspace-Auswahl, Bestätigungen etc.) per HTTP-Request an die bestehende Server-API — analog dazu, wie die Bash-Module heute schon für Aktivierung und Handshake mit dem Server sprechen.
installer.shfragt seinerseits beim Server ab, ob und wie die Interaktion abgeschlossen wurde (Polling oder eine vergleichbare Abfrage eines definierten Endzustands), statt eine lokal geschriebene Datei zu lesen.
Der Provisioning Server bleibt damit alleinige Quelle der Wahrheit für den Ausgang des interaktiven Ablaufs — konsistent mit dem bereits etablierten Muster bei Bereitstellungsvorlage/Assignment/Activation (siehe 09-data-model-v1.md).
Konsequenzen
Es wird kein dateibasierter IPC-Mechanismus zwischen Browser und Bash-Modulen gebraucht. Die bereits vorhandene HTTP-Anbindung der Bash-Module (Aktivierung, Handshake) wird um Abfrage-/Polling-Logik für den Ausgang des interaktiven Ablaufs erweitert.
Diese ADR legt das Kommunikationsmodell fest, nicht die konkreten API-Endpunkte oder das genaue Polling-Verfahren — das ist Aufgabe der eigentlichen Umsetzung des interaktiven Ablaufs (F-005, 10-interactive-provisioning-flow.md) und der Provisioning-API (08-provisioning-api.md), wenn diese ansteht.
Die Kiosk-Seite ist damit von Netzwerkzugriff auf den Server abhängig, um überhaupt etwas anzeigen zu können — das ist bereits vorausgesetzt, da Netzwerk-Einrichtung (05_network.sh) als "always"-Modul vor jeder Moduswahl läuft (siehe 13-live-provisioning-boot.md).
Die in ADR-0006 aufgeworfene Idee eines Watchdogs, der bei geschlossenem Browser einen Reboot auslöst, bleibt bewusst zurückgestellt und wird von dieser Entscheidung entkoppelt: Sie betrifft Kiosk-Absicherung (verhindert Verlassen des Kiosk-Kontexts), nicht das "fertig"-Signal für den interaktiven Ablauf — Letzteres kommt jetzt aus dem Server-Zustand, nicht aus dem Prozessstatus des Browsers. Der Watchdog ergibt erst Sinn, sobald der Server-seitige Abschluss-Zustand definiert ist, damit er zwischen normalem Abschluss und tatsächlichem Verlassen des Kiosks unterscheiden kann.