BACKLOG.md: auf zentrales Backlogs-Repo verweisen
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
+14
-202
@@ -1,209 +1,21 @@
|
|||||||
# Backlog
|
# 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
|
Der Grund für den Umzug: dieses Repo beschreibt einen Stack auf einem Host, die
|
||||||
**2026-10-28** ab. Traefik erneuert automatisch ca. 30 Tage vorher, also ab
|
offenen Punkte betreffen inzwischen mehrere. Ein Backlog an zwei Stellen läuft
|
||||||
**Ende September 2026**.
|
auseinander, deshalb hier nur der Verweis und keine eigene Liste.
|
||||||
|
|
||||||
Traefik ist auf TLS-ALPN-01 konfiguriert
|
Die Historie der ursprünglichen Einträge steht in diesem Repo bis Commit `25bb5dd`.
|
||||||
(`--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.
|
|
||||||
|
|||||||
Reference in New Issue
Block a user