dank/serverAppConfigs
1
0
Fork 0
Code Issues 6 Pull Requests Actions Packages Projects Releases Wiki Activity

hermes: restore the LAN bind — reverting my own regression

Browse Source 
I tightened HERMES_WEBUI_HOST to 127.0.0.1 on the reasoning that the compose
service had published loopback and the unit had widened it. That reasoning
missed the consumer: this unit is host-networked (it shares the CDP daemon's
loopback), so Caddy cannot reach it by container name and fronts the guarded
vhost hermes.franksdank.cloud with `reverse_proxy 192.168.0.143:8787` — recorded
in dankclaw/Caddyfile with the same explanation. With the app on loopback that
upstream is dead, so the vhost broke.

The wildcard bind is what serves BOTH consumers: Caddy on the LAN address and
the phone's SSH tunnel on the host's localhost. Controls are the auth chain in
front of the vhost plus the webui password. The unit comment now states this
instead of the incorrect 'as before' claim, and the near-miss is worth the
paragraph: the e2e gate stayed green because no spec covers that vhost.
This commit is contained in:
Frank
2026-09-16 07:24:54 -07:00
parent aaa1f82313
commit 9c8a62f9fe
1 changed files with 11 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
dankclaw/hermes/quadlet/hermes-webui.container
+11 -8
View File
@@ -14,13 +14,16 @@
# daemon binds loopback-only in the host network namespace (see
# chrome-devtools-protocol.container). Only processes sharing that namespace
# can drive the browser; a bridge-network client could not reach it at all.
# The server binds LOOPBACK (HERMES_WEBUI_HOST=127.0.0.1). Host networking
# means there is no Podman port forwarder, so the bind IS the exposure: the
# compose service this replaced published 127.0.0.1:8787:8787, and the first
# version of this unit bound 0.0.0.0 instead, which put the phone-facing API on
# the whole LAN with only the password in front of it (measured 2026-09-16:
# 192.168.0.143:8787 answered 200). The SSH tunnel (phone -> Dankclaw:22) dials
# localhost:8787 from the host, so loopback serves it exactly as well.
# The server binds 0.0.0.0:8787 of the host netns, and that is deliberate:
# this unit is host-networked (the CDP daemon above needs a shared loopback), so
# Caddy cannot reach it by container name and fronts the guarded vhost
# hermes.franksdank.cloud with `reverse_proxy 192.168.0.143:8787` (see the
# hermes block in dankclaw/Caddyfile, which records the same constraint). A
# loopback bind was tried on 2026-09-16 for a tighter posture and broke that
# vhost, because a bind is also the only way an off-host process can reach a
# host-networked container: the LAN address and the tunnel's localhost hop are
# both served by the wildcard, and a loopback-only bind serves only the latter.
# Controls are the auth chain in front of the vhost plus the password.
[Unit]
Description=Hermes webui (Hermex) container
@@ -31,7 +34,7 @@ Image=localhost/hermes-agent:latest
Pull=never
Network=host
EnvironmentFile=/home/dank/serverAppConfigs/dankclaw/.env
Environment=HERMES_WEBUI_HOST=127.0.0.1
Environment=HERMES_WEBUI_HOST=0.0.0.0
Environment=HERMES_WEBUI_PORT=8787
Environment=HERMES_WEBUI_PASSWORD=${HERMES_WEBUI_PASSWORD}
Environment=HERMES_HOME=/data