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