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>
32 lines
3.3 KiB
Markdown
32 lines
3.3 KiB
Markdown
# 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.sh` fragt 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.
|