# Live-Provisionierung und Boot-Modi **Status:** Beschlossen **Datum:** 18.07.2026 ## Zweck dieses Dokuments Dieses Dokument beschreibt, wie die Provisionierungs-ISO bootet, wie der automatisierte und der interaktive Ablauf sich unterscheiden, und wie der native Installer aus der Live-Umgebung heraus gestartet wird. Es ergänzt `10-interactive-provisioning-flow.md` (F-005), das den interaktiven Ablauf selbst beschreibt, um die Boot-Ebene davor. Siehe `ADR-0003` für die Entscheidung und ihre Begründung. --- ## Ausgangslage Die bisherige ISO basiert auf einer Fedora-DVD/Netinst-Struktur ohne Live-Umgebung. GRUB startet Anaconda direkt, mit einer über `inst.ks=` fest verdrahteten Kickstart-URL. Der gesamte in F-005 beschriebene Ablauf hat darauf keinen Einstiegspunkt. Die neue ISO basiert stattdessen auf einem echten Live-Medium (erkennbar an `/LiveOS/squashfs.img`). `scripts/installer.sh` läuft als gewöhnliche Anwendung innerhalb dieser Live-Sitzung, mit vollem Zugriff auf Netzwerk (NetworkManager, WLAN), Bildschirm und Tastatur. --- ## Boot-Ablauf ```text Boot ↓ GRUB-Menü (Countdown) ├── Zeitüberschreitung oder Standardeintrag │ ↓ │ Live-Umgebung startet mit tuxflotte.mode=auto │ └── manuelle Auswahl des zweiten Eintrags ↓ Live-Umgebung startet mit tuxflotte.mode=interactive ↓ installer.sh liest tuxflotte.mode ↓ Netzwerk, Hardware, Aktivierung (wie bisher, "always"-Module) ↓ Moduswahl ├── auto │ ↓ │ device.registration_status prüfen │ ├── existing → Bereitstellungsvorlage automatisch wählen (is_default), Commit Point automatisch bestätigen │ └── registered → Fail-Closed-Abbruch, Verweis auf interaktiven Ablauf │ └── interactive ↓ bisheriger F-005-Ablauf (Bereitstellungsvorlage-Auswahl, explizite Bestätigung) ↓ Runtime Blueprint erzeugen → Backend laden → backend_generate_config() ↓ backend_launch() startet den nativen Installer explizit aus der Live-Sitzung heraus ``` Beide Moduspfade laufen ab „Runtime Blueprint erzeugen" identisch weiter. Der Unterschied liegt ausschließlich davor: in der Frage, ob eine Bereitstellungsvorlage interaktiv gewählt und der Commit Point interaktiv bestätigt wird, oder ob beides automatisch anhand vorhandener Daten geschieht. --- ## Auto-Modus-Gate 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. Voraussetzung für den automatisierten Ablauf ist ausschließlich: `device.registration_status == "existing"` in der Antwort von `POST /api/v1/activate`. 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. 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. --- ## Konsequenz für die Geräteregistrierung Wer ein Gerät registriert, akzeptiert damit, dass dieses Gerät künftig ohne erneute interaktive Rückfrage automatisiert neu installiert werden kann, solange es über seinen Hardware-Fingerprint als bereits registriert erkannt wird. Dies wird bei der Geräteregistrierung ausdrücklich kommuniziert (siehe `11-device-enrollment.md`). --- ## Nativer Installer aus der Live-Sitzung Der native Installer wird nicht mehr über einen boot-zeitlichen Parameter gestartet. Stattdessen ruft `backend_launch()` (siehe `06-backend-api.md`) den nativen Installer explizit auf, mit der zuvor von `backend_generate_config()` erzeugten, lokal vorliegenden Konfiguration. Die statische Kickstart-Datei sowie ihr Server-Endpoint (`GET /installers/fedora-workstation/ks.cfg`) entfallen damit. --- ## 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 (zum Beispiel als NetworkManager-Verbindungsprofil in einem organisationsspezifischen ISO-Build), nicht dynamisch vom Server geladen werden. **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. --- ## Konkrete Umsetzung (Stand 18.07.2026) 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. 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. 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). `scripts/build.sh` und `scripts/extract.sh` extrahieren die Quell-ISO über `xorriso -osirrox` statt über einen Loop-Mount und benötigen dadurch keine Root-Rechte mehr für den Build selbst. Das Menü verwendet ein Farbschema in Markenblau (`color_normal=blue/white`, `color_highlight=white/blue`, angelehnt an `rgb(52,101,164)` aus `pics/tuxflotte-beschriftet-schatten.svg`). Das Logo selbst lässt sich darin nicht darstellen: Klassisches `gfxterm` malt bei jeder Zeichenzelle einen deckenden Hintergrund, wodurch ein `background_image` vollständig verdeckt wird — geprüft durch tatsächliches Booten der Variante mit Logo in QEMU. Ein sichtbares Logo bräuchte die GRUB-Theme-Engine (`gfxmenu`/`theme.txt`), die diese Live-ISO nicht mitbringt (leeres `/boot/grub2/themes`, kein `x86_64-efi`-Modulverzeichnis). Das Logo ist deshalb für den Plymouth-Bootsplash oder den Live-Desktop-Hintergrund vorgesehen, nicht für das GRUB-Menü. ### Autostart von installer.sh 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. 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 ein Terminal mit `installer.sh` als root. - `etc/sudoers.d/90-tuxflotte` — `liveuser` erhält passwortloses sudo (angemessen für diese Wegwerf-Live-Umgebung). 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: 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. --- ## Zusammenfassung Die Live-ISO ersetzt das direkte Booten in Anaconda durch eine vorgeschaltete, frei gestaltbare Live-Sitzung, in der `installer.sh` läuft. Ein Bootmenü mit Countdown unterscheidet zwischen automatisiertem und interaktivem Ablauf; beide münden ab der Runtime-Blueprint-Erzeugung in denselben Codepfad. Automatisierung ersetzt keine Sicherheitsprüfung, sondern bindet die Bestätigung an eine bereits bestehende, geprüfte Gerätezuordnung statt an eine Benutzereingabe.