adminandClaude Sonnet 5
a6fecdd818
Live gefunden beim Icon-Backfill (Phase 6): learningequality.org liefert sein Favicon mit Content-Type "image/svg+xml", tatsächlich sind die Bytes ein PNG-in-ICO-Container - wäre im Browser als kaputtes Bild gelandet (SVG-Parser auf Binärdaten). _erkanntes_bildformat() sniffed jetzt die echten Magic Bytes (PNG/JPEG/GIF/ICO/WEBP/SVG-Erkennung), der HTTP-Header dient nur noch als Fallback. Zentral in _fetch_url_bytes() gefixt, damit sowohl Webapp- als auch Merkmal-Icons profitieren (gleicher Fetch-Pfad). 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.