docs: document provisioning handshake and persistence model

00-glossary.md

@@ -0,0 +1,81 @@
+# Tuxflotte Glossary
+
+**Status:** Stable  
+**Datum:** 2026-07-07
+
+## Workspace
+
+Ein fachlich definierter Arbeitsplatz.
+
+Ein Workspace beschreibt, welchen Zielzustand ein System haben soll.
+
+Beispiele:
+
+- Developer Workspace
+- Office Workspace
+- Kiosk Workspace
+
+Ein Workspace ist nicht distributionsabhängig.
+
+## Backend
+
+Eine distributionsspezifische Implementierung.
+
+Ein Backend beschreibt, wie ein Workspace auf einer bestimmten Distribution installiert wird.
+
+Beispiele:
+
+- Fedora Backend
+- Mint Backend
+- Debian Backend
+
+## Organization
+
+Eine Organisation beschreibt kunden- oder unternehmensweite Vorgaben.
+
+Beispiele:
+
+- Zertifikate
+- LDAP
+- Keycloak
+- Paketquellen
+- Proxy
+- Branding
+- VPN
+- Monitoring
+
+## Blueprint
+
+Die technische Beschreibung eines Workspace.
+
+## Runtime Blueprint
+
+Die zur Installationszeit erzeugte vollständige Zielbeschreibung.
+
+Sie entsteht aus:
+
+- Backend
+- Organization
+- Workspace
+- optional Benutzerkontext
+
+## Orchestrator
+
+Die Komponente der Provisioning-ISO, die den Ablauf steuert.
+
+Der Orchestrator erkennt Hardware, lädt Profile, erzeugt Runtime Blueprints und startet das passende Backend.
+
+## Provisioning Agent
+
+Der Agent läuft auf dem installierten System und übernimmt Registrierung, Nachkonfiguration, Inventarisierung und Lebenszyklusaufgaben.
+
+## Native Installer
+
+Der offizielle Installer der jeweiligen Distribution.
+
+Beispiele:
+
+- Anaconda
+- Calamares
+- Debian Installer
+- Subiquity

00-philosophy.md

@@ -0,0 +1,57 @@
+# Tuxflotte Philosophy
+
+**Status:** Stable  
+**Datum:** 2026-07-07
+
+## Leitidee
+
+Tuxflotte installiert keine Distributionen.
+
+Tuxflotte stellt Workspaces bereit.
+
+Ein Workspace beschreibt einen gewünschten Arbeitsplatzzustand, unabhängig davon, ob dieser später mit Fedora, Linux Mint, Debian oder Ubuntu umgesetzt wird.
+
+## Grundsätze
+
+1. Vision vor Implementierung
+2. Architektur vor Code
+3. Schnittstellen vor Implementierungen
+4. Dokumentation ist Teil des Produkts
+5. Der Code implementiert die Spezifikation
+6. Distributionen sind austauschbare Zielplattformen
+7. Der Tuxflotte-Kern bleibt distributionsneutral
+
+## Was Tuxflotte ist
+
+Tuxflotte ist eine Plattform zur Beschreibung, Bereitstellung und Verwaltung standardisierter Linux-Arbeitsplätze.
+
+## Was Tuxflotte nicht ist
+
+Tuxflotte ist kein eigener Linux-Installer.
+
+Die eigentliche Betriebssysteminstallation erfolgt über die nativen Installer der jeweiligen Distribution.
+
+## Produktgedanke
+
+Nicht Fedora oder Mint sind das Produkt.
+
+Der bereitgestellte Arbeitsplatz ist das Produkt.
+
+Beispiele:
+
+- Office Workspace
+- Developer Workspace
+- Kiosk Workspace
+- Schulungsraum
+- Secure Workspace
+
+## Notiz:
+Linux ist das Ergebnis einer weltweiten Gemeinschaft.
+
+Seine Vielfalt ist Ausdruck unterschiedlicher Ideen, Anforderungen und Überzeugungen.
+
+Tuxflotte respektiert diese Vielfalt.
+
+Die Plattform schafft eine gemeinsame Grundlage für die Bereitstellung und Verwaltung von Linux-Workspaces, ohne die Eigenständigkeit der Distributionen aufzugeben.
+
+Tuxflotte schafft Gemeinsamkeit, ohne Vielfalt aufzugeben.

01-design-principles.md

