dsh-web
| Repo | box/github.com/opencharly/pod-dsh:v2026.279.1210 |
Serves the DeepSeek Harness web Web UI (port 3080) as a supervised
service. The web app binds 127.0.0.1:3080 ONLY — dsh-web-app
0.2.0-rc.2 hard-rejects –host 0.0.0.0 (RCE safety) — so a
charly-owned entrypoint runs dsh web in the background and
exec’s a socat forwarder that listens on the container’s eth0
(0.0.0.0:3081) and forwards to loopback. socat cannot share port
3080 (Linux forbids a wildcard + loopback pair on one port), so the
published port (auto-allocated host port -> container 3081) reaches
the web UI on the pod substrate. The web UI authenticates every
request: each process mints a random launch token and dsh web
prints it in its dsh web: http://127.0.0.1:3080/?token=...
readiness line. The entrypoint captures that token and persists it
to $DSH_HOME/web-token (on the dsh volume, so it survives the fresh
charly update rebuild), and the in-box checks authenticate with
curl "http://127.0.0.1:3080/?token=$(cat $DSH_HOME/web-token)".
Every fact is observable: the running service, the persisted token
file, and the HTTP 200 the token-authenticated web UI answers on
127.0.0.1:3080.
Packages
Section titled “Packages”Installed on every distro:
socat
Services
Section titled “Services”dsh
Acceptance plan
Section titled “Acceptance plan”This candy’s plan: — the runnable spec charly check executes against a live deployment. check: steps are idempotent probes; run: steps change state.
| Intent | Step |
|---|---|
run |
mkdir=${HOME}/.local/bin |
run |
copy=dsh-entrypoint |
check |
the dsh service is running under the init system |
check |
the token-authenticated dsh web UI answers on 127.0.0.1:3080 in-box |
check |
the socat forwarder relays the token-authenticated dsh web UI on 127.0.0.1:3081 in-box |
check |
the published port reaches the dsh web UI and enforces its auth fence (401 without a token) |