admin/platform-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
platform-docs/adr/0008-neugeraete-auto-modus-portal-bestaetigung.md
Thomas Stallinger 525ad58b60 docs: portal confirmation for new devices in auto mode without an enrollment session (ADR-0008) 
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>
2026-07-23 09:37:47 +02:00

4.1 KiB
Raw Blame History

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.