@@ -0,0 +1,117 @@
+# Design Principles
+
+**Status:** Stable
+
+## Zweck dieses Dokuments
+
+Dieses Dokument beschreibt die grundlegenden Gestaltungsprinzipien von Tuxflotte.
+
+Die Design Principles bilden den architektonischen Rahmen für die Entwicklung der Plattform. Sie sind bewusst technologieunabhängig formuliert und gelten unabhängig von Programmiersprachen, Frameworks oder den verwendeten Werkzeugen.
+
+Bei Architektur- und Implementierungsentscheidungen dienen diese Prinzipien als Orientierung. Sie bilden den gemeinsamen Maßstab für die Weiterentwicklung der Plattform. 
+
+---
+
+# 1. Der Workspace steht im Mittelpunkt
+
+Der fachliche Mittelpunkt von Tuxflotte ist der **Workspace**.
+
+Ein Workspace beschreibt den gewünschten Arbeitsplatz eines Benutzers oder einer Benutzergruppe. Er definiert den Zielzustand eines Systems und bildet die Grundlage jeder Provisionierung.
+
+Linux-Distributionen sind die technischen Zielplattformen, auf denen ein Workspace bereitgestellt wird. Der Workspace selbst bleibt unabhängig von der gewählten Distribution.
+
+---
+
+# 2. Tuxflotte orchestriert
+
+Tuxflotte steuert und begleitet den gesamten Bereitstellungsprozess eines Workspaces.
+
+Dazu erkennt die Plattform Hardware, verarbeitet Organisations- und Workspace-Informationen, erzeugt ein Runtime Blueprint, das den vollständigen Zielzustand der Installation beschreibt, und übergibt dieses an das passende Backend.
+
+Die eigentliche Installation des Betriebssystems erfolgt mit den nativen Installationswerkzeugen der jeweiligen Distribution. Tuxflotte ergänzt diese Werkzeuge, ersetzt sie jedoch bewusst nicht.
+
+---
+
+# 3. Der Kern bleibt distributionsneutral
+
+Der Kern von Tuxflotte stellt die distributionsunabhängige Orchestrierung der Plattform bereit.
+
+Distributionsspezifische Implementierungen werden ausschließlich in Backends umgesetzt. Dadurch bleibt der Kern schlank, wartbar und leicht erweiterbar.
+
+---
+
+# 4. Jede Schicht besitzt eine klare Verantwortung
+
+Die Architektur von Tuxflotte ist in klar abgegrenzte Schichten unterteilt.
+
+Jede Schicht erfüllt genau eine Aufgabe und stellt definierte Schnittstellen für die darüber- oder darunterliegenden Schichten bereit.
+
+Klare Verantwortlichkeiten bilden die Grundlage für eine verständliche, wartbare und langfristig erweiterbare Architektur.
+
+---
+
+# 5. Runtime Blueprints beschreiben den Zielzustand
+
+Vor jeder Installation erzeugt Tuxflotte ein **Runtime Blueprint**.
+
+Es beschreibt den vollständigen Zielzustand einer konkreten Installation und entsteht aus den Informationen der verschiedenen Architekturschichten, beispielsweise Workspace, Organization und Backend.
+
+Das Runtime Blueprint dient dem Backend als Grundlage für die Erstellung distributionsspezifischer Installationsdaten.
+
+---
+
+# 6. Wiederverwendung vor Duplizierung
+
+Tuxflotte setzt auf wiederverwendbare Bausteine.
+
+Neue Anforderungen werden nach Möglichkeit durch die Kombination bestehender Komponenten umgesetzt.
+
+Dadurch entstehen flexible Lösungen mit geringem Wartungsaufwand und einer hohen Konsistenz über alle Workspaces hinweg.
+
+---
+
+# 7. Dokumentation ist Teil der Architektur
+
+Die Dokumentation beschreibt die Architektur und die gemeinsame Sprache von Tuxflotte.
+
+Sie begleitet die Entwicklung von Beginn an und bildet die Grundlage für Implementierung, Erweiterung und Wartung der Plattform. Die Implementierung folgt der Architektur – nicht umgekehrt.
+
+
+---
+
+# 8. Entscheidungen bleiben nachvollziehbar
+
+Architekturentscheidungen werden dokumentiert und begründet.
+
+Historische Dokumente werden archiviert, anstatt gelöscht zu werden. Dadurch bleibt die Entwicklung der Plattform langfristig nachvollziehbar und Erfahrungen gehen nicht verloren.
+
+---
+
+# 9. Verständlichkeit schafft Qualität
+
+Eine verständliche Architektur ist langfristig wertvoller als eine möglichst raffinierte technische Lösung.
+
+Klarheit, Lesbarkeit und nachvollziehbare Zusammenhänge erleichtern die Zusammenarbeit und bilden die Grundlage für nachhaltige Softwareentwicklung.
+
+---
+
+# 10. Nachhaltigkeit vor kurzfristiger Optimierung
+
+Tuxflotte wird als langfristige Plattform entwickelt.
+
+Architekturentscheidungen sollen deshalb nicht nur aktuelle Anforderungen erfüllen, sondern auch zukünftige Erweiterungen ermöglichen.
+
+
+---
+
+# Zusammenfassung
+
+Tuxflotte beschreibt Linux-Workspaces, stellt sie bereit und verwaltet sie.
+
+Workspaces definieren den gewünschten Zielzustand.
+
+Backends übersetzen diesen Zielzustand in distributionsspezifische Installationsdaten.
+
+Die nativen Installer der Distributionen installieren das Betriebssystem.
+
+Tuxflotte orchestriert den gesamten Prozess und schafft damit eine distributionsunabhängige Plattform für den Lebenszyklus standardisierter Linux-Workspaces.

02-workspace-model.md

@@ -0,0 +1,57 @@
+# Workspace Model
+
+**Status:** Stable
+
+## Zweck dieses Dokuments
+
+Dieses Dokument beschreibt den Workspace als zentralen Gegenstand von Tuxflotte.
+
+Es definiert seine Aufgabe innerhalb der Plattform und beschreibt seine Verantwortung sowie seine Abgrenzung zu den übrigen Komponenten der Architektur.
+
+---
+
+## Motivation
+
+Benutzende erfüllen unterschiedliche Aufgaben und übernehmen unterschiedliche Rollen.
+
+Daraus ergeben sich unterschiedliche Anforderungen an ihren Arbeitsplatz.
+
+**Ein Workspace beschreibt die Anforderungen, die sich aus einer bestimmten Aufgabe oder Rolle der Benutzenden ergeben.**
+
+---
+
+## Definition
+
+Der Workspace ist der zentrale Gegenstand von Tuxflotte.
+
+Er beschreibt den gewünschten Zielzustand eines Linux-Arbeitsplatzes unabhängig von dessen technischer Umsetzung.
+
+Ein Workspace definiert, welche Eigenschaften ein Arbeitsplatz besitzen soll. Er beschreibt den gewünschten Zielzustand, der durch die weiteren Komponenten der Plattform umgesetzt wird.
+
+---
+
+## Verantwortungsbereich
+
+Ein Workspace beschreibt beispielsweise
+
+- den Zweck eines Arbeitsplatzes,
+- die Zielgruppe,
+- die erforderlichen Funktionen,
+- die benötigte Software,
+- optionale Erweiterungen,
+- Sicherheitsanforderungen sowie
+- organisatorische Anforderungen.
+
+Der Workspace beschreibt den gewünschten Zielzustand eines Arbeitsplatzes.
+
+Die technische Umsetzung dieses Zielzustands erfolgt durch die weiteren Komponenten der Plattform.
+
+---
+
+## Zusammenfassung
+
+Der Workspace bildet die Grundlage jeder Bereitstellung.
+
+Er beschreibt den gewünschten Zielzustand eines Linux-Arbeitsplatzes.
+
+Alle weiteren Komponenten von Tuxflotte arbeiten darauf hin, diesen Zielzustand auf einem Zielsystem bereitzustellen.

03-organization-model.md

@@ -0,0 +1,59 @@
+# Organization Model
+
+**Status:** Stable
+
+## Zweck dieses Dokuments
+
+Dieses Dokument beschreibt die Organization als organisatorischen Rahmen für die Bereitstellung von Workspaces.
+
+Es definiert ihre Aufgabe innerhalb der Plattform und beschreibt ihre Verantwortung sowie ihre Abgrenzung zu den übrigen Komponenten der Architektur.
+
+---
+
+## Motivation
+
+Workspaces beschreiben den gewünschten Arbeitsplatz.
+
+Unterschiedliche Organisationen stellen jedoch unterschiedliche Anforderungen an die Bereitstellung desselben Workspace.
+
+So kann ein Workspace beispielsweise auf einem einer Person fest zugeordneten Gerät oder auf einem gemeinsam genutzten Gerät bereitgestellt werden.
+
+Die Organization beschreibt die organisatorischen Rahmenbedingungen, unter denen Workspaces bereitgestellt werden.
+
+---
+
+## Definition
+
+Die Organization beschreibt die organisatorischen Rahmenbedingungen, unter denen Workspaces bereitgestellt werden.
+
+Sie ergänzt den Workspace um organisationsspezifische Anforderungen, die unabhängig vom eigentlichen Arbeitsplatz gelten.
+
+Dadurch können identische Workspaces in unterschiedlichen Organisationen unter jeweils passenden Rahmenbedingungen bereitgestellt werden.
+
+---
+
+## Verantwortungsbereich
+
+Eine Organization beschreibt beispielsweise
+
+- organisatorische Richtlinien,
+- organisationsweite Sicherheitsanforderungen,
+- Standardkonfigurationen,
+- Anforderungen an Authentifizierung und Identitätsmanagement,
+Zertifikate,
+- Softwarequellen,
+- Netzwerkanforderungen,
+- Branding sowie
+- Rahmenbedingungen für die Nutzung von Geräten.
+
+Die Organization beschreibt den organisatorischen Rahmen der Bereitstellung.
+
+Die technische Umsetzung dieser Rahmenbedingungen erfolgt durch die weiteren Komponenten der Plattform.
+
+---
+
+## Zusammenfassung
+
+Die Organization ergänzt den Workspace um organisationsspezifische Rahmenbedingungen.
+
+Gemeinsam beschreiben Workspace und Organization die fachliche Grundlage für die Bereitstellung eines Linux-Workspaces.

