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.
3.8 KiB
Feature- und Blueprint-Modell
Status: Entwurf Datum: 17.07.2026
Zweck dieses Dokuments
Dieses Dokument beschreibt, wie die Merkmale eines Workspace für ein konkretes Backend technisch umgesetzt werden.
Es ergänzt das Workspace-Modell (02-workspace-model.md) und das Backend-Modell um den bisher fehlenden Übersetzungsmechanismus und präzisiert den Begriff „Blueprint" aus dem Glossar.
Motivation
Ein Workspace beschreibt einen Einsatzzweck, nicht seine technische Umsetzung.
Ein Backend beschreibt eine Distribution, nicht die einzelnen fachlichen Eigenschaften eines Workspace.
Zwischen beiden fehlt ein Bindeglied: die Frage, wie ein einzelnes Merkmal eines Workspace auf einem bestimmten Backend konkret realisiert wird.
Dieses Bindeglied ist der Blueprint.
Definition
Merkmal
Ein Merkmal ist eine einzelne fachliche Eigenschaft eines Workspace.
Ein Merkmal ist distributionsunabhängig benannt.
Beispiele:
- browser-brave
- office-onlyoffice
- guest-session-ephemeral
- appstore
Ein Workspace besteht aus einer Menge von Merkmalen.
Blueprint
Ein Blueprint beschreibt die technische Umsetzung genau eines Merkmals für genau ein Backend.
Ein Blueprint ist im Regelfall eine Ansible-Rolle bzw. -Aufgabe.
Für ein Merkmal existiert je unterstütztem Backend höchstens ein Blueprint.
Beispiel:
| Merkmal | Backend | Blueprint |
|---|---|---|
| browser-brave | fedora | Ansible-Rolle „brave-fedora" (dnf, Brave-Repository) |
| browser-brave | mint | Ansible-Rolle „brave-mint" (apt, Brave-Repository) |
| guest-session-ephemeral | fedora | Ansible-Rolle „guest-session" (tmpfs-Home, PAM) |
| guest-session-ephemeral | mint | Ansible-Rolle „guest-session" (tmpfs-Home, PAM) |
Ein Blueprint kann von mehreren Backends wiederverwendet werden, wenn die Umsetzung identisch ist.
Runtime Blueprint
Das Runtime Blueprint einer konkreten Installation entsteht, indem für jedes Merkmal des gewählten Workspace der zum gewählten Backend passende Blueprint aufgelöst wird.
Die Sammlung aller aufgelösten Blueprints wird nach dem ersten Start über den bestehenden Ansible-Pull-Mechanismus angewendet.
Abgrenzung zu installationszeitlichen Vorgaben
Partitionierung, Festplattenverschlüsselung, Secure-Boot- und TPM-Bindung sowie weitere zur Installationszeit unveränderliche Eigenschaften sind kein Bestandteil eines Blueprints.
Sie werden als direkte Vorgabe der gewählten Bereitstellungsvorlage an backend_generate_config() übergeben und fließen unmittelbar in die native Installationskonfiguration ein (siehe 06-backend-api.md, 08-provisioning-api.md).
Blueprints setzen ausschließlich userspace-seitige Merkmale um, die nach der Installation angewendet werden können, ohne die Partitionierung oder die native Installationskonfiguration zu verändern.
Erweiterbarkeit
Neue Merkmale erfordern Blueprints für jedes bereits unterstützte Backend.
Neue Backends erfordern Blueprints für jedes bereits bestehende Merkmal.
Workspace- und Merkmal-Definitionen bleiben davon unberührt.
Beispiel
Workspace: Schulcomputer
Merkmale:
- guest-session-ephemeral
- browser-brave
- office-onlyoffice
Workspace: Entwickler
Merkmale:
- Programmiersprachen
- Virtualisierung
- Editoren
- Entwicklungsumgebungen
Unterstützte Backends
- Fedora
- Linux Mint
Zusammenfassung
Ein Workspace besteht aus Merkmalen.
Ein Blueprint setzt genau ein Merkmal für genau ein Backend um, in der Regel als Ansible-Rolle.
Das Runtime Blueprint einer konkreten Installation entsteht aus der Auflösung aller Merkmale des gewählten Workspace gegen das gewählte Backend.
Installationszeitliche Vorgaben wie Partitionierung und Verschlüsselung bleiben ein direkter Kanal der Bereitstellungsvorlage und sind kein Bestandteil eines Blueprints.