docs(hermes,dns): document the new internal-only exposure surface
Post-change doc reconciliation for the hermes vhosts + DNS deletion batch: - Hermes-Dashboard.md: access is now the hermesadmin.franksdank.cloud vhost (direct Caddy proxy to 192.168.0.143:9119, no guard chain — exempt because the dashboard enforces its own basic-auth login), plus the raw LAN port. The old text claimed an Authentik-guarded public vhost, which was decommissioned. - Hermes-WebUI.md: description updated — the webui is now also reachable via the unguarded hermes.franksdank.cloud vhost (its own password auth is the gate). - LAN-DNS.md: "add a name in two places" corrected to a two-or-three-step decision; internal-only names (prometheus/loki/grafana/seerr) deliberately get no public A record and resolve on the LAN only, and DNS-01 issuance is unaffected because the challenge is a TXT record in the same zone. - Seerr.md: DNS row corrected — addn-hosts only since 2026-09-02; NXDOMAIN on WAN. - hermes-dashboard.container: unit comment no longer claims Authentik termination. No behavior change in this commit; tests 233/233 green (docs-completeness seam included).
This commit is contained in:
Frank
@@ -2,7 +2,7 @@
|
||||
|
||||
The Hermes web dashboard is a browser UI for managing the agent. It shows config, API keys, and sessions. It is a management tool. It is not a chat window. Chat happens over Signal or the CLI. See [[Hermes]].
|
||||
|
||||
**Host:** Dankclaw — **Port:** `9119` — **URL:** `http://192.168.0.143:9119`
|
||||
**Host:** Dankclaw — **Port:** `9119` (published) — **URL:** `https://hermesadmin.franksdank.cloud` (internal-only; direct Caddy proxy, no guard chain) or `http://192.168.0.143:9119`
|
||||
|
||||
## Facts
|
||||
|
||||
@@ -47,7 +47,19 @@ The dashboard refuses to bind to a non-loopback address without an auth provider
|
||||
|
||||
## Access
|
||||
|
||||
Open `http://192.168.0.143:9119` in a browser on the LAN. Log in with the configured username and password.
|
||||
Two paths reach the same process, both gated by the dashboard's own basic-auth
|
||||
login — there is no unauthenticated bind:
|
||||
|
||||
1. **`https://hermesadmin.franksdank.cloud`** — Caddy vhost added 2026-09-02 that
|
||||
reverse-proxies `192.168.0.143:9119` directly, with **no** Anubis/Outpost guard
|
||||
chain in front of it (exempt-by-construction: the app carries its own complete
|
||||
auth). The name deliberately has no public DNS record, so the vhost resolves on
|
||||
the LAN only; WAN clients get NXDOMAIN. See [[LAN DNS]].
|
||||
2. **`http://192.168.0.143:9119`** — the raw published port. Still reachable from
|
||||
any LAN host (the container binds `0.0.0.0` inside its namespace and publishes
|
||||
`9119:9119`), so treat the LAN as a trusted boundary here, not as a gate.
|
||||
See [[Container Network Namespaces]] for why this container is on a bridge
|
||||
network rather than the host namespace like its two siblings.
|
||||
|
||||
## Gotchas
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
type: configuration
|
||||
title: Hermes-WebUI (Hermex server)
|
||||
description: The hermes-webui container on Dankclaw — the API server that the Hermex iPhone app talks to, reachable over an SSH tunnel and, because it binds all interfaces, from the whole LAN.
|
||||
description: The hermes-webui container on Dankclaw — the API server that the Hermex iPhone app talks to, reachable over an SSH tunnel, from the whole LAN (it binds all interfaces), and from https://hermes.franksdank.cloud (internal-only vhost).
|
||||
tags:
|
||||
- hermes
|
||||
- hermes-webui
|
||||
|
||||
@@ -14,7 +14,7 @@ Seerr is the unified request manager for the *arr stack (the maintained `seerr-t
|
||||
| Unit | `dankclaw/seerr/quadlet/seerr.container` → `seerr.service` |
|
||||
| Network | `dankclaw_default` (post-auth listener reachability) |
|
||||
| Guard | Caddy TLS edge → Anubis :8923 → Authentik outpost provider `seerr-proxy` → Caddy :8017 `@seerr` handler → `seerr:5055` |
|
||||
| DNS | Pi-hole addn-hosts + Porkbun public A `seerr.franksdank.cloud → 192.168.0.143` |
|
||||
| DNS | Pi-hole addn-hosts only. The public Porkbun A record was deleted on 2026-09-02, so the name resolves on the LAN (→ 192.168.0.143) and returns NXDOMAIN on the WAN: Seerr is internal-only by construction |
|
||||
|
||||
## Why loopback-only publishing
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ See [[Caddy]] for the reverse proxy that serves the names, and [[Network Archite
|
||||
|-----------|-------|------|
|
||||
| Pi-hole | Dankclaw quadlet (`dankclaw/pihole/`) | Answers the flat service names for LAN clients |
|
||||
| SURFboard G36 | 192.168.0.1 | Hands dnsmasq to clients as the DHCP DNS server |
|
||||
| Porkbun | Registrar for `franksdank.cloud` | Answers the same names for the WAN |
|
||||
| Porkbun | Registrar for `franksdank.cloud` | Answers the **public** names for the WAN; internal-only names have no public record and resolve only on the LAN |
|
||||
| Caddy | Dankclaw (192.168.0.143:443) | Serves every name over HTTPS |
|
||||
|
||||
## How a name reaches a client
|
||||
@@ -52,12 +52,24 @@ Pi-hole FTL is a dnsmasq fork. It serves the same `addn-hosts` file the retired
|
||||
- **Web UI:** `pihole.franksdank.cloud` (Caddy vhost → 8083), family login
|
||||
- **Deploy + restart after a change:** `./scripts/deploy-pihole-quadlet.sh dankclaw`
|
||||
|
||||
Add a new service name in two places:
|
||||
Adding a new service name is a two-or-three step decision — decide the exposure
|
||||
first, because it decides whether the name gets a public record at all:
|
||||
|
||||
1. `dankclaw/pihole/addn-hosts` — `192.168.0.143 <name>.franksdank.cloud`
|
||||
2. Porkbun — A record `<name> 71.227.227.172` (so WAN clients and the DNS-01 challenge work)
|
||||
1. `dankclaw/pihole/addn-hosts` — `192.168.0.143 <name>.franksdank.cloud` (always).
|
||||
2. **Public** name only: Porkbun A record `<name> 71.227.227.172`, so WAN clients
|
||||
resolve it too. An **internal-only** name deliberately gets no public record:
|
||||
the query falls through to the upstream resolvers, which answer NXDOMAIN for
|
||||
`franksdank.cloud` subdomains, so off-LAN clients cannot reach the vhost at all.
|
||||
3. Add the vhost to [[Caddy]] and run `./scripts/deploy.sh dankclaw`. See
|
||||
[[Pi-hole]] for the full configuration.
|
||||
|
||||
Then add the vhost to [[Caddy]] and run `./scripts/deploy.sh dankclaw`. See [[Pi-hole]] for the full configuration.
|
||||
Internal-only names as of 2026-09-02: `prometheus.`, `loki.`, `grafana.`
|
||||
(observability) and `seerr.` (the `*arr` request front-end). Their public A
|
||||
records were deleted from the Porkbun zone that day; each is still served by
|
||||
Caddy on the same name, so LAN clients see no change and WAN clients get
|
||||
NXDOMAIN. DNS-01 issuance is unaffected — Caddy's challenge is a TXT record in
|
||||
the same zone and needs no A record at all, which is why an internal-only vhost
|
||||
still gets a real Let's Encrypt certificate.
|
||||
|
||||
## G36 router DNS hand-off
|
||||
|
||||
|
||||
Reference in New Issue
Block a user