04-backend-model.md

@@ -0,0 +1,55 @@
+# Backend Model
+
+**Status:** Stable
+
+## Zweck dieses Dokuments
+
+Dieses Dokument beschreibt das Backend als distributionsspezifische Umsetzung der Workspaces von Tuxflotte.
+
+Es definiert seine Aufgabe innerhalb der Plattform und beschreibt seine Verantwortung sowie seine Abgrenzung zu den übrigen Komponenten der Architektur.
+
+---
+
+## Motivation
+
+Die Linux-Welt zeichnet sich durch ihre Vielfalt aus.
+
+Unterschiedliche Distributionen verfolgen unterschiedliche Ziele und besitzen eigene Stärken. Sie unterscheiden sich beispielsweise in ihrer Systemarchitektur, den Paketformaten, den Desktopumgebungen oder ihren Veröffentlichungsmodellen.
+
+Diese Vielfalt ist eine Stärke des Linux-Ökosystems.
+
+Tuxflotte respektiert diese Vielfalt und bewahrt sie. Anstatt Distributionen zu vereinheitlichen, kapselt die Plattform distributionsspezifische Unterschiede bewusst in Backends.
+
+Dadurch können identische Workspaces auf unterschiedlichen Linux-Distributionen bereitgestellt werden.
+
+---
+
+## Definition
+
+Ein Backend beschreibt die distributionsspezifische Umsetzung eines Workspace unter Berücksichtigung der organisatorischen Rahmenbedingungen.
+
+Es übersetzt die fachlichen Anforderungen in distributionsspezifische Installationsdaten und nutzt dabei die nativen Installationsmechanismen der jeweiligen Distribution.
+
+---
+
+## Verantwortungsbereich
+
+Ein Backend beschreibt beispielsweise
+
+- die Zuordnung fachlicher Funktionen zu distributionsspezifischen Paketen,
+- distributionsspezifische Konfigurationen,
+- die Erstellung distributionsspezifischer Installationsdaten,
+- die Anbindung an native Installationswerkzeuge sowie
+- distributionsspezifische Besonderheiten.
+
+Das Backend beschreibt die technische Umsetzung eines Workspace.
+
+Die fachliche Beschreibung eines Arbeitsplatzes erfolgt durch den Workspace. Die organisatorischen Rahmenbedingungen werden durch die Organization beschrieben.
+
+---
+
+## Zusammenfassung
+
+Das Backend verbindet die distributionsunabhängigen Modelle von Tuxflotte mit den nativen Installationsmechanismen einer Linux-Distribution.
+
+Dadurch bleibt der Kern von Tuxflotte distributionsneutral, während gleichzeitig die Vielfalt des Linux-Ökosystems vollständig erhalten bleibt.

README.md

@@ -1,13 +1,27 @@
-# Stallinux Provisioning Platform
+# Tuxflotte Platform Docs
 
-Repositories:
+Dieses Repository beschreibt die Architektur, Begriffe und Leitentscheidungen von Tuxflotte.
 
-- provisioning-server
+Tuxflotte ist eine distributionsunabhängige Workspace-Provisioning-Plattform für Linux-Arbeitsplätze.
-- provisioning-client
-- platform-docs
 
-Planned:
+## Einstieg
 
-- profiles
+1. `00-philosophy.md`
-- installer definitions
+2. `00-glossary.md`
-- ansible roles
+3. `architecture/01-layered-provisioning.md`
+4. `architecture/02-workspace-model.md`
+5. `architecture/05-runtime-blueprint.md`
+6. `architecture/06-backend-api.md`
+
+## Bereiche
+
+- `architecture/` – gültige Architektur
+- `adr/` – Architekturentscheidungen
+- `roadmap/` – Planung und Meilensteine
+- `archive/` – historische Dokumente
+
+## Grundsatz
+
+Die Dokumentation ist die Spezifikation.
+
+Der Code implementiert diese Spezifikation.

adr/0001-postgresql-platform-database.md

@@ -0,0 +1,61 @@
+# ADR-0001: PostgreSQL als persistente Plattformdatenbank
+
+**Status:** Beschlossen  
+**Datum:** 12.07.2026
+
+## Kontext
+
+Tuxflotte verwaltet zunehmend persistente und miteinander verknüpfte Plattformdaten.
+
+Dazu gehören unter anderem:
+
+- Organisationen
+- Geräte
+- Gerätezuordnungen
+- Hardware-Snapshots
+- Netzwerkprofile
+- Workspaces
+- Backends
+- Runtime Blueprints
+- Secret-Referenzen
+
+Die bisherige dateibasierte Device Registry diente dem Nachweis des grundlegenden Provisioning-Handshakes.
+
+Für das langfristige Plattformmodell ist eine strukturierte persistente Datenhaltung erforderlich.
+
+## Entscheidung
+
+Tuxflotte verwendet PostgreSQL als persistente Plattformdatenbank.
+
+Die Datenbank bildet die Beziehungen zwischen Organisationen, Geräten, Hardware-Snapshots, Workspaces, Backends und Gerätezuordnungen ab.
+
+Die dateibasierte Device Registry wird nicht als dauerhaftes Persistenzmodell weitergeführt.
+
+Hardwareinformationen werden als zeitbezogene Snapshots gespeichert.
+
+Die stabile Geräteidentität und der erfasste Hardwarezustand werden getrennt behandelt.
+
+Secrets werden nicht als Klartextbestandteil der fachlichen Plattformdaten gespeichert.
+
+Das konkrete Secret-Management wird in einer separaten Architekturentscheidung definiert.
+
+## Konsequenzen
+
+Der Provisioning-Server erhält eine PostgreSQL-Anbindung.
+
+Änderungen am Datenbankschema werden über versionierte Migrationen verwaltet.
+
+Geräte erhalten eine interne, von Hardwaremerkmalen unabhängige Datenbank-ID.
+
+Der Hardware-Fingerprint dient der Wiedererkennung eines Geräts während des Provisioning-Handshakes.
+
+Hardwaredaten werden getrennt von der Geräteidentität als Snapshots gespeichert.
+
+Ein Gerät kann mehrere Hardware-Snapshots besitzen.
+
+Netzwerkinterfaces und Massenspeicher können einem Hardware-Snapshot zugeordnet werden.
+
+Die bestehende dateibasierte Device Registry wird nach erfolgreicher Einführung der Datenbank entfernt.
+
+Die Provisioning API bleibt von der konkreten Persistenzimplementierung unabhängig.
+

