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>
Kiosk UI: Chromium was evaluated as an Epiphany alternative (ADR-0005)
after ADR-0004's application-mode approach turned out unusable
end-to-end, then abandoned after four distinct real-boot failures in a
row (ADR-0006) in favor of a hardened plain --profile Epiphany launch.
ADR-0004 amended with the actual fix history (profile directory
creation, application-mode's undocumented web-app requirement,
--private-instance/--profile conflict on the target's Epiphany 50.1
vs. the 43.1 used for local testing). ADR-0007 resolves ADR-0004's
open question: the kiosk web UI and installer.sh never talk directly,
only via the provisioning server.
WLAN autoprovisioning: customer profile gets an "Autoprovisionierung"
flag plus WLAN credentials, driving self-service generation of a
personalized ISO with the credentials baked in as a NetworkManager
profile — works from device one, no persistent on-stick state needed.
Personalizing the build this way also motivated giving the ISO its
own volume label (TUXFLOTTE) instead of the source Fedora label.
Also folds in the EROFS root-cause writeup and the Ubuntu-live-medium
alternative noted for a future ISO rework, and brings
roadmap/installer-roadmap.md's checkboxes in line with actual status.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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.
Introduces the Merkmal-Backend-Blueprint realization model: a Merkmal
describes one distribution-independent workspace feature, a Blueprint
realizes exactly one Merkmal for exactly one backend (usually an
Ansible role applied post-first-boot via ansible-pull), and a
Bereitstellungsvorlage bundles workspace + backend + org-specific
installation directives (partitioning, encryption, secure boot).
Replaces the old flat profile model (profiles/profile.json/
distribution+version) throughout the provisioning API, data model,
interactive provisioning flow, and device enrollment docs with
templates/Bereitstellungsvorlage terminology. Moves 02-workspace-model.md
and 04-backend-model.md into architecture/, archives the superseded
flat organization-model.md.
