# 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.