architecture/00-provisioning-flow.md

@@ -0,0 +1,51 @@
+Boot
+ ↓
+Preflight
+ ↓
+Netzwerk
+ ↓
+Hardware Identity
+ ↓
+Server Discovery
+ ↓
+Device Registration
+ ↓
+Assignment
+ ↓
+Runtime Blueprint
+ ↓
+Backend Selection
+ ↓
+Backend API
+ ↓
+Native Installer
+ ↓
+First Boot
+ ↓
+Provisioning Agent
+ ↓
+Managed System
+
+## Aktivierung und Gerätebindung
+
+Ein neues Gerät authentifiziert den ersten Provisionierungsvorgang mit einem Aktivierungscode.
+
+Nach erfolgreicher Prüfung wird der vom Installer erzeugte Hardware-Fingerprint an den Provisioning-Server übertragen.
+
+Der Server bindet den Fingerprint an die Aktivierung beziehungsweise an die zugehörige Organisation.
+
+Der Aktivierungscode ist damit die initiale Berechtigung.
+
+Der Hardware-Fingerprint dient anschließend zur Wiedererkennung des Geräts.
+
+Ablauf:
+
+Aktivierungscode
+        ↓
+Hardware-Fingerprint
+        ↓
+Geräteregistrierung oder Wiedererkennung
+        ↓
+Profil- beziehungsweise Workspace-Zuordnung
+        ↓
+Runtime Blueprint

architecture/01-layered-provisioning.md

@@ -0,0 +1,251 @@
+# Tuxflotte – Architekturentscheidung: Layered Provisioning
+
+**Status:** Beschlossen
+**Datum:** 07.07.2026
+
+## Ausgangspunkt
+
+Während der Entwicklung des Tuxflotte-Installers entstand die grundlegende Frage:
+
+> Soll Tuxflotte selbst Betriebssysteme installieren oder die nativen Installer der jeweiligen Distribution orchestrieren?
+
+Nach der Analyse der Projektziele fiel die Entscheidung eindeutig zugunsten der zweiten Variante.
+
+---
+
+# Architekturentscheidung
+
+Tuxflotte ist **kein eigener Linux-Installer**.
+
+Tuxflotte ist eine **distributionsunabhängige Workspace-Provisioning-Plattform**, die den nativen Installer der jeweiligen Distribution steuert und mit den notwendigen Informationen versorgt.
+
+Die eigentliche Installation erfolgt immer mit den offiziellen Installationsmechanismen der Distribution.
+
+Beispiele:
+
+* Fedora → Anaconda / Kickstart
+* Debian → Debian Installer / Preseed
+* Ubuntu → Subiquity / Autoinstall
+* Linux Mint → entsprechendes Installer-Backend
+
+Dadurch bleibt Tuxflotte distributionsneutral und muss keine distributionsspezifischen Installationslogiken nachbilden.
+
+---
+
+# Grundidee
+
+Der Administrator denkt nicht mehr in Distributionen.
+
+Er denkt in Arbeitsplätzen.
+
+Beispiele:
+
+* Office Workspace
+* Developer Workspace
+* Kiosk Workspace
+* Schulungsraum
+* Labor
+* CAD-Arbeitsplatz
+
+Die verwendete Linux-Distribution ist dabei eine Implementierungsentscheidung und kein Bestandteil des eigentlichen Arbeitsplatzes.
+
+---
+
+# Layered Provisioning
+
+Die Architektur besteht aus mehreren Schichten.
+
+```text
+Distribution
+        │
+        ▼
+Backend
+        │
+        ▼
+Organisation
+        │
+        ▼
+Workspace
+        │
+        ▼
+Benutzer (optional)
+        │
+        ▼
+Runtime Blueprint
+        │
+        ▼
+Nativer Installer
+        │
+        ▼
+Provisioning Agent
+```
+
+---
+
+# Verantwortlichkeiten
+
+## Backend
+
+Beschreibt, **wie** eine bestimmte Distribution installiert wird.
+
+Beispiele:
+
+* Fedora
+* Linux Mint
+* Debian
+* Ubuntu
+
+Ein Backend enthält ausschließlich distributionsspezifische Logik.
+
+---
+
+## Organisation
+
+Beschreibt unternehmens- oder organisationsweite Vorgaben.
+
+Beispiele:
+
+* Zertifikate
+* Paketquellen
+* Proxy
+* LDAP
+* Keycloak
+* Branding
+* VPN
+* Monitoring
+* Compliance
+
+Diese Einstellungen gelten unabhängig vom jeweiligen Workspace.
+
+---
+
+## Workspace
+
+Ein Workspace beschreibt den gewünschten Arbeitsplatz.
+
+Beispiele:
+
+* Office Workspace
+* Developer Workspace
+* Secure Workspace
+* Schulungsraum
+* Kiosk
+
+Ein Workspace beschreibt den fachlichen Zielzustand.
+
+Nicht die Distribution.
+
+---
+
+## Benutzer
+
+Optional können benutzerspezifische Einstellungen ergänzt werden.
+
+Beispiele:
+
+* Sprache
+* SSH-Schlüssel
+* persönliche Zertifikate
+* individuelle Software
+* Drucker
+
+---
+
+## Runtime Blueprint
+
+Während der Installation erzeugt Tuxflotte automatisch ein vollständiges Runtime Blueprint.
+
+Dieses entsteht aus:
+
+Backend
+
+*
+
+Organisation
+
+*
+
+Workspace
+
+*
+
+Benutzer
+
+Das Runtime Blueprint beschreibt den vollständigen Zielzustand der Installation.
+
+Dieses Blueprint wird anschließend vom Backend in distributionsspezifische Installationsdaten übersetzt.
+
+---
+
+# Trennung von Fachlichkeit und Technik
+
+Die Architektur trennt bewusst:
+
+**Was soll entstehen?**
+
+↓
+
+Workspace
+
+von
+
+**Wie wird es umgesetzt?**
+
+↓
+
+Backend
+
+Dadurch bleibt der gewünschte Arbeitsplatz unabhängig von der verwendeten Linux-Distribution.
+
+---
+
+# Erweiterbarkeit
+
+Neue Distributionen werden ausschließlich durch neue Backends ergänzt.
+
+Neue Kunden werden ausschließlich durch neue Organisationen ergänzt.
+
+Neue Arbeitsplatztypen werden ausschließlich durch neue Workspaces ergänzt.
+
+Der Kern von Tuxflotte bleibt unverändert.
+
+---
+
+# Langfristige Vision
+
+Ein Administrator arbeitet ausschließlich mit Workspaces.
+
+Beispiel:
+
+Workspace:
+
+Developer Workspace
+
+Backend:
+
+Fedora 42
+
+Organisation:
+
+Muster GmbH
+
+Benutzer:
+
+Max Mustermann
+
+Tuxflotte erzeugt daraus automatisch das Runtime Blueprint und startet anschließend den nativen Installer der ausgewählten Distribution.
+
+---
+
+# Leitprinzip
+
+> Administratoren verwalten Workspaces.
+>
+> Organisationen definieren Standards.
+>
+> Backends implementieren Distributionen.
+>
+> Tuxflotte orchestriert den gesamten Prozess.
+
+Die Linux-Distribution wird dadurch zu einem austauschbaren technischen Detail, während der gewünschte Arbeitsplatz dauerhaft erhalten bleibt.
+

