oliver/vanityontour-status
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
No description
45 commits 1 branch 0 tags 106 KiB
Find a file
Oliver G 61c486167c
fix: nur noch über IPv4 prüfen, hetzner hat kein funktionierendes IPv6 
hetzner hat eine globale IPv6-Adresse und eine Default-Route, aber keine
Konnektivität — auch google.com und cloudflare.com laufen über IPv6 in den
Timeout. Bei jeder Domain mit AAAA-Record wartete Python erst ~20s, bevor es
auf IPv4 zurückfiel: vanityontour.de und wiki wurden mit über 20000ms statt
~180ms gemessen, und der Lauf überschritt das 5-Minuten-Cron-Intervall.

Bisher war das verdeckt, weil ein /etc/hosts-Block auf hetzner die betroffenen
Domains auf IPv4 pinnte. Der Block stammte aus der DNS-Migration im April, war
überholt und enthielt für wiki.vanityontour.de eine tote IP (2.57.91.91) —
daher der TLS-Fehler und das dauerhafte "down" des Wikis. Mit dem Entfernen des
Blocks kam die latente IPv6-Störung zum Vorschein.

Der Checker filtert getaddrinfo jetzt auf AF_INET. Das ist kein Workaround um
die Störung herum, sondern beschreibt den Messpunkt korrekt: mehr als IPv4
kann hetzner derzeit nicht erreichen. Die IPv6-Störung selbst bleibt offen.
2026-08-03 07:02:31 +02:00
public chore: status update 2026-04-08 07:01 UTC 2026-04-08 07:01:19 +00:00
scripts fix: nur noch über IPv4 prüfen, hetzner hat kein funktionierendes IPv6 2026-08-03 07:02:31 +02:00
README.md fix: Admin-Dienste hinter dem VPN wieder korrekt prüfen 2026-08-03 06:55:32 +02:00

README.md

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
  1. /opt/check_status.py prüft alle Dienste und schreibt /opt/public/status.json
  2. 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.