matrix: inventarisieren, MATRIX-01/02 verifiziert erledigt, MATRIX-04 neu
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>
This commit is contained in:
Thore Cimbal
co-authored by
Claude Sonnet 5
Claude Sonnet 5
parent
34686ee2e1
commit
15396d53e8
+38
-2
@@ -147,8 +147,16 @@ umgesetzt ist er nicht.
|
||||
**Nächster Schritt:** Beide Ports per Hetzner-Cloud-Firewall auf die Absender
|
||||
einschränken. Sauberer wäre, sie gar nicht öffentlich zu binden: k3s liegt mit
|
||||
`10.0.0.2` im selben privaten Netz wie CFGMON (`10.0.0.3`), der Push könnte also
|
||||
über das private Netz laufen. Für den Matrix-Server auf `49.13.132.245` prüfen, ob
|
||||
er in dasselbe Netz aufgenommen werden kann — siehe [matrix](matrix.md).
|
||||
über das private Netz laufen.
|
||||
|
||||
**Update 2026-07-30**: der k3s/Matrix-Host (`49.13.132.245`, privat `10.0.0.2` — ist
|
||||
derselbe Host, siehe [MATRIX-02](matrix.md#matrix-02--pusht-per-remote-write-auf-einen-offenen-prometheus--erledigt-2026-07-30))
|
||||
nutzt für seinen eigenen Remote-Write/Loki-Push bereits die private IP
|
||||
(`http://10.0.0.3:9090`/`:3100`, verifiziert in `apps/monitoring/alloy-config.yaml`), nicht
|
||||
`188.245.193.243`. Der öffentlich erreichbare, unauthentifizierte Port bleibt trotzdem ein
|
||||
CFGMON-seitiges Risiko (jeder im Internet könnte ihn ansprechen, nicht nur der k3s-Host) -
|
||||
dieser Teil des Punkts ist also weiterhin offen, nur nicht mehr durch fehlende
|
||||
Netz-Erreichbarkeit des Matrix-Hosts blockiert.
|
||||
|
||||
---
|
||||
|
||||
@@ -171,6 +179,34 @@ sauberer, weil dafür kein Admin-Passwort nötig ist.
|
||||
|
||||
---
|
||||
|
||||
## CFGMON-08 — Kein Gitea-Actions-Runner registriert, Standort noch offen
|
||||
|
||||
**Status:** offen
|
||||
|
||||
`gitea.rohana.axion1337.de` (dieser Host) hostet mehrere Repos mit `.gitea/workflows/`
|
||||
(u. a. `axion1337.chat-gitops`, `ThreadNet-Web`), aber es läuft **kein Runner** — Workflows
|
||||
existieren, greifen aber nie. Tracking der eigentlichen Notwendigkeit (drei Baustellen
|
||||
hängen daran: Web-/Desktop-Build-CI, Electron-Automatisierung, npm-Publish für
|
||||
`threadnet-call`) läuft zentral in
|
||||
[gitops#33](https://rohana.axion1337.de/sorb/axion1337.chat-gitops/issues/33) — hier nur
|
||||
die **Standort-Frage**, die noch nicht entschieden ist:
|
||||
|
||||
- **Auf CFGMON** (neben Gitea selbst): kürzeste Wege zu Gitea, aber dieser Host hat laut
|
||||
[CFGMON-02](#cfgmon-02--traefik-gitea-und-cadvisor-sind-nicht-versioniert) ohnehin schon
|
||||
unversionierte Infrastruktur - ein weiterer nicht-deklarativer Baustein wäre ungünstig,
|
||||
außer der Runner wird von Anfang an sauber (IaC) aufgesetzt.
|
||||
- **Auf dem k3s/Matrix-Cluster** (siehe [matrix](matrix.md)): passt zum GitOps-Modell dort
|
||||
(alles deklarativ), Runner-Pod bräuchte aber Netzzugriff zu Gitea auf CFGMON - existiert
|
||||
bereits privat (`10.0.0.2` ↔ `10.0.0.3`).
|
||||
- **Secret-Handling für CI-Tokens** (z. B. der npm-Publish-Token für `threadnet-call`):
|
||||
unabhängig vom Standort über Gitea Actions' eigene Secrets-Funktion (Repo-/Org-Settings),
|
||||
nicht SOPS - siehe Begründung in gitops#33.
|
||||
|
||||
**Nächster Schritt:** Standort entscheiden, dann Runner registrieren, dann #33 und die
|
||||
verlinkten Issues (ThreadNet-Web#2, gitops#44) abarbeiten.
|
||||
|
||||
---
|
||||
|
||||
## Erledigt
|
||||
|
||||
### CFGMON-05 — Monitoring-Stack unter IaC bringen · erledigt 2026-07-30
|
||||
|
||||
+81
-61
@@ -1,74 +1,29 @@
|
||||
# matrix
|
||||
|
||||
Matrix-Homeserver.
|
||||
Matrix-Homeserver (Element Server Suite / Synapse) + K3s-Single-Node-Cluster, GitOps-verwaltet.
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Hostname** | `MATRIX` |
|
||||
| **IPv4** | `49.13.132.245` |
|
||||
| **IPv6** | kein AAAA-Record |
|
||||
| **DNS** | `matrix.axion1337.de` |
|
||||
| **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 |
|
||||
|
||||
> **Nicht inventarisiert.** Alle Angaben stammen aus DNS-Abfragen und der
|
||||
> Prometheus-Konfiguration auf CFGMON. Auf dem Host selbst wurde nichts geprüft.
|
||||
> Beim ersten direkten Zugriff OS, Dienste und Compose-Projekte hier nachtragen.
|
||||
> Verwandte Repos, noch nicht zugeordnet: `sorb/axion1337.chat-gitops`,
|
||||
> `sorb/element-web`, `sorb/ThreadNet-Stack`.
|
||||
**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`](https://rohana.axion1337.de/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.
|
||||
|
||||
---
|
||||
|
||||
## MATRIX-01 — Klären, ob der Server Mail als `@matrix.axion1337.de` verschickt
|
||||
|
||||
**Status:** offen — **blockiert die Mail-Härtung der Zone**
|
||||
|
||||
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 aus dem
|
||||
Anlegen der Subdomain und wird entfernt.
|
||||
|
||||
**Hier nicht ungeprüft übernehmen.** Matrix-Homeserver verschicken typischerweise
|
||||
Mail für Registrierungsbestätigungen, Passwort-Resets und Benachrichtigungen. Wenn
|
||||
der Absender `…@matrix.axion1337.de` lautet, sind SPF und DKIM auf diesem Namen
|
||||
**funktional nötig** — sie zu löschen oder auf `-all` zu setzen würde den Mailversand
|
||||
zerlegen, und zwar auf eine Weise, die erst auffällt, wenn sich jemand nicht
|
||||
registrieren kann.
|
||||
|
||||
**Nächster Schritt:** in der SMTP-Konfiguration des Homeservers den `From:`-Absender
|
||||
nachsehen (bei Synapse: `email.notif_from` in der `homeserver.yaml`). Dann:
|
||||
|
||||
- **Absender lautet auf `matrix.axion1337.de`:** SPF und DKIM behalten und prüfen,
|
||||
ob sie den tatsächlichen versendenden Host abdecken. Läuft der Versand nicht über
|
||||
IONOS, ist das aktuelle `include:_spf-eu.ionos.com` falsch und der echte Relay
|
||||
muss aufgenommen werden.
|
||||
- **Absender lautet anders** (z. B. auf den Apex): Härtung wie bei `selendis` —
|
||||
Null-MX, `v=spf1 -all`, `_dmarc` mit `p=reject`.
|
||||
|
||||
In beiden Fällen kann `autodiscover.matrix` weg: das ist ein Exchange-/Outlook-
|
||||
Mechanismus, für Matrix-Föderation irrelevant — die läuft über `.well-known` bzw.
|
||||
SRV-Records.
|
||||
|
||||
Dieser Punkt blockiert außerdem `sp=reject` am Apex, siehe
|
||||
[ZONE-02](../shared/zone-axion1337.md).
|
||||
|
||||
---
|
||||
|
||||
## MATRIX-02 — Pusht per Remote-Write auf einen offenen Prometheus
|
||||
|
||||
**Status:** offen — Gegenstück zu [CFGMON-03](cfgmon.md#cfgmon-03--prometheus-remote-write-und-loki-sind-öffentlich-ohne-auth)
|
||||
|
||||
Dieser Host schreibt Metriken per Remote-Write an Prometheus auf CFGMON. Der
|
||||
Receiver dort ist auf `188.245.193.243:9090` öffentlich und **ohne
|
||||
Authentifizierung** erreichbar.
|
||||
|
||||
**Nächster Schritt:** prüfen, ob dieser Host in das private Hetzner-Netz aufgenommen
|
||||
werden kann, in dem CFGMON (`10.0.0.3`) und der k3s-Host (`10.0.0.2`) liegen. Dann
|
||||
kann der Push über die private Adresse laufen und Port 9090 muss nicht mehr
|
||||
öffentlich offen sein. Falls nicht möglich: Firewall-Regel auf CFGMON, die 9090 auf
|
||||
`49.13.132.245` und die k3s-Absender einschränkt.
|
||||
|
||||
Wichtig bei der Umstellung: die Remote-Write-URL liegt in der Konfiguration **dieses**
|
||||
Hosts, die Firewall-Regel auf CFGMON. Beides muss zusammen geändert werden, sonst
|
||||
brechen die Metriken ab.
|
||||
`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-04--host-level-pre-update-benachrichtigung-erledigt).
|
||||
|
||||
---
|
||||
|
||||
@@ -81,3 +36,68 @@ angelegt. Begründung siehe [ZONE-01](../shared/zone-axion1337.md). **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` — kein `email:`/`smtp_host`/
|
||||
`notif_from`-Block.
|
||||
- `apps/production/custom-configs/mas-secret.yaml` (SOPS-entschlüsselt geprüft) — kein
|
||||
`email`/`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](../shared/zone-axion1337.md) 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](cfgmon.md#cfgmon-03--prometheus-remote-write-und-loki-sind-öffentlich-ohne-auth)
|
||||
- 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](https://rohana.axion1337.de/sorb/axion1337.chat-gitops/issues/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.
|
||||
|
||||
@@ -119,13 +119,22 @@ explizite „nimmt keine Mail an"-Aussage.
|
||||
- **`game`** und **`matrix`**: `www.`-Records, siehe
|
||||
[GAME-02](../hosts/game.md#game-02--wwwgameaxion1337de-ist-überflüssig) und
|
||||
[MATRIX-03](../hosts/matrix.md#matrix-03--wwwmatrixaxion1337de-ist-überflüssig).
|
||||
- **Mail-Records auf `matrix`**: **erst** [MATRIX-01](../hosts/matrix.md) klären. Wenn
|
||||
der Homeserver Mail als `@matrix.axion1337.de` verschickt, sind SPF und DKIM dort
|
||||
funktional nötig.
|
||||
- **`ftp.axion1337.de`** → `217.160.233.227`: IONOS-Default aus dem Hosting-Paket,
|
||||
zeigt auf IONOS und nicht auf eigene Infrastruktur — also keine zusätzliche
|
||||
Angriffsfläche, aber Ballast. Löschen, falls dort kein FTP genutzt wird.
|
||||
|
||||
### Geklärt: Mail-Records auf `matrix`
|
||||
|
||||
[MATRIX-01](../hosts/matrix.md#matrix-01--klären-ob-der-server-mail-als-matrixaxion1337de-verschickt--erledigt-2026-07-30)
|
||||
ist erledigt (2026-07-30): weder Synapse noch MAS versenden Mail (per Config verifiziert,
|
||||
nicht nur vermutet — Registrierung/Reset laufen über Authentik). Der komplette Mail-Satz
|
||||
auf `matrix.axion1337.de` kann damit genauso gehärtet werden wie bei `selendis`
|
||||
(Null-MX, `v=spf1 -all`, `_dmarc p=reject`), siehe ZONE-01 oben. Separat davon läuft seit
|
||||
2026-07-30 echter, unabhängiger Mailversand über das **Apex**-Postfach
|
||||
`wartung@axion1337.de` (Host-Wartungsbenachrichtigungen) - betrifft die
|
||||
`matrix.`-Subdomain-Records nicht, bestätigt aber, dass am Apex weiterhin reale
|
||||
IONOS-Mail-Infrastruktur aktiv genutzt wird.
|
||||
|
||||
**Nach der Umsetzung von hier aus verifizieren:** dass `www.rohana` und
|
||||
`www.selendis` nicht mehr auflösen; dass MX, SPF und DMARC greifen und **nur ein**
|
||||
SPF-Record pro Name existiert; und dass `A`/`AAAA` von `rohana` und `selendis`
|
||||
@@ -136,7 +145,7 @@ Punkt ist der, bei dem ein Verklicker in der IONOS-Oberfläche wehtun würde.
|
||||
|
||||
## ZONE-02 — Apex-DMARC ist `p=none` und schützt nichts
|
||||
|
||||
**Status:** offen — **blockiert durch [MATRIX-01](../hosts/matrix.md)**
|
||||
**Status:** offen — nicht mehr blockiert, [MATRIX-01](../hosts/matrix.md#matrix-01--klären-ob-der-server-mail-als-matrixaxion1337de-verschickt--erledigt-2026-07-30) ist seit 2026-07-30 erledigt
|
||||
|
||||
`_dmarc.axion1337.de` enthält `v=DMARC1; p=none;` (via `dmarc.ionos.de`). Das ist
|
||||
reines Monitoring: Empfänger melden Verstöße, verwerfen aber nichts. Für gefälschte
|
||||
|
||||
Reference in New Issue
Block a user