docs: the ESS step is prepared, and two acceptance lines carry it

A fresh application backup covers the Synapse and MAS databases and the media —
2.36 GB, taken by hand because the nightly one is eighteen hours old. sorb adds a
host snapshot. No disarming is needed this time: matrix-stack sets no remediation
at all, so Flux will not roll anything back on its own.

The acceptance list has eight lines and only the last two prove anything new. The
ClamAV module's API compatibility with v1.158 is measured; its function is not.
And our call fork's compatibility with LiveKit v1.12.0 instead of v1.10.0 is
neither measured nor documented anywhere — the fork carries custom audio work
built against the older server.

Named in advance for the third time today: an intermediate state is not a result.
Synapse runs background updates for hours after a jump this size, and a ready pod
with background updates still logging is normal rather than a failure.
This commit is contained in:
Thore Cimbal
2026-08-21 12:00:00 +00:00
parent 71e78fc653
commit bd6b0b6058
+44
View File
@@ -664,3 +664,47 @@ wie die echte Datei, mit **anderem** Inhalt und nur 8,8 KB statt 30,7 KB. Sie
steht **nicht** im Kustomize-Bauplan und ist damit heute wirkungslos — aber wer
sie je aufnimmt oder umbenennt, ersetzt die Element-Konfiguration stillschweigend
durch einen älteren, kleineren Stand. Nicht angefasst; gehört sorb.
#### Der Plan für den ESS-Schritt
**Vorbedingungen, beide erfüllt:**
- **Anwendungssicherung frisch von Hand**: `synapse-backup-vor-ess-268-…T19:22:43`,
2,36 GB — deckt die Synapse- **und** die MAS-Datenbank sowie die Medien ab. Die
nächtliche war von 01:00; seitdem sind Nachrichten und Sitzungen entstanden.
- **Host-Snapshot durch sorb** (zusätzlich zur Anwendungssicherung).
**Keine Entschärfung nötig.** `matrix-stack` hat **gar keine** `remediation`
gesetzt, Flux' Vorgabe ist `retries: 0` ohne selbsttätiges Zurückrollen — anders
als bei Authentik, wo `retries: 3` erst zu entwaffnen war.
**Der Schritt:** eine Zeile, `apps/production/element-server-suite.yaml` Z. 15,
`26.4.0` → `26.8.0`. **Nicht 26.8.1** — die ist vom selben Tag.
**Abnahmeliste. Die letzten beiden Zeilen entscheiden, alles davor ist Vorlauf:**
| # | Prüfung | Erwartet |
|---|---|---|
| 1 | Synapse-Schema-Migrationen im Protokoll | durchgelaufen, kein Abbruch |
| 2 | Pods bereit, Fassungen | `synapse:v1.158.0`, `mas:1.22.0`, `element-admin:0.1.12`, `lk-jwt:0.4.4`, SFU `v1.12.0` |
| 3 | `threadnet-web` unverändert | weiterhin `v0.6.0` — die Überschreibung darf nicht verloren gehen |
| 4 | Föderation weiter geschlossen | `federation_domain_whitelist` im Secret vorhanden |
| 5 | Anmeldung durch die Kette | Element → MAS → Authentik, serverseitig belegt |
| 6 | Eine Nachricht senden und empfangen | im Ereignisprotokoll belegt |
| 7 | ⚠️ **Ein echter Call mit aktiver Rauschunterdrückung** | unser Call-Fork gegen **LiveKit v1.12.0** statt v1.10.0 |
| 8 | ⚠️ **Ein Upload, den ClamAV abweist** | das Synapse-Modul unter **v1.158** in Funktion, nicht nur API-verträglich |
⚠️ **Zeile 7 und 8 sind die einzigen, die etwas Neues beweisen.** Die
API-Verträglichkeit des ClamAV-Moduls ist gemessen, seine Funktion nicht; die
Verträglichkeit unseres Call-Forks mit dem neuen SFU ist **weder** gemessen noch
dokumentiert.
⚠️ **Ein Zwischenstand ist auch hier kein Ergebnis** — zum dritten Mal heute.
Synapse fährt nach einem Sieben-Minor-Sprung **Hintergrund-Aktualisierungen**,
die Stunden laufen können. Ein Pod, der bereit ist, während im Protokoll noch
`background updates` stehen, ist normal und kein Fehlschlag.
**Rückweg:** `git revert` der Fassungszeile **plus** Anstoßen der Quelle. Sind
die Schema-Migrationen gelaufen, zusätzlich die Datenbank aus der Sicherung von
19:22 — dann gehen Nachrichten und Sitzungen seit diesem Zeitpunkt verloren, die
Konten nicht.