From 9c8a62f9fe3f795980590b787734f1ef7ec359a8 Mon Sep 17 00:00:00 2001 From: Frank Date: Wed, 16 Sep 2026 07:24:54 -0700 Subject: [PATCH] =?UTF-8?q?hermes:=20restore=20the=20LAN=20bind=20?= =?UTF-8?q?=E2=80=94=20reverting=20my=20own=20regression?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. --- .../hermes/quadlet/hermes-webui.container | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/dankclaw/hermes/quadlet/hermes-webui.container b/dankclaw/hermes/quadlet/hermes-webui.container index b69c27b..f58c905 100644 --- a/dankclaw/hermes/quadlet/hermes-webui.container +++ b/dankclaw/hermes/quadlet/hermes-webui.container @@ -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