77 lines
3 KiB
Markdown
77 lines
3 KiB
Markdown
# 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
|