Thore CimbalandClaude Fable 5
9e0af1370b
Die Stacks sind jetzt unter axion1337.chat/game-operating abgebildet. Der Bestandseintrag sagt ausdruecklich, dass es ein Abbild und keine Quelle ist und was ihm noch fehlt - sonst liest sich der Verweis wie eine Zusicherung, die er nicht einloest. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
3.9 KiB
game
Pterodactyl- / Gameserver-Host.
| IPv4 | 157.90.155.206 |
| IPv6 | kein AAAA-Record |
| DNS | game.axion1337.de |
| Privat | 10.0.0.4 (im vSwitch seit 2026-08-02) |
| Stand | 2026-08-02 |
Teil-inventarisiert (2026-08-02). Die Compose-Definitionen sind bekannt, der Host selbst wurde weiterhin nicht betreten — OS-Stand, Plattenbelegung und Docker-Version fehlen. Beim ersten direkten Zugriff nachtragen.
Was darauf läuft
Zwei über Coolify deployte Stacks, abgebildet in axion1337.chat/game-operating (angelegt 2026-08-02).
⚠️ Das Repo ist ein Abbild, keine Quelle: Verwaltet wird weiter in Coolify,
Änderungen müssen dort und im Repo passieren. Der Umstieg auf git-basiertes
Deployment ist gewollt, aber bewusst zurückgestellt, bis das Matrix-Projekt
abgeschlossen ist (sorb, 2026-08-02). Bis dahin fehlen dem Abbild noch die
mitgemounteten Konfigdateien (entrypoint.sh, wings-Config, die drei
Monitoring-Konfigs) und die Volume-Deklarationen — aus dem Repo allein ließe
sich der Host derzeit nicht wiederherstellen.
Pterodactyl (Gameserver-Verwaltung, in Benutzung durch Bekannte des Betreibers — Ausfälle und Datenverlust sind hier real spürbar):
| Dienst | Image |
|---|---|
pterodactyl (Panel) |
ghcr.io/pterodactyl/panel:v1.12.0 |
wings (Daemon, fährt die Gameserver als Docker-Container) |
ghcr.io/pterodactyl/wings:v1.12.0 |
mariadb |
mariadb:11.8 |
redis |
redis:alpine |
Eigener Monitoring-Stack (grafana-oss, prometheus v3.0.0 mit 15 d Retention, loki 3.1.1, promtail 3.1.1, node-exporter v1.8.1, cadvisor v0.49.2). Wird perspektivisch von CFGMON abgelöst — siehe unten.
⚠️ Kein einziger ports:-Block in beiden Stacks. Alles hängt an Coolifys
Docker-Netz und ist nur containerintern erreichbar. Genau das war die Ursache von
GAME-01: Auf 9100/8080 des Hosts lauscht nichts, CFGMONs Scrape-Ziele auf der
öffentlichen IP konnten nie funktionieren.
Erreichbarkeit von außen (gemessen)
Vor dem Host liegt eine quellbewusste Firewall — dieselben Ports verhalten sich je nach Quelle unterschiedlich:
| Port | von CFGMON (188.245.193.243, 2026-08-01) |
vom Hausanschluss (178.25.213.70, 2026-08-02) |
|---|---|---|
| 80 / 443 | offen | offen (HTTP 404 bzw. 503) |
| 22 | Timeout | offen |
| 8080 / 9100 (Exporter) | Timeout | Timeout |
| ICMP | 100 % Verlust | 100 % Verlust |
Daraus folgt zweierlei: Es gibt bereits eine SSH-Freigabe für den Hausanschluss, und CFGMON ist nicht pauschal gesperrt (sonst wären auch 80/443 von dort tot) — es ist eine portbezogene Regel mit Quellliste. Die Exporter-Ports 8080/9100 sind dagegen für niemanden freigegeben, auch nicht für den Hausanschluss.
Es fehlte also keine Ausnahme für CFGMON. Seit 2026-08-02 liegt der Host im
vSwitch (10.0.0.4); die Monitoring-Anbindung läuft künftig per Push über das
private Netz — Alloy sammelt lokal ein und schiebt nach 10.0.0.3, wodurch der
Host keinen einzigen eingehenden Port braucht. Dasselbe Muster wie beim
k3s-Cluster. Details: GAME-01.
Die Umstellung erfolgt additiv: Der lokale Monitoring-Stack läuft weiter, bis auf CFGMON über Wochen belastbar Daten liegen. Auf diesem Host wird nichts abgeräumt, solange nicht klar ist, dass nichts fehlt.
Offene Punkte → git.lab-Issues
Seit dem Framework-Umbau (2026-08-01) leben offene Punkte als Issues im management-Projekt; die IDs bleiben in den Issue-Titeln erhalten. Dieses File hält nur noch Bestand und Historie.