ARIA
68bdc0968f
README dokumentierte den seit 19.07.2026 pflichtigen Dashboard-Auth-Block (HERMES_DASHBOARD_USER/PASSWORD_HASH, dashboard.basic_auth in config.yaml) noch gar nicht - neuer Setup-Schritt 4, Schritt 7/8 umnummeriert, Architektur- Diagramm und Sicherheitshinweis auf den 0.0.0.0-Dashboard-Stand gebracht. Nebenbei echten Bug gefunden: .env.example und config.yaml.example sagten, den Passwort-Hash per 'docker exec hermes-agent-dashboard' zu erzeugen - aber genau dieser Container startet ohne bereits gesetztes HERMES_DASHBOARD_PASSWORD_HASH gar nicht (docker-compose :?-Pflichtvar). Hash muss gegen 'hermes-agent' erzeugt werden, der teilt sich das Image ohne die Pflicht-Var.
58 lines
3.1 KiB
Plaintext
58 lines
3.1 KiB
Plaintext
# Hermes Agent Model-Config — zeigt auf UNSEREN Claude-Max-Proxy statt auf
|
|
# OpenRouter/Nous Portal/direkte Provider-Keys.
|
|
#
|
|
# WICHTIG: das ist NICHT die volle ~/.hermes/config.yaml (die hat noch
|
|
# hunderte weitere optionale Blöcke — terminal, toolsets, memory, etc., siehe
|
|
# hermes-agent-src/cli-config.yaml.example fürs Referenz-Full-File). Diese
|
|
# Datei hier enthält bewusst NUR den model:-Block. Hermes seedet beim ersten
|
|
# Container-Start automatisch alle fehlenden Felder aus seinen eingebauten
|
|
# Defaults (Stage2-Hook: seed_one() kopiert cli-config.yaml.example NUR wenn
|
|
# config.yaml noch nicht existiert — diese Datei hier gewinnt also, wird
|
|
# NICHT überschrieben, solange sie schon liegt).
|
|
#
|
|
# ${HERMES_GATEWAY_PORT} / ${HERMES_GATEWAY_TOKEN} werden von Hermes selbst
|
|
# beim Config-Laden aus den Container-Env-Vars expandiert (nicht von Docker
|
|
# Compose) — die kommen im hermes-agent-Service aus .env durch. Deshalb hier
|
|
# NICHT hardcoden, auch nicht "zum Testen".
|
|
model:
|
|
# sonnet/opus/haiku werden vom Proxy-Adapter (proxy-patches/openai-to-cli.js,
|
|
# MODEL_MAP) auf die claude --model Flags gemappt. Unbekannte Namen fallen
|
|
# dort automatisch auf "opus" zurück.
|
|
default: "sonnet"
|
|
|
|
# "custom" = jeder OpenAI-kompatible Endpoint, der nicht einer der
|
|
# named Provider (openrouter/nous/anthropic/...) ist — genau unser Fall.
|
|
provider: "custom"
|
|
|
|
# localhost, weil Hermes Agent laut Stefan auf DERSELBEN Maschine läuft wie
|
|
# unser hermes-gateway (network_mode: host im hermes-agent-Service).
|
|
base_url: "http://localhost:${HERMES_GATEWAY_PORT}/v1"
|
|
|
|
# Gateway prüft das als "Authorization: Bearer <api_key>" — der OpenAI SDK
|
|
# (den Hermes intern nutzt) setzt den Header automatisch aus diesem Feld.
|
|
api_key: "${HERMES_GATEWAY_TOKEN}"
|
|
|
|
# ─── Dashboard-Auth ─────────────────────────────────────────────────────
|
|
# Seit 19.07.2026 Pflicht: Hermes verweigert den Bind des Dashboards auf
|
|
# 0.0.0.0 komplett, wenn kein Auth-Provider registriert ist ("Refusing to
|
|
# bind dashboard to 0.0.0.0 — the auth gate engages on non-loopback binds,
|
|
# but no auth providers are registered"). Ohne diesen Block bindet's nur
|
|
# noch auf 127.0.0.1 (Tunnel), egal was im docker-compose `command:` steht.
|
|
#
|
|
# Hash EINMALIG erzeugen (NICHT das Klartext-Passwort committen oder in .env
|
|
# schreiben — nur den Hash). Gegen den "hermes-agent"-Container, NICHT
|
|
# "hermes-agent-dashboard" — der braucht HERMES_DASHBOARD_PASSWORD_HASH schon
|
|
# zum Hochfahren (Henne-Ei-Problem: ohne Hash kein Start, ohne laufenden
|
|
# Container kein Hash). "hermes-agent" teilt sich dasselbe Image und laeuft
|
|
# auch ohne den Wert:
|
|
# docker exec -it hermes-agent python -c \
|
|
# "from plugins.dashboard_auth.basic import hash_password; print(hash_password('DEIN-PASSWORT'))"
|
|
# Ergebnis nach .env als HERMES_DASHBOARD_PASSWORD_HASH eintragen.
|
|
#
|
|
# ${HERMES_DASHBOARD_USER} / ${HERMES_DASHBOARD_PASSWORD_HASH} werden wie
|
|
# oben von Hermes selbst aus den Container-Env-Vars expandiert.
|
|
dashboard:
|
|
basic_auth:
|
|
username: "${HERMES_DASHBOARD_USER}"
|
|
password_hash: "${HERMES_DASHBOARD_PASSWORD_HASH}"
|