Hermes' eigenes Auth-Gate (dashboard.basic_auth/HERMES_DASHBOARD_PASSWORD_HASH) engagiert sich laut eigener Fehlermeldung ohnehin nur bei einem 0.0.0.0-Bind, der Dashboard-Container bindet aber fest auf 127.0.0.1 -- das Gate haette hier nie gegriffen. Statt es als "Fallback falls Bind mal wieder wandert" zu behalten, jetzt sauber raus: HERMES_DASHBOARD_PASSWORD_HASH aus .env.example und docker-compose.yml, der auskommentierte dashboard:-Block aus config.yaml.example, README-Setup auf 8 statt 9 Schritte umnummeriert. Caddy (TLS + eigene Basic-Auth) ist damit die einzige noetige Auth-Schicht -- ein Layer statt zwei, weniger Setup, weniger Verwirrung. Stale Kommentare im Caddy-Compose-Block (redeten noch von "zweiter Basic-Auth-Schicht noetig weil unklar ob dashboard.basic_auth greift") ebenfalls korrigiert.
43 lines
2.3 KiB
Plaintext
43 lines
2.3 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}"
|
|
|
|
# Kein dashboard.basic_auth-Block mehr hier: Hermes' eigenes Auth-Gate
|
|
# engagiert sich laut eigener Fehlermeldung nur bei einem 0.0.0.0-Bind. Das
|
|
# Dashboard bindet in docker-compose.yml fest auf 127.0.0.1 (command:), der
|
|
# Caddy-Reverse-Proxy davor (TLS + eigene Basic-Auth) uebernimmt die
|
|
# komplette Absicherung nach aussen. Falls der Dashboard-Bind je wieder auf
|
|
# 0.0.0.0 gestellt wird, blockt Hermes den Start hart ab ("no auth providers
|
|
# are registered") — das ist dann ein Signal, den Bind zurueckzustellen statt
|
|
# hier einen Auth-Provider nachzuruesten.
|