docs: align runtime layout with interactive provisioning flow
This commit is contained in:
parent
dcc4051286
commit
de3d7352df
@ -13,7 +13,11 @@ Jedes Modul besitzt genau ein eigenes Unterverzeichnis.
|
||||
/run/tuxflotte/
|
||||
├── network/
|
||||
├── hardware/
|
||||
├── enrollment/
|
||||
├── server/
|
||||
├── provisioning/
|
||||
├── assignment/
|
||||
├── installation/
|
||||
├── runtime/
|
||||
├── backend/
|
||||
└── logs/
|
||||
@ -26,9 +30,21 @@ 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
|
||||
|
||||
@ -47,7 +63,11 @@ Andere Modulverzeichnisse dürfen nur gelesen werden, wenn dies für den definie
|
||||
Beispiele:
|
||||
|
||||
- 10_hardware.sh schreibt nur nach /run/tuxflotte/hardware/
|
||||
- 15_server_handshake.sh liest aus /run/tuxflotte/network/ und /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 liest aus /run/tuxflotte/server/
|
||||
- Der Backend-Orchestrator liest aus /run/tuxflotte/runtime/
|
||||
|
||||
|
||||
@ -15,41 +15,98 @@ Boot
|
||||
↓
|
||||
Netzwerk initialisieren
|
||||
↓
|
||||
Aktivierungscode erfassen
|
||||
Hardware und Geräteidentität erfassen
|
||||
↓
|
||||
Enrollment-Autorisierung erfassen
|
||||
↓
|
||||
Provisioning Handshake
|
||||
↓
|
||||
Gerät und Organisation erkennen
|
||||
↓
|
||||
verfügbare Profile anzeigen
|
||||
Gerätestatus anzeigen
|
||||
↓
|
||||
Profil auswählen
|
||||
Provisionierung fortsetzen?
|
||||
├── nein → kontrollierter Abbruch
|
||||
└── ja
|
||||
↓
|
||||
Installationsplan anzeigen
|
||||
verfügbare Profile anzeigen
|
||||
↓
|
||||
Installation explizit bestätigen
|
||||
Profil auswählen
|
||||
↓
|
||||
Commit Point
|
||||
Installationsplan anzeigen
|
||||
↓
|
||||
Runtime Blueprint
|
||||
Installation explizit bestätigen
|
||||
↓
|
||||
Backend
|
||||
Commit Point
|
||||
↓
|
||||
Native Installation
|
||||
|
||||
|
||||
Also:
|
||||
|
||||
```markdown
|
||||
Runtime Blueprint
|
||||
↓
|
||||
Native Installation
|
||||
Backend
|
||||
↓
|
||||
Native Installation
|
||||
```
|
||||
|
||||
## Runtime-Zustände
|
||||
|
||||
Der interaktive Provisionierungsablauf übergibt seinen Zustand über klar getrennte Runtime-Verzeichnisse unter `/run/tuxflotte/`.
|
||||
|
||||
### Enrollment-Autorisierung
|
||||
|
||||
Die Autorisierung des Provisionierungsvorgangs wird unter folgendem Pfad gespeichert:
|
||||
|
||||
```text
|
||||
/run/tuxflotte/enrollment/
|
||||
└── authorization.json
|
||||
```
|
||||
|
||||
`authorization.json` enthält den für den aktuellen Provisionierungsvorgang vorbereiteten Autorisierungszustand.
|
||||
|
||||
Im aktuellen Bootstrap-Modell wird ein temporärer Aktivierungscode verwendet.
|
||||
|
||||
Beispiel:
|
||||
|
||||
```json
|
||||
{
|
||||
"schema_version": 1,
|
||||
"authorization_type": "bootstrap_activation_code",
|
||||
"activation_code": "LAB-2026-START"
|
||||
}
|
||||
```
|
||||
|
||||
Der Provisioning Handshake besitzt keinen eigenen Fallback-Aktivierungscode.
|
||||
|
||||
Fehlt eine gültige Enrollment-Autorisierung, muss der Handshake abgebrochen werden.
|
||||
|
||||
Der Bootstrap-Aktivierungscode ist ein Übergangsmechanismus und wird langfristig durch Benutzeranmeldung oder Enrollment Sessions ersetzt.
|
||||
|
||||
### Provisionierungsentscheidung
|
||||
|
||||
Die Entscheidung, ob der interaktive Provisionierungsablauf nach Anzeige des Gerätestatus fortgesetzt werden soll, wird unter folgendem Pfad gespeichert:
|
||||
|
||||
```text
|
||||
/run/tuxflotte/provisioning/
|
||||
└── state.env
|
||||
```
|
||||
|
||||
Der Zustand enthält:
|
||||
|
||||
```bash
|
||||
TUXFLOTTE_PROVISIONING_CONTINUE=true
|
||||
```
|
||||
|
||||
oder:
|
||||
|
||||
```bash
|
||||
TUXFLOTTE_PROVISIONING_CONTINUE=false
|
||||
```
|
||||
|
||||
Bei `false` beendet der Orchestrator den Provisionierungsvorgang kontrolliert und erfolgreich.
|
||||
|
||||
Fehlt die Zustandsdatei oder enthält sie einen unbekannten Wert, muss der Orchestrator den Ablauf mit einem Fehler beenden.
|
||||
|
||||
|
||||
### Aktivierung
|
||||
.
|
||||
|
||||
Die Aktivierungsphase verwendet die bereits bestehende Server-Runtime:
|
||||
|
||||
```text
|
||||
@ -213,7 +270,9 @@ Der Interactive Provisioning Flow wird durch folgende Module umgesetzt:
|
||||
```text
|
||||
05_network.sh
|
||||
10_hardware.sh
|
||||
12_enrollment_auth.sh
|
||||
15_server_handshake.sh
|
||||
17_device_status.sh
|
||||
20_profile_selection.sh
|
||||
25_installation_confirm.sh
|
||||
30_runtime_blueprint.sh
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user