# 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

## Merkmal

Eine einzelne fachliche Eigenschaft eines Workspace, distributionsunabhängig benannt.

Beispiele:

- browser-brave
- office-onlyoffice
- guest-session-ephemeral

Ein Workspace besteht aus einer Menge von Merkmalen.

## Blueprint

Die technische Umsetzung genau eines Merkmals für genau ein Backend.

Ein Blueprint ist im Regelfall eine Ansible-Rolle beziehungsweise -Aufgabe, die nach dem ersten Start über den bestehenden Ansible-Pull-Mechanismus angewendet wird.

Details: `architecture/12-feature-blueprint-model.md`.

## Auftragskatalog

Die Menge der Merkmale, die zusätzlich zur Workspace-Zugehörigkeit direkt einem einzelnen, bereits provisionierten Device zugewiesen und wieder entzogen werden können.

Ein Auftrag ist fachlich und technisch ein Merkmal (`im_auftragskatalog = true`) — kein eigenständiges Modell. Der Unterschied zur gewöhnlichen Workspace-Zuweisung ist ausschließlich der Zuweisungsweg: geräteweise und jederzeit veränderbar, statt fix über die Bereitstellungsvorlage zum Installationszeitpunkt.

Aufträge werden zur besseren Übersicht optional einer Kategorie zugeordnet.

Details: `architecture/09-data-model-v1.md`, ADR-0010.

## Kategorie

Eine Gruppierung von Merkmalen im Auftragskatalog, ausschließlich zur Darstellung — ohne fachliche Wirkung auf die Anwendung eines Merkmals.

## Runtime Blueprint

Die zur Installationszeit erzeugte vollständige Zielbeschreibung.

Sie entsteht aus:

- den aufgelösten Blueprints der Merkmale des Workspace für das gewählte Backend
- direkten Organization- und Backend-Vorgaben (zum Beispiel Partitionierung, Verschlüsselung)
- 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

## Auto-Modus

Ein Bootmodus der Provisionierungs-ISO, in dem Bereitstellungsvorlage-Auswahl und Commit-Point-Bestätigung ohne Benutzereingabe erfolgen.

Nur für bereits registrierte Geräte zulässig (`device.registration_status == "existing"`).

Details: `architecture/13-live-provisioning-boot.md`.

## Interaktiv-Modus

Der in F-005 (`architecture/10-interactive-provisioning-flow.md`) beschriebene Ablauf mit expliziter Benutzerinteraktion bei Bereitstellungsvorlage-Auswahl und Installationsbestätigung.