Files
hermes-agent/hermes-agent-config/config.yaml.example
T
ARIA b1423ffb6e Dashboard-Auth: Hermes-eigene Auth nicht mehr Pflicht, Caddy reicht
Dashboard bindet seit dem Caddy-Umbau nur noch auf 127.0.0.1 -- Hermes'
Auth-Gate engagiert sich laut eigener Fehlermeldung NUR bei einem
0.0.0.0-Bind, greift also gar nicht mehr. HERMES_DASHBOARD_PASSWORD_HASH
ist damit optional statt Pflicht (kein docker-compose-Abbruch mehr bei
leerem Wert), der dashboard: basic_auth-Block in config.yaml.example ist
standardmaessig auskommentiert. Caddy (TLS + eigene Basic-Auth) bleibt
die einzige im Normalbetrieb noetige Auth-Schicht. README/.env.example
entsprechend entschlackt -- Hash-Erzeugen + Dollarzeichen-Escaping nur
noch als Fallback dokumentiert, falls der Bind mal wieder auf 0.0.0.0
wandert.
2026-07-19 22:15:26 +00:00

59 lines
3.2 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 (standardmaessig AUSKOMMENTIERT) ────────────────────
# Hermes' eigenes Auth-Gate 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") — greift aber laut derselben Meldung
# NUR bei einem 0.0.0.0-Bind. Unser docker-compose.yml bindet das Dashboard
# bewusst auf 127.0.0.1 und stellt es per Caddy-Reverse-Proxy (TLS + eigene
# Basic-Auth) nach aussen bereit — das Gate hier engagiert sich dabei gar
# nicht erst, dieser Block ist im Normalbetrieb also NICHT noetig.
#
# Nur falls Du den Dashboard-Bind mal direkt auf 0.0.0.0 stellst (z.B. ohne
# Caddy testen): Block unten einkommentieren + HERMES_DASHBOARD_PASSWORD_HASH
# in .env setzen. 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 den Hash schon zum
# Hochfahren, Henne-Ei-Problem):
# 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.
#
# dashboard:
# basic_auth:
# username: "${HERMES_DASHBOARD_USER}"
# password_hash: "${HERMES_DASHBOARD_PASSWORD_HASH}"