wartung: Dashboard-Token weg, alte Hermes-Umgebung ablösbar, Box-Units als Kopie

- Hermes-Dashboard: festes Session-Token der früheren Desktop-Anbindung wird nicht mehr gesichert oder zurückgespielt (liegt im Archiv auf der Box). Es bindet weiter an 0.0.0.0, weil Hermes seine Anmeldung auf 127.0.0.1 abschaltet; ufw hält 9119 zu (Kommentar in config.py nachgezogen). - Selbstreparatur und PC-Pfad-Skill nutzen das System-Python (hat PyYAML) statt der alten Hermes-venv; die steht jetzt samt Sicherung als Altrest im Aufräumen-Panel (Löschen per Klick, empfohlen nach dem Sonntagslauf). - deploy/nur-box/: Kopien der Units, die nur auf der Box leben (Hermes-Dashboard, llama-swap samt Drop-ins) — werden nicht ausgespielt. - Offene Fäden nachgezogen: Discard VM 106, Rückweg-Probe, AdGuard, Ausbauplan-Entscheide der Klärungsrunde. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-25 15:12:31 +02:00
parent 23cecd3abc
commit 18fb446aa9
14 changed files with 127 additions and 37 deletions
@@ -0,0 +1,21 @@
+# Units, die nur auf der Box leben — Kopien zum Nachlesen
+
+Stand 25.09.2026, abgezogen von der KI-Box. **`deploy.sh` spielt diese Dateien nicht aus**; die Wahrheit ist die Box.
+Sie stehen hier, damit man ohne SSH sieht, wie Hermes-Dashboard und llama-swap gestartet werden, und damit ein
+Wiederaufbau eine Vorlage hat. Jede Sicherung (`deploy/backup.sh`) nimmt die echten Dateien ohnehin mit.
+
+| Datei hier | Ort auf der Box |
+|---|---|
+| `hermes-builtin-ui.service` | `~/.config/systemd/user/hermes-builtin-ui.service` |
+| `hermes-builtin-ui.service.d-override.conf` | `~/.config/systemd/user/hermes-builtin-ui.service.d/override.conf` |
+| `llama-swap.service` | `/etc/systemd/system/llama-swap.service` |
+| `llama-swap.service.d-vulkan.conf` | `/etc/systemd/system/llama-swap.service.d/vulkan.conf` |
+| `llama-swap.service.d-warmset.conf` | `/etc/systemd/system/llama-swap.service.d/warmset.conf` |
+| `llama-swap.service.d-warmup.conf` | `/etc/systemd/system/llama-swap.service.d/warmup.conf` (ruft `/usr/local/bin/llama-swap-warmup.sh`, Vorlage `deploy/warmup.sh`) |
+
+Beim Hermes-Dashboard gilt der Drop-in, nicht die Kommentare der Basis-Unit: Es bindet an `0.0.0.0:9119`, weil Hermes
+seine Anmeldung auf `127.0.0.1` abschaltet; ufw hält den Port zu, erreichbar ist es nur über `/hermes-ui/` im
+Orchestrator. Seit 25.09.2026 startet es über den Starter der neuen Hermes-Umgebung (`hermes pm`), und das feste
+Session-Token der früheren Desktop-Anbindung ist weg.
+
+Die alte Unit `hermes-dashboard.service` (abgeschaltet, alte Umgebung) steht als Altrest im Aufräumen-Panel.
@@ -0,0 +1,19 @@
+[Unit]
+Description=Hermes Built-in Web UI (hermes dashboard — Agent-Dashboard/Chat, nur ueber MC2 /hermes-ui/)
+After=network-online.target
+Wants=network-online.target
+
+[Service]
+# Serviert die EINGEBAUTE Hermes-Web-GUI (die reiche Agent-Oberflaeche mit Threads/Tool-Calls) headless.
+# Erreichbar nur ueber den MC2-Reverse-Proxy (routers/hermes_ui.py → same-origin /hermes-ui/ auf Port 9001).
+# Der Drop-in override.conf bindet an 0.0.0.0, damit Hermes' Anmeldung greift (auf 127.0.0.1 schaltet Hermes
+# sie ab); ufw haelt 9119 zu. --skip-build nutzt das von deploy.sh mit Vite-base=/hermes-ui/ vorgebaute web_dist.
+# Seit 25.09.2026 ueber den Starter der neuen Hermes-Umgebung (hermes pm) statt der alten venv (3.11).
+Type=simple
+Environment=HERMES_HOME=%h/.hermes
+ExecStart=%h/.hermes/hermes-agent/.hermes/bin/hermes dashboard --no-open --skip-build --host 127.0.0.1 --port 9119
+Restart=always
+RestartSec=3
+
+[Install]
+WantedBy=default.target
@@ -0,0 +1,9 @@
+# Stufe 1 (20.08.2026), bereinigt 21.08. und 25.09.2026: Das Dashboard bindet nach aussen, damit
+# seine Anmeldung greift — auf 127.0.0.1 schaltet Hermes sie ab (hermes_cli/dashboard_auth: „no-op
+# on loopback“), dann waere es ueber MC2s /hermes-ui-Proxy ohne Login offen. Port 9119 ist in ufw ZU —
+# erreichbar nur ueber MC2 auf 9001. Zugangsdaten stehen NUR in config.yaml (dashboard.basic_auth).
+# Seit 25.09.2026 ueber den Starter der neuen Hermes-Umgebung (hermes pm, Python 3.14) statt des alten
+# venv (3.11); das feste Session-Token der frueheren Desktop-Anbindung ist weg (liegt im Archiv).
+[Service]
+ExecStart=
+ExecStart=%h/.hermes/hermes-agent/.hermes/bin/hermes dashboard --no-open --skip-build --host 0.0.0.0 --port 9119
@@ -0,0 +1,16 @@
+[Unit]
+Description=llama-swap (lokaler LLM Router)
+After=network-online.target
+Wants=network-online.target
+
+[Service]
+Type=simple
+User=hitonabi
+Environment=HSA_OVERRIDE_GFX_VERSION=11.5.1
+Environment=PATH=/usr/local/bin:/usr/bin:/bin
+ExecStart=/usr/local/bin/llama-swap --config /etc/llama-swap/config.yaml --listen 0.0.0.0:8080 --watch-config
+Restart=on-failure
+RestartSec=3
+
+[Install]
+WantedBy=multi-user.target
@@ -0,0 +1,2 @@
+[Service]
+Environment=LD_LIBRARY_PATH=/opt/llamacpp-vulkan
@@ -0,0 +1,8 @@
+[Service]
+# 25.07.2026 — KORREKTUR. Hier standen kurzzeitig "fast coder kritiker": das schob
+# ~35 s Modell-Laden VOR das Vorkauen von Hermes' Agenten-Prompt (warmup.sh warmt erst
+# alle Chat-Modelle, dann Embeddings, DANN den Agenten-Prompt). Der Tool-Smoke im
+# hermes-postcheck hat 90 s Limit und lief dadurch in die Zeitueberschreitung.
+# Der Coder waermt sich beim ersten Auftrag selbst (23 s einmalig, dann 90 min warm) —
+# Lucys Hirn und der Agenten-Prompt haben Vorrang.
+Environment=MC_WARMUP_MODELS=fast
@@ -0,0 +1,2 @@
+[Service]
+ExecStartPost=-/usr/local/bin/llama-swap-warmup.sh