Thomas Stallinger
e96fbd4733
ADR-0006: Der zitierte Befehl (epiphany --application-mode --profile=...)
wurde nachweislich nie ausgeliefert - ADR-0004s eigene, einen Tag später
datierte Folgeuntersuchung (Fund 2) stellte fest, dass --application-mode
für skriptgesteuerte Einrichtung unbrauchbar ist. Der tatsächlich seit dem
allerersten Commit ausgelieferte Befehl (start-kiosk.sh) nutzt nur
--profile, nie --application-mode. Diese Diskrepanz wurde beim ersten
Lesen von ADR-0004/0006 in einer früheren Session bereits bemerkt, aber
nie zu Ende verfolgt - jetzt korrigiert, an beiden Stellen (Entscheidung +
Konsequenzen), inkl. Verifikation gegen den echten Code.
ADR-0004: 'grouped-window-list@cinnamon.org' war von Anfang an falsch
dokumentiert - der Code verwendet seit demselben Ausgangscommit bewusst
das einfache 'window-list@cinnamon.org' (Begründung stand nur als
Code-Kommentar: die gruppierte Variante brachte ungewollte Pinned-Apps-
Starter mit). Kein späterer Kurswechsel, sondern ein Autorenfehler im
ADR selbst.
ADR-0018: kleinere Wortwahlkorrektur ('gestrichelte' -> 'durchgezogene'
Konturlinien - das SVG hat kein stroke-dasharray, die Linien sind nicht
gestrichelt).
Alle 19 ADRs vollständig neu gelesen (nicht nur grep-Stichproben),
Cross-Referenzen und Struktur erneut geprüft - sonst keine weiteren
Funde.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
11 KiB
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.desktops 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=<Verzeichnis> 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=<Verzeichnis>, 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.desktops 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-defaultinorg.gnome.Epiphanyisttrue(pergschema.xmlverifiziert). Fix:dconf write /org/gnome/epiphany/ask-for-default falsevor 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 perdnf repoquery -l setroubleshootverifiziert, nicht geraten). Fix: eigenesealertauto.desktopmitHidden=trueimlive-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.