fix: Admin-Dienste hinter dem VPN wieder korrekt prüfen

Seit der VPN-Absicherung (Phase 2) antworten n8n, die beiden Nginx Proxy
Manager, Grafana und CloudPanel auf ihren öffentlichen Domains nur noch mit
403. Der Checker wertete das als "down" — die Statusseite stand deshalb
dauerhaft auf "down", ohne dass ein Dienst tatsächlich gestört war.

Der Checker läuft per Cron auf hetzner, das selbst WireGuard-Peer 10.10.0.14
ist. Diese Dienste werden jetzt über das neue Feld "check_url" intern geprüft,
Grafana und CloudPanel laufen auf hetzner selbst und werden über localhost
angesprochen. "url" bleibt die öffentliche Adresse für die Anzeige; "check_url"
wird vor dem Schreiben aus status.json entfernt, damit die interne
Netztopologie nicht auf einer öffentlichen Seite landet.

Uptime Kuma zeigte bisher nur einen 302 auf der gesperrten Root-URL. Geprüft
wird jetzt die öffentliche Status-Page, die tatsächlich beweist, dass Kuma
antwortet.

Nebenbei korrigiert: ng.vanityontour.de war als "CloudPanel" gefuehrt, ist aber
laut NPM-Datenbank der Nginx Proxy Manager auf VoTServer. CloudPanel selbst
(cp.blog.vanityontour.de) wurde dadurch nie geprüft und ist jetzt ergaenzt.

Der GitHub-Actions-Workflow entfaellt: er lief ohnehin nur noch manuell, von
GitHub aus sind die internen Adressen unerreichbar, und ein Start haette ein
falsches "alles down" committet und per FTP über die Live-Seite geschoben.
README beschreibt jetzt den tatsaechlichen Weg (Cron auf hetzner + SCP).

2026-08-03 06:55:32 +02:00

2.7 KiB

Raw Blame History

VanityOnTour Status Page

Automated status dashboard for all VanityOnTour services, hosted on Hostinger at status.vanityontour.de.

What it monitors

Websites: vanityontour.de, news, wiki, staysense, landing
Tools: N8N, Nginx Proxy Manager, Uptime Kuma, Stats, App Backend, CloudPanel
APIs: RSS News API, StaySense API
iOS App: Vanity Expense Logbook (version, rating, last update)
SSL: Certificate expiry for all main domains

How it works

Ein Cron auf hetzner (88.99.209.207) läuft alle 5 Minuten:

*/5 * * * * /opt/run_status_check.sh >> /var/log/status_check.log 2>&1

/opt/check_status.py prüft alle Dienste und schreibt /opt/public/status.json
run_status_check.sh kopiert die Datei per SCP (Port 65002) nach /home/u982551092/domains/status.vanityontour.de/public_html/status.json

Die statischen Dateien unter public/ (HTML, CSS, Icons) liegen unverändert auf Hostinger; nur status.json wird zyklisch überschrieben.

Der frühere Weg über GitHub Actions + FTP-Deploy wird nicht mehr benutzt. Das committete public/status.json ist deshalb nur ein Platzhalter — der Live-Stand steht ausschließlich auf Hostinger.

Deployment einer Skript-Änderung

scripts/check_status.py wird nicht automatisch ausgerollt. Nach einer Änderung:

scp scripts/check_status.py hetzner:/opt/check_status.py
ssh hetzner '/opt/run_status_check.sh'   # einmal testweise ausführen

Dienste hinter dem Management-VPN

Seit der VPN-Absicherung antworten die Admin-Oberflächen öffentlich nur noch mit 403. Weil der Checker auf hetzner läuft und hetzner WireGuard-Peer 10.10.0.14 ist, werden diese Dienste über das Feld check_url intern geprüft:

Dienst	Anzeige (`url`)	Prüfung (`check_url`)
N8N Automation	`n8n.vanityontour.de`	`http://10.10.0.13:5678`
Nginx Proxy Manager	`nginx.vanityontour.de`	`http://10.10.0.13:81`
Nginx Proxy Mgr (VoT)	`ng.vanityontour.de`	`http://10.10.0.12:81`
Statistiken (Grafana)	`stats.vanityontour.de`	`http://127.0.0.1:3000`
CloudPanel	`cp.blog.vanityontour.de`	`https://127.0.0.1:8443`
Uptime Kuma	`server.vanityontour.de`	`…/status/vanity` (öffentlich)

check_url wird vor dem Schreiben aus status.json entfernt — die interne Netztopologie gehört nicht auf eine öffentliche Seite. Die Statusseite zeigt weiterhin nur den Hostnamen aus url an.

Local test

python3 scripts/check_status.py
# → writes public/status.json

Achtung: Lokal (ohne VPN-Route zu 10.10.0.0/24) melden die intern geprüften Dienste zwangsläufig „down". Aussagekräftig ist der Lauf nur auf hetzner.

2.7 KiB Raw Blame History