# 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.