Files

T

Thore CimbalandClaude Opus 5 6fb3cb7fed docs: relevance pass over the backlog - close #0055 , retire four stale issues

#0055 is done: ThreadNet-Web be323ed checks in an .npmrc binding @sorb to rohana.
The bump that mattered was not the file but what upstream's .gitignore does with
it - it ignores /.npmrc, so the naive fix would have stayed local while CI kept
resolving against npmjs. Measured in an isolated tree: without the file pnpm goes
to npmjs and fails, with it the scope resolves to rohana at the integrity hash
the lockfile already carries, and with rohana unreachable the install fails
instead of falling back. threadnet-call only publishes and already sets the scope
in its own CI; gitops never touches it. ThreadNet-Web was the only consumer.

Four issues no longer describe reality, each verified rather than assumed:

- #0091 (gitops#61) was fixed when it was written - on_conflict: fail shipped in
  ef04d86 and the MAS pod has run that config since 2026-08-11T14:08:41Z. Its one
  deliberate remainder became #0043, which is closed and verified live.
- #0079 (gitops#46) asked for the Gitea migration and a central view. The
  migration ran; the central view was decided the other way round - repo canonical,
  GitLab mirrored (ADR-0012/0019) - which also answers the reachability trade-off
  it left open, and better than its three options did.
- #0075 (gitops#40) is rejected, not done: it wanted new issues to appear in the
  Gitea kanban automatically. Issues no longer live in Gitea and the board is
  script-written. Nothing was accomplished; the question dissolved.
- #0098 is a rollout record whose only remainder, the macOS build, is #0022.

Three AARs move to harvested - every open item in them is tracked as an issue.

Checked and still accurate, so left alone: the wiki branch still exists on both
remotes (#0019), docs/TASKS.md and oldwiki/ are still there (#0085),
element-web-docs still names live resources (#0086), res/themes/element persists
(#0100), only WIKI_CANONIZE_TOKEN is set so TURN rotation still lacks its token
(#0084), gameserver still has zero push mirrors (#0032), the broken .6 package is
still published (#0101), and options.ts still builds simulcast layers regardless
of codec, which is what blocks VP9 (#0057).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-18 12:00:00 +00:00

3.4 KiB

Raw Blame History

type, status, date, related

type

status

date

aar

harvested

2026-08-16

docs/issues/0005-zone-01-ionos-default-records-bereinigen-www.md

AAR — Gruppen-Calls fünf Tage tot: `mrtc`-A-Record bei der Zonen-Bereinigung gelöscht

Datum des Vorfalls: 2026-08-11 bis 2026-08-16 · Beteiligt: sorb + Mac-Session · Stack: MatrixRTC (LiveKit-SFU + Authorisation-Service), IONOS-DNS, cert-manager Auftrag am 16.08.: „zwischen frank und sorb kommt in raum test kein call zustande, OPEN_ID_Error" — Grundursache finden.

1. Ergebnis

Behoben: mrtc.axion1337.chat A 49.13.132.245 von sorb bei IONOS neu gesetzt; danach Token-Tausch am Authorisation-Service nachweislich wieder angekommen, Calls liefen im Test.

Grundursache: Der A-Record wurde bei der IONOS-Zonen-Bereinigung (#0005, 11.08.) mit gelöscht — auf Empfehlung der Session, die keine Soll-Liste hatte, gegen die sie hätte prüfen können. Letzter erfolgreicher Call-Beitritt 11.08. 21:48; erster Fehlversuch danach erst am 16.08. — fünf Tage unbemerkt, weil niemand telefonierte.

2. Warum nichts Alarm schlug

Zertifikat blieb grün: DNS-01-Renewal braucht keinen A-Record.
Cluster blieb grün: Ingress, SFU-Pod, Authorisation-Service — alles gesund; der Dienst bekam schlicht keine Anfragen mehr (nur Health-Checks).
Der Client-Fehler führte in die Irre: „OPEN_ID_Error" — dabei war das OpenID-Stück das Einzige, was funktionierte (Synapse gab Tokens mit 200 aus). Der Bruch lag eine Stufe später: https://mrtc…/sfu/get war nicht auflösbar.

3. Diagnose-Weg (was künftig Zeit spart)

Synapse-Log: openid/request_token 200 für beide Nutzer → OpenID entlastet.
Authorisation-Service-Log: nur Health-Checks, keine echte Anfrage → Bruch davor.
curl https://mrtc…/healthz → HTTP 000 → dig → kein Record, autoritativ bestätigt.
DB-Abgleich Versuche↔Beitritte (open_id_tokens vs. call.member-Events) datierte den Bruch exakt: 11.08. 76/61, 16.08. 3/0.

4. Lehren und Maßnahmen

Es gab keine DNS-Soll-Liste. Die einzige Nennung von mrtc als Pflicht-Record steckte in einem alten Fehlerbericht (gitops:docs/oldwiki/fix report mrtc.md). → Umgesetzt: notfallhandbuch:dns-soll.md (Soll-Liste mit „Wenn er fehlt"-Spalte und dem, was es bewusst NICHT gibt) plus pruefe-dns.sh (prüft öffentlich UND autoritativ; Positiv- und Negativlauf verifiziert). Vor jeder Zonen-Änderung laufen lassen.
Aufschreiben allein hätte nicht gereicht (Wiederholung der Bindmount-Lehre): wirksam ist das ausführbare Skript, nicht die Tabelle daneben.
„Meldet Erfolg, ist aber blind", DNS-Ausgabe: Grüne Zertifikate und grüne Pods sagen nichts über die Erreichbarkeit von außen. Der Fehlertext des Clients benennt die Stufe, auf der er scheitert — nicht die Ursache.
Bereinigungen brauchen eine Soll-Liste vorab. Die Session hat beim Aufräumen Einträge freigegeben, deren Zweck sie nicht kannte. Erst prüfen, wogegen — dann löschen.

5. Offen

DMARC-/Mail-Härtung der Zone axion1337.chat: bei der Diagnose als Nebenbefund erhoben, seit 2026-08-18 als #0102 geführt. Beim Anlegen präzisiert: #0006 hat axion1337.**de** gehärtet (dort heute p=reject); die Plattform-Zone .chat hängt weiterhin als CNAME an IONOS' geteiltem p=none — sie war nie Gegenstand von #0006.

3.4 KiB Raw Blame History

AAR — Gruppen-Calls fünf Tage tot: mrtc-A-Record bei der Zonen-Bereinigung gelöscht