architecture/02-workspace-model.md

@@ -0,0 +1,76 @@
+# Workspace Model
+
+**Status:** Stable  
+**Datum:** 2026-07-07
+
+## Zweck
+
+Ein Workspace beschreibt einen fachlichen Arbeitsplatz-Zustand.
+
+Er beantwortet die Frage:
+
+> Welchen Arbeitsplatz soll der Benutzer erhalten?
+
+Ein Workspace beschreibt nicht, mit welcher Distribution dieser Zustand umgesetzt wird.
+
+## Beispiele
+
+- Office Workspace
+- Developer Workspace
+- Kiosk Workspace
+- Schulungsraum Workspace
+- Secure Workspace
+- Lab Workspace
+
+## Eigenschaften
+
+Ein Workspace kann definieren:
+
+- Name
+- Beschreibung
+- Zielgruppe
+- benötigte Rollen
+- Softwaregruppen
+- optionale Features
+- Konfigurationen
+- Sicherheitsanforderungen
+- empfohlene Hardware
+- Lebenszyklusregeln
+
+## Beispiel
+
+```yaml
+id: developer
+name: Developer Workspace
+description: Standard-Arbeitsplatz für Softwareentwicklung.
+
+features:
+  - git
+  - container-tools
+  - ssh
+  - vpn
+  - ide
+
+recommended_hardware:
+  ram: 16GB
+  cpu_cores: 4
+  disk: 256GB
+Abgrenzung
+Ein Workspace enthält keine distributionsspezifische Installationslogik.
+
+Nicht erlaubt:
+
+Kickstart-Anweisungen
+
+Preseed-Direktiven
+
+Autoinstall-Details
+
+Anaconda-spezifische Optionen
+
+Calamares-Konfiguration
+
+Diese Übersetzung übernimmt das jeweilige Backend.
+
+Leitprinzip
+Ein Workspace beschreibt den gewünschten Arbeitsplatz, nicht die gewünschte Distribution.

architecture/05-runtime-blueprint.md

@@ -0,0 +1,66 @@
+# Runtime Blueprint Model
+
+**Status:** Stable
+
+## Zweck dieses Dokuments
+
+Dieses Dokument beschreibt das Runtime Blueprint als zentralen Integrationspunkt des Provisionierungsprozesses von Tuxflotte.
+
+Es definiert seine Aufgabe innerhalb der Plattform und beschreibt seine Verantwortung sowie seine Abgrenzung zu den übrigen Komponenten der Architektur.
+
+---
+
+## Motivation
+
+Workspace, Organization und Backend beschreiben jeweils einen eigenständigen Aspekt einer Bereitstellung.
+
+Erst durch ihr Zusammenführen entsteht die vollständige Beschreibung einer konkreten Bereitstellung.
+
+Das Runtime Blueprint verbindet diese Informationen und bildet die Grundlage für den weiteren Provisionierungsprozess.
+
+---
+
+## Definition
+
+Das Runtime Blueprint beschreibt den vollständigen Zielzustand einer konkreten Bereitstellung.
+
+Es wird zentral aus den Informationen von Workspace, Organization und Backend erzeugt und bereitgestellt.
+
+Jede Bereitstellung erhält ihr eigenes Runtime Blueprint.
+
+---
+
+## Provisionierungsprozess
+
+Der Provisionierungsprozess beginnt mit der Auswahl eines Workspace und endet nicht mit der Installation des Betriebssystems.
+
+Er beschreibt den Weg von der fachlichen Beschreibung eines Arbeitsplatzes bis zur Umsetzung des gewünschten Zielzustands.
+
+Während dieses Prozesses wird das Runtime Blueprint zentral erzeugt und den ausführenden Komponenten der Plattform bereitgestellt.
+
+Der Installer setzt den beschriebenen Zielzustand während der Erstbereitstellung um.
+
+Nach der Registrierung setzt der Provisioning Agent Änderungen des Zielzustands im weiteren Lebenszyklus um.
+
+---
+
+## Verantwortungsbereich
+
+Das Runtime Blueprint beschreibt insbesondere
+
+den vollständigen Zielzustand einer konkreten Bereitstellung,
+die Zusammenführung der Informationen aus Workspace, Organization und Backend,
+alle für die Umsetzung erforderlichen Informationen sowie
+die Grundlage für die Umsetzung durch Installer und Provisionierungs-Agent.
+
+Das Runtime Blueprint beschreibt den Zielzustand.
+
+Die Umsetzung dieses Zielzustands erfolgt durch die ausführenden Komponenten der Plattform.
+
+---
+
+## Zusammenfassung
+
+Das Runtime Blueprint verbindet die fachlichen Modelle von Tuxflotte mit ihrer konkreten Umsetzung.
+
+Es bildet den zentralen Integrationspunkt des Provisionierungsprozesses und beschreibt den vollständigen Zielzustand eines konkreten Systems.

architecture/06-backend-api.md

@@ -0,0 +1,196 @@
+# Tuxflotte Backend API v1
+
+## Zweck
+
+Die Backend-API definiert die Schnittstelle zwischen dem Tuxflotte-Orchestrator und den distributionsspezifischen Backends.
+
+Der Orchestrator kennt keine distributionsabhängigen Details. Er ruft ausschließlich die in diesem Dokument definierten Funktionen auf.
+
+Jedes Backend muss diese Schnittstelle implementieren.
+
+---
+
+# Backend-Verzeichnis
+
+Beispiel:
+
+```text
+backends/
+├── fedora/
+│   ├── backend.sh
+│   ├── kickstart.tpl
+│   └── README.md
+│
+├── mint/
+│   ├── backend.sh
+│   ├── autoinstall.tpl
+│   └── README.md
+```
+
+---
+
+# Lebenszyklus
+
+Der Orchestrator arbeitet immer in derselben Reihenfolge:
+
+```text
+backend_init()
+
+↓
+
+backend_validate()
+
+↓
+
+backend_generate_config()
+
+↓
+
+backend_launch()
+
+↓
+
+backend_postinstall()
+```
+
+---
+
+# Pflichtfunktionen
+
+## backend_init()
+
+Initialisiert das Backend.
+
+Aufgaben:
+
+* Backend-Version prüfen
+* benötigte Werkzeuge prüfen
+* Templates laden
+* interne Variablen initialisieren
+
+Rückgabe:
+
+* 0 = erfolgreich
+* ungleich 0 = Fehler
+
+---
+
+## backend_validate()
+
+Prüft, ob das Profil mit diesem Backend kompatibel ist.
+
+Beispiele:
+
+* unterstützte Distribution
+* unterstützte Version
+* unterstützte Architektur
+
+Rückgabe:
+
+* 0 = Profil gültig
+* ungleich 0 = Profil ungültig
+
+---
+
+## backend_generate_config()
+
+Erzeugt die installationsspezifischen Konfigurationsdateien.
+
+Beispiele:
+
+Fedora:
+
+* Kickstart-Datei
+
+Ubuntu:
+
+* Autoinstall-Konfiguration
+
+Debian:
+
+* Preseed-Datei
+
+Mint:
+
+* distributionsabhängige Antwortdatei
+
+Ausgabe:
+
+Konfigurationsdateien im Laufzeitverzeichnis.
+
+---
+
+## backend_launch()
+
+Startet den nativen Installer.
+
+Beispiele:
+
+* Anaconda
+* Calamares
+* Debian Installer
+* Subiquity
+
+Ab diesem Zeitpunkt übernimmt der Installer der Distribution die eigentliche Installation.
+
+---
+
+## backend_postinstall()
+
+Vorbereitung für den ersten Start.
+
+Beispiele:
+
+* Provisioning-Agent installieren oder aktivieren
+* Erststart-Konfiguration vorbereiten
+* Registrierung am Provisioning-Server vorbereiten
+
+---
+
+# Optionale Funktionen
+
+Ein Backend kann zusätzliche Funktionen bereitstellen.
+
+Beispiele:
+
+* backend_upgrade()
+* backend_cleanup()
+* backend_debug()
+
+Der Orchestrator verwendet ausschließlich die Pflichtfunktionen.
+
+---
+
+# Laufzeitdaten
+
+Der Orchestrator stellt dem Backend alle benötigten Informationen bereit.
+
+Beispiele:
+
+* ausgewähltes Profil
+* Zielsystem
+* Hardwareinformationen
+* Netzwerk
+* Laufzeitverzeichnis
+
+Backends greifen nicht direkt auf andere Module zu.
+
+---
+
+# Fehlerbehandlung
+
+Jede Backend-Funktion liefert einen Rückgabecode.
+
+Der Orchestrator entscheidet, ob:
+
+* erneut versucht wird,
+* abgebrochen wird,
+* oder der Benutzer eingreifen muss.
+
+---
+
+# Grundsatz
+
+Backends enthalten ausschließlich distributionsspezifische Logik.
+
+Der Tuxflotte-Kern bleibt distributionsneutral.

architecture/07-runtime-layout.md

@@ -0,0 +1,56 @@
+# Runtime Layout
+
+## Laufzeitverzeichnis
+
+Alle Installer-Module kommunizieren ausschließlich über:
+
+/run/tuxflotte/
+
+Jedes Modul besitzt genau ein eigenes Unterverzeichnis.
+
+## Verzeichnisstruktur
+
+/run/tuxflotte/
+├── network/
+├── hardware/
+├── server/
+├── runtime/
+├── backend/
+└── logs/
+
+## Eigentümer der Verzeichnisse
+
+network/
+Besitzer: 05_network.sh
+
+hardware/
+Besitzer: 10_hardware.sh
+
+server/
+Besitzer: 15_server_handshake.sh
+
+runtime/
+Besitzer: Runtime-Builder
+
+backend/
+Besitzer: Backend-Orchestrator
+
+logs/
+Besitzer: zentraler Installer-Orchestrator
+
+## Lese- und Schreibregeln
+
+Ein Modul darf ausschließlich in sein eigenes Verzeichnis schreiben.
+
+Andere Modulverzeichnisse dürfen nur gelesen werden, wenn dies für den definierten Ablauf erforderlich ist.
+
+Beispiele:
+
+- 10_hardware.sh schreibt nur nach /run/tuxflotte/hardware/
+- 15_server_handshake.sh liest aus /run/tuxflotte/network/ und /run/tuxflotte/hardware/
+- Der Runtime-Builder liest aus /run/tuxflotte/server/
+- Der Backend-Orchestrator liest aus /run/tuxflotte/runtime/
+
+Direkte Funktionsaufrufe zwischen Modulen sind nicht vorgesehen.
+
+Die Kommunikation erfolgt ausschließlich über Dateien im Runtime-Verzeichnis.

architecture/08-provisioning-api.md

@@ -0,0 +1,142 @@
+# Provisioning API
+
+## Zweck
+
+Die Provisioning API beschreibt die Kommunikation zwischen dem Tuxflotte-Installer und dem Provisioning-Server.
+
+Sie ist distributionsunabhängig.
+
+Die Backend API (06-backend-api.md) beginnt erst nach der Erstellung des Runtime Blueprints.
+
+## Aktivierung
+
+### Endpoint
+
+POST /api/v1/activate
+
+### Zweck
+
+Der Endpoint autorisiert einen initialen Provisionierungsvorgang und registriert oder erkennt ein Gerät anhand seines Hardware-Fingerprints wieder.
+
+### Request
+
+```json
+{
+  "activation_code": "LAB-2026-START",
+  "device_fingerprint": "<sha256>",
+  "hostname": "enterprise",
+  "machine_id": "<machine-id>",
+  "client_version": "0.1.0",
+  "hardware": {
+    "schema_version": 1,
+    "identity": {
+      "device_fingerprint": "<sha256>",
+      "system_uuid": "<uuid>",
+      "system_serial": null,
+      "board_serial": "<serial>",
+      "machine_id": "<machine-id>"
+    },
+    "system": {
+      "manufacturer": null,
+      "product_name": null,
+      "product_version": null,
+      "architecture": "x86_64",
+      "cpu": {
+        "model": "<cpu-model>",
+        "logical_count": 8
+      },
+      "memory_bytes": 33446432768
+    },
+    "mainboard": {
+      "vendor": "Intel Corporation",
+      "name": "DH87MC"
+    },
+    "firmware": {
+      "bios_vendor": "Intel Corp.",
+      "bios_version": "<bios-version>",
+      "boot_mode": "bios",
+      "secure_boot": "unsupported"
+    },
+    "security": {
+      "tpm_version": "none"
+    },
+    "network_interfaces": [
+      {
+        "name": "eno1",
+        "type": "ethernet",
+        "mac": "<mac-address>"
+      }
+    ],
+    "storage_devices": [
+      {
+        "name": "sda",
+        "model": "<model>",
+        "serial": "<serial>",
+        "size_bytes": 512110190592,
+        "transport": "sata"
+      }
+    ]
+  }
+}
+
+Der `hardware`-Block enthält den während der Provisionierung erfassten Hardwarezustand.
+
+Der Provisioning-Server registriert oder erkennt das Gerät anhand des `device_fingerprint` und speichert den übertragenen Hardwarezustand als zeitbezogenen Hardware-Snapshot.
+
+Bei einer erneuten erfolgreichen Aktivierung desselben Geräts bleibt die interne Geräte-ID erhalten. Für den aktuellen Aktivierungsvorgang wird ein neuer Hardware-Snapshot erzeugt.
+
+### Response
+
+Bei erfolgreicher Aktivierung antwortet der Provisioning-Server mit dem registrierten Gerät, der zugeordneten Organisation und den verfügbaren Provisioning-Profilen.
+
+```json
+{
+  "success": true,
+  "device": {
+    "id": "<device-uuid>",
+    "fingerprint": "<sha256>",
+    "hostname": "enterprise",
+    "created": false,
+    "hardware_snapshot_id": "<hardware-snapshot-uuid>"
+  },
+  "customer": {
+    "id": "default",
+    "organization_id": "<organization-uuid>",
+    "name": "Default Lab"
+  },
+  "profiles": [
+    {
+      "id": "fedora-workstation",
+      "label": "Fedora Workstation",
+      "distribution": "fedora",
+      "version": "40",
+      "description": "Standard-Workstation-Profil für Fedora.",
+      "ansible_repo": "<repository-url>",
+      "installer": {
+        "type": "kickstart",
+        "url": "<kickstart-url>"
+      }
+    }
+  ]
+}
+```
+
+`device.id` ist die interne, von Hardwaremerkmalen unabhängige Geräte-ID.
+
+`device.created` gibt an, ob das Gerät während dieses Aktivierungsvorgangs neu registriert wurde.
+
+`device.hardware_snapshot_id` referenziert den für diesen Aktivierungsvorgang erzeugten Hardware-Snapshot.
+
+Der Aktivierungscode bestimmt die zugeordnete Organisation und die für den Provisionierungsvorgang verfügbaren Profile.
+
+### Fehlerantwort
+
+Ist der Aktivierungscode ungültig, antwortet der Provisioning-Server mit:
+
+```json
+{
+  "success": false,
+  "error": "invalid_activation_code",
+  "message": "Der Aktivierungscode ist ungültig."
+}
+```

