sorb/threadnet-operating
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

BACKLOG.md: auf zentrales Backlogs-Repo verweisen

Browse Source 
Die offenen Punkte betreffen inzwischen mehrere Hosts, dieses Repo
beschreibt aber einen Stack auf einem Host. Inhalte sind nach
sorb/Backlogs umgezogen und dort pro Host strukturiert; hier bleibt nur
der Verweis, damit die Liste nicht an zwei Stellen auseinanderlaeuft.

Die Historie der urspruenglichen Eintraege bleibt bis 25bb5dd erhalten.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Claude
2026-07-30 14:37:38 +02:00
parent 25bb5dd44e
commit b067c93677
1 changed files with 14 additions and 202 deletions
Download Patch File Download Diff File Expand all files Collapse all files
BACKLOG.md
+14 -202
View File
@@ -1,209 +1,21 @@
# Backlog
Offene Punkte, die bewusst nicht sofort erledigt wurden. Stand: 2026-07-30.
Umgezogen. Offene Punkte werden zentral über alle Hosts hinweg geführt:
---
**→ [sorb/Backlogs](https://rohana.axion1337.de/sorb/Backlogs)**
## 1. Zertifikatserneuerung braucht offene Ports — oder Umstellung auf DNS-01
Für den Monitoring-Stack in diesem Repo relevant:
**Status:** offen, zeitkritisch ab ca. **2026-09-28**
- [hosts/cfgmon.md](https://rohana.axion1337.de/sorb/Backlogs/src/branch/main/hosts/cfgmon.md)
— Zertifikatserneuerung, nicht versionierter Portainer-Stack, offener
Remote-Write-Receiver, Grafana-API-Credentials
- [hosts/game.md](https://rohana.axion1337.de/sorb/Backlogs/src/branch/main/hosts/game.md)
— die beiden down-Targets auf `157.90.155.206`
- [shared/zone-axion1337.md](https://rohana.axion1337.de/sorb/Backlogs/src/branch/main/shared/zone-axion1337.md)
— DNS-Zone und Mail-Policy
Das Cert für `selendis.axion1337.de` wurde am 2026-07-30 ausgestellt und läuft am
**2026-10-28** ab. Traefik erneuert automatisch ca. 30 Tage vorher, also ab
**Ende September 2026**.
Der Grund für den Umzug: dieses Repo beschreibt einen Stack auf einem Host, die
offenen Punkte betreffen inzwischen mehrere. Ein Backlog an zwei Stellen läuft
auseinander, deshalb hier nur der Verweis und keine eigene Liste.
Traefik ist auf TLS-ALPN-01 konfiguriert
(`--certificatesresolvers.letsencrypt.acme.tlschallenge=true`). Diese Challenge
läuft ausschließlich über **Port 443, erreichbar aus dem offenen Internet**. Ist
der Port zu diesem Zeitpunkt in der Hetzner-Cloud-Firewall gesperrt, scheitert die
Erneuerung still mit:
```
urn:ietf:params:acme:error:connection :: Timeout during connect (likely firewall problem)
```
Traefik liefert dann sein Default-Self-Signed-Cert aus — Browser und `curl` brechen
mit Zertifikatsfehler ab. **Das betrifft auch Gitea** (`rohana.axion1337.de`,
Cert im selben Resolver), also die Erreichbarkeit dieses Repos per HTTPS.
Eine IP-Allowlist für die Let's-Encrypt-Server ist **keine** Option: LE
veröffentlicht seine Validierungs-IPs nicht und prüft seit Einführung der
Multi-Perspective Validation aus mehreren Regionen gleichzeitig.
**IPv6 beachten (Stand 2026-07-30):** `rohana`, `www.rohana` und `selendis` haben
inzwischen AAAA-Records auf `2a01:4f8:c17:93eb::1`. Damit validiert Let's Encrypt
**bevorzugt über IPv6**. Die Hetzner-Cloud-Firewall braucht für Port 443 deshalb
eine Regel mit Quelle `::/0` — `0.0.0.0/0` deckt IPv6 **nicht** mit ab. Fehlt sie,
scheitert die Erneuerung, obwohl IPv4 offen ist. Vom Host aus lässt sich das nicht
verifizieren (Verbindung auf die eigene öffentliche Adresse läuft lokal), das muss
in der Hetzner-Konsole geprüft werden.
Zwei Wege:
- **A — Port 443 zur Erneuerung öffnen.** Nichts umbauen, aber alle ~60 Tage
daran denken. Fehleranfällig, weil das Scheitern nicht auffällt, bis jemand die
Seite aufruft.
- **B — auf DNS-01 umstellen** (empfohlen). Validierung über einen TXT-Record,
**kein offener Port nötig**, Erneuerung läuft bei komplett dichter Firewall
durch. Voraussetzung: API-Token des DNS-Providers für `axion1337.de`, hinterlegt
als Secret für Traefik. Ermöglicht zusätzlich Wildcard-Certs
(`*.axion1337.de`), was künftige Subdomains ohne Portöffnung abdeckt.
**Nächster Schritt:** Entscheidung A oder B. Bei B: DNS-Provider benennen und
API-Token bereitstellen, dann Traefik-Resolver umstellen.
### Nebenpunkt: `www.rohana.axion1337.de` löschen
Der Record (A + AAAA) wurde nach IONOS-Default-Muster angelegt. Bei einer
Subdomain ist ein `www.`-Präfix überflüssig — das Muster gilt für Apex-Domains
(`axion1337.de` / `www.axion1337.de`, dort bei IONOS sinnvoll). `rohana` ist
bereits der Hostname des Dienstes.
Aktueller Zustand: kein Traefik-Router matcht den Namen, Traefik liefert sein
`TRAEFIK DEFAULT CERT` aus, TLS bricht mit Zertifikatsfehler ab. Der Name
funktioniert also ohnehin nicht.
**Empfehlung:** A- und AAAA-Record für `www.rohana` löschen. Es geht nichts
verloren. Die Alternative — Router plus Cert-SAN für den zweiten Namen — bedeutet
mehr Teile, die bei jeder Erneuerung mitvalidieren müssen, ohne Nutzen. Für
`selendis` aus demselben Grund kein `www.` anlegen. Siehe Punkt 3 für die
vollständige DNS-Bereinigung.
---
## 3. DNS-Bereinigung bei IONOS
**Status:** `rohana` und `selendis` werden vom User direkt umgesetzt (2026-07-30),
`game` / `matrix` / `ftp` / Apex noch offen
Die Zone liegt bei IONOS (`ns10xx.ui-dns.*`), Zonentransfer ist verweigert — die
Records unten stammen aus gezielten Abfragen und der IONOS-Oberfläche, die Liste
ist daher **nicht garantiert vollständig**. Für eine vollständige Prüfung entweder
die ungefilterte IONOS-Liste durchgehen oder die Certificate-Transparency-Logs
abfragen.
IONOS legt beim Anlegen einer Subdomain automatisch einen kompletten Mail-Satz mit
an (MX, SPF, DKIM-CNAMEs, `autodiscover`) und ein `www.`-Paar — auch für Hosts, auf
denen nie Mail läuft. Bei `selendis` und `matrix` ist das passiert, bei `rohana` und
`game` nur das `www.`-Paar.
### Warum nicht einfach löschen
Ersatzloses Entfernen der Mail-Records ist die schlechtere Variante:
- Ohne SPF existiert **keine** Aussage darüber, wer als dieser Name senden darf.
Das bestehende `~all` ist nur Softfail und wird von vielen Empfängern
akzeptiert — eine ungenutzte Subdomain mit gültigen MX und Softfail-SPF ist ein
brauchbarer Spoofing-Vektor.
- **Fehlt ein MX-Record, weichen Absender per RFC 5321 auf A/AAAA aus.** Mail an
`@rohana.axion1337.de` würde also Port 25 auf `188.245.193.243` ansprechen.
Richtig ist daher, „hier gibt es keine Mail" explizit zu erklären: Null-MX
(RFC 7505), SPF `-all`, DMARC `p=reject`.
### rohana.axion1337.de
Löschen: `A www.rohana`, `AAAA www.rohana`
Anlegen:
| Typ | Name | Wert |
|---|---|---|
| MX | `rohana` | `.` (Priorität 0) |
| TXT | `rohana` | `v=spf1 -all` |
| TXT | `_dmarc.rohana` | `v=DMARC1; p=reject;` |
Nicht anfassen: `A rohana`, `AAAA rohana` — daran hängen Gitea und das Zertifikat.
### selendis.axion1337.de
Löschen: `MX mx00.ionos.de`, `MX mx01.ionos.de`,
`CNAME s1-ionos._domainkey.selendis`, `CNAME s2-ionos._domainkey.selendis`,
`CNAME s42582890._domainkey.selendis`, `CNAME autodiscover.selendis`,
`A www.selendis`, `AAAA www.selendis`
Ändern — **den bestehenden TXT editieren, nicht einen zweiten anlegen** (zwei
SPF-Records auf einem Namen ergeben einen PermError, die Prüfung fällt komplett
aus): `v=spf1 include:_spf-eu.ionos.com ~all` → `v=spf1 -all`
Anlegen: `MX selendis` = `.` (Priorität 0), `TXT _dmarc.selendis` =
`v=DMARC1; p=reject;`
Nicht anfassen: `A selendis`, `AAAA selendis`.
Vorab prüfen: ob im IONOS-Mail-Bereich ein Postfach oder eine Weiterleitung für
`selendis.axion1337.de` existiert. Wenn ja, entfallen die MX-Änderungen.
Falls die IONOS-Oberfläche `.` als MX-Ziel ablehnt: MX löschen und nur die TXT-
Records setzen. `-all` und `p=reject;` greifen trotzdem.
### Noch offen
- **`www.game`, `www.matrix`** (A-Records): dasselbe überflüssige Muster, aber auf
fremden Hosts — nicht verifiziert, ob dort etwas darauf hört.
- **`matrix.axion1337.de`**: gleicher Mail-Satz wie `selendis`, aber **erst prüfen**,
ob der Matrix-Server Benachrichtigungsmails mit Absender
`…@matrix.axion1337.de` verschickt. Wenn ja, müssen SPF und DKIM dort bleiben und
auf den echten Absender zeigen. `autodiscover.matrix` kann in jedem Fall weg —
Matrix-Föderation läuft über `.well-known` bzw. SRV.
- **`ftp.axion1337.de`** → `217.160.233.227`: IONOS-Default aus dem Hosting-Paket,
zeigt auf IONOS und nicht auf eigene Infrastruktur. Löschen, falls dort kein FTP
genutzt wird.
- **Apex-DMARC ist `v=DMARC1; p=none;`** — reines Monitoring, kein Schutz. Ohne
`sp=`-Angabe erben alle Subdomains dieses `p=none`. `sp=reject` am Apex wäre der
effiziente Hebel für alle Subdomains inklusive künftiger, **aber erst nach**
Klärung von `matrix`, sonst bricht dessen Mailversand.
- **`game.axion1337.de` ist `157.90.155.206`** — derselbe Host wie in Punkt 2, den
Prometheus per roher IP scrapt. Der Name wäre die wartbarere Variante.
---
## 2. Pterodactyl-Host 157.90.155.206 nicht erreichbar — 2 Prometheus-Targets down
**Status:** offen, Ursache liegt außerhalb dieses Hosts
Zwei Scrape-Targets sind seit Längerem down — bereits vor dem Monitoring-Rework,
also **kein Regressionsschaden** aus der Umstellung:
| Job | Target | Fehler |
|---|---|---|
| `gameserver_cadvisor` | `157.90.155.206:8080` | `context deadline exceeded` |
| `pterodactyl_host_node` | `157.90.155.206:9100` | `context deadline exceeded` |
Der Host antwortet von `188.245.193.243` aus **nicht auf Ping** (100 % packet
loss) und auf keinem der beiden Ports. Das Problem ist also nicht die
Prometheus-Konfiguration, sondern die Erreichbarkeit des Zielhosts. Mögliche
Ursachen, von wahrscheinlich nach unwahrscheinlich:
1. Hetzner-Cloud-Firewall des Pterodactyl-Hosts lässt `188.245.193.243` nicht auf
8080/9100 — passend zum restriktiven Firewall-Setup.
2. cAdvisor und node-exporter laufen dort nicht (mehr) bzw. binden nur auf
`127.0.0.1`.
3. Host ist abgeschaltet oder umgezogen (IP veraltet).
**Nächster Schritt:** auf dem Pterodactyl-Host prüfen, ob die beiden Exporter
laufen und worauf sie binden, und die Firewall dort für `188.245.193.243` auf
8080/9100 öffnen. Idealerweise nicht öffentlich, sondern über das private Netz —
dieser Host hat `10.0.0.3/32` auf `enp7s0`; wenn der Pterodactyl-Host im selben
Hetzner-vSwitch liegt, sollte über die privaten IPs gescrapt werden statt über
die öffentlichen. Dann sind dafür gar keine offenen Ports im Internet nötig.
Solange offen: die beiden Targets in Grafana/Alertmanager als *known down*
behandeln, damit sie kein Dauer-Alerting erzeugen.
---
## Weitere Beobachtungen (nicht beauftragt, aber notiert)
- **Prometheus Port 9090 ist öffentlich und ohne Auth erreichbar.** Nötig, weil
k3s-Cluster und Matrix-Server per `--web.enable-remote-write-receiver` dorthin
pushen. Ein offener Remote-Write-Receiver erlaubt Fremden aber das
**Einspeisen beliebiger Metriken** und das Auslesen aller Daten. Sollte per
Hetzner-Cloud-Firewall auf die Absender-IPs beschränkt werden — der Hinweis
steht als Kommentar in `monitoring/docker-compose.yml`, ist aber noch nicht
umgesetzt. Gleiches gilt für **Loki auf 3100**.
- **Grafana-Admin-Credentials aus `.env` greifen nicht für die HTTP-API.** Der
Live-Admin wurde offenbar irgendwann in der UI geändert; `GF_SECURITY_ADMIN_*`
wirkt nur beim allerersten Start mit leerem Volume. Verifikation läuft deshalb
über `grafana.db` statt über die API. Kein Defekt, aber bei künftigen Checks
wissen.
Die Historie der ursprünglichen Einträge steht in diesem Repo bis Commit `25bb5dd`.