2.8 KiB
Kompatibilität und Abnahme
Es gibt zum Auslieferungszeitpunkt keinen auf Hardware oder in einer VM
freigegebenen Proxmox-ISO-Build. Die Registrierung test_status=passed ist eine
vom Administrator dokumentierte Freigabe; sie ersetzt keinen tatsächlichen Test.
| Kombination | Status | Nachweis |
|---|---|---|
| API/SQLite/Sicherheitslogik, Python 3.14 unter Windows | Automatisierte lokale Softwaretests | python -m pytest |
| Python 3.13 im bereitgestellten Dockerfile | Image gebaut; Tests, TLS-Start und Dienstneustart bestanden | Ergebnisse im Testbericht |
| Python 3.12+ | Deklarierte Python-Untergrenze; keine vollständige CI-Matrix | Auf gewählter Version testen |
| Proxmox VE ISO mit nativem Answer-Token und First-Boot-URL | Pro konkretem ISO-Build zu testen | Noch offen |
| UEFI, BIOS und Secure Boot | Je verwendetem Bootmodus zu testen | Noch offen |
| Netzunterbrechung/Neustart auf echtem Proxmox-Host | Runner-Softwaretests plus erforderlicher Integrationstest | Hardware-/VM-Test offen |
| 100 Hosts, zehn gleichzeitige Installationen | Planungsziel | Lasttest offen |
| RPO 24 Stunden / RTO zwei Stunden | Planungsziel | Betrieblicher Restore-Test offen |
Ein ISO ohne native Unterstützung für --answer-auth-token wird nicht freigegeben.
Die Assistant-Version allein belegt nicht die Funktionen der Komponenten in einer
älteren ISO. Alle Beispieldaten sind Platzhalter und stellen keine Freigabe dar.
Freigabe eines Builds
Für jeden Build ein eigenes Prüfprotokoll außerhalb der Anwendung archivieren:
- Original-ISO und SHA-256, Assistant-Paketversion, Build-Befehl, Ergebnisdatei und Prüfsumme; Tokens im Protokoll redigieren.
- Installer-Request als redigiertes JSON; UUID-, Seriennummer- und MAC-Zuordnung sowie Ablehnung unbekannter und widersprüchlicher Identitäten.
- Antwortdatei ohne Geheimnisse, Prüfung mit dem zugehörigen Assistant, korrekte Netzwerkwerte und Auswahl ausschließlich der vorgesehenen Testdatenträger.
- Bearer-Header, TLS-Verifikation, First-Boot-Download, Zeitpunkt des ersten Starts und Vertrauen in die Server-CA.
- Modulabläufe
check,apply,verify, Verlust einer Serverantwort, Netzausfall, erneuter Start und kontrollierter Reboot. Unterbrochene nicht sichere Änderungen müssen einen prüfbedürftigen Zustand ergeben. - Abschluss nur nach erfolgreichen Pflichtprüfungen; danach keine erneute Installationsantwort oder weitere Skriptausführung mit alten Berechtigungen.
- Hardware-/VM-Konfiguration und Bootverfahren. Secure Boot nur nennen, wenn genau dieser Modus tatsächlich geprüft wurde.
Die Akzeptanzszenarien A01–A16 des Feinkonzepts sind die vollständige fachliche Abnahmeliste. Repositorytests decken die simulierbaren Server- und Runner-Teile ab, nicht die Betriebssysteminstallation oder reale Ausfälle.