architecture/09-data-model-v1.md

@@ -0,0 +1,246 @@
+# Tuxflotte Datenmodell v1
+
+## Zweck
+
+Das Datenmodell beschreibt die persistenten Kernobjekte der Tuxflotte-Plattform und ihre Beziehungen.
+
+Die konkrete SQL-Implementierung und das Migrationssystem werden getrennt von diesem fachlichen Modell behandelt.
+
+## Kernobjekte
+
+- Organization
+- Device
+- Hardware Snapshot
+- Network Interface
+- Storage Device
+- Workspace
+- Backend
+- Assignment
+- Network Profile
+- Secret Reference
+
+## Organization
+
+Eine Organization beschreibt eine organisatorische Einheit innerhalb der Tuxflotte-Plattform.
+
+Eine Organization besitzt eigene Geräte, Workspaces, Netzwerkprofile und Richtlinien.
+
+Attribute:
+
+- id
+- name
+- created_at
+- updated_at
+
+Beziehungen:
+
+- besitzt mehrere Devices
+- besitzt mehrere Workspaces
+- besitzt mehrere Network Profiles
+- referenziert Secrets
+
+## Device
+
+Ein Device repräsentiert ein dauerhaft bekanntes physisches oder virtuelles Gerät.
+
+Die interne Geräte-ID ist unabhängig von Hardwaremerkmalen.
+
+Der Hardware-Fingerprint dient der Wiedererkennung während des Provisioning-Handshakes.
+
+Attribute:
+
+- id
+- organization_id
+- device_fingerprint
+- hostname
+- created_at
+- last_seen
+
+Beziehungen:
+
+- gehört zu genau einer Organization
+- besitzt mehrere Hardware Snapshots
+- besitzt optional ein Assignment
+
+## Hardware Snapshot
+
+Ein Hardware Snapshot beschreibt den zu einem bestimmten Zeitpunkt erfassten Hardwarezustand eines Devices.
+
+Hardware Snapshots sind zeitbezogene Inventardaten und nicht Bestandteil der stabilen Geräteidentität.
+
+Attribute:
+
+- id
+- device_id
+- collected_at
+- architecture
+- manufacturer
+- product_name
+- product_version
+- system_uuid
+- system_serial
+- board_vendor
+- board_name
+- board_serial
+- bios_vendor
+- bios_version
+- boot_mode
+- secure_boot
+- tpm_version
+- cpu_model
+- cpu_logical_count
+- memory_bytes
+
+Beziehungen:
+
+- gehört zu genau einem Device
+- besitzt mehrere Network Interfaces
+- besitzt mehrere Storage Devices
+
+## Network Interface
+
+Ein Network Interface beschreibt eine zum Zeitpunkt des Hardware Snapshots vorhandene Netzwerkschnittstelle.
+
+Attribute:
+
+- id
+- hardware_snapshot_id
+- name
+- type
+- mac_address
+
+Beziehungen:
+
+- gehört zu genau einem Hardware Snapshot
+
+## Storage Device
+
+Ein Storage Device beschreibt einen zum Zeitpunkt des Hardware Snapshots vorhandenen Massenspeicher.
+
+Attribute:
+
+- id
+- hardware_snapshot_id
+- model
+- serial
+- size_bytes
+- transport
+- name
+
+Beziehungen:
+
+- gehört zu genau einem Hardware Snapshot
+
+## Relationales Schema v1
+
+### organizations
+
+Spalten:
+
+- id
+- name
+- created_at
+- updated_at
+
+### devices
+
+Spalten:
+
+- id
+- organization_id
+- device_fingerprint
+- hostname
+- created_at
+- last_seen
+
+Beziehungen:
+
+- organization_id referenziert organizations.id
+
+Constraints:
+
+- device_fingerprint ist eindeutig
+
+### hardware_snapshots
+
+Spalten:
+
+- id
+- device_id
+- collected_at
+- architecture
+- manufacturer
+- product_name
+- product_version
+- system_uuid
+- system_serial
+- board_vendor
+- board_name
+- board_serial
+- bios_vendor
+- bios_version
+- boot_mode
+- secure_boot
+- tpm_version
+- cpu_model
+- cpu_logical_count
+- memory_bytes
+
+Beziehungen:
+
+- device_id referenziert devices.id
+
+### network_interfaces
+
+Spalten:
+
+- id
+- hardware_snapshot_id
+- name
+- type
+- mac_address
+
+Beziehungen:
+
+- hardware_snapshot_id referenziert hardware_snapshots.id
+
+### storage_devices
+
+Spalten:
+
+- id
+- hardware_snapshot_id
+- name
+- model
+- serial
+- size_bytes
+- transport
+
+Beziehungen:
+
+- hardware_snapshot_id referenziert hardware_snapshots.id
+
+## Beziehungskonsequenzen
+
+Wird eine Organization gelöscht, dürfen zugehörige Devices nicht implizit mitgelöscht werden.
+
+Wird ein Device gelöscht, werden zugehörige Hardware Snapshots mitgelöscht.
+
+Wird ein Hardware Snapshot gelöscht, werden zugehörige Network Interfaces und Storage Devices automatisch mitgelöscht.
+
+Für die relationale Umsetzung gilt daher:
+
+- devices.organization_id → ON DELETE RESTRICT
+- hardware_snapshots.device_id → ON DELETE CASCADE
+- network_interfaces.hardware_snapshot_id → ON DELETE CASCADE
+- storage_devices.hardware_snapshot_id → ON DELETE CASCADE
+
+## ID-Erzeugung
+
+Persistente Plattformobjekte verwenden UUIDs als interne IDs.
+
+UUIDs werden durch die Anwendung erzeugt.
+
+Die Datenbank validiert und speichert die IDs, erzeugt sie jedoch nicht selbst.
+
+Dadurch stehen Objekt-IDs bereits vor dem Datenbank-INSERT zur Verfügung und können innerhalb einer Transaktion für abhängige Datensätze verwendet werden.

