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

2.0 KiB

Raw Blame History

Runtime Layout

Laufzeitverzeichnis

Alle Installer-Module kommunizieren ausschließlich über:

/run/tuxflotte/

Jedes Modul besitzt genau ein eigenes Unterverzeichnis.

Verzeichnisstruktur

/run/tuxflotte/ ├── network/ ├── hardware/ ├── enrollment/ ├── server/ ├── provisioning/ ├── assignment/ ├── installation/ ├── runtime/ ├── backend/ └── logs/

Eigentümer der Verzeichnisse

network/ Besitzer: 05_network.sh

hardware/ Besitzer: 10_hardware.sh

enrollment/ Besitzer: 12_enrollment_auth.sh

server/ Besitzer: 15_server_handshake.sh

provisioning/ Besitzer: 17_device_status.sh

assignment/ Besitzer: 20_profile_selection.sh

installation/ Besitzer: 25_installation_confirm.sh

runtime/ Besitzer: Runtime-Builder

backend/ Besitzer: Backend-Orchestrator

logs/ Besitzer: zentraler Installer-Orchestrator

Lese- und Schreibregeln

Ein Modul darf ausschließlich in sein eigenes Verzeichnis schreiben.

Andere Modulverzeichnisse dürfen nur gelesen werden, wenn dies für den definierten Ablauf erforderlich ist.

Beispiele:

10_hardware.sh schreibt nur nach /run/tuxflotte/hardware/
12_enrollment_auth.sh schreibt nur nach /run/tuxflotte/enrollment/
15_server_handshake.sh liest aus /run/tuxflotte/network/, /run/tuxflotte/hardware/ und /run/tuxflotte/enrollment/
17_device_status.sh liest aus /run/tuxflotte/server/ und schreibt nach /run/tuxflotte/provisioning/
20_profile_selection.sh liest aus /run/tuxflotte/server/ und schreibt nach /run/tuxflotte/assignment/
25_installation_confirm.sh liest aus /run/tuxflotte/assignment/ und schreibt nach /run/tuxflotte/installation/
Der Runtime-Builder (30_runtime_blueprint.sh) liest aus /run/tuxflotte/network/, /run/tuxflotte/server/ und /run/tuxflotte/assignment/ und schreibt nach /run/tuxflotte/runtime/
Der Backend-Orchestrator liest aus /run/tuxflotte/runtime/

Direkte Funktionsaufrufe zwischen Modulen sind nicht vorgesehen.

Die Kommunikation erfolgt ausschließlich über Dateien im Runtime-Verzeichnis.

2.0 KiB Raw Blame History