# Tuxflotte Installer Roadmap

Der Tuxflotte Installer ist der Einstiegspunkt in die Tuxflotte-Provisioning-Plattform.

Seine Aufgabe ist es, Geräte möglichst einfach, reproduzierbar und distributionsunabhängig für die weitere Verwaltung vorzubereiten.

## Version 0.2

Ziel: Erste komfortable Installer-Version.

### Build

* [x] ISO-Erzeugung vollständig in `build.sh` integrieren (kein manueller Zwischenschritt mehr nötig, bestätigt durch den erfolgreichen End-to-End-Boot am 20.07.2026, siehe `roadmap/milestones.md`)
* [ ] reproduzierbarer Build (gleicher Source-ISO-Hash + gleicher Repo-Stand → gleiches, funktional identisches Ergebnis; kein bit-identisches Ausgabe-ISO als Ziel, da Aufwand/Nutzen dafür nicht lohnt)
* [ ] automatische Verifikation (statische/syntaktische Prüfungen vor dem ISO-Bau: Source-ISO-Hash, GRUB-Configs enthalten Branding, Payload-Struktur vollständig, Execute-Bits auf allen Skripten gesetzt, Bash-Syntax valide. Explizit keine automatisierte Boot-/Laufzeitprüfung — die funktionale Prüfung bleibt bewusst manuell in Proxmox: KI prüft syntaktisch, Mensch prüft Durchführung, siehe `roadmap/milestones.md` 2026-07-20)

### Bootmenü

* [x] Boot from local disk (siehe `architecture/01-layered-provisioning.md`)
* [x] Tuxflotte-Branding (Text/Farbschema im GRUB-Menü; Logo folgt am Plymouth-Bootsplash, siehe `architecture/13-live-provisioning-boot.md`)
* [x] eigenes ISO-Label (`TUXFLOTTE`, siehe `architecture/13-live-provisioning-boot.md`)

### Oberfläche

* [ ] Kiosk-UI (Epiphany statt Terminal, siehe ADR-0004/ADR-0006 — Chromium-Zwischenspiel in ADR-0005 verworfen) — Epiphany startet seit 22.07.2026 zuverlässig; Nachbesserungen (Standardbrowser-Abfrage, deutsche Tastatur, SELinux-Benachrichtigungen) umgesetzt, Boot-Verifikation dieser drei noch ausstehend

---

## Version 0.3

Ziel: Netzwerkgestützter Installer.

### Netzwerk

* [ ] WLAN-Unterstützung
* [ ] Netzwerkdiagnose
* [ ] Personalisierte ISO-Generierung mit eingebetteten WLAN-Zugangsdaten und individualisiertem ISO-Label (aus Org-Kennung abgeleitet), ausgelöst über Kundenprofil-Flag „Autoprovisionierung" (siehe `architecture/13-live-provisioning-boot.md`, Abschnitt „WLAN-Zugangsdaten")

### Bootstrap

* [ ] Installationsmedium möglichst früh entfernbar
* [ ] Installationsdaten über den Provisioning Server beziehen
* [ ] Vorbereitung für PXE

### Registrierung

* [x] Geräteaktivierung (siehe `architecture/11-device-enrollment.md`)
* [ ] Benutzeranmeldung
* [ ] Auswahl von OS- und Konfigurationsprofilen

---

## Version 1.0

Ziel: Vollständiger Einstieg in die Provisioning-Plattform.

### Lifecycle

* [ ] Reprovisionierung ohne Installationsmedium
* [ ] PXE-Unterstützung
* [ ] automatische Geräteerkennung

### Benutzererlebnis

* [ ] modernes Bootmenü
* [ ] Tuxflotte-Design
* [ ] einfache Bedienung

---

## Langfristige Vision

**Hinweis:** Der Kerngedanke dieser Vision – Distributionspakete werden nicht auf dem Medium mitgeführt, sondern je Installation aus dem Netz gezogen – bleibt mit `ADR-0003` unverändert bestehen. Für den interaktiven, gebrandeten Ablauf wurde dort jedoch bewusst ein volles Live-Medium statt eines minimalen Boot-Mediums gewählt (siehe `architecture/13-live-provisioning-boot.md`); das Medium selbst wird dadurch größer, nicht die mitgeführten Installationsdaten der Distribution. Dieser größere Fußabdruck wird für die damit gewonnenen UX-Möglichkeiten bewusst in Kauf genommen.

Der Installer soll kein klassisches Installationsmedium sein.

Langfristig enthält er nur noch die Komponenten, die zum Starten eines Geräts erforderlich sind (Bootloader, Kernel, initrd). Alle weiteren Daten werden über den Provisioning Server bereitgestellt.

Dadurch wird:

* das Installationsmedium klein und leicht aktuell zu halten,
* ein einzelner USB-Stick für viele Geräte nutzbar,
* die Grundlage für PXE-Installationen geschaffen,
* und eine spätere Reprovisionierung ohne physisches Medium ermöglicht.

**Geprüft, für eine spätere ISO-Überarbeitung vorgemerkt (21.07.2026):** Ubuntu-basiertes Live-Medium statt Fedora, um den EROFS-Bug (siehe `architecture/13-live-provisioning-boot.md`) von vornherein zu vermeiden — Ubuntus `casper`/`live-build` nutzt weiterhin klassisches SquashFS. Kein Beschluss, nur ein Prüfpunkt für den Fall, dass die ISO ohnehin grundlegend überarbeitet wird.