# 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)

```bash
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:
  ```bash
  scp -o ProxyJump=root@103.241.51.104 <datei> root@103.241.51.192:<pfad>
  ```

### 2. Passwort-Fallback über kasm

Von kasm aus:

```bash
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:**

1. **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.
2. **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.
3. **fail2ban** gestoppt + disabled (war nicht die Ursache, aber als zusätzliche
   Fehlerquelle für IP-Bans ausgeschlossen) — kein IP-Ban mehr möglich.
4. **`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