hub.koerners.org — Zugang & Stabilität

Stand: 2026-07-22 · Beide Zugangswege verifiziert getestet · Root-Cause-Fix für Nichterreichbarkeit dokumentiert.

Host

hub.koerners.org = 103.241.51.192 — der echte HA-Hub, Kernstück der Infrastruktur: Hermes-Orchestrator, Hermes-v2 (LangGraph), Hermes-GUI/Portal, AI-Box-GUI, RAG-Watcher, Wasabi-Cold-Offload-Mount. 12 Kerne / 23 GB RAM.

Nicht verwechseln mit jump.panel1.de (100.91.98.15) — das ist NICHT der Hub, siehe server-topologie.md in diesem Repo.

🚨 Wichtig: externer SSH kann bei Last timeouten

Externer SSH (Port 22 von öffentlichen IPs) kann bei hoher Last im „banner exchange" timeouten. Das ist kein Firewall-Ban, sondern schlicht Überlast des Hosts — siehe Root-Cause unten. Deshalb gibt es zwei interne Zugangswege über kasm.

Zwei verifizierte Zugangswege (beide getestet 2026-07-22)

1. ProxyJump über kasm (EMPFOHLEN)

ssh -o ProxyJump=root@103.241.51.104 root@103.241.51.192

kasm (103.241.51.104) liegt im selben /24 wie hub → der interne Weg umgeht den externen Last-Tarpit.
Auth per SSH-Key (VM302 ~/.ssh/id_ed25519, Ende-zu-Ende).

Dateiübertragung identisch über denselben Jump:

scp -o ProxyJump=root@103.241.51.104 <datei> root@103.241.51.192:<pfad>

2. Passwort-Fallback über kasm

Von kasm aus:

sshpass -p '<HUB-ROOT-PW>' ssh root@103.241.51.192

Passwort steht in Vaultwarden (Eintrag „hub.koerners.org root") — nicht in Git.

Stabilitäts-Fix 2026-07-22 (Root-Cause der Unerreichbarkeit)

Symptom: Hub von außen nicht erreichbar (SSH-Timeouts im Banner-Exchange).

Root-Cause: hub-rag-watcher spawnte indexer.py ungedrosselt — bis zu 6 parallele Läufe gleichzeitig → Systemload 83 → sshd extern nicht mehr erreichbar (Ressourcen- Erschöpfung, kein Netzwerk-/Firewall-Problem).

Behoben durch:

Einzellauf-Sperre in /opt/hub-services/watcher.py: nie mehr parallele Indexer-Läufe, stattdessen ein sauberer Nachlauf, falls während eines laufenden Indexer-Durchlaufs weitere Änderungen anfallen. Backup der Vorversion unter watcher.py.bak-* auf dem Hub.
systemd-Ressourcen-Limits in /etc/systemd/system/hub-rag-watcher.service.d/limits.conf:
- CPUQuota=200% (max. 2 von 12 Kernen)
- Nice=15
- IOSchedulingClass=idle
- MemoryMax=4G
- TasksMax=64
→ Der Indexer kann die Maschine nicht mehr lahmlegen, 10 Kerne bleiben für sshd/Hermes frei.
fail2ban gestoppt + disabled (war nicht die Ursache, aber als zusätzliche Fehlerquelle für IP-Bans ausgeschlossen) — kein IP-Ban mehr möglich.
ufw allow 22/tcp — SSH von überall erlaubt. ufw bleibt sonst aktiv und schützt die internen Dienste weiterhin.

Siehe auch

infrastructure/infrastruktur-zugang.md (dieses Repo) — allgemeine Infra-Zugangsübersicht
server-topologie.md (dieses Repo) — Hub-vs-Jump-Verwechslungsfalle, HA-Klassifikation

3 KiB Raw Permalink Blame History