--- title: Upgrades description: Stack aktualisieren — alles über GitOps published: true date: 2026-08-14T14:34:49.634Z tags: editor: markdown dateCreated: 2026-08-13T20:27:33.029Z --- Der Stack wird per **GitOps** aktualisiert — nichts von Hand am Cluster, alles über einen Commit nach git.lab (**nie direkt nach Gitea** pushen). ## ESS-Chart - Chart-Version in `apps/production/element-server-suite.yaml` (HelmRelease) anheben, committen → Flux zieht die neue Version. - Vorher das Changelog/Breaking-Changes der ESS-Version prüfen (die Schema-Validierung ist streng — ungültige Werte brechen den Reconcile mit kryptischen Fehlern). ## Einzel-Images (Authentik, coturn, ClamAV, Draupnir, Wiki.js …) - Image-Tag im jeweiligen Manifest anheben, committen → Flux rollt neu aus. - Bei DB-Schema-Migrationen (Authentik, Wiki.js): vorher ein aktuelles **Backup** sicherstellen. ## Ablauf 1. Backup-Stand prüfen. 2. Version im Repo anheben, committen, nach git.lab pushen. 3. `flux reconcile` beobachten; Pods + Health prüfen. 4. Bei Problemen: Commit zurückrollen — GitOps macht das Rollback trivial. ## Stack-Anpassungen & Fork-Porting Beim Upgrade der zugrundeliegenden Element-/Synapse-Versionen müssen **unsere Anpassungen mit**. Wo sie liegen: | Komponente | Basis | Änderungen dokumentiert in | |---|---|---| | **ThreadNet Web** (Element-Web-Fork) | Element Web/Desktop `1.12.17` | `ThreadNet-Web:docs/axion1337-fork.md` · [/betrieb/element-customization](/betrieb/element-customization) | | **threadnet-call** (Element-Call-Fork) | Element Call `0.19.2` (via `emmick4/element-call` `livekit`) | `threadnet-call:docs/axion1337-fork.md` · [/betrieb/element-call](/betrieb/element-call) | | **Synapse & Stack** | ESS `v26.4.0` — **kein** Code-Fork, nur Config/Module | gitops (`synapse-values.yaml`, `clamav_spam_checker.py`, …) + die jeweiligen Betriebsseiten | **Ablauf beim Element-Upgrade eines Forks:** 1. Ziel-Upstream-Version wählen; das jeweilige `axion1337-fork.md` ist die **Liste dessen, was re-appliziert/geportet werden muss**. 2. Rebase/Merge auf die neue Version; die dort genannten **kritischen Dateien** zuerst prüfen (dort sitzt die Merge-Reibung). 3. Bauen, Image nach Gitea publizieren, im gitops-Stack die Version anheben (siehe oben). **Synapse/Stack ist kein Fork:** unsere Eingriffe sind GitOps-Config (Room-Policies, ClamAV-Modul, Backups, TURN-Rotation …) und wandern mit dem ESS-Chart-Upgrade automatisch mit — dokumentiert auf den jeweiligen Betriebsseiten, nicht als Code-Diff. ## Wiki.js: Startup-Patch (Zeitzone) Wiki.js läuft als **Upstream-Image** (`ghcr.io/requarks/wiki:2.5`) — **kein** Code-Fork, keine Build-Pipeline. Unsere eine Anpassung wird als **Startup-Overlay** im Deployment (`apps/production/wikijs.yaml`, Container-`command`) eingespielt: neue OIDC-Nutzer bekommen `timezone: 'Europe/Berlin'` statt des Wiki.js-Defaults `America/New_York`. Wiki.js legt SSO-Nutzer in `processProfile` (`server/models/users.js`) ohne Zeitzone an, sonst greift der DB-Spalten-Default (New York). Der Container `sed`-patcht die Datei vor dem Boot — **idempotent** (grep-Guard) und **fail-open** (Wiki.js startet auch, wenn der Patch nicht greift; neue Nutzer fielen dann auf New York zurück). ⚠️ **Beim Wiki.js-Upgrade prüfen:** Der Patch hängt am Anker `localeCode: WIKI.config.lang.code,` in `users.js`. Ändert sich diese Zeile in einer neueren Version, muss der `sed` im Deployment nachgezogen werden (der ⚠️-Kommentar steht direkt im Manifest). Gleiche Logik wie bei den Element-Forks oben: Upstream-Bump → Patch gegenprüfen → ggf. Anker anpassen. Der `localeCode` selbst kommt bereits aus der Standard-Locale (`de`), nur die Zeitzone braucht den Patch. ## Kadenz & CVE-Bezug Updates sind zugleich unser wichtigster **CVE-Fix** (siehe [Sicherheit & CVE-Remediation](/betrieb/sicherheit)). Deshalb: - **Regelmäßig** (Richtwert monatlich) Basis-Images/Charts anheben — nicht warten, bis der Report explodiert. - **Ad-hoc** bei einer CRITICAL-CVE mit verfügbarem Fix. - `:latest`-Tags vermeiden (z.B. coturn) — sonst kein reproduzierbarer/scanbarer Stand.