Thomas Stallinger
fce6e4860c
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.
77 lines
2.0 KiB
Markdown
77 lines
2.0 KiB
Markdown
# 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.
|