4.3 KiB
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.
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.