63 lines
4.1 KiB
Markdown
63 lines
4.1 KiB
Markdown
---
|
|
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.
|