config.json wurde still nicht mehr ausgeliefert (Derivat-Image ohne Exec-Bit) — Fix: kanonischer Release v0.3.0 #8
Assignees
sorb (ScrublordMcBad)
Clear assignees
sorb (ScrublordMcBad)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: sorb/ThreadNet-Web#8
Reference in New Issue
Block a user
Vorfall 2026-08-01 (~09:45–10:05): Nach einem ConfigMap-Update meldete sorb „wo sind meine Themes hin" — der Web-Client lief plötzlich mit Element-Defaults.
Diagnose (vollständig verifiziert):
/config.jsonlieferte 404 — nginx serviert den Pfad aus/tmp/element-web-config/(location-Block der ESS-nginx-Config), das ein Entrypoint-Script (18-load-element-modules.sh) beim Containerstart befüllt.Ignoring /docker-entrypoint.d/18-load-element-modules.sh, not executable— das Script lief nie./config.jsonwar damit seit dem Pod vom 29.07. still kaputt; Nutzer mit lange offenen Tabs merkten nichts, jeder frische Load lief ohne Config (keine Themes, kein Branding). Der heutige ConfigMap-Rollout war nur der Anlass zum Reload, nicht die Ursache.FROM sorb/threadnet-web:v0.1.0+ Widget-COPY, Handarbeit vom Juli) — v0.1.0 entstand vor dem Mode-Fix im Repo. Im heutigen Repo-Stand ist alles korrekt: Exec-Bits 755, kanonischesapps/web/Dockerfileinkl. Healthcheck genau aufconfig.json.Sofortmaßnahme (aktiv, aber flüchtig):
mkdir+cpnach/tmp/element-web-config/im laufenden Pod — Themes sind zurück. ⚠️ Stirbt mit jedem Pod-Restart.Dauerhafter Fix (läuft): erster kanonischer CI-Release
v0.3.0(Pipeline 122) → Image ausapps/web/Dockerfileersetzt die Derivat-Linie; gitops-Tag-Bump folgt nach Build-Verifikation (Exec-Bit-Check am gebauten Image).Lehren: (a) Derivat-Images auf Basis von Handarbeit-Ständen sind ab jetzt tabu — Releases nur noch über die CI-Kette; (b) der Healthcheck im kanonischen Image hätte genau diesen Fehler gefangen (k8s nutzt Docker-HEALTHCHECK nicht — ggf. als Liveness-Probe in die gitops-Werte übernehmen, prüft dann config.json aktiv).
Fix gebaut und verifiziert (2026-08-01 ~10:45):
v*war kein geschütztes Tag-Muster → protected CI-Variablen (REGISTRY_*) fehlten im ersten Tag-Lauf (Must provide --username). Musterv*jetzt protected, Retry grün.rohana.axion1337.de/sorb/threadnet-web:v0.3.0liegt in der Registry und ist dreifach inspiziert: Entrypoint-Script ausführbar (rwxrwxrwx), Call-Widget enthalten (/app/widgets/element-call— kommt jetzt aus der npm-Dependency statt per Hand-COPY),config.jsonan Ort und Stelle. Der Docker-HEALTHCHECK des Images prüft künftig genau/config.json.release-v0.3.0-webimageliegt lokal bereit (Ein-Zeilen-Bumpv0.3.0-clientscan→v0.3.0+ Begründungskommentar). Push + Merge = Flux rollt, der Pod-Restart macht zugleich den flüchtigen Hotfix überflüssig.Bis dahin gilt: keinen element-web-Pod-Restart ohne anschließenden Hotfix (
mkdir -p /tmp/element-web-config && cp /app/config.json /tmp/element-web-config/im Pod), sonst ist /config.json wieder weg.Erledigt (2026-08-01 ~11:15, Deploy-Freigabe sorb): gitops
82827c4gemerged, Flux hat ausgerollt.Verifiziert live: Pod-Image
rohana.axion1337.de/sorb/threadnet-web:v0.3.0,/config.json→ HTTP 200 aus dem Image-eigenen Entrypoint (kein Hotfix mehr nötig),aXion1337 Dark+ 6 Custom-Themes +feature_video_roomsaktiv. Die Derivat-Image-Ära ist damit beendet — Releases laufen ab jetzt ausschließlich über die CI-Kette (Tag → docker_web → gitops-Bump). Nebenbefund auf dem Weg:v*ist jetzt protected Tag-Muster (war die Lücke, durch die die Registry-Variablen im ersten Tag-Build fehlten).Follow-up-Idee aus der Diagnose bleibt offen notiert: config.json-Liveness-Probe in den gitops-Werten (der Docker-HEALTHCHECK greift unter k8s nicht) — bei Gelegenheit.
Migriert nach git.lab: axion1337.chat/ThreadNet-Web#8 (nur im Lab bzw. via VPN erreichbar — das Lab ist seit 2026-08-01 die Quelle der Wahrheit, siehe gitops#48). Weiterarbeit dort; dieses Gitea-Issue bleibt als Verweis stehen.