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.
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.
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).
services.hermes-agent.environment: MATRIX_DEVICE_ID=HERMES01 deklarativ — überlebt die .env-Regeneration
Manuelle Schritte nach Merge (Runbook im Chat)
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
## 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 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).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Root cause chain (Matrix-Ausfall 2026-08-16)
matrix.m3ta.devnicht auflösbar → Login failed.MATRIX_ACCESS_TOKENwirft 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..env, nicht im agenix-Secret → Passwort-Login → pro Restart ein Ghost-Device (device_id-Drift im Log: HERMES01 → KDQS91N2PB → ejkSHOBRPh).Changes
networking.hosts: Pinmatrix.m3ta.dev → 152.53.85.162(m3-atlas, TLS-Terminierung) — Matrix-Verbindung überstebt Netbird-DNS-Ausfälleservices.hermes-agent.environment:MATRIX_DEVICE_ID=HERMES01deklarativ — überlebt die .env-RegenerationManuelle Schritte nach Merge (Runbook im Chat)
secrets/hermes-env.ageaufnehmen (MATRIX_ACCESS_TOKEN=...), dabeiMATRIX_USER_ID/MATRIX_PASSWORD-Duplikate und den TippfehlerMATIRX_HOME_ROOMbereinigenrm -f /var/lib/hermes/.hermes/platforms/matrix/store/crypto.db*(gehört Ghost-Device)python3 scripts/matrix-device-cleanup.py(Skill hermes-devops)sudo nixos-rebuild switch --flake .#m3-hermes+ Verifikation (device_id=HERMES01, ESTABLISHED, keine Retry-Drop-Warnung)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).Pull request closed