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.
3.5 KiB
ADR-0003: Live-ISO als Provisionierungsmedium mit Auto- und Interaktiv-Modus
Status: Beschlossen Datum: 18.07.2026
Kontext
Das bisherige Provisionierungsmedium ist eine gepatchte Fedora-DVD/Netinst-ISO. GRUB startet Anaconda dort direkt über einen fest verdrahteten Kernel-Parameter (inst.ks=https://.../ks.cfg), der auf eine statische Kickstart-Datei auf dem Provisioning-Server zeigt.
Das hat zwei Konsequenzen:
Der in 10-interactive-provisioning-flow.md (F-005) beschriebene und in scripts/installer.sh umgesetzte Ablauf (Netzwerk, Hardware, Aktivierung, Bereitstellungsvorlage-Auswahl, Runtime Blueprint, Backend) hat auf der aktuellen ISO keinen Einstiegspunkt. Anaconda startet, bevor installer.sh je ausgeführt wird.
Eine gebrandete, frei gestaltbare Oberfläche für Workspace-Auswahl und Provisioning-Server-Authentifizierung ist auf dieser Basis nur über Anaconda-eigene Erweiterungsmechanismen (Addons) erreichbar, die eng an Anacondas UI-Framework gebunden und aufwendig sind.
Gleichzeitig ist eine durchgängige interaktive Bestätigungspflicht für jede Installation bei Massenrollouts und Geräteersatz unpraktikabel.
Entscheidung
Tuxflotte wechselt die Grundlage der Provisionierungs-ISO von einer Fedora-DVD/Netinst-Basis auf ein echtes Live-Medium (z. B. Fedora Workstation Live, erkennbar an /LiveOS/squashfs.img).
scripts/installer.sh läuft als Anwendung innerhalb dieser Live-Sitzung. Der native Installer wird nicht mehr über einen boot-zeitlichen inst.ks=-Parameter gestartet, sondern erst am Ende des Ablaufs explizit durch backend_launch(), mit der von backend_generate_config() erzeugten Konfiguration.
Das Bootmenü bietet zwei Einträge, die dieselbe Live-Umgebung starten, sich aber in einem Kernel-Cmdline-Flag unterscheiden:
Ein Standardeintrag mit Countdown, der bei Nichtstun automatisch in den unbeaufsichtigten Ablauf führt.
Ein manuell auswählbarer zweiter Eintrag für den interaktiven, gebrandeten Ablauf.
Der unbeaufsichtigte Ablauf ist ausschließlich für bereits registrierte Geräte zulässig, erkennbar an device.registration_status == "existing" in der Antwort von POST /api/v1/activate. Bei einem unbekannten Gerät (registration_status == "registered") bricht der unbeaufsichtigte Ablauf kontrolliert ab (Fail-Closed) und verweist auf den interaktiven Ablauf mit expliziter Geräteaufnahme-Bestätigung gemäß 11-device-enrollment.md.
Dass ein bereits registriertes Gerät ohne erneute interaktive Rückfrage automatisiert neu installiert werden kann, wird explizit Bestandteil der Bedingungen, denen bei der Geräteregistrierung zugestimmt wird.
Konsequenzen
scripts/build.sh und scripts/extract.sh benötigen künftig ein Live-ISO als Quelle statt einer DVD/Netinst-ISO. Die GRUB-Konfiguration erhält einen zweiten Menüeintrag sowie ein Kernel-Cmdline-Flag zur Moduswahl.
Die statische ks.cfg sowie ihr Server-Endpoint (GET /installers/fedora-workstation/ks.cfg) entfallen mit der Umstellung.
WLAN-Zugangsdaten für die Live-Provisionierungsumgebung selbst müssen weiterhin im ISO-Build hinterlegt werden, da ohne Netzwerk kein Zugriff auf den Provisioning-Server möglich ist. WLAN-Zugangsdaten für das installierte Zielsystem gehören zum noch unspezifizierten Network Profile-Modell der Organization (09-data-model-v1.md).
Die Geräteregistrierung (11-device-enrollment.md) wird um den ausdrücklichen Hinweis ergänzt, dass registrierte Geräte automatisiert neu installiert werden können.
Details zum Ablauf: architecture/13-live-provisioning-boot.md.