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.
111 lines
5.2 KiB
Markdown
111 lines
5.2 KiB
Markdown
# 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.
|
|
|
|
---
|
|
|
|
## 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.
|