platform-docs/architecture/00-provisioning-flow.md
Thomas Stallinger fce6e4860c docs: switch provisioning ISO to live medium with auto/interactive boot modes (ADR-0003)
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.
2026-07-18 10:46:46 +02:00

1.3 KiB

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