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.
56 lines
1.3 KiB
Markdown
56 lines
1.3 KiB
Markdown
Boot
|
|
↓
|
|
GRUB-Menü: Auto- oder Interaktiv-Modus (siehe 13-live-provisioning-boot.md)
|
|
↓
|
|
Preflight
|
|
↓
|
|
Netzwerk
|
|
↓
|
|
Hardware Identity
|
|
↓
|
|
Server Discovery
|
|
↓
|
|
Device Registration
|
|
↓
|
|
Assignment
|
|
↓
|
|
Runtime Blueprint erzeugen
|
|
↓
|
|
Backend laden
|
|
↓
|
|
Backend API
|
|
↓
|
|
Native Installer
|
|
↓
|
|
First Boot
|
|
↓
|
|
Provisioning Agent
|
|
↓
|
|
Managed System
|
|
|
|
Der Schritt „Assignment" unterscheidet sich je nach Modus: Im Interaktiv-Modus wählt der Benutzer eine Bereitstellungsvorlage und bestätigt den Commit Point explizit. Im Auto-Modus geschieht beides automatisch, und nur für bereits registrierte Geräte (siehe `13-live-provisioning-boot.md`).
|
|
|
|
## Aktivierung und Gerätebindung
|
|
|
|
Ein neues Gerät authentifiziert den ersten Provisionierungsvorgang mit einem Aktivierungscode.
|
|
|
|
Nach erfolgreicher Prüfung wird der vom Installer erzeugte Hardware-Fingerprint an den Provisioning-Server übertragen.
|
|
|
|
Der Server bindet den Fingerprint an die Aktivierung beziehungsweise an die zugehörige Organisation.
|
|
|
|
Der Aktivierungscode ist damit die initiale Berechtigung.
|
|
|
|
Der Hardware-Fingerprint dient anschließend zur Wiedererkennung des Geräts.
|
|
|
|
Ablauf:
|
|
|
|
Aktivierungscode
|
|
↓
|
|
Hardware-Fingerprint
|
|
↓
|
|
Geräteregistrierung oder Wiedererkennung
|
|
↓
|
|
Bereitstellungsvorlage-Zuordnung
|
|
↓
|
|
Runtime Blueprint erzeugen
|