The SOPS secret updated via Flux but MAS kept the old config in memory until a
rollout restart. Records committed != deployed != active for the security fix.
Root cause proven end to end: a pre-Authentik account that lost its profiles
row (deactivate clears it, reactivate does not recreate it) crashes the
displayname write path, so it never gets a display name and the Element Call
widget never initialises. Fixed with a cross-checked INSERT; open_id_tokens
went 0 -> 6 and the call joined. Records the ruled-out suspects, what led to
the solution, and the lessons - chief among them: compare old accounts against
freshly provisioned ones, and reproduce in a cleartext room before blaming
crypto. Also notes the account-takeover finding (gitops#61) surfaced along the
way.
Eleven findings, two false leads recorded as such (a wrong first diagnosis on #60, a false-clean secret scan caused by a wrong raw path), and the methods that actually surfaced each finding - most came from reading live state (database, ak apply_blueprint, the served config.json) rather than trusting green status.
The anonymisation rewrite of 2026-08-07 gave every touched commit a new SHA, leaving the references in these documents pointing at objects that no longer exist. The mapping was reconstructed from the backup branches and each pair verified by tree and commit message before substituting.
Prefix lookups were built for lengths 7 to 12 and any ambiguous prefix would have been skipped; none were ambiguous across all 251 pairs.
vision/ ist laut README 'eine Vision je Linie' - drei Linien, drei Dateien, alle
als Entwurf fuers Refinement markiert. branding.md ist keine Vision, sondern
Bestand und Historie eines uebergreifenden Themas, also genau das, was shared/
beschreibt (neben lab-netzwerk.md und zone-axion1337.md).
Der Beleg fuer den Fehlgriff steckte im letzten Commit selbst: ich musste die
README-Beschreibung von vision/ um einen Zusatz erweitern, damit die Datei
hineinpasst. Eine Kategorie aufzubohren, damit ein Artefakt hineinpasst, heisst,
dass es in die falsche Kategorie sollte. Die Zeile ist zurueckgebaut.
Ausserdem praezisiert, warum das Dokument in genau diesem Repo liegt: management
ist gespiegelt, homelab/wiki-bookstack nicht - die dortige theme/sorbs-palette.md
ist von ausserhalb des Labs nicht lesbar (CLAUDE.md, Mirror-Geltungsbereich).
Beide Rollen stehen jetzt explizit da.
AAR 2026-08-02: Nachtrag zur Theme-Korrektur. Die Ergebniszeile behauptete '11
neue Themes, Web live' - die Paletten waren aber erfunden. Statt die Historie
umzuschreiben ein datierter Nachtrag mit Verweis in der Zeile. Er schaerft das
Muster aus Abschnitt 4: erfundene Vorlagen erzeugen kein Symptom, an dem man sie
bemerkt - deshalb ist bei Vorlagen die Quelle zu pruefen, nicht nur das Ergebnis.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Fuenf Ursachen bei BookStack, die einander maskierten; wichtigste neue Lehre:
ein unhealthy Container ist fuer Traefik unsichtbar und sieht dabei exakt aus wie
ein fehlendes Netz. Dazu die electron-builder-Feinheit name vs. productName und
das Muster hinter meinen teuersten Fehlern: ungeprueft geaenderte Dinge.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Das Verfahren verlangt einen AAR nach Deploys; er fehlte und ist damit die
Luecke, die die zweite Konventionspruefung aufgedeckt hat. Neun Befunde, sieben
Lehren - darunter 'zuerst in die Traefik-Logs', 'thumbnail vergroessert nicht'
und 'Testumgebung ist nicht Zielumgebung'.
Nebenbei: Verweise auf wiki.lab auf die real genutzte Adresse axionwiki.lab
korrigiert.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
- ADR-0004: Status akzeptiert; real gebaute Architektur v2 dokumentiert
(UniFi bietet kein WG-Site-to-Site -> UDM-Server + CFGMON als Client mit
'Networks Behind Client'), inkl. Messwerten aus dem Negativtest
- AAR Lab-Seite: 5 Befunde, Eingrenzungsmethodik, 5 Lehren (u.a. 'Server'-Auswahl
erfasst nur das Tunnel-Subnetz; Portbedingung gehoert in beide Portfelder)
- README: Uebergabe-Issue-Ausnahme als auslaufend markiert
- shared/lab-netzwerk.md: beide WG-Zugaenge tabellarisch
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Host-Neustart 2026-08-01 ~21:57 CEST. Tunnel, Bootfix (After=docker.service),
Firewall-Regeln und Split-DNS kamen ohne manuellen Eingriff hoch; Handshake
2 s nach Messbeginn. Bootfix und Persistenz damit im Ernstfall verifiziert.
Der Handshake stand am 2026-08-01 ~21:15. Ursache des tagelangen Schweigens
war der in management#2 (Kommentar 399) als bestaetigt uebergebene UDM-Server-
PublicKey, der zu keinem Server auf der UDM gehoert. Nachtrag 2 dokumentiert
Eingrenzungsweg (tcpdump beidseitig, wg show am Geraet), Endzustand und Lehren.
Der Portversatz Fritzbox/UDM war ein realer zweiter Fehler, allein aber nicht
hinreichend.
Der AAR und der Kommentar an management#2 legten nahe, der Tunnel komme nach
dem Reboot von allein wieder, weil wg-quick@lab "enabled" war. Der Neustart am
2026-08-01 hat das widerlegt: der Dienst war ab 19:36 failed, weil wg-quick vor
dockerd startet und die PostUp-Regel an der noch fehlenden Kette DOCKER-USER
scheiterte -- wg-quick raeumte das Interface daraufhin ab.
Nachtrag als Abschnitt 6 ergaenzt, Fundstellen in Abschnitt 1 und Pruefpunkt 5
verweisen darauf. Behebung (systemd-Drop-in After=docker.service plus
idempotentes "iptables -N DOCKER-USER" in lab.conf) ist dort dokumentiert und
auf CFGMON umgesetzt.
Schritte 1-3 ausgefuehrt, Tunnel gestartet und enabled. Kein Handshake --
der Public Key von CFGMON ist noch nicht als UniFi-Client hinterlegt.
Drei Befunde ueber den Auftrag hinaus:
- enp7s0 seit 18:11 DOWN, ausgeloest durch die Hetzner-Range-Umstellung
(NIC neu angehaengt, hc-net-ifup wegen unmet condition uebersprungen).
Zeitstempel belegen: 29 Minuten VOR dem Tunnelstart, kein Zusammenhang.
- ufw ist auf CFGMON inaktiv; das Briefing setzte eine erzwingende
Forward-Policy voraus. Regeln liegen jetzt als iptables-ACCEPT in
PostUp/PreDown der lab.conf statt in ufw.
- sudo ist aus einer Agenten-Session nicht bedienbar (kein TTY); die
Schritte liefen ueber die docker-Gruppe, die root-aequivalent ist.
Die sudo-Passwortabfrage ist damit keine wirksame Grenze -- Entscheidung
darueber liegt bei sorb.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nach dem Deploy der CVE-Pipeline (gitops#47) als Verfahren festgehalten. Der
Stand war korrekt und gelintet; der Blocker entstand erst aus der Datenmenge,
gegen die er lief -- eine Alarm-Instanz pro CVE, real 126 CRITICAL und 1222
HIGH. So etwas faellt in keinem Diff auf, nur beim Messen vor dem Deploy.
Neu:
- .gitea/ISSUE_TEMPLATE/deploy-uebergabe.yaml -- Uebergabe-Issue mit
Pflichtfeldern Mengengeruest, vollstaendiges Deploy-Kommando, Verifikation
im laufenden Dienst, Aussenwirkung samt Not-Aus, Rollback
- verfahren/deploy-uebergabe.md -- Ablauf und Pruefliste
- verfahren/aar-vorlage.md -- AAR-Vorlage
- verfahren/aar/2026-08-01-cve-pipeline-gitops47.md -- der ausloesende AAR
Abgrenzung im README ergaenzt: hosts/ und shared/ halten offene Punkte,
verfahren/ haelt, wie wir arbeiten. Die Uebergabe-Issues laufen bewusst hier
statt im Projekt-Repo, weil das Verfahren repo-uebergreifend gilt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Thore Cimbal
