adr/0004-kiosk-ui-epiphany.md

@@ -1,6 +1,6 @@
 # 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.
+**Status:** Beschlossen
 **Datum:** 20.07.2026
 
 ## Kontext
@@ -21,7 +21,7 @@ Epiphany ist auf dem verwendeten Live-Image (Fedora Cinnamon Live) bereits vorha
 
 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.)
+Der Application-Mode liefert ein chromeloses Fenster ohne Adressleiste, Tabs oder Menüs — die Grundlage für einen Kiosk-artigen Auftritt ohne Fremdsoftware.
 
 Chromium wurde geprüft und ist auf diesem Image nicht vorhanden; es hätte nachinstalliert werden müssen.
 
@@ -31,32 +31,6 @@ Die fachliche Logik der einzelnen Ablaufschritte (Netzwerk, Hardware, Aktivierun
 
 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.
+Wie die Web-Oberfläche mit den bestehenden Bash-Modulen kommuniziert (Zustand aus `/run/tuxflotte/*.json` lesen, Aktionen auslösen), ist noch nicht entschieden und wird beim tatsächlichen Bau festgelegt.
 
 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=<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.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 — `grouped-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.

adr/0005-kiosk-ui-chromium.md

@@ -1,42 +0,0 @@
-# ADR-0005: Chromium statt Epiphany für den Kiosk-Modus
-
-**Status:** Verworfen durch ADR-0006 (21.07.2026) — vier reale Boot-Fehlschläge in Folge, siehe dort. Bleibt als historischer Datensatz stehen: die hier dokumentierten Techniken (Isolation unter `/opt`, Loader-Relokation, SquashFS-Verpackung) funktionierten einzeln nachweislich, nur in Summe erwies sich der Ansatz als zu fragil.
-**Datum:** 20.07.2026
-
-## Kontext
-
-ADR-0004 wählte Epiphany im Application-Mode (`--application-mode`) für die Kiosk-Oberfläche, unter anderem mit der Begründung, dieser Modus liefere "ein chromeloses Fenster ohne Adressleiste, Tabs oder Menüs".
-
-Der tatsächliche Test auf dem Live-System widerlegt das für den hier vorgesehenen Einsatzzweck: Epiphany im Application-Mode benötigt explizite Session-/Profildaten (den `--profile=<Verzeichnis>`-Aufbau, wie ihn die bisherige `tuxflotte-installer.desktop` verwendet hat) und liefert trotzdem ein Fenster mit sichtbarer Adresszeile und Fenstermenü — keinen echten Kiosk-Modus. Für eine gebrandete, eingabefreie Provisionierungsoberfläche ist das ungeeignet.
-
-## Entscheidung
-
-Statt Epiphany wird Chromium im echten Kiosk-Modus (`--kiosk`) verwendet.
-
-Chromiums `--kiosk`-Flag liefert ein vollständig chromeloses Fenster ohne Adressleiste und Menü, ohne dass vorab ein Profil oder eine Session angelegt werden muss — das Flag reicht für sich allein.
-
-Chromium ist auf dem verwendeten Fedora-Cinnamon-Live-Image nicht vorhanden (siehe ADR-0004) und muss daher zur Build-Zeit ins Live-Payload aufgenommen werden.
-
-Ursprünglich war geplant, das dadurch wachsende ISO im Gegenzug durch Entfernen großer, nicht benötigter Pakete (z.B. LibreOffice) auszugleichen. Das ist inzwischen verworfen (21.07.2026): Das würde eine Änderung an `/LiveOS/squashfs.img` selbst erfordern, und genau das ist der Bereich, der laut dem in `13-live-provisioning-boot.md` dokumentierten `erofs-utils`-Bug nachweislich destruktiv fehlschlägt. Stattdessen wird die durch Chromium entstehende Größe bewusst in Kauf genommen — siehe Konsequenzen.
-
-## Konsequenzen
-
-ADR-0004 wird in diesem einen Punkt korrigiert: der Browser für den Kiosk ist Chromium statt Epiphany. Die übrigen Entscheidungen aus ADR-0004 — Web-App statt native GTK-Anwendung, fachliche Logik bleibt in den bestehenden Bash-Modulen, die Web-Oberfläche ist ausschließlich Präsentationsschicht — bleiben unverändert gültig.
-
-Umgesetzt (21.07.2026), in zwei Anläufen:
-
-**Erster Anlauf (verworfen):** `dnf --installroot` in ein Wegwerf-Verzeichnis, danach `usr/` und `etc/chromium/` ins reale `updates/`-Payload kopiert (also in das echte `/usr` des Live-Systems gemergt). Das vermied zwar das `/etc/passwd`-Problem des allerersten Versuchs, übersah aber, dass `usr/` selbst alle ~350 transitiven Basis-Pakete enthält — `systemd`, `bash`, `glibc`, `coreutils`, `dbus`, `pam`, `util-linux`. Der reale Testboot in Proxmox endete in einem Kernel Panic ("Attempted to kill init! exitcode=0x00007f00", dekodiert als Exit-Status 127) — die frisch heruntergeladenen Versionen dieser Kerndateien haben die des Live-Systems überschrieben und PID 1 zerschossen.
-
-**Zweiter Anlauf (aktuell):** Vollständige Isolation statt Blockliste. Chromium landet nicht mehr in `/usr`, sondern komplett unter `/opt/tuxflotte/chromium/usr` — ein Pfad, der mit nichts auf dem Live-System kollidieren kann. Gestartet wird über `launch.sh`, das den mitgelieferten eigenen Loader (`ld-linux-x86-64.so.2 --library-path ...`) explizit aufruft, statt sich auf den Loader des Live-Systems zu verlassen (ein einfacher `exec` mit nur `LD_LIBRARY_PATH` gesetzt schlägt mit `undefined symbol ... GLIBC_PRIVATE` fehl, sobald Loader und libc aus unterschiedlichen Builds stammen — lokal reproduziert und verifiziert). Der Such-Suchpfad für Bibliotheken wird beim Start dynamisch durch Scannen aller Unterverzeichnisse unter `lib64`/`lib` ermittelt (nicht hartkodiert), weil Chromium auch private Paket-Unterverzeichnisse braucht (gefunden: `usr/lib64/samba/`) — lokal gegen die echte installierte Chromium-Binary getestet (`chromium-browser --version` liefert korrekt `Chromium 146.0.7680.164`).
-
-**Dritter Anlauf (aktuell): Auslieferung als SquashFS-Image statt loser Dateien.** Der zweite Anlauf löste die Sicherheits-/Korrektheitsprobleme, aber nicht die Performance: Der Dracut-Hook kopiert `/updates` vor dem Pivot Datei für Datei, und ~350 Pakete bedeuten hunderttausende kleine Dateien — auf echter Hardware dauerte allein dieser Kopiervorgang mehrere Minuten, obwohl die Gesamtgröße (~1,2 GB) dafür nicht groß genug wäre (dateianzahl-, nicht größengebunden). Zusätzlich verschärfte das erneut das RAM-Thema (bei 2 GB VM-RAM ~80% Auslastung während des Kopierens). Fix: `usr/` wird zur Build-Zeit mit `mksquashfs` (Standard-Tool, mit dem `erofs-utils`-Bug nicht verwandt) zu einer einzelnen komprimierten Datei gepackt (lokal getestet: 434 MB statt 1,2 GB, Setuid-Bit auf `chrome-sandbox` bleibt erhalten). `launch.sh` mountet diese Datei beim ersten Start per Loop-Mount nach `/opt/tuxflotte/chromium/usr` (nahezu verzögerungsfrei, keine RAM-Duplizierung, Daten bleiben komprimiert auf dem Medium und werden bei Bedarf eingelesen) — das räumt das RAM-Thema strukturell aus, nicht nur durch mehr RAM in der Test-VM.
-
-**Vierter Anlauf (aktuell): `/proc/self/exe`-Fix für die ICU-Ressourcenauflösung.** Der reale Testboot nach Anlauf 3 startete zwar (schnell, dank SquashFS), aber Chromium erschien nicht (`ps aux | grep chromium` fand nichts). `launch.sh` manuell ausgeführt lieferte `Invalid file descriptor to ICU data received`. Per `strace` lokal reproduziert und ursächlich geklärt: Chromium bestimmt sein eigenes Ressourcenverzeichnis über `dirname(readlink(/proc/self/exe))`. Weil `launch.sh` den Loader aus `usr/lib64/ld-linux-x86-64.so.2` direkt aufruft, zeigt `/proc/self/exe` auf den Loader selbst (in `usr/lib64/`), nicht auf `chromium-browser` (eine Ebene tiefer in `usr/lib64/chromium-browser/`) — Chromium sucht `icudtl.dat` deshalb am falschen Ort. Fix: eine Kopie des Loaders wird zur Build-Zeit direkt neben `chromium-browser` gelegt (`usr/lib64/chromium-browser/ld-linux-x86-64.so.2`) und von dort aus gestartet — `/proc/self/exe` zeigt dann korrekt ins richtige Verzeichnis. Lokal verifiziert: der ICU-Fehler verschwindet vollständig.
-
-Beim Weitertesten (lokal, ohne echten Fedora-Live-Boot) trat danach ein zweiter Fehler auf: `chrome_crashpad_handler` (Absturzbericht-Hilfsprozess, von Chromium selbst per `execve()` mit eigenem, nicht von uns kontrolliertem Pfad gestartet) scheiterte an fehlenden `GLIBC_2.38`/`GLIBC_2.39`-Symbolen im System-Loader. Sehr wahrscheinlich ein Artefakt der lokalen Testumgebung (Debian Bookworm, glibc von 2022) und kein Problem auf dem eigentlichen Zielsystem (Fedora Cinnamon Live 44, deutlich näher an der `dnf`-heruntergeladenen Version) — aber ohne echten Boot nicht abschließend auszuschließen. Als nächster Schritt bei erneutem Scheitern: `chrome_crashpad_handler` per denselben Loader-Trick abfangen, oder Absturzberichterstattung ganz deaktivieren.
-
-Details siehe `13-live-provisioning-boot.md`, Abschnitt „Autostart von installer.sh". Akzeptierter Nebeneffekt unverändert: `dnf` löst den vollen Abhängigkeitsbaum auf (351 Pakete), nicht nur Chromium plus tatsächlich fehlende Bibliotheken — eine gezielte Verschlankung ist mangels Lesezugriff auf die `squashfs.img` nicht verifizierbar.
-
-Neue Build-Voraussetzung: `build.sh` braucht jetzt Root-Rechte (`dnf --installroot` verlangt das) sowie Internetzugriff zu Fedora-Repos. Bewusster Sicherheits-Trade-off: `chrome-sandbox` (Setuid-Root-Helfer) wird zwar unverändert mitkopiert, aber ob er von dem neuen, isolierten Pfad aus funktioniert, ist ungeprüft — `launch.sh` startet vorerst mit `--no-sandbox`, vertretbar für eine Wegwerf-Live-Session ohne sensible Daten, aber keine Nebensächlichkeit. Noch nicht per echtem grafischem Live-Boot verifiziert.
-
-Die in ADR-0004 offen gelassene Frage, wie die Web-Oberfläche mit den bestehenden Bash-Modulen kommuniziert (Zustand lesen, Aktionen auslösen), bleibt unverändert offen und ist von der Browserwahl unabhängig.

adr/0006-kiosk-ui-zurueck-zu-epiphany.md

@@ -1,43 +0,0 @@
-# ADR-0006: Zurück zu Epiphany für den Kiosk-Modus
-
-**Status:** Beschlossen
-**Datum:** 21.07.2026
-
-## Kontext
-
-ADR-0005 entschied sich für Chromium statt Epiphany, weil Epiphany im Application-Mode kein wirklich chromeloses Fenster lieferte (Adressleiste und Fenstermenü blieben sichtbar).
-
-Die Umsetzung von Chromium erwies sich als Sackgasse: Vier reale Boot-Tests in Proxmox scheiterten nacheinander an vier unterschiedlichen Fehlerklassen, jedes Mal in einer anderen Schicht der Lösung:
-
-1. `dnf --installroot` direkt ins Live-Payload installiert → hätte `/etc/passwd` überschrieben (`liveuser` wäre verschwunden).
-2. Fix (nur `usr/` kopieren) reichte nicht → `usr/` enthält alle ~350 Basis-Pakete → Kernel Panic beim Boot, weil `systemd`/`bash`/`glibc` des Live-Systems überschrieben wurden.
-3. Fix (Isolation unter `/opt/tuxflotte/chromium`) behob den Absturz, aber der Dracut-Hook kopierte hunderttausende lose Dateien vor dem Pivot — mehrere Minuten Bootzeit, zusätzlicher RAM-Druck.
-4. Fix (Auslieferung als SquashFS-Image, gemountet statt kopiert) behob die Bootzeit, aber Chromium startete gar nicht (`Invalid file descriptor to ICU data received` — `/proc/self/exe` zeigte auf den falschen Pfad wegen des eigenen Loader-Aufrufs).
-
-Der vierte Fix behob das ICU-Problem nachweislich (lokal per `strace` verifiziert), aber der reale Boot-Test zeigte danach immer noch kein laufendes Chromium — vermutlich der beim vierten Fix bereits vermutete `chrome_crashpad_handler`-Folgefehler, aber nicht mehr im Detail untersucht, weil zu diesem Zeitpunkt das Muster selbst zur Entscheidungsgrundlage wurde: vier verschiedene, jeweils erst durch einen echten Boot-Test sichtbare Fehlerklassen in Folge sind kein Zufall, sondern strukturell — ein komplettes, fremdes Chromium-Paket samt ~350 transitiven Abhängigkeiten in eine laufende, andere Live-Umgebung zu verpflanzen, kämpft gegen die Art, wie Chromium gebaut und paketiert ist.
-
-## Entscheidung
-
-Zurück zu Epiphany im Application-Mode (`epiphany --application-mode --profile=/home/liveuser/.local/share/tuxflotte-kiosk`, wie ursprünglich in ADR-0004 beschrieben), trotz sichtbarer Adressleiste und Fenstermenü.
-
-Das ist explizit kein Kompromiss unter Zeitdruck, sondern eine bewusste Neubewertung des ursprünglichen Ablehnungsgrundes: die sichtbare Adressleiste ist in der Praxis kaum relevant, weil
-
-- der angezeigte Inhalt zentral vom Provisioning Server bereitgestellt wird, nicht hartkodiert auf der ISO liegt — es gibt keine sensiblen, auf dem Medium gespeicherten Inhalte, die ein Benutzer über die Adressleiste erreichen könnte,
-- die Live-Umgebung ohnehin eine Wegwerf-Sitzung ohne persistente Nutzerdaten ist,
-- ein Benutzer, der während der Installation z.B. Nachrichten liest, kein Sicherheitsproblem darstellt, nur ein kosmetisches.
-
-Als möglicher künftiger Baustein (nicht jetzt umgesetzt): ein Watchdog-Prozess, der die Prozessliste beobachtet und bei geschlossenem Browser einen Reboot auslöst — würde ein versehentliches oder absichtliches Verlassen des Kiosk-Kontexts abfangen, unabhängig von der Adressleiste.
-
-Die kosmetische Frage (Epiphany doch noch vollständig chromelos bekommen, z.B. per GTK-CSS-Override der Header-Bar-Widgets) ist explizit zurückgestellt, keine offene Anforderung für die aktuelle Version.
-
-## Konsequenzen
-
-`scripts/build.sh`: `install_chromium()` und ihr Aufruf entfernt, `check_dependencies()` verlangt wieder nur `xorriso`, kein Root/`dnf`/Internetzugriff mehr nötig für den Build. `tuxflotte-installer/build-deps/` (Fedora-GPG-Key) entfernt, da nicht mehr referenziert.
-
-`tuxflotte-installer.desktop`: wieder `epiphany --application-mode --profile=...` wie vor ADR-0005.
-
-ADR-0005 bleibt als historischer Datensatz stehen (git-loses Repo — das ist die einzige Quelle für die dort dokumentierten, tatsächlich funktionierenden Techniken: Isolation unter `/opt`, Loader-Relokation für `/proc/self/exe`, SquashFS-Verpackung), gilt aber als überholt/verworfen.
-
-Weitere Installer-ISO-Optimierung (inklusive einer möglichen erneuten Chromium-Bewertung, oder ob z.B. eine Ubuntu-basierte Live-ISO denselben EROFS-Bug hat) wird explizit auf eine spätere, dedizierte Überarbeitung der ISO verschoben — nicht Teil der aktuellen Arbeit. Priorität verschiebt sich zurück auf die eigentliche Provisionierungslogik (Runtime Blueprint u.a.).
-
-Noch offen, unverändert seit ADR-0004: wie die Web-Oberfläche mit den bestehenden Bash-Modulen kommuniziert (Zustand lesen, Aktionen auslösen).

adr/0007-web-kiosk-kommunikation-ueber-server.md

@@ -1,31 +0,0 @@
-# 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.

adr/0008-neugeraete-auto-modus-portal-bestaetigung.md

@@ -1,39 +0,0 @@
-# ADR-0008: Portal-Bestätigung für Neugeräte im Auto-Modus ohne Enrollment Session
-
-**Status:** Beschlossen
-**Datum:** 23.07.2026
-
-## Kontext
-
-`13-live-provisioning-boot.md` (Abschnitt "Auto-Modus-Gate") legte bisher fest, dass ein unbekanntes Gerät (`registration_status == "registered"`) niemals den automatisierten Ablauf durchläuft, unabhängig vom gewählten Bootmenüeintrag — die Geräteaufnahme blieb ausnahmslos an eine lokale, interaktive Bestätigung gebunden. Diese Formulierung war der Situation geschuldet, dass zum Zeitpunkt der ursprünglichen Entscheidung noch keine bessere Umsetzung für eine unbeaufsichtigte Neugeräte-Provisionierung im Auto-Modus vorlag.
-
-`11-device-enrollment.md` beschreibt daneben bereits **Enrollment Sessions**: zeitlich begrenzte, organisationsgebundene Vorab-Freigaben für geplante Massenrollouts (maximale Geräteanzahl, erlaubte Bereitstellungsvorlagen, widerrufbar, auditierbar). Diese lösen den Fall eines *geplanten* Rollouts, aber nicht den Fall eines *einzelnen, spontan gebooteten* Neugeräts ohne vorab eingerichtete Session — genau diese Lücke schließt die vorliegende Entscheidung.
-
-## Entscheidung
-
-Ein neues Gerät (`registration_status == "registered"`), das im Auto-Modus bootet und **nicht** durch eine aktive Enrollment Session abgedeckt ist, wird nicht mehr zwingend in den interaktiven Ablauf gezwungen. Stattdessen:
-
-1. Das Gerät durchläuft den üblichen Identifikations-Handshake (Geräte-ID wird dem Provisioning Server bekanntgegeben).
-2. Es geht anschließend in einen **Wartezustand ("on hold")** über — die destruktive Installation beginnt nicht.
-3. Ein Kunde bestätigt über die künftige Verwaltungsoberfläche die Registrierung des Geräts und weist ihm einen Workspace zu.
-4. Erst nach dieser serverseitig vermerkten, zentralen Bestätigung überschreitet der Orchestrator den Commit Point.
-
-Damit ergeben sich für neue Geräte im Auto-Modus zwei Freigabewege, die sich nicht überschneiden, sondern ergänzen:
-
-- **Mit abdeckender Enrollment Session:** vollständig unbeaufsichtigt, wie ursprünglich für Massenrollouts vorgesehen — die Vorab-Freigabe der Session deckt die Autorisierung ab.
-- **Ohne abdeckende Enrollment Session:** Einzel-Bestätigung über das Portal, wie oben beschrieben — für den spontanen, ungeplanten Fall.
-
-Die beiden Bootmodi bleiben dadurch klar unterscheidbar:
-
-- **auto:** bei Neugeräten ist stets eine zentrale Bestätigung/Festlegung notwendig — vorab durch eine Enrollment Session, oder nachträglich durch eine Portal-Bestätigung.
-- **interaktiv:** der Benutzer bestätigt und konfiguriert lokal am Gerät, ohne dass parallel eine zentrale Aktion nötig wäre.
-
-Für bereits bekannte Geräte (`registration_status == "existing"`) ändert sich nichts — die automatisierte Reprovisionierung ohne erneute Bestätigung bleibt wie in `11-device-enrollment.md` beschrieben.
-
-## Konsequenzen
-
-- Der Auto-Modus für Neugeräte ohne Enrollment Session ist ohne ein funktionierendes Verwaltungsportal (Registrierung + Workspace-Zuweisung) nicht nutzbar. Für den aktuellen Piloten irrelevant — dort kommt der interaktive Modus zum Einsatz (siehe Pilot-Roadmap).
-- Technisch lässt sich der Wartezustand mit demselben Fail-Closed-Baustein umsetzen, der für den interaktiven Ablauf bereits vorgesehen ist: `25_installation_confirm.sh` pollt im Auto-Modus den Server auf einen expliziten Freigabe-Zustand, statt eine TTY-Eingabe zu lesen — dieselbe Grundmechanik wie in ADR-0007 für die Kiosk-Kommunikation festgelegt.
-- Kein statisches Geheimnis auf dem Medium (Aktivierungscode o.ä.) autorisiert je allein eine destruktive Aktion — konsistent mit der in `11-device-enrollment.md` ohnehin schon vorgesehenen schrittweisen Ablösung des Aktivierungscodes.
-- Offen, nicht Teil dieser Entscheidung: das genaue Zusammenspiel zwischen Enrollment Session und Workspace-Zuweisung — ob eine Session mit genau einer erlaubten Bereitstellungsvorlage die Workspace-Wahl implizit vorwegnimmt, oder ob auch dort noch ein einzelner Bestätigungsschritt nötig ist.
-- `13-live-provisioning-boot.md` (Auto-Modus-Gate) und `11-device-enrollment.md` werden entsprechend angepasst.

adr/0009-anaconda-live-kickstart-verworfen.md

@@ -1,54 +0,0 @@
-# ADR-0009: Anaconda-Kickstart aus der laufenden Live-Sitzung heraus verworfen
-
-**Status:** Beschlossen
-**Datum:** 23.07.2026
-
-## Kontext
-
-`13-live-provisioning-boot.md` (Abschnitt "Nativer Installer aus der Live-Sitzung") legt fest, dass `backend_launch()` den nativen Installer explizit aus der bereits gebooteten Live-Sitzung heraus aufruft, mit der von `backend_generate_config()` erzeugten Kickstart-Datei. Für das Fedora-Backend hieße das: `anaconda` (bzw. `liveinst`) innerhalb der laufenden Cinnamon-Sitzung mit der generierten Kickstart-Datei starten.
-
-Vor der Implementierung wurde recherchiert und real getestet, ob das funktioniert.
-
-## Untersuchung
-
-Der `liveinst`-Wrapper (`/usr/bin/liveinst`, Teil des `anaconda`-Pakets) lehnt `ks=`/`kickstart=`-Argumente laut eigenem Quellcode aktiv ab und erzwingt stattdessen den interaktiven Modus — Zitat aus der Anaconda-Projektdokumentation: *"anaconda developers really, really do not want to support kickstart from liveinst!"*. Auch die eigene `anaconda --help`-Ausgabe dokumentiert `--kickstart KICKSTART_PATH` explizit als *"not supported for live installations"*.
-
-Direkter Test am Wrapper vorbei (`anaconda --liveinst --kickstart=<datei>`, auf echtem Fedora 44 / Anaconda 44.30-2.fc44) bestätigte das empirisch, mit einer noch ungünstigeren Fehlerart als "klar abgelehnt":
-
-- **Mit `-T` (Text-Modus):** Anaconda startet, übernimmt Sprache/Zeitzone/Partitionierungsart (`autopart`) korrekt aus der Kickstart-Datei, ignoriert aber `rootpw` und `user` **kommentarlos** — beide Felder mussten vollständig manuell nachgetragen werden ("Root-Konto ist deaktiviert", "Es wird kein Benutzer erstellt", trotz korrekter Kickstart-Zeilen). Kein Fehler, keine Warnung — nur eine leise, unvollständige Übernahme.
-- **Mit `-C` (Cmdline-Modus, laut Hilfetext für nicht-interaktive Automatisierung gedacht):** sauberer, aber ebenso eindeutiger Abbruch, Exit-Code 1, mit explizitem Log-Eintrag:
-  ```
-  pyanaconda.errors.CmdlineError: Die folgenden obligatorischen Speichen sind nicht beendet:
-  Installation Destination
-  Root password
-  User creation
-  ```
-  Anaconda selbst bewertet also `autopart`/`rootpw`/`user` aus der Kickstart-Datei als nicht abgeschlossen — trotz syntaktisch korrekter Angabe.
-
-Der zusätzlich dokumentierte Flag `--ks` (ohne die "not supported for live"-Einschränkung im Hilfetext) erwies sich als Sackgasse: in dieser Anaconda-Version nimmt `--ks` in der direkten Kommandozeilen-Nutzung keinen Wert entgegen (`error: argument --ks: ignored explicit argument`) — die Beschreibung im Hilfetext bezieht sich vermutlich auf den `inst.ks=`-Boot-Parameter, nicht auf diesen CLI-Flag bei direktem Programmaufruf.
-
-## Entscheidung
-
-Der native Installer wird **nicht** per Kickstart aus der laufenden Live-Sitzung heraus gestartet. Diese Umsetzung des in `13-live-provisioning-boot.md` beschriebenen Modells ("Nativer Installer aus der Live-Sitzung") ist für das Fedora-Backend nicht tragfähig.
-
-Ausdrücklich **nicht** gewählt: Anaconda umgehen und Partitionierung/Dateisystem/Bootloader selbst nachbauen (parted/mkfs/rsync/grub2-install) — zu hoher Wartungsaufwand, Verlust von Anacondas ausgereifter Partitionierungs-/Verschlüsselungs-/Secure-Boot-Logik.
-
-## Konsequenzen
-
-- `13-live-provisioning-boot.md` (Abschnitt "Nativer Installer aus der Live-Sitzung") muss überarbeitet werden, sobald der tatsächliche Weg feststeht — noch nicht Teil dieser Entscheidung.
-- Betroffene Anaconda-Version zur Einordnung: 44.30-2.fc44 ("bluesky", Pre-Release, neue WebUI-basierte Oberfläche) — die "Kickstart auf Live-Medien nicht unterstützt"-Haltung selbst ist aber laut Anaconda-Projektdokumentation langjährig und nicht auf diese Version beschränkt.
-
-## Update (23.07.2026): Muster erkannt, verfeinerter Prüfplan
-
-Weitere Recherche zeigt: das Problem ist nicht Fedora-spezifisch. Ubuntu/Subiquity (`autoinstall`) und Ubiquity (Preseed, älterer Mint-Installer) sind laut Dokumentation ebenfalls ausschließlich für eine Auslösung per **Kernel-Boot-Parameter** gebaut, nicht für einen Aufruf aus einer bereits laufenden Live-Sitzung heraus — dasselbe Muster wie bei Anaconda. Calamares (Basis einiger Mint-Editionen) hat dagegen unabhängig vom Zeitpunkt **grundsätzlich keinen** eingebauten unbeaufsichtigten Modus.
-
-Daraus folgt ein vielversprechenderer Ansatz als ein Distro-Wechsel: **zweistufiger Boot statt Aufruf aus der laufenden Sitzung.** Die Live-Sitzung macht weiterhin alles wie bisher (Netzwerk, Hardware, Handshake, interaktive/Auto-Entscheidung), löst am Ende aber keinen direkten Installer-Aufruf mehr aus, sondern setzt den passenden Boot-Parameter (`inst.ks=`, `autoinstall`, Preseed-Äquivalent) für den **nächsten** Boot und startet neu. Der native Installer läuft dann in genau der Betriebsart, für die er gebaut ist — kein Live-Sitzungs-Umweg. Das würde bedeuten, dass Fedora/Anaconda eventuell gar nicht aufgegeben werden muss.
-
-Offener Punkt dabei: das Medium ist laut WLAN-Autoprovisionierungs-Entscheidung (`13-live-provisioning-boot.md`) bewusst nicht dauerhaft beschreibbar — die generierte Konfigurationsdatei muss dem zweiten Boot also vermutlich über eine Server-URL zugestellt werden (`inst.ks=https://...`, passend zu ADR-0003), nicht über eine lokale Datei. Ob die frühe Dracut-Boot-Netzwerkumgebung dafür ausreicht (sie ist nicht dieselbe wie die volle NetworkManager-/WLAN-Konfiguration der laufenden Live-Sitzung), ist ungeklärt und Teil der folgenden Prüfschritte, nicht vorab gelöst.
-
-**Vereinbarter Prüfplan, in dieser Reihenfolge:**
-
-1. Klären, welchen Installer Linux Mint (Cinnamon) tatsächlich mitbringt (Ubiquity/Preseed oder Subiquity/Autoinstall) — die Seed-Daten (`installer_type: 'autoinstall'`) sind dahingehend noch unbestätigt, evtl. falsch benannt.
-2. **Fedora + Kickstart per Reboot zuerst testen**, nicht Distro wechseln — geringste Kosten, da ISO/VM/die gesamte Kiosk-Arbeit (Epiphany, Panel) erhalten bleiben, falls es funktioniert. Test: aus der laufenden Live-Sitzung heraus gezielt mit `inst.ks=<URL>` am Cmdline neu booten, beobachten ob Anaconda diesmal vollständig automatisiert durchläuft (inklusive der Zustellungsfrage oben).
-3. Nur falls Schritt 2 scheitert: dasselbe Reboot-Muster mit dem in Schritt 1 geklärten Ubuntu/Mint-Mechanismus.
-4. Nur falls auch das scheitert: Ultima Ratio wie oben — separates Netinstall-/Boot-Medium, inklusive der Grundsatzfrage, ob der interaktive Modus mangels grafischer Sitzung zugunsten von reinem Auto-Modus mit Portal-Bestätigung (ADR-0008) aufgegeben wird.

architecture/11-device-enrollment.md

@@ -118,7 +118,7 @@ Für ein bereits registriertes, über seinen Hardware-Fingerprint wiedererkannte
 
 Mit der Registrierung eines Geräts wird akzeptiert, dass es künftig auf diesem Weg ohne erneute interaktive Bestätigung neu installiert werden kann, solange es als bereits registriert erkannt wird.
 
-Diese Eigenschaft gilt ausschließlich für bereits registrierte Geräte. Die Aufnahme eines unbekannten Geräts bleibt in jedem Fall an eine explizite Bestätigung gebunden (siehe Sicherheitsprinzip unten) — lokal-interaktiv am Gerät, oder, im Auto-Modus ohne abdeckende Enrollment Session, zentral über die künftige Verwaltungsoberfläche (siehe ADR-0008 und `13-live-provisioning-boot.md`, Abschnitt „Auto-Modus-Gate").
+Diese Eigenschaft gilt ausschließlich für bereits registrierte Geräte. Die Aufnahme eines unbekannten Geräts bleibt in jedem Fall an eine explizite, interaktive Bestätigung gebunden (siehe Sicherheitsprinzip unten).
 
 ## Enrollment Sessions
 

architecture/13-live-provisioning-boot.md

@@ -61,18 +61,15 @@ Beide Moduspfade laufen ab „Runtime Blueprint erzeugen" identisch weiter. Der
 
 ## Auto-Modus-Gate
 
-Der automatisierte Ablauf ersetzt keine Sicherheitsprüfung, sondern ersetzt nur, wer/wann die Bestätigung gibt: statt einer lokalen Benutzereingabe entscheidet ein bereits bestehender, geprüfter Zustand — eine Vorab-Freigabe, eine zentrale Freigabe, oder ein bereits bekannter Registrierungszustand.
+Der automatisierte Ablauf ersetzt keine Sicherheitsprüfung, sondern ersetzt nur, wer die Bestätigung gibt: statt einer Benutzereingabe entscheidet ein bereits bestehender, geprüfter Zustand.
 
-Für ein bereits bekanntes Gerät (`device.registration_status == "existing"` in der Antwort von `POST /api/v1/activate`) läuft der automatisierte Ablauf wie bisher ohne weitere Bestätigung durch.
+Voraussetzung für den automatisierten Ablauf ist ausschließlich:
 
-Für ein neues Gerät (`registration_status == "registered"`) hängt der weitere Ablauf davon ab, ob eine aktive Enrollment Session (siehe `11-device-enrollment.md`) es abdeckt:
+`device.registration_status == "existing"` in der Antwort von `POST /api/v1/activate`.
 
-- **Mit abdeckender Enrollment Session:** automatisierter Ablauf wie vorgesehen — die Vorab-Freigabe der Session genügt, kein weiterer Bestätigungsschritt nötig.
+Ein unbekanntes Gerät (`registration_status == "registered"`) durchläuft niemals den automatisierten Ablauf, unabhängig vom gewählten Bootmenüeintrag. Die Geräteaufnahme bleibt gemäß `11-device-enrollment.md` an eine explizite, interaktive Bestätigung gebunden.
-- **Ohne abdeckende Enrollment Session (ADR-0008, 23.07.2026):** das Gerät geht nach dem Identifikations-Handshake in einen Wartezustand über. Die destruktive Installation beginnt erst, nachdem ein Kunde über die künftige Verwaltungsoberfläche die Registrierung bestätigt und einen Workspace zugewiesen hat.
 
-Ein unbekanntes Gerät ohne abdeckende Enrollment Session durchläuft damit weiterhin keine unbeaufsichtigte Installation ohne jede Bestätigung — nur die Quelle der Bestätigung ist im Auto-Modus jetzt zentral (Portal) statt lokal (Kiosk-Browser).
+Das Fail-Closed-Prinzip aus `10-interactive-provisioning-flow.md` gilt unverändert: Fehlt eine gültige Grundlage für die automatische Bestätigung (zum Beispiel eine unerwartete oder unlesbare Serverantwort), bricht der Ablauf ab, statt ersatzweise eine Bestätigung anzunehmen.
-
-Das Fail-Closed-Prinzip aus `10-interactive-provisioning-flow.md` gilt unverändert: Fehlt eine gültige Grundlage für die automatische Bestätigung (zum Beispiel eine unerwartete oder unlesbare Serverantwort, oder ein Wartezustand, der nie in eine Freigabe übergeht), bricht der Ablauf ab beziehungsweise verharrt im Wartezustand, statt ersatzweise eine Bestätigung anzunehmen.
 
 ---
 
@@ -92,21 +89,13 @@ Stattdessen ruft `backend_launch()` (siehe `06-backend-api.md`) den nativen Inst
 
 Die statische Kickstart-Datei sowie ihr Server-Endpoint (`GET /installers/fedora-workstation/ks.cfg`) entfallen damit.
 
-**Für das Fedora-Backend widerlegt (23.07.2026, ADR-0009):** Anaconda verarbeitet Kickstart-Direktiven aus der laufenden Live-Sitzung heraus nachweislich nicht zuverlässig (`rootpw`/`user`/Partitionierung bleiben unvollständig, real getestet). Der tatsächliche Weg für das Fedora-Backend ist noch offen — Details und Alternativen in ADR-0009.
-
 ---
 
 ## WLAN-Zugangsdaten
 
 Zwei getrennte Anwendungsfälle:
 
-**WLAN für die Live-Provisionierungsumgebung.** Ohne Netzwerk ist der Provisioning-Server nicht erreichbar. Zugangsdaten für dieses Netzwerk müssen deshalb bereits im ISO-Build hinterlegt sein, nicht dynamisch vom Server geladen werden.
+**WLAN für die Live-Provisionierungsumgebung.** Ohne Netzwerk ist der Provisioning-Server nicht erreichbar. Zugangsdaten für dieses Netzwerk müssen deshalb bereits im ISO-Build hinterlegt sein (zum Beispiel als NetworkManager-Verbindungsprofil in einem organisationsspezifischen ISO-Build), nicht dynamisch vom Server geladen werden.
-
-Konkretes Modell (entschieden 21.07.2026): Der Kunde hinterlegt im Kundenprofil eine Anforderung „Autoprovisionierung" samt den WLAN-Zugangsdaten für die Live-Provisionierungsumgebung, und löst darüber die Erzeugung einer für ihn personalisierten ISO aus (Self-Service, Download). Die Zugangsdaten werden dabei als NetworkManager-Verbindungsprofil zur Build-Zeit ins Live-Payload aufgenommen (analog zum bestehenden Mechanismus für `etc/sudoers.d/90-tuxflotte` und `etc/xdg/autostart/tuxflotte-installer.desktop`, siehe „Autostart von installer.sh" unten) — funktioniert sofort ab dem ersten Gerät, nicht erst ab dem zweiten.
-
-Da die ISO für diesen Fall ohnehin personalisiert gebaut wird, wird bei dieser Gelegenheit auch das Volume-Label individualisiert (statt des sonst festen `TUXFLOTTE`, siehe „Konkrete Umsetzung" unten) — abgeleitet aus einer bestehenden Organisations-Kennung (z.B. Org-Kurzname/-Slug), nicht aus einem Freitextfeld, da die ISO9660-Volume-ID auf Großbuchstaben/Ziffern/Unterstrich und 32 Zeichen beschränkt ist und ein frei eingegebener Name eigene Sanitisierung bräuchte. Die GRUB-Configs und der `CDLABEL`-Kernel-Parameter werden für diesen Build entsprechend mitgeneriert, nicht nur die WLAN-Datei.
-
-Verworfen wurde die Alternative, WLAN-Zugangsdaten interaktiv am ersten Gerät einzugeben und auf dem Stick selbst persistent zu machen (damit ab dem zweiten Gerät automatisch verbunden wird). Das hätte einen beschreibbaren, boot-übergreifend persistenten Bereich auf dem Stick vorausgesetzt (z.B. über dracut-Live-Overlay oder eine eigene Datenpartition) — eine reine ISO-Datei, roh auf einen Stick geschrieben (`dd`), bietet das nicht von selbst. Dafür wäre zusätzlich ein plattformübergreifendes Schreibwerkzeug nötig gewesen, das diesen Platz beim Erstellen des Sticks reserviert. Der Aufwand steht in keinem Verhältnis zum Nutzen, zumal dieser Ansatz ohnehin voraussetzt, dass der Kunde vorher durchs Profil geht — das serverseitige Modell liefert die bessere UX (automatisch ab Gerät 1) bei deutlich weniger Infrastruktur.
 
 **WLAN für das installierte Zielsystem.** Dies ist eine dauerhafte, organisationsweite Vorgabe und gehört zum noch unspezifizierten `Network Profile`-Modell der Organization (siehe `09-data-model-v1.md`). Die Anwendung erfolgt wie andere organisationsweite Vorgaben, nicht als Teil der Provisionierungs-Bootphase.
 
@@ -114,15 +103,9 @@ Verworfen wurde die Alternative, WLAN-Zugangsdaten interaktiv am ersten Gerät e
 
 ## Konkrete Umsetzung (Stand 18.07.2026)
 
-Als konkrete Basis wird eine Fedora-Cinnamon-Live-ISO verwendet, nicht Fedora Workstation Live. Für die Zwecke dieses Dokuments ist das austauschbar — entscheidend ist ausschließlich das Vorhandensein von `/LiveOS/squashfs.img`, nicht die konkrete Desktop-Umgebung.
+Als konkrete Basis wird eine Fedora-Cinnamon-Live-ISO verwendet (Volume-Label `Fedora-Cinn-Live-44`), nicht Fedora Workstation Live. Für die Zwecke dieses Dokuments ist das austauschbar — entscheidend ist ausschließlich das Vorhandensein von `/LiveOS/squashfs.img`, nicht die konkrete Desktop-Umgebung.
 
-**Für eine spätere ISO-Überarbeitung festgehalten (21.07.2026):** Der oben beschriebene EROFS-Bug ist keine allgemeine Live-Medien-Eigenschaft, sondern eine Fedora-spezifische, noch laufende Umstellung — offizieller Fedora-Change-Proposal ab Fedora 42 ("Switch to EROFS for Live Media"), getrieben von RHEL-10-Angleichung (RHEL 10 nutzt EROFS für seine Live-Medien). Ubuntus Live-/Install-Medien (`casper`/`live-build`) verwenden weiterhin klassisches SquashFS über `mksquashfs`/`squashfs-tools` — dasselbe Tooling, das dieses Projekt bereits für das Chromium-SquashFS-Experiment (ADR-0005, mittlerweile verworfen) problemlos genutzt hat. Eine Ubuntu-basierte Live-ISO als Basis wäre also vom EROFS-Bug gar nicht betroffen, bräuchte den Dracut-Hook-Umweg für das Installer-Payload aber vermutlich trotzdem nicht auf dieselbe Art zu umgehen, sondern könnte direkt im Payload arbeiten. Das ist kein Beschluss, nur ein für eine künftige ISO-Überarbeitung festgehaltener Prüfpunkt — mit dem Wechsel wäre auch anderes Branding-/Backend-Anpassungs-Ökosystem verbunden, nicht nur ein Filesystem-Detail.
+Das in der Boot-Ablauf-Grafik oben genannte Kernel-Cmdline-Flag heißt konkret `tuxflotte.mode` und wird als `tuxflotte.mode=auto` beziehungsweise `tuxflotte.mode=interactive` an den Kernel übergeben, zusätzlich zu den vom Live-Medium ohnehin benötigten Parametern (`root=live:CDLABEL=Fedora-Cinn-Live-44 rd.live.image`) sowie `vconsole.keymap=de`. `installer.sh` soll den gewählten Modus zur Laufzeit aus `/proc/cmdline` lesen (siehe „Noch nicht umgesetzt" unten) — aktuell durchläuft es unabhängig vom Flag immer den vollständigen interaktiven Ablauf.
-
-Die gebaute ISO trägt ein eigenes Volume-Label `TUXFLOTTE` (per `-volid` in `scripts/build.sh`, `create_iso()`), statt des ursprünglichen Fedora-Labels der Quell-ISO. Reines Branding (21.07.2026 entschieden) — es wird aktuell von genau einem im Umlauf befindlichen USB-Stick ausgegangen, es gibt keine Anforderung, mehrere Sticks über das Label zu unterscheiden. Sollte sich das ändern, ist die Anpassung unkompliziert. Das Label ist funktional relevant, nicht nur kosmetisch: GRUB (`search -l 'TUXFLOTTE'`) und der Kernel-Cmdline-Parameter `root=live:CDLABEL=TUXFLOTTE` lösen darüber beim Boot das Live-Root auf — beide Werte müssen exakt mit dem `-volid` übereinstimmen.
-
-Ein eigenes, schlankeres Live-System anstelle des Fedora-Live-Images wurde geprüft und verworfen (21.07.2026): Der Aufwand, die dahinterliegende Live-Boot-Infrastruktur selbst zu pflegen (Kernel-/Initramfs-Kompatibilität, Firmware, Hardware-Erkennung über ein breites Gerätespektrum), steht in keinem Verhältnis zum Nutzen — zumal die bekannten Reibungspunkte (EROFS-Extraktionsfehler, Chromium-Nachinstallation, ISO-Größe) bereits mit kleinen, gut verstandenen Maßnahmen gelöst beziehungsweise geplant sind. Revisitieren, falls ISO-Größe/Boot-Zeit zu einem gemessenen operativen Problem wird oder eine dauerhafte Festlegung auf eine dann als Wartungslast spürbare Live-Basis ansteht.
-
-Das in der Boot-Ablauf-Grafik oben genannte Kernel-Cmdline-Flag heißt konkret `tuxflotte.mode` und wird als `tuxflotte.mode=auto` beziehungsweise `tuxflotte.mode=interactive` an den Kernel übergeben, zusätzlich zu den vom Live-Medium ohnehin benötigten Parametern (`root=live:CDLABEL=TUXFLOTTE rd.live.image`) sowie `vconsole.keymap=de`. `installer.sh` soll den gewählten Modus zur Laufzeit aus `/proc/cmdline` lesen (siehe „Noch nicht umgesetzt" unten) — aktuell durchläuft es unabhängig vom Flag immer den vollständigen interaktiven Ablauf.
 
 Das GRUB-Menü verwendet einen Countdown von 10 Sekunden; der Auto-Eintrag ist Index 0 und damit Standardauswahl. Ein dritter Menüpunkt zum Booten des bereits installierten lokalen Systems bleibt erhalten (vormals in `01-layered-provisioning.md` als Anforderung an das Bootmenü genannt).
 
@@ -134,24 +117,16 @@ Das Menü verwendet ein Farbschema in Markenblau (`color_normal=blue/white`, `co
 
 Das Installer-Payload wird **nicht** in `/LiveOS/squashfs.img` integriert — dieses Image ist trotz des Namens EROFS statt SquashFS, und die einzige verfügbare `erofs-utils`-Tooling-Version (auch frisch aus dem Quellcode gebaut) extrahiert das gepackte/fragmentierte Inode dieses konkreten Images fehlerhaft.
 
-Der Fehler wurde zusätzlich direkt auf einem nativen Fedora 44 nachgestellt (die Build-Umgebung selbst ist Debian Bookworm) und trat dort identisch auf. Das bestätigt, dass es sich um einen echten `erofs-utils`-Bug handelt und nicht um eine Bookworm-spezifische Tooling-Lücke.
-
-Präzisiert (21.07.2026): Der Fehler ist kein reines Versions-Nachhinken des Debian-Bookworm-Pakets (`erofs-utils` 1.5-1). Ein frischer Build direkt vom `erofs-utils`-`dev`-Branch (Commit vom 14.07.2026, Version 1.9.2) zeigt denselben Fehler gegen dieselbe `squashfs.img`. Ursache, per Quellcode nachvollzogen (`fsck/main.c`): Das Image nutzt EROFS' Fragments-Feature — eine spezielle, versteckte „Packed Inode" (hier nid 37), die Tail-Daten kleiner Dateien fürs gesamte Dateisystem gebündelt speichert. `fsck.erofs --extract` verarbeitet den Verzeichnisbaum zunächst korrekt vollständig (bestätigt per `dump.erofs -S`: 271.200 Dateien lesbar, keine Auffälligkeiten), behandelt diese eine Packed Inode aber in einem separaten Schritt danach — und dabei kollidiert die interne Pfadverwaltung mit dem Extraktions-Wurzelverzeichnis: im Test wurde der bereits vollständig extrahierte Verzeichnisbaum am Ende durch eine einzelne ca. 4,3-GB-Rohdatei gleichen Namens überschrieben. Der Fehler ist damit nicht nur ein sauberer Abbruch, sondern im Fehlerfall aktiv destruktiv gegenüber bereits extrahierten Daten.
-
-Eine gezielte Suche (GitHub, linux-erofs-Mailingliste) fand keinen bestehenden Bugreport genau für diese Packed-Inode/Extract-Pfad-Kollision, wohl aber eine dokumentierte Historie anderer Pfad-Handling-Bugs im selben `--extract`-Codepfad (u.a. bereits gefixte Heap-Overflow- und Segfault-Fälle bei tiefen/langen Pfaden) — die Stelle gilt im Projekt selbst als bekanntermaßen fragil. Es gibt keinen erkennbaren Zeithorizont für einen Fix. Die gewählte Umgehung über den Dracut-Hook (Image gar nicht erst anfassen) bleibt damit nicht nur der pragmatische, sondern der einzig belastbare Ansatz — Extraktion ist für dieses Image nachweislich unzuverlässig, nicht nur unbequem.
-
 Stattdessen nutzt der Build den offiziellen Dracut-Hook `20-apply-live-updates.sh` (`var/lib/dracut/hooks/pre-pivot/`): Ein `updates/`-Verzeichnis direkt auf dem Boot-Medium (nicht im komprimierten Image) wird von Dracut automatisch vollständig in das Live-Root kopiert, bevor die Live-Sitzung startet — ganz ohne Image-Remastering.
 
 `scripts/build.sh` (`prepare_updates()`) baut dieses Verzeichnis zur Build-Zeit aus `scripts/`, `backends/`, `config/` (unter `/opt/tuxflotte`) sowie `live-updates/etc/` zusammen:
 
-- `etc/xdg/autostart/tuxflotte-installer.desktop` — startet beim Anmelden von `liveuser` automatisch Epiphany im Application-Mode (`epiphany --application-mode --profile=/home/liveuser/.local/share/tuxflotte-kiosk`, siehe ADR-0004/ADR-0006), der die Kiosk-Oberfläche unter `/opt/tuxflotte/kiosk/index.html` lädt. Adressleiste und Fenstermenü bleiben dabei sichtbar — bewusst hingenommen (ADR-0006), da der angezeigte Inhalt zentral vom Provisioning Server kommt und nicht sensibel ist.
+- `etc/xdg/autostart/tuxflotte-installer.desktop` — startet beim Anmelden von `liveuser` automatisch ein Terminal mit `installer.sh` als root.
 - `etc/sudoers.d/90-tuxflotte` — `liveuser` erhält passwortloses sudo (angemessen für diese Wegwerf-Live-Umgebung).
 
-Epiphany ist auf dem Fedora-Cinnamon-Live-Image bereits vorhanden, es sind keine zusätzlichen Build-Schritte nötig. Zwischen ADR-0004 und ADR-0006 wurde Chromium ausführlich evaluiert und wieder verworfen (vier verschiedene reale Boot-Fehlschläge in Folge — `/etc/passwd`-Überschreibung, Kernel Panic durch `/usr`-Überschreibung, minutenlange Bootzeit durch hunderttausende lose Dateien, dann ein `/proc/self/exe`-Ressourcenauflösungsfehler) — Details, Begründung und die dabei erarbeiteten, einzeln funktionierenden Techniken (Isolation unter `/opt`, Loader-Relokation, SquashFS-Verpackung) stehen in ADR-0005 und ADR-0006, falls das je wieder aufgegriffen wird.
-
 xorriso übernimmt beim `-map` die Berechtigungen der lokalen Quelldateien in die ISO. Da `liveuser`s uid (1000) sonst mitkopiert würde und `sudo` root-fremde `sudoers.d`-Dateien verweigert, setzt der Build `-chown_r 0 /updates -- -chgrp_r 0 /updates --` explizit auf das gesamte `updates/`-Verzeichnis — ganz ohne lokales root beim Bauen.
 
-Verifiziert per vollständigem Live-Boot in Proxmox (siehe `roadmap/milestones.md`, 2026-07-20): Autostart-Terminal öffnete sich zuverlässig, `installer.sh` durchlief alle Module bis zum sauberen Exit. Diese Verifikation stammt aus der Zeit vor dem Kiosk-UI-Umbau (Terminal statt Epiphany) — der Epiphany-Autostart selbst ist noch nicht mit dem aktuellen Build (inkl. TUXFLOTTE-Label, WLAN-Vorbereitung) per echtem Boot re-verifiziert.
+Verifiziert per vollständigem Live-Boot in Proxmox: Autostart-Terminal öffnet sich zuverlässig, `installer.sh` durchläuft alle Module bis zum sauberen Exit (siehe `roadmap/milestones.md`, 2026-07-20).
 
 Noch nicht umgesetzt: `installer.sh` liest `tuxflotte.mode` noch nicht aus und durchläuft deshalb immer den vollständigen interaktiven Ablauf, unabhängig vom gewählten Bootmenüeintrag. `backend_launch()`/`backend_postinstall()` bleiben Phase-1-Stubs — der native Installer wird noch nicht tatsächlich gestartet.
 

roadmap/installer-roadmap.md

@@ -10,19 +10,15 @@ Ziel: Erste komfortable Installer-Version.
 
 ### Build
 
-* [x] ISO-Erzeugung vollständig in `build.sh` integrieren (kein manueller Zwischenschritt mehr nötig, bestätigt durch den erfolgreichen End-to-End-Boot am 20.07.2026, siehe `roadmap/milestones.md`)
+* [ ] ISO-Erzeugung vollständig in `build.sh` integrieren
-* [ ] reproduzierbarer Build (gleicher Source-ISO-Hash + gleicher Repo-Stand → gleiches, funktional identisches Ergebnis; kein bit-identisches Ausgabe-ISO als Ziel, da Aufwand/Nutzen dafür nicht lohnt)
+* [ ] reproduzierbarer Build
-* [ ] automatische Verifikation (statische/syntaktische Prüfungen vor dem ISO-Bau: Source-ISO-Hash, GRUB-Configs enthalten Branding, Payload-Struktur vollständig, Execute-Bits auf allen Skripten gesetzt, Bash-Syntax valide. Explizit keine automatisierte Boot-/Laufzeitprüfung — die funktionale Prüfung bleibt bewusst manuell in Proxmox: KI prüft syntaktisch, Mensch prüft Durchführung, siehe `roadmap/milestones.md` 2026-07-20)
+* [ ] automatische Verifikation
 
 ### Bootmenü
 
-* [x] Boot from local disk (siehe `architecture/01-layered-provisioning.md`)
+* [x] Boot from local disk
 * [x] Tuxflotte-Branding (Text/Farbschema im GRUB-Menü; Logo folgt am Plymouth-Bootsplash, siehe `architecture/13-live-provisioning-boot.md`)
-* [x] eigenes ISO-Label (`TUXFLOTTE`, siehe `architecture/13-live-provisioning-boot.md`)
+* [ ] eigenes ISO-Label
-
-### Oberfläche
-
-* [ ] Kiosk-UI (Epiphany statt Terminal, siehe ADR-0004/ADR-0006 — Chromium-Zwischenspiel in ADR-0005 verworfen) — Epiphany startet seit 22.07.2026 zuverlässig; Nachbesserungen (Standardbrowser-Abfrage, deutsche Tastatur, SELinux-Benachrichtigungen) umgesetzt, Boot-Verifikation dieser drei noch ausstehend
 
 ---
 
@@ -34,7 +30,6 @@ Ziel: Netzwerkgestützter Installer.
 
 * [ ] WLAN-Unterstützung
 * [ ] Netzwerkdiagnose
-* [ ] Personalisierte ISO-Generierung mit eingebetteten WLAN-Zugangsdaten und individualisiertem ISO-Label (aus Org-Kennung abgeleitet), ausgelöst über Kundenprofil-Flag „Autoprovisionierung" (siehe `architecture/13-live-provisioning-boot.md`, Abschnitt „WLAN-Zugangsdaten")
 
 ### Bootstrap
 
@@ -44,7 +39,7 @@ Ziel: Netzwerkgestützter Installer.
 
 ### Registrierung
 
-* [x] Geräteaktivierung (siehe `architecture/11-device-enrollment.md`)
+* [x] Geräteaktivierung
 * [ ] Benutzeranmeldung
 * [ ] Auswahl von OS- und Konfigurationsprofilen
 
@@ -83,5 +78,3 @@ Dadurch wird:
 * die Grundlage für PXE-Installationen geschaffen,
 * und eine spätere Reprovisionierung ohne physisches Medium ermöglicht.
 
-**Geprüft, für eine spätere ISO-Überarbeitung vorgemerkt (21.07.2026):** Ubuntu-basiertes Live-Medium statt Fedora, um den EROFS-Bug (siehe `architecture/13-live-provisioning-boot.md`) von vornherein zu vermeiden — Ubuntus `casper`/`live-build` nutzt weiterhin klassisches SquashFS. Kein Beschluss, nur ein Prüfpunkt für den Fall, dass die ISO ohnehin grundlegend überarbeitet wird.
-