# ADR-0004: Web-Kiosk mit Epiphany statt Terminal- oder nativer GTK-Oberfläche **Status:** Beschlossen. Zwischenzeitlich durch ADR-0005 in der Browserwahl ersetzt (Chromium), dann per ADR-0006 wieder zurückgenommen — die Browserwahl aus dieser ADR (Epiphany) gilt wieder vollständig. **Datum:** 20.07.2026 ## Kontext Der interaktive Ablauf (F-005, `10-interactive-provisioning-flow.md`) läuft aktuell als reines Terminal-Programm: `installer.sh` startet automatisch in einem `gnome-terminal` (siehe `13-live-provisioning-boot.md`) und fragt Eingaben über `read -p` ab. Mit der Live-ISO (ADR-0003) steht jetzt eine vollwertige Desktop-Umgebung zur Verfügung, in der sich eine frei gestaltbare, gebrandete Oberfläche für Workspace-Auswahl und Provisioning-Server-Authentifizierung bauen lässt, statt eines reinen Text-Interfaces. ## Entscheidung Die interaktive Oberfläche wird als lokale Web-Anwendung gebaut, angezeigt in einem Browser-Kiosk-Fenster, nicht als native GTK-Anwendung. Als Browser wird Epiphany (GNOME Web) im Application-Mode (`--application-mode`) verwendet, nicht Firefox und nicht Chromium. Begründung: Epiphany ist auf dem verwendeten Live-Image (Fedora Cinnamon Live) bereits vorhanden, ebenso wie Firefox. Es sind keine zusätzlichen Pakete oder Downloads beim Boot nötig. Epiphany ist WebKitGTK-basiert und startet spürbar schneller und ressourcenschonender als das Gecko-basierte Firefox. Der Application-Mode liefert laut Dokumentation ein chromeloses Fenster ohne Adressleiste, Tabs oder Menüs — die Grundlage für einen Kiosk-artigen Auftritt ohne Fremdsoftware. (Korrigiert 22.07.2026: In der Praxis unbrauchbar für skriptgesteuerte Einrichtung, siehe „Fund 2" unten — tatsächlich verwendet wird `--private-instance` mit sichtbarer Symbolleiste.) Chromium wurde geprüft und ist auf diesem Image nicht vorhanden; es hätte nachinstalliert werden müssen. Die fachliche Logik der einzelnen Ablaufschritte (Netzwerk, Hardware, Aktivierung, Handshake, Bereitstellungsvorlage-Auflösung, Commit Point, Runtime Blueprint, Backend) bleibt in den bestehenden Bash-Modulen. Die Web-Oberfläche ist ausschließlich Präsentationsschicht. ## Konsequenzen Der Autostart-Mechanismus aus `13-live-provisioning-boot.md` (Dracut-Hook, `/updates`-Payload) wechselt von „Terminal mit `installer.sh`" auf „Epiphany im Application-Mode mit einer lokalen Kiosk-Seite". Wie die Web-Oberfläche mit den bestehenden Bash-Modulen kommuniziert: entschieden in ADR-0007 (22.07.2026) — ausschließlich über den Provisioning Server, keine direkte Kommunikation, kein lokales JSON-File. Der automatisierte Modus (`tuxflotte.mode=auto`) benötigt keine grafische Oberfläche, da er ohne Benutzereingabe abläuft. Die Kiosk-Oberfläche betrifft ausschließlich den interaktiven Modus. **Fund nach dem Revert von ADR-0006 (21.07.2026): Epiphany startete gar nicht.** Realer Boot-Test zeigte keinen laufenden Epiphany-Prozess. Manueller Aufruf des exakten `.desktop`-Kommandos auf der Live-VM lieferte die Ursache direkt: `--profile must be an existing directory when --application-mode is requested` (Abort, Core Dump). Epiphany legt das per `--profile=` angegebene Verzeichnis anders als angenommen **nicht selbst an** — `/home/liveuser/.local/share/tuxflotte-kiosk` existierte nie, weder von uns ausgeliefert noch von Epiphany erzeugt. Das war die tatsächliche Ursache, nicht die zuvor beobachtete (harmlose) Warnung zum Fehlschlagen des Werbeblocker-Filterlisten-Downloads. Fix v1: `tuxflotte-installer.desktop`s `Exec=` legt das Verzeichnis jetzt selbst an, bevor Epiphany startet: `sh -c "mkdir -p /home/liveuser/.local/share/tuxflotte-kiosk && exec epiphany ..."`. Als `liveuser` selbst angelegt (nicht zur Build-Zeit mitgeliefert), damit die Berechtigungen automatisch stimmen — ein zur Build-Zeit mitgeliefertes Verzeichnis würde beim `xorriso`-Payload-Build auf root-Eigentümerschaft gezwungen (siehe `13-live-provisioning-boot.md`, `-chown_r 0 /updates`), was Epiphany als `liveuser` beim Schreiben von Cookies/Cache dort vermutlich behindert hätte. **Fund 2 (22.07.2026): Fix v1 reichte nicht — Application-Mode braucht eine echt installierte Web-App, kein Profilverzeichnis reicht.** Erneuter manueller Testlauf des exakten (gefixten) `.desktop`-Kommandos lieferte einen neuen, tieferliegenden Fehler: `Profile directory ... does not begin with required web app prefix org.gnome.Epiphany.WebApp_`. Lokal (Epiphany 43.1 ist zufällig auf dem Entwicklungsrechner installiert) nachgestellt und mit korrekt benanntem Verzeichnis erneut getestet — der Namenspräfix-Fehler verschwindet, aber ein neuer, härterer Fehler folgt: `Epiphany is trying to access web app settings outside web app mode. Your web app may be broken.` — der Application-Mode verlangt zusätzlich eine unter `xdg-desktop-portal` registrierte `.desktop`-Datei und interne GSettings-Metadaten, die normalerweise ausschließlich durch Epiphanys eigene "Install as Web Application"-GUI-Aktion entstehen (kein dokumentiertes CLI-Äquivalent gefunden, siehe Diskussion vom 21.07.2026). `--application-mode` ist damit für eine rein skriptgesteuerte Einrichtung ohne einmalige GUI-Interaktion nicht praktikabel — unabhängig vom Profilverzeichnisnamen. **Fix v2: `--private-instance` statt `--application-mode`.** `--private-instance --profile=` durchläuft dieselbe Webapp-Validierung nicht (lokal verifiziert: kein Absturz mehr, nur harmlose Warnungen zu fehlendem Extensions-Verzeichnis und deprecated WebKit-Properties). Preis dafür: ein normales Epiphany-Fenster mit vollständiger Symbolleiste (Tabs, Menü, Adressleiste), nicht die reduzierte App-Mode-Optik — mehr sichtbares Chrome als ursprünglich angenommen, aber im Sinne von ADR-0006 (zuverlässiger Start vor Optik, Inhalt ohnehin zentral und nicht sensibel) bewusst in Kauf genommen. **Fund 3 (22.07.2026): Fix v2 crashte auf dem Zielsystem — UND riss die Cinnamon-Sitzung mit ("Cinnamon just crashed - fallback mode").** `journalctl --user -b` zeigte einen Coredump von `epiphany` (Version **50.1** auf dem Zielsystem, gegenüber der lokal zum Testen verwendeten 43.1 — die Versionsdifferenz erklärt, warum der lokale Test dieses Problem nicht aufdeckte) und separat einen abnormalen Absturz des `cinnamon`-Prozesses selbst kurz danach — vermutlich zusammenhängend (ein hart abstürzender Client kann eine Compositor-Sitzung destabilisieren), aber nicht zweifelsfrei belegt. Manueller Testlauf auf dem Zielsystem lieferte die exakte Ursache: `Cannot use --private-instance and --profile at the same time`. Beide Flags schließen sich in Epiphany 50.1 aus — laut Hilfetext ist `--profile=DIR` selbst schon "Custom profile directory **for private instance**", `-p` obendrauf ist redundant und wird abgelehnt. **Fix v3: nur `--profile=`, ohne `--private-instance` und ohne `--application-mode`.** Lokal erneut verifiziert (Epiphany 43.1): kein Absturz, nur dieselben harmlosen Warnungen wie zuvor. Wichtiger Vorbehalt aus Fund 3: die lokale Testumgebung (Epiphany 43.1) hat sich bereits einmal als unzureichend erwiesen, um exakte Flag-Kombinationen des Zielsystems (Epiphany 50.1) zu verifizieren — ein lokal sauberer Test ist ein Signal, keine Garantie mehr. **Erfolg (22.07.2026): Epiphany startet.** Fix v3 hat auf dem echten Zielsystem funktioniert. Drei kleinere Nachbesserungen direkt danach beobachtet und behoben, alle in `opt/tuxflotte/kiosk/start-kiosk.sh` (löst jetzt `tuxflotte-installer.desktop`s `Exec=` auf, statt einer wachsenden `sh -c "..."`-Inline-Zeile — vermeidet weitere Quoting-Verschachtelung): - **Epiphany fragt beim ersten Start, ob es Standardbrowser werden soll.** Schema-Default von `ask-for-default` in `org.gnome.Epiphany` ist `true` (per `gschema.xml` verifiziert). Fix: `dconf write /org/gnome/epiphany/ask-for-default false` vor dem Epiphany-Start. - **Keine deutsche Tastaturbelegung in der grafischen Sitzung.** `vconsole.keymap=de` (Kernel-Cmdline) gilt nur für die Textkonsole, nicht für X11/Wayland. Fix: `dconf write /org/gnome/desktop/input-sources/sources "[('xkb', 'de')]"` — Cinnamon übernimmt dconf-Änderungen an diesem Schlüssel live, kein Relogin nötig. - **Laufende SELinux-Security-Benachrichtigungen** (siehe auch die beiden AVC-Meldungen vom 21.07.: "passwd (create)", "accounts-daemon (watch)"). Kommen von `sealert`/`setroubleshootd`, ausgelöst über `/etc/xdg/autostart/sealertauto.desktop` (Pfad per `dnf repoquery -l setroubleshoot` verifiziert, nicht geraten). Fix: eigene `sealertauto.desktop` mit `Hidden=true` im `live-updates`-Payload überschreibt die Fedora-eigene Datei am selben Pfad. SELinux-Enforcement selbst bleibt unverändert aktiv, nur die Desktop-Benachrichtigung wird unterdrückt. Alle drei lokal auf Korrektheit der dconf-Syntax geprüft (`dconf write`/`dconf read` roundtrip). Per echtem Boot verifiziert (22.07.2026): Standardbrowser-Dialog weg, SELinux-Benachrichtigungen weg — beide erfolgreich. Deutsche Tastatur **noch nicht** wirksam: `org.gnome.desktop.input-sources` allein reicht nicht, Cinnamon liest offenbar sein eigenes, paralleles `org.cinnamon.desktop.input-sources`-Schema (beide Schemas koexistieren auf dem System, aber Cinnamon scheint nur seines zu beachten). Fix: zusätzlich `dconf write /org/cinnamon/desktop/input-sources/sources "[('xkb', 'de')]"`. **Zusätzliche Kiosk-Bereinigung (22.07.2026):** Desktop-Symbole und Panel-Inhalte sollen weg, damit möglichst nur das Epiphany-Fenster sichtbar ist. `dconf write /org/nemo/desktop/show-desktop-icons false` (Nemo verwaltet die Desktop-Icons). Der erste Versuch, das Panel per `panels-enabled = []` komplett zu entfernen, löste beim echten Boot-Test Cinnamons eigenen Sicherheits-Dialog aus: "You don't have any panels added. Do you want to open panel settings?" — im Cinnamon-Quellcode (`js/ui/panel.js`, ~Zeile 879) fest verdrahtet als Reaktion auf eine Laufzeit-**Änderung** von `panels-enabled` auf leer (nicht beim Sitzungsstart selbst, da unser Autostart-Skript den Wert erst nach dem Start von Cinnamon ändert) — keine Möglichkeit, ihn zu unterdrücken, ohne die Panel-Anzahl unverändert zu lassen. Fix, mit Absicht so gewählt statt eines echten Null-Panel-Setups (das bräuchte einen systemweiten dconf-Default vor dem Cinnamon-Start, deutlich mehr Aufwand/Risiko): `panels-enabled` bleibt unangetastet, stattdessen wird nur `enabled-applets` auf zwei nützliche Einträge reduziert — `window-list@cinnamon.org` (damit ein Nutzer ein versehentlich minimiertes Epiphany-Fenster wiederherstellen kann) und `power@cinnamon.org` (Shutdown/Reboot bleiben erreichbar). Alle anderen Applets (Menü, Systray, Uhr, Workspace-Switcher etc.) entfernt. Lokal auf dconf-Syntax geprüft. Noch nicht per Boot verifiziert. **Korrigiert (23.08.2026, bei der Gegenlese gegen den tatsächlich ausgelieferten Code gefunden):** Der oben genannte `grouped-window-list@cinnamon.org` war ein Fehler in diesem ADR selbst, nicht eine spätere Kursänderung — `live-updates/opt/tuxflotte/kiosk/start-kiosk.sh` verwendet laut Git-Historie seit dem allerersten Commit (22.07.2026) durchgehend die einfache Variante `window-list@cinnamon.org`, bewusst nicht die gruppierte: Letztere liefert standardmäßig feste „Pinned Apps"-Starter (`firefox.desktop`, `org.gnome.Terminal.desktop`, `nemo.desktop`) mit, die auch nach Entfernen aller anderen Applets im Panel sichtbar blieben — die einfache Variante kennt kein Pinned-Apps-Konzept, zeigt ausschließlich tatsächlich offene Fenster. Diese Begründung stand nur als Code-Kommentar, nie in diesem Dokument.