Compare commits
No commits in common. "40d9bc77a6c47f4868a3d484428994e63ec1571a" and "5b4fb3cf6ada0dd6a788a4c4241827a17c222789" have entirely different histories.
40d9bc77a6
...
5b4fb3cf6a
@ -1,81 +0,0 @@
|
|||||||
# 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
|
|
||||||
@ -1,57 +0,0 @@
|
|||||||
# 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.
|
|
||||||
@ -1,117 +0,0 @@
|
|||||||
# 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.
|
|
||||||
@ -1,57 +0,0 @@
|
|||||||
# 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.
|
|
||||||
@ -1,59 +0,0 @@
|
|||||||
# 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.
|
|
||||||
@ -1,55 +0,0 @@
|
|||||||
# 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.
|
|
||||||
32
README.md
32
README.md
@ -1,27 +1,13 @@
|
|||||||
# Tuxflotte Platform Docs
|
# Stallinux Provisioning Platform
|
||||||
|
|
||||||
Dieses Repository beschreibt die Architektur, Begriffe und Leitentscheidungen von Tuxflotte.
|
Repositories:
|
||||||
|
|
||||||
Tuxflotte ist eine distributionsunabhängige Workspace-Provisioning-Plattform für Linux-Arbeitsplätze.
|
- provisioning-server
|
||||||
|
- provisioning-client
|
||||||
|
- platform-docs
|
||||||
|
|
||||||
## Einstieg
|
Planned:
|
||||||
|
|
||||||
1. `00-philosophy.md`
|
- profiles
|
||||||
2. `00-glossary.md`
|
- installer definitions
|
||||||
3. `architecture/01-layered-provisioning.md`
|
- ansible roles
|
||||||
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.
|
|
||||||
|
|||||||
@ -1,61 +0,0 @@
|
|||||||
# 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.
|
|
||||||
|
|
||||||
@ -1,51 +0,0 @@
|
|||||||
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
|
|
||||||
@ -1,251 +0,0 @@
|
|||||||
# 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.
|
|
||||||
|
|
||||||
@ -1,76 +0,0 @@
|
|||||||
# 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.
|
|
||||||
@ -1,66 +0,0 @@
|
|||||||
# 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.
|
|
||||||
@ -1,196 +0,0 @@
|
|||||||
# 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.
|
|
||||||
@ -1,56 +0,0 @@
|
|||||||
# 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.
|
|
||||||
@ -1,142 +0,0 @@
|
|||||||
# 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."
|
|
||||||
}
|
|
||||||
```
|
|
||||||
@ -1,246 +0,0 @@
|
|||||||
# 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.
|
|
||||||
@ -1,263 +0,0 @@
|
|||||||
# 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.
|
|
||||||
@ -39,7 +39,7 @@ Ziel: Netzwerkgestützter Installer.
|
|||||||
|
|
||||||
### Registrierung
|
### Registrierung
|
||||||
|
|
||||||
* [x] Geräteaktivierung
|
* [ ] Geräteaktivierung
|
||||||
* [ ] Benutzeranmeldung
|
* [ ] Benutzeranmeldung
|
||||||
* [ ] Auswahl von OS- und Konfigurationsprofilen
|
* [ ] Auswahl von OS- und Konfigurationsprofilen
|
||||||
|
|
||||||
@ -1,8 +1,8 @@
|
|||||||
# Tuxflotte Provisioning
|
# Stallinux Provisioning Platform
|
||||||
|
|
||||||
## Vision
|
## Vision
|
||||||
|
|
||||||
Die Tuxflotte Provisioning soll die automatisierte Bereitstellung und Konfiguration von Linux-Systemen vereinfachen.
|
Die Stallinux Provisioning Platform 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.
|
Das Ziel ist eine distributionsübergreifende Plattform, die Linux Mint, Fedora und zukünftig weitere Distributionen über denselben Provisionierungsprozess installieren und konfigurieren kann.
|
||||||
|
|
||||||
Loading…
x
Reference in New Issue
Block a user