adminandClaude Sonnet 5
676e324381
CreateBereitstellungsvorlageRequest bekommt scheme + extra_partitions (Mountpoint/Prozent/Dateisystem je Zusatzpartition), mit serverseitiger Validierung (Prozentsumme < 100, keine doppelten Mountpoints, nur ext4/btrfs). Bisher war "custom" laut Code-Kommentar nur per direkter DB-Pflege erreichbar - jetzt vollstaendig ueber das bestehende Admin- Formular (Organisationen -> Bereitstellungsvorlagen). fetch_templates() liefert partitioning jetzt mit aus, damit die Admin- Tabelle das gewaehlte Schema anzeigen kann. Migration 0046 dokumentiert die neue JSONB-Form im Spalten-Default und zieht bestehende Zeilen nach (Muster wie Migration 0026). Teil der E2E-Testrunde, siehe platform-docs/roadmap/ e2e-testrunde-lokale-adressierung.md Phase 3. Gegenstueck im Install- Backend (image_deploy_partition_custom() etc.) ist in tuxflotte-installer bereits umgesetzt. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DWKevK2QUK5tsGmqfSD6Yy
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.