archive/architecture-v2.md

@@ -0,0 +1,263 @@
+# Tuxflotte – Architektur v2
+
+## Vision
+
+Tuxflotte ist eine distributionsunabhängige Provisionierungsplattform für Linux-Systeme.
+
+Tuxflotte installiert **keine Betriebssysteme selbst**, sondern orchestriert den Installationsprozess, indem die nativen Installer der jeweiligen Distribution genutzt werden.
+
+Dadurch bleibt Tuxflotte unabhängig von distributionsspezifischen Installationsdetails und profitiert von den offiziellen Installationsmechanismen.
+
+---
+
+# Architekturprinzipien
+
+## 1. Klare Verantwortlichkeiten
+
+### Provisioning-ISO
+
+Verantwortlich für:
+
+* Hardware erkennen
+* Netzwerk initialisieren
+* Provisioning-Server kontaktieren
+* Profile laden
+* Zielsystem auswählen
+* Installationsparameter erzeugen
+* nativen Installer starten
+
+Nicht verantwortlich für:
+
+* Partitionierung
+* Dateisysteme
+* Paketinstallation
+* Bootloader-Konfiguration
+
+Diese Aufgaben übernimmt der Installer der jeweiligen Distribution.
+
+---
+
+### Distribution-Installer
+
+Beispiele:
+
+* Fedora → Anaconda (Kickstart)
+* Linux Mint → abhängig von der verwendeten Installer-Technologie
+* Debian → Debian Installer (Preseed)
+* Ubuntu → Subiquity (Autoinstall)
+
+Verantwortlich für:
+
+* Partitionierung
+* Dateisysteme
+* Betriebssysteminstallation
+* Bootloader
+* Benutzeranlage
+* Erstkonfiguration des Systems
+
+---
+
+### Provisioning-Agent
+
+Nach dem ersten Systemstart übernimmt der Agent:
+
+* Registrierung am Provisioning-Server
+* Inventarisierung
+* Nachinstallation
+* Konfigurationsmanagement
+* Softwareverteilung
+* Statusmeldungen
+
+---
+
+### Provisioning-Server
+
+Der Server verwaltet:
+
+* Profile
+* Geräte
+* Installationsvorlagen
+* Richtlinien
+* Inventar
+* Provisioning-Aufträge
+
+---
+
+# Komponenten
+
+```text
+                Provisioning Server
+                        │
+                        ▼
+              Provisioning-Profile
+                        │
+                        ▼
+                Provisioning-ISO
+                        │
+                        ▼
+             Distribution-Installer
+                        │
+                        ▼
+              Installiertes System
+                        │
+                        ▼
+               Provisioning-Agent
+                        │
+                        ▼
+                Provisioning-Server
+```
+
+---
+
+# Installer-Workflow
+
+## Phase 1
+
+Preflight
+
+* Hardware prüfen
+* RAM
+* CPU
+* Firmware
+* Netzwerk
+
+---
+
+## Phase 2
+
+Inventarisierung
+
+* Datenträger erkennen
+* Netzwerkkarten
+* Firmware
+* Seriennummern
+* Systeminformationen
+
+---
+
+## Phase 3
+
+Profil
+
+* Benutzer wählt Profil
+
+oder
+
+* Profil wird automatisch vom Server geliefert
+
+---
+
+## Phase 4
+
+Backend
+
+Passendes Backend wird geladen.
+
+Beispiele:
+
+* Fedora
+* Mint
+* Debian
+* Ubuntu
+
+---
+
+## Phase 5
+
+Installationsparameter erzeugen
+
+Beispiele:
+
+* Kickstart
+* Autoinstall
+* Preseed
+
+---
+
+## Phase 6
+
+Nativen Installer starten
+
+Ab diesem Zeitpunkt übernimmt die Distribution die eigentliche Installation.
+
+---
+
+## Phase 7
+
+Erster Start
+
+Provisioning-Agent startet automatisch.
+
+---
+
+# Profile
+
+Jedes Profil beschreibt:
+
+* Distribution
+* Version
+* Desktop
+* Softwarepakete
+* Benutzer
+* Netzwerkeinstellungen
+* Provisioning-Richtlinien
+
+Beispiel:
+
+```text
+profiles/
+    fedora-workstation/
+        profile.json
+
+    mint-desktop/
+        profile.json
+```
+
+---
+
+# Backend-Konzept
+
+Jede Distribution besitzt ein eigenes Backend.
+
+Beispiel:
+
+```text
+profiles/
+
+    fedora-workstation/
+        profile.json
+        installer.sh
+        kickstart.tpl
+
+    mint-desktop/
+        profile.json
+        installer.sh
+        autoinstall.tpl
+```
+
+Der Kern von Tuxflotte kennt keine distributionsspezifischen Details.
+
+Er lädt ausschließlich das gewählte Profil und übergibt die Kontrolle an das passende Backend.
+
+Dadurch kann Tuxflotte jederzeit um weitere Distributionen erweitert werden, ohne den Kern ändern zu müssen.
+
+---
+
+# Ziele
+
+* distributionsunabhängig
+* modular
+* erweiterbar
+* reproduzierbar
+* automatisierbar
+* servergesteuert
+* Zero-Touch-fähig
+* sowohl interaktiv als auch unbeaufsichtigt nutzbar
+
+---
+
+# Grundsatz
+
+**Tuxflotte ist eine Provisionierungsplattform und kein eigener Linux-Installer.**
+
+Die Installation erfolgt grundsätzlich mit den offiziellen Installationsmechanismen der jeweiligen Linux-Distribution.

archive/vision-and-architecture.md

@@ -1,8 +1,8 @@
-# Stallinux Provisioning Platform
+# Tuxflotte Provisioning
 
 ## Vision
 
-Die Stallinux Provisioning Platform soll die automatisierte Bereitstellung und Konfiguration von Linux-Systemen vereinfachen.
+Die Tuxflotte Provisioning soll die automatisierte Bereitstellung und Konfiguration von Linux-Systemen vereinfachen.
 
 Das Ziel ist eine distributionsübergreifende Plattform, die Linux Mint, Fedora und zukünftig weitere Distributionen über denselben Provisionierungsprozess installieren und konfigurieren kann.
 

roadmap/installer-roadmap.md

@@ -39,7 +39,7 @@ Ziel: Netzwerkgestützter Installer.
 
 ### Registrierung
 
-* [ ] Geräteaktivierung
+* [x] Geräteaktivierung
 * [ ] Benutzeranmeldung
 * [ ] Auswahl von OS- und Konfigurationsprofilen