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.
2.5 KiB
Tuxflotte Glossary
Status: Stable
Datum: 2026-07-07
Workspace
Ein fachlich definierter Arbeitsplatz.
Ein Workspace beschreibt, welchen Zielzustand ein System haben soll.
Beispiele:
- Developer Workspace
- Office Workspace
- Kiosk Workspace
Ein Workspace ist nicht distributionsabhängig.
Backend
Eine distributionsspezifische Implementierung.
Ein Backend beschreibt, wie ein Workspace auf einer bestimmten Distribution installiert wird.
Beispiele:
- Fedora Backend
- Mint Backend
- Debian Backend
Organization
Eine Organisation beschreibt kunden- oder unternehmensweite Vorgaben.
Beispiele:
- Zertifikate
- LDAP
- Keycloak
- Paketquellen
- Proxy
- Branding
- VPN
- Monitoring
Merkmal
Eine einzelne fachliche Eigenschaft eines Workspace, distributionsunabhängig benannt.
Beispiele:
- browser-brave
- office-onlyoffice
- guest-session-ephemeral
Ein Workspace besteht aus einer Menge von Merkmalen.
Blueprint
Die technische Umsetzung genau eines Merkmals für genau ein Backend.
Ein Blueprint ist im Regelfall eine Ansible-Rolle beziehungsweise -Aufgabe, die nach dem ersten Start über den bestehenden Ansible-Pull-Mechanismus angewendet wird.
Details: architecture/12-feature-blueprint-model.md.
Runtime Blueprint
Die zur Installationszeit erzeugte vollständige Zielbeschreibung.
Sie entsteht aus:
- den aufgelösten Blueprints der Merkmale des Workspace für das gewählte Backend
- direkten Organization- und Backend-Vorgaben (zum Beispiel Partitionierung, Verschlüsselung)
- optional Benutzerkontext
Orchestrator
Die Komponente der Provisioning-ISO, die den Ablauf steuert.
Der Orchestrator erkennt Hardware, lädt Profile, erzeugt Runtime Blueprints und startet das passende Backend.
Provisioning Agent
Der Agent läuft auf dem installierten System und übernimmt Registrierung, Nachkonfiguration, Inventarisierung und Lebenszyklusaufgaben.
Native Installer
Der offizielle Installer der jeweiligen Distribution.
Beispiele:
- Anaconda
- Calamares
- Debian Installer
- Subiquity
Auto-Modus
Ein Bootmodus der Provisionierungs-ISO, in dem Bereitstellungsvorlage-Auswahl und Commit-Point-Bestätigung ohne Benutzereingabe erfolgen.
Nur für bereits registrierte Geräte zulässig (device.registration_status == "existing").
Details: architecture/13-live-provisioning-boot.md.
Interaktiv-Modus
Der in F-005 (architecture/10-interactive-provisioning-flow.md) beschriebene Ablauf mit expliziter Benutzerinteraktion bei Bereitstellungsvorlage-Auswahl und Installationsbestätigung.