fix(m3-hermes): stable Matrix device + DNS pin for homeserver #24

Closed
m3ta-chiron wants to merge 1 commits from fix/matrix-stable-token-dns-pin into master
Collaborator

Root cause chain (Matrix-Ausfall 2026-08-16)

  1. DNS-SPOF Netbird: m3-hermes löst DNS ausschließlich über den Netbird-Resolver (wt0). Nameserver-Group 14:03–15:24 unreachable → matrix.m3ta.dev nicht auflösbar → Login failed.
  2. Gateway-Kapitulation: Ohne MATRIX_ACCESS_TOKEN wirft der Gateway Matrix nach fehlgeschlagenem Start PERMANENT aus der Retry-Queue (gateway/run.py:12322: 'no bot credential on queued config'). Kein Auto-Reconnect nach DNS-Recovery.
  3. Fix 0 wurde gewischt: Der stabile Token vom 14.08. lag nur in der bei jedem Service-Start regenerierten .env, nicht im agenix-Secret → Passwort-Login → pro Restart ein Ghost-Device (device_id-Drift im Log: HERMES01 → KDQS91N2PB → ejkSHOBRPh).

Changes

  • networking.hosts: Pin matrix.m3ta.dev → 152.53.85.162 (m3-atlas, TLS-Terminierung) — Matrix-Verbindung überstebt Netbird-DNS-Ausfälle
  • services.hermes-agent.environment: MATRIX_DEVICE_ID=HERMES01 deklarativ — überlebt die .env-Regeneration

Manuelle Schritte nach Merge (Runbook im Chat)

  1. Token als HERMES01 erstellen und in agenix secrets/hermes-env.age aufnehmen (MATRIX_ACCESS_TOKEN=...), dabei MATRIX_USER_ID/MATRIX_PASSWORD-Duplikate und den Tippfehler MATIRX_HOME_ROOM bereinigen
  2. rm -f /var/lib/hermes/.hermes/platforms/matrix/store/crypto.db* (gehört Ghost-Device)
  3. Ghost-Device-Cleanup: python3 scripts/matrix-device-cleanup.py (Skill hermes-devops)
  4. sudo nixos-rebuild switch --flake .#m3-hermes + Verifikation (device_id=HERMES01, ESTABLISHED, keine Retry-Drop-Warnung)
## Root cause chain (Matrix-Ausfall 2026-08-16) 1. **DNS-SPOF Netbird**: m3-hermes löst DNS ausschließlich über den Netbird-Resolver (wt0). Nameserver-Group 14:03–15:24 unreachable → `matrix.m3ta.dev` nicht auflösbar → Login failed. 2. **Gateway-Kapitulation**: Ohne `MATRIX_ACCESS_TOKEN` wirft der Gateway Matrix nach fehlgeschlagenem Start PERMANENT aus der Retry-Queue (`gateway/run.py:12322`: 'no bot credential on queued config'). Kein Auto-Reconnect nach DNS-Recovery. 3. **Fix 0 wurde gewischt**: Der stabile Token vom 14.08. lag nur in der bei jedem Service-Start regenerierten `.env`, nicht im agenix-Secret → Passwort-Login → pro Restart ein Ghost-Device (device_id-Drift im Log: HERMES01 → KDQS91N2PB → ejkSHOBRPh). ## Changes - `networking.hosts`: Pin `matrix.m3ta.dev → 152.53.85.162` (m3-atlas, TLS-Terminierung) — Matrix-Verbindung überstebt Netbird-DNS-Ausfälle - `services.hermes-agent.environment`: `MATRIX_DEVICE_ID=HERMES01` deklarativ — überlebt die .env-Regeneration ## Manuelle Schritte nach Merge (Runbook im Chat) 1. Token als HERMES01 erstellen und in agenix `secrets/hermes-env.age` aufnehmen (`MATRIX_ACCESS_TOKEN=...`), dabei `MATRIX_USER_ID`/`MATRIX_PASSWORD`-Duplikate und den Tippfehler `MATIRX_HOME_ROOM` bereinigen 2. `rm -f /var/lib/hermes/.hermes/platforms/matrix/store/crypto.db*` (gehört Ghost-Device) 3. Ghost-Device-Cleanup: `python3 scripts/matrix-device-cleanup.py` (Skill hermes-devops) 4. `sudo nixos-rebuild switch --flake .#m3-hermes` + Verifikation (`device_id=HERMES01`, ESTABLISHED, keine Retry-Drop-Warnung)
m3ta-chiron added 1 commit 2026-08-16 16:07:21 +02:00
Root cause chain of recurring Matrix outages (2026-08-16):

1. DNS on m3-hermes resolves exclusively via the Netbird-managed
   resolver. When the Netbird nameserver group is unreachable
   (observed 14:03-15:24), matrix.m3ta.dev fails to resolve.
2. A gateway restart during that window fails the Matrix login, and
   without MATRIX_ACCESS_TOKEN the gateway drops Matrix permanently
   from its reconnect queue ('no bot credential on queued config').
   Recovery happens only on the next restart - with working DNS.
3. The stable-token setup from 2026-08-14 was wiped because it was
   only written to the regenerated .env, not to the agenix secret.

Changes:
- Pin matrix.m3ta.dev to the m3-atlas public IP (TLS termination)
  so the Matrix connection survives Netbird DNS outages.
- Declare MATRIX_DEVICE_ID=HERMES01 in the module environment so the
  device id survives .env regeneration. The matching
  MATRIX_ACCESS_TOKEN must be added to secrets/hermes-env.age
  (separate manual step: agenix edit + re-encrypt).
m3tam3re closed this pull request 2026-08-16 16:32:34 +02:00

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
No Reviewers
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m3tam3re/nixos-config#24