MATRIX-01 (Mail-Absender-Frage): per Config verifiziert, dass weder Synapse noch MAS Mail versenden - kein Konfigurationsblock in den deployten Werten. MATRIX-02: Korrektur einer falschen Annahme - "k3s-Host (10.0.0.2)" und "matrix" sind dieselbe Maschine, nicht zwei getrennte. Remote-Write nutzt bereits die private IP. MATRIX-04 neu: Host-Level Pre-Update-Benachrichtigung (Issue #24). Cross-Referenzen in zone-axion1337.md (ZONE-02 entblockt) und cfgmon.md (CFGMON-03-Update, neues CFGMON-08 fuer die Gitea-Runner-Standortfrage) aktualisiert. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
5.7 KiB
matrix
Matrix-Homeserver (Element Server Suite / Synapse) + K3s-Single-Node-Cluster, GitOps-verwaltet.
| Hostname | MATRIX |
| IPv4 | 49.13.132.245 |
| IPv6 | kein AAAA-Record |
| Privat | 10.0.0.2 (enp7s0, dasselbe Hetzner-Netz wie CFGMON 10.0.0.3) |
| OS | Debian 13 (trixie) |
| DNS | matrix.axion1337.de und matrix.axion1337.chat zeigen auf dieselbe IP — ebenso axion1337.chat (Apex) und account.axion1337.chat (MAS). axion1337.de ist die ältere/Registrar-Domain (IONOS-Mail läuft dort), axion1337.chat die eigentliche Matrix-Service-Domain. |
| Stand | 2026-07-30 |
Inventarisiert (direkter SSH-Zugriff, ~/.ssh/config-Alias axion1337, Port 2248):
K3s + FluxCD + Element Server Suite (Synapse, MAS, Element Web, MatrixRTC), Authentik (OIDC),
Traefik, Cert-Manager, coturn, Draupnir, ClamAV, NetworkPolicies (Default-Deny). IaC-Repo:
sorb/axion1337.chat-gitops - dieser
Host ist das Deployment-Ziel dieses Repos, nicht nur verwandt. Client-Forks:
sorb/ThreadNet-Web (Element Web), sorb/threadnet-call (Element Call/LiveKit-Widget).
sorb/element-web und sorb/ThreadNet-Stack sind veraltete/abgelöste Vorgänger-Repos
(letzte Aktivität 2026-05-11 bzw. 2025-10-24) - nicht mehr das, was hier läuft.
ufw: aktiv, Default Deny Incoming / Allow Outgoing, explizite Allow-Regeln für
2248/tcp (SSH), 80/443, TURN/RTC-Ports. unattended-upgrades aktiv (Debian-Security +
Debian-Origin), siehe MATRIX-04.
MATRIX-03 — www.matrix.axion1337.de ist überflüssig
Status: offen, geringe Priorität
A-Record www.matrix.axion1337.de → 49.13.132.245, nach IONOS-Default-Muster
angelegt. Begründung siehe ZONE-01. Nicht
verifiziert, ob auf dem Host etwas auf den Namen hört.
Nächster Schritt: prüfen und sonst löschen.
Erledigt
MATRIX-01 — Klären, ob der Server Mail als @matrix.axion1337.de verschickt · erledigt 2026-07-30
Für matrix.axion1337.de existiert der komplette IONOS-Mail-Satz: MX mx00/mx01,
TXT "v=spf1 include:_spf-eu.ionos.com ~all", CNAME s1-ionos._domainkey und
CNAME autodiscover. Bei selendis ist dasselbe Muster reine Altlast; hier war die Frage
offen, weil Matrix-Homeserver typischerweise Mail für Registrierung/Passwort-Reset
verschicken.
Antwort, verifiziert per Config (nicht nur vermutet) — direkt im IaC-Repo
sorb/axion1337.chat-gitops, dem tatsächlich hier deployten Stand geprüft:
apps/production/custom-configs/synapse-values.yaml— keinemail:/smtp_host/notif_from-Block.apps/production/custom-configs/mas-secret.yaml(SOPS-entschlüsselt geprüft) — keinemail/smtp/mailer-Eintrag.apps/production/element-server-suite.yaml(HelmRelease values) — dito, nichts.
Weder Synapse noch MAS versenden aktuell irgendeine Mail. Registrierung/Passwort-Reset
laufen ausschließlich über Authentik (OIDC, auth.axion1337.chat) und Einladungslinks.
Der komplette IONOS-Mail-Satz auf matrix.axion1337.de ist damit funktional unnötig —
dieselbe Härtung wie bei selendis anwenden (Null-MX, v=spf1 -all, _dmarc p=reject),
autodiscover.matrix kann ebenfalls weg. Damit ist auch
ZONE-02 an dieser Stelle entblockt.
Separat davon (andere Domain-Ebene, kein Widerspruch): auf diesem Host läuft seit
2026-07-30 ein eigener Mailversand für Host-Wartungsbenachrichtigungen
(wartung@axion1337.de, Apex-Postfach, nicht die matrix.-Subdomain) — siehe
MATRIX-04 unten. Nutzt die ohnehin am Apex laufende echte IONOS-Mail-Infrastruktur,
betrifft die matrix.-Subdomain-Records oben also nicht.
MATRIX-02 — Pusht per Remote-Write auf einen offenen Prometheus · erledigt 2026-07-30
Korrektur einer falschen Annahme im ursprünglichen Eintrag: der Text ging von zwei
getrennten Absendern aus - "CFGMON (10.0.0.3) und der k3s-Host (10.0.0.2)" - als wären
das zwei verschiedene Maschinen. Es ist dieselbe Maschine: dieser Host (matrix) hat
selbst die private IP 10.0.0.2 (verifiziert per ip -4 addr show auf dem Host).
Verifiziert in apps/monitoring/alloy-config.yaml (diesem Cluster): Der Remote-Write-Push
geht bereits an http://10.0.0.3:9090/api/v1/write und Loki an http://10.0.0.3:3100/... -
private IP, nicht die öffentliche 188.245.193.243:9090. Von dieser Seite aus ist hier
nichts mehr zu tun. Ob Prometheus/Loki auf CFGMON zusätzlich öffentlich erreichbar sind
(unabhängig davon, ob dieser Host den privaten Weg nutzt), ist
CFGMON-03
- ein reines CFGMON-Thema, nicht mehr blockiert durch etwas auf diesem Host.
MATRIX-04 — Host-Level Pre-Update-Benachrichtigung · erledigt 2026-07-30
Neuer, eigenständiger Mechanismus auf diesem Host, außerhalb von Flux/GitOps (Details:
docs/deployment-guides/07-host-maintenance-notifications.md im gitops-Repo,
Issue #24):
unattended-upgrades war bereits aktiv, neu ergänzt ist ein systemd-Timer
(maintenance-notify.timer, fest 05:00 Uhr, vor dem 06:00-07:00-Update-Fenster), der bei
anstehenden Paket-Updates per Mail und Matrix (Thread-Reply im wartung-Raum)
benachrichtigt.
Mail-Versand läuft über msmtp, Absender wartung@axion1337.de (IONOS SMTP,
smtp.ionos.de:587, STARTTLS - Port 465 war ausgehend blockiert, vermutlich
Cloud-Provider-Firewall-Regel, 587 ging durch). Relevant für die Mail-Policy-Diskussion
oben: dieses Postfach nutzt die reale, bereits am Apex laufende IONOS-Mail-Infrastruktur,
keine neue Subdomain, kein neuer Handlungsbedarf für die Zone.