From 8590f9a8a8fd716e847c40fa82bbca48d7096abe Mon Sep 17 00:00:00 2001 From: Thomas Stallinger Date: Tue, 7 Jul 2026 10:27:57 +0200 Subject: [PATCH] Define layered provisioning architecture and backend API --- 01-layered-provisioning.md | 251 ++++++++++++++++++++++++++++++++++ README.md | 2 +- architecture-v2.md | 263 ++++++++++++++++++++++++++++++++++++ tuxflotte-backend-api-v1.md | 196 +++++++++++++++++++++++++++ vision-and-architecture.md | 4 +- 5 files changed, 713 insertions(+), 3 deletions(-) create mode 100644 01-layered-provisioning.md create mode 100644 architecture-v2.md create mode 100644 tuxflotte-backend-api-v1.md diff --git a/01-layered-provisioning.md b/01-layered-provisioning.md new file mode 100644 index 0000000..f50d8d5 --- /dev/null +++ b/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. + diff --git a/README.md b/README.md index 04d236f..964af5d 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -# Stallinux Provisioning Platform +# Tuxflotte Provisioning Repositories: diff --git a/architecture-v2.md b/architecture-v2.md new file mode 100644 index 0000000..9a98b9f --- /dev/null +++ b/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. diff --git a/tuxflotte-backend-api-v1.md b/tuxflotte-backend-api-v1.md new file mode 100644 index 0000000..93e14d6 --- /dev/null +++ b/tuxflotte-backend-api-v1.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. diff --git a/vision-and-architecture.md b/vision-and-architecture.md index c943c24..a308611 100644 --- a/vision-and-architecture.md +++ b/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.