Thomas Stallinger
525ad58b60
The previous Auto-Modus-Gate rule unconditionally forced new devices into the interactive flow because no better mechanism was known yet. Enrollment Sessions (11-device-enrollment.md) already solve planned bulk rollouts, but not a single, spontaneously booted new device. New devices in auto mode now go on hold after the identification handshake and wait for a customer to confirm registration and assign a workspace via the future management UI, reusing the same fail-closed poll mechanism already planned for the interactive flow's kiosk communication (ADR-0007). Devices covered by an active Enrollment Session are unaffected and remain fully unattended. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
40 lines
4.1 KiB
Markdown
40 lines
4.1 KiB
Markdown
# ADR-0008: Portal-Bestätigung für Neugeräte im Auto-Modus ohne Enrollment Session
|
|
|
|
**Status:** Beschlossen
|
|
**Datum:** 23.07.2026
|
|
|
|
## Kontext
|
|
|
|
`13-live-provisioning-boot.md` (Abschnitt "Auto-Modus-Gate") legte bisher fest, dass ein unbekanntes Gerät (`registration_status == "registered"`) niemals den automatisierten Ablauf durchläuft, unabhängig vom gewählten Bootmenüeintrag — die Geräteaufnahme blieb ausnahmslos an eine lokale, interaktive Bestätigung gebunden. Diese Formulierung war der Situation geschuldet, dass zum Zeitpunkt der ursprünglichen Entscheidung noch keine bessere Umsetzung für eine unbeaufsichtigte Neugeräte-Provisionierung im Auto-Modus vorlag.
|
|
|
|
`11-device-enrollment.md` beschreibt daneben bereits **Enrollment Sessions**: zeitlich begrenzte, organisationsgebundene Vorab-Freigaben für geplante Massenrollouts (maximale Geräteanzahl, erlaubte Bereitstellungsvorlagen, widerrufbar, auditierbar). Diese lösen den Fall eines *geplanten* Rollouts, aber nicht den Fall eines *einzelnen, spontan gebooteten* Neugeräts ohne vorab eingerichtete Session — genau diese Lücke schließt die vorliegende Entscheidung.
|
|
|
|
## Entscheidung
|
|
|
|
Ein neues Gerät (`registration_status == "registered"`), das im Auto-Modus bootet und **nicht** durch eine aktive Enrollment Session abgedeckt ist, wird nicht mehr zwingend in den interaktiven Ablauf gezwungen. Stattdessen:
|
|
|
|
1. Das Gerät durchläuft den üblichen Identifikations-Handshake (Geräte-ID wird dem Provisioning Server bekanntgegeben).
|
|
2. Es geht anschließend in einen **Wartezustand ("on hold")** über — die destruktive Installation beginnt nicht.
|
|
3. Ein Kunde bestätigt über die künftige Verwaltungsoberfläche die Registrierung des Geräts und weist ihm einen Workspace zu.
|
|
4. Erst nach dieser serverseitig vermerkten, zentralen Bestätigung überschreitet der Orchestrator den Commit Point.
|
|
|
|
Damit ergeben sich für neue Geräte im Auto-Modus zwei Freigabewege, die sich nicht überschneiden, sondern ergänzen:
|
|
|
|
- **Mit abdeckender Enrollment Session:** vollständig unbeaufsichtigt, wie ursprünglich für Massenrollouts vorgesehen — die Vorab-Freigabe der Session deckt die Autorisierung ab.
|
|
- **Ohne abdeckende Enrollment Session:** Einzel-Bestätigung über das Portal, wie oben beschrieben — für den spontanen, ungeplanten Fall.
|
|
|
|
Die beiden Bootmodi bleiben dadurch klar unterscheidbar:
|
|
|
|
- **auto:** bei Neugeräten ist stets eine zentrale Bestätigung/Festlegung notwendig — vorab durch eine Enrollment Session, oder nachträglich durch eine Portal-Bestätigung.
|
|
- **interaktiv:** der Benutzer bestätigt und konfiguriert lokal am Gerät, ohne dass parallel eine zentrale Aktion nötig wäre.
|
|
|
|
Für bereits bekannte Geräte (`registration_status == "existing"`) ändert sich nichts — die automatisierte Reprovisionierung ohne erneute Bestätigung bleibt wie in `11-device-enrollment.md` beschrieben.
|
|
|
|
## Konsequenzen
|
|
|
|
- Der Auto-Modus für Neugeräte ohne Enrollment Session ist ohne ein funktionierendes Verwaltungsportal (Registrierung + Workspace-Zuweisung) nicht nutzbar. Für den aktuellen Piloten irrelevant — dort kommt der interaktive Modus zum Einsatz (siehe Pilot-Roadmap).
|
|
- Technisch lässt sich der Wartezustand mit demselben Fail-Closed-Baustein umsetzen, der für den interaktiven Ablauf bereits vorgesehen ist: `25_installation_confirm.sh` pollt im Auto-Modus den Server auf einen expliziten Freigabe-Zustand, statt eine TTY-Eingabe zu lesen — dieselbe Grundmechanik wie in ADR-0007 für die Kiosk-Kommunikation festgelegt.
|
|
- Kein statisches Geheimnis auf dem Medium (Aktivierungscode o.ä.) autorisiert je allein eine destruktive Aktion — konsistent mit der in `11-device-enrollment.md` ohnehin schon vorgesehenen schrittweisen Ablösung des Aktivierungscodes.
|
|
- Offen, nicht Teil dieser Entscheidung: das genaue Zusammenspiel zwischen Enrollment Session und Workspace-Zuweisung — ob eine Session mit genau einer erlaubten Bereitstellungsvorlage die Workspace-Wahl implizit vorwegnimmt, oder ob auch dort noch ein einzelner Bestätigungsschritt nötig ist.
|
|
- `13-live-provisioning-boot.md` (Auto-Modus-Gate) und `11-device-enrollment.md` werden entsprechend angepasst.
|