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.
45 lines
3.5 KiB
Markdown
45 lines
3.5 KiB
Markdown
# 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`.
|