Kritisch: sync_vpn_certificate() rief docker compose exec als blanke
Zuweisung unter set -Eeuo pipefail auf — schlaegt das fehl (kein
laufender vpn-gateway), beendet set -e den ganzen Agenten, still,
nachdem write_alive schon lief. Beide Zuweisungen bekommen jetzt
`|| stamp=''`, mit Begruendung im Kommentar.
Wichtig: der Gesundheits-Port antwortete immer mit 204, auch wenn das
Startskript fuer den Konsolennamen kein Zertifikat fand und den
Gateway ohne jede Seite auf 443 rendert. VPN_READY wurde dann wahr,
und ausgegebene Client-Konfigurationen nannten einen Resolver, der die
Verbindung ablehnt. vpn-entrypoint.sh prueft jetzt, ob die
Konsolen-Seite wirklich gerendert wurde, und antwortet sonst mit 503 —
wget --spider (gegen das echte caddy:2-alpine-Image verifiziert, nicht
angenommen) behandelt das als Fehlschlag, vpn_ready bleibt false, und
die bestehende Warnung in update.sh greift wieder: sie ist nicht
verschwunden, sondern hierher gewandert. Zwei Tests in
VpnGatewayConfigTest decken beide Richtungen ab; der alte Test mit der
jetzt falschen Annahme "unabhaengig von jedem Zertifikat" wich dem
Test fuer den Fall mit Zertifikat.
Kleinigkeit: ein Satz im Kommentar von sync_vpn_certificate() haelt
fest, dass die Zertifikatsliste einmalig beim Start geschrieben wird
und ein nachtraeglich ausgestelltes Zertifikat erst den naechsten
Neustart des Gateways sieht.
Der Test bestand bislang auch dann, wenn das Skript ueberhaupt nichts
rendert — die einzige Behauptung war eine Verneinung. Jetzt prueft er
zusaetzlich, dass admin.clupilot.test wirklich im Ergebnis steht.
nexxo