Thomas Stallinger
faa06a51fc
Wichtigster Fund: 13-live-provisioning-boot.md widersprach sich selbst
zum GRUB-Standardeintrag - ein noch nicht korrigierter Abschnitt
('Auto-Eintrag ist Index 0 und damit Standardauswahl') stand neben der
bereits vorhandenen Korrektur weiter oben im selben Dokument ('Standard
ist von lokaler Festplatte booten', Erkenntnis vom 01.08.2026). Ein
Reader des älteren Abschnitts hätte das sicherheitsrelevante Verhalten
bei destruktiven Installationen falsch verstanden. Jetzt konsistent,
mit Verweis auf die Korrektur. ADR-0003 (Ursprungsentscheidung, dort
unkorrigiert) bekam denselben Nachtrag.
Kleinere Korrekturen: zwei Anführungszeichen-Inkonsistenzen (ADR-0009,
ADR-0011) - gerade Anführungszeichen für eigene Zusammenfassungen des
Autors statt der sonst durchgängigen „..."-Form, während echte wörtliche
Zitate (Terminal-Fehlermeldungen, Anaconda-Doku) unangetastet bleiben,
weil die Originalschreibweise dort bewusst erhalten werden soll.
Alle ADR-Querverweise (0001-0015) auf Gültigkeit geprüft, keine toten
Verweise gefunden.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
4.0 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.
Korrigiert (01.08.2026, siehe ADR-0009-Update vom selben Tag): Welcher der beiden Einträge bei Nichtstun (Countdown-Ablauf) automatisch ausgewählt wird, wurde hier zunächst falsch entschieden — nicht der unbeaufsichtigte Ablauf, sondern „von lokaler Festplatte booten" ist der Standard. Die destruktive, unbeaufsichtigte Installation erfordert eine aktive, bewusste Auswahl aus dem Menü, kein bloßes Verstreichenlassen eines Zeitfensters. Umgesetzt in architecture/13-live-provisioning-boot.md.
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.