Thomas Stallinger
fce6e4860c
Moves from a Fedora DVD/netinst base (GRUB boots straight into Anaconda via a static inst.ks= URL, bypassing installer.sh entirely) to a real live medium. installer.sh runs as an application inside the live session; backend_launch() starts the native installer explicitly at the end instead of a boot-time kickstart parameter. The boot menu offers two entries: a default with a countdown that leads to an unattended flow, and a manual entry for the branded interactive flow. The unattended flow is gated on device.registration_status == "existing" - unknown devices always fail closed into the interactive enrollment path. Device registration now documents that this is a condition of registering a device. Also notes the tension with the installer roadmap's long-term minimal-medium vision: distribution packages still aren't bundled and are pulled per install, but the live environment itself makes the medium larger, accepted for the UX it enables. Details: architecture/13-live-provisioning-boot.md.
5.2 KiB
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
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.
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.