adminandClaude Sonnet 5
4706870774
Webapps bekommen zwei neue, optionale Eigenschaften (Migration 0043): kategorie_id (FK auf kategorien, nullable) und kiosk_modus (Boolean). Kein eigener "Webapps"-Menüpunkt (per Nutzer-Feedback in der Plan-Runde verworfen) - stattdessen ordnet sich eine Webapp optional einer der bestehenden App-Kategorien zu, KATEGORIE_ZU_XDG_CATEGORIES übersetzt das in eine echte Freedesktop-Categories=-Zeile fürs .desktop-Menü (Default unverändert Network;WebBrowser; ohne gewählte Kategorie). Kiosk-Modus: bei aktiviertem kiosk_modus löst der Server (nicht das Gerät) anhand der Workspace-Merkmal-Zuordnung auf, welcher Browser das Kiosk-Fenster öffnet (Chrome bevorzugt, Chromium Fallback, sonst normaler Tab) - _resolve_kiosk_browser() in fetch_workspace_webapps(). Migration 0044: Chromium + Microsoft Edge als neue Browser-Merkmale (Google Chrome existiert bereits aus Migration 0031). Chromium bewusst NUR für debian-image/mint-image blueprint-verknüpft, nicht ubuntu-image - recherchiert: Ubuntus "chromium"-Paket ist seit 19.10 nur ein transitionelles Paket, das im Hintergrund Snap nachzieht (passt nicht zu unserem Modell), während Debian und Mint ein echtes .deb bauen. Microsoft Edge über das offizielle, distributionsunabhängige Microsoft-Repo auf allen drei Backends. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VLk93dhDMrkPXefVdknMV9
provisioning-server
Maschinen-zu-Maschine-API für Geräteaktivierung, Agent-Check-in/Report und
den Self-Service-ISO-Bau (anode) — von kundenplattform bewusst getrennter
Dienst, siehe ADR-0011.
Architektur
- FastAPI, reine Maschinen-Endpoints (kein Frontend) - Aktivierung, Agent-Bootstrap/Checkin/Report, Auftragskatalog, Self-Service-ISO-Bau.
- Eigene Postgres-Datenbank (
tuxflotte), getrennt von kundenplattforms Datenbank - Migrationen untermigrations/. - Läuft unter einem eigenen, unprivilegierten System-User
provisioning-server(nicht root - sieheprovisioning-server.serviceund ADR-0027). Der Self-Service-ISO-Bau (run_iso_build()inapp.py) braucht fürunsquashfs/mksquashfsweiterhin echtes root (Datei-Eigentümer-Erhalt im Squashfs) - dafür eskaliert genau dieser eine Aufruf per eng gefasster sudo-Regel, sieheprovisioning-server-iso-build.sudoers.
Setup (lokal)
python3 -m venv .venv
.venv/bin/pip install -r requirements.txt
TUXFLOTTE_DATABASE_URL=postgresql://... .venv/bin/psql ... -f migrations/0001_*.sql # + alle weiteren migrations/ der Reihe nach
Wichtige Env-Variablen (/etc/tuxflotte/provisioning-server.env im Betrieb):
TUXFLOTTE_DATABASE_URLTUXFLOTTE_ADMIN_TOKENTUXFLOTTE_KUNDENPLATTFORM_TOKEN- muss mit dem gleichnamigen Wert in kundenplattforms Env übereinstimmenTUXFLOTTE_ANSIBLE_CONTENT_REPO- URL desansible-content-ReposTUXFLOTTE_INSTALLER_DIR(Default/root/tuxflotte-installer- im produktiven De-Root-Setup stattdessen explizit auf einen für denprovisioning-server-User lesbaren Pfad setzen, z.B./opt/tuxflotte-installer)TUXFLOTTE_MINT_ISO_PATH,TUXFLOTTE_ISO_BUILD_OUTPUT_DIR- relativ zum Arbeitsverzeichnis des Dienstes (data/upstream/...,data/iso-builds)
Start: .venv/bin/uvicorn app:app --port 8080
Deploy (anode)
git pull --ff-only
systemctl restart provisioning-server
Port 8080 (kundenplattform belegt 8081). Bei einer Neuinstallation
zusätzlich zum Code-Deploy nötig (einmalig, nicht Teil von git pull):
- System-User
provisioning-serveranlegen,/opt/provisioning-serverdiesem User gehörend. provisioning-server.servicenach/etc/systemd/system/kopieren,systemctl daemon-reload && systemctl enable --now provisioning-server.provisioning-server-iso-build.sudoersnach/etc/sudoers.d/provisioning-server-iso-buildkopieren (Eigentümer root:root, Modus 440), mitvisudo -cfprüfen.tuxflotte-installer-Repo an den Pfad ausTUXFLOTTE_INSTALLER_DIRklonen (für den diese Sudo-Regel gilt - bei einem anderen Pfad die Regel entsprechend anpassen).
Öffentliche Erreichbarkeit über Pangolin ist nicht Teil dieses Repos — das ist ein separater Ops/DNS/Reverse-Proxy-Schritt.