admin/platform-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

ADR-0014 Nachtrag: zeitbasierter ISO-Ablauf nach 7 Tagen

Browse Source 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Thomas Stallinger 2026-08-26 09:55:10 +02:00
parent 5eabdbd180
commit eb828fcd06
1 changed files with 32 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
adr/0014-self-service-iso-bau-orchestrierung.md
View File

@ -30,3 +30,35 @@ Der **Download läuft durch Kundenplattform hindurch gestreamt** (`GET /installa
Ein ISO-Bau blockiert den anfragenden Request nicht, aber es gibt aktuell keine Begrenzung gleichzeitig laufender Bau-Threads — bei der aktuellen Kundenzahl kein praktisches Problem, bei deutlich mehr gleichzeitigen Bauten (mehrere Organisationen zur gleichen Zeit) müsste das nachgerüstet werden (Warteschlange oder Parallelitätslimit). Ein ISO-Bau blockiert den anfragenden Request nicht, aber es gibt aktuell keine Begrenzung gleichzeitig laufender Bau-Threads — bei der aktuellen Kundenzahl kein praktisches Problem, bei deutlich mehr gleichzeitigen Bauten (mehrere Organisationen zur gleichen Zeit) müsste das nachgerüstet werden (Warteschlange oder Parallelitätslimit).
Details zum technischen Payload-Mechanismus für das Mint/Casper-Backend (inklusive eines dabei gefundenen Casper-Bugs): `13-live-provisioning-boot.md`. Details zum Datenmodell (`iso_builds`): `09-data-model-v1.md`. `installationsmedium_konfiguration` (Kundenplattform-eigene Datenbank, WLAN-Zugangsdaten, gewählte Bereitstellungsvorlage) ist nicht Teil dieses provisioning-server-Datenmodells, siehe ADR-0011 zur Datenbanktrennung. Details zum technischen Payload-Mechanismus für das Mint/Casper-Backend (inklusive eines dabei gefundenen Casper-Bugs): `13-live-provisioning-boot.md`. Details zum Datenmodell (`iso_builds`): `09-data-model-v1.md`. `installationsmedium_konfiguration` (Kundenplattform-eigene Datenbank, WLAN-Zugangsdaten, gewählte Bereitstellungsvorlage) ist nicht Teil dieses provisioning-server-Datenmodells, siehe ADR-0011 zur Datenbanktrennung.
## Nachtrag 26.08.2026: Zeitbasierter ISO-Ablauf nach 7 Tagen
`cleanup_old_iso_builds()` (siehe oben) hat bewusst keine Zeitdimension —
sie greift ausschließlich, wenn dieselbe Organisation erneut baut. Eine
Organisation, die nur einmal baut und ihr Medium nie erneuert, behielt den
Download dadurch faktisch für immer. Ergänzt (nicht ersetzt) um eine feste
Ablauffrist: `iso_builds` bekommt eine neue Spalte `expires_at` (Migration
`0021_iso_build_expiry.sql`), die `update_iso_build()` bei erfolgreichem
Abschluss auf `finished_at + 7 Tage` setzt (fest ab Fertigstellung, nicht
verlängerbar durch erneuten Download — bewusst einfach gehalten). Ein
periodischer Sweep (`run_iso_build_expiry_sweep()`, Daemon-Thread,
stündlich, gestartet über `@app.on_event("startup")`) löscht Datei + Zeile
jedes `completed`-Builds mit abgelaufenem `expires_at`, unabhängig davon,
ob die Organisation je erneut baut.
Bewusst getrennt von der Enrollment-Session-Gültigkeit
(`enrollment_sessions.expires_at`/`max_devices`, „Aufladen"-Flow oben): der
ISO-Ablauf betrifft nur die **Downloadbarkeit der Datei**, nicht die
Berechtigung, sich mit einer bereits verteilten ISO zu registrieren — ein
abgelaufener Download-Link zwingt nicht zu einer neuen Registrierungsrunde
für Geräte, die die ISO schon vor dem Ablauf heruntergeladen haben.
`iso_build_row_to_dict()` und damit alle iso-builds-Endpunkte geben
`expires_at` jetzt mit aus; Kundenplattform zeigt es auf
`/installationsmedium` als Hinweistext beim Download-Button an.
Live auf anode verifiziert: Migration eingespielt, ein Testbuild mit
künstlich zurückdatiertem `expires_at` per SQL angelegt, Sweep-Funktion
manuell aufgerufen (nicht die volle Stunde abgewartet) — Datei und
Datenbankzeile wurden korrekt entfernt, ein nicht abgelaufener Build blieb
unangetastet.