The manifest named /services/qbittorrent/config and /var/lib/mesh/qbittorrent/
config.json, host paths ADR 0112 takes out of definitions. The config dir is now
pathless (${dir:config}); the runtime's config and route binding live in a
placed state dir.
The image is pinned to 5.2.3_v2.0.14-ls477, the digest ace runs; the old pin
(ls474) was older than the running build.
The tools could not log in to qBittorrent 5.2: it answers a good login with 204
and no body (not 200 "Ok.") and names its cookie QBT_SID_<port> (not SID). The
client now accepts both shapes and sends the cookie back under the name it was
set. It also read the user as "admin" always; it now reads WebUI\Username from
qBittorrent.conf on the read-only config mount.
qBittorrent refuses a request whose Host header names a port other than the one
it listens on. With the mesh publishing 8080 on another machine port, the tools
and every consumer dialling that port were refused. The WebUI now listens on
8112 (WEBUI_PORT, ace's and HAL's number, and clear of unifi's 8080) and is
published on the same number. The torrent port 6881 tcp+udp was not declared at
all; it is now, long-form, because the client announces it to peers.
sonarr, radarr and lidarr reached it by container name on HAL's shared network.
qbittorrent now provides qbittorrent-api (node scope: a download client must share
the consumer's spool) and serves scheme, port, url-base and username; the
password is the operator-accepted pair credential, as for #156. The web endpoint
is routed (label qbittorrent). The runtime dials ${port:8112}, as #154 does.
Verified: catalogue tests with MESH_CATALOGUE set (not skipped); rendered for ace
with pins and without (8112:8112, 6881:6881, 6881:6881/udp either way); a
throwaway of the pinned image on an ace-shaped conf showed the port-mismatch
refusal, then on a same-number port the compiled client logged in, read the user
from qBittorrent.conf, listed torrents and was refused a wrong password and the
default user; strict typecheck and the Dockerfile build pass.
The six modules that run a mesh-<mod> tool-runtime sidecar read an app
credential from an env var the manifest never provided, so the sidecar
crash-looped in the whole-mesh dry-run (e.g. "no Plex token — set
MESH_PLEX_TOKEN"). These are operator-set app secrets, so deliver them the
same way cloudflare-dns delivers its API token: an own-secret file mounted
read-only, with a MESH_<APP>_*_FILE env pointing at the mount, and the
runtime code preferring that file (falling back to the existing env so
nothing regresses).
- plex: own-secret token -> /run/secrets/token, MESH_PLEX_TOKEN_FILE
- bazarr: own-secret api-key -> /run/secrets/api-key, MESH_BAZARR_API_KEY_FILE
- ombi: own-secret api-key -> /run/secrets/api-key, MESH_OMBI_API_KEY_FILE
- home-assistant: own-secret token -> /run/secrets/token, MESH_HOMEASSISTANT_TOKEN_FILE
- nzbget: own-secret password -> /run/secrets/password, MESH_NZBGET_PASSWORD_FILE (URL stays plain env)
- qbittorrent: own-secret password -> /run/secrets/password, MESH_QBITTORRENT_PASSWORD_FILE (URL stays plain env)
The operator now completes each with `secret accept <node> <module> <name> --from <file>`.
tsc passes for all six.
Nineteen modules gain a broker-bound runtime container that serves the module's
tools under its own scoped account: bazarr, gitea, grafana, home-assistant,
icecast, influxdb, jackett, keycloak, mailu, nextcloud, nodered, nzbget, ombi,
photos, portainer, qbittorrent, searxng, tautulli, verdaccio.
Config is the assignment's, not the manifest's (ADR 0051): each client's fromEnv
overlays a settings-merged config file (MESH_<M>_CONFIG_FILE) over its env
fallbacks, so URL and credentials come from `settings set`, with the URL defaulting
to the server on the node. nextcloud and mailu also mount the docker socket for
their exec-based tools.
Proven in the mesh-lab: assigned-grafana green — settings deliver the URL and token,
the runtime reads the merged config and serves grafana's tools under the scoped
account, with nothing in the manifest. Two gaps this surfaced are filed as hq
issues 008 (a provider runtime's seal key) and 009 (a settings change does not
restart a container runtime).
Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF
nzbget (usenet, JSON-RPC) and qbittorrent (torrents, WebUI API with manual SID
session). Tools: status, queue/torrents, add, pause/resume, delete. Both poll
and emit module.<app>.download.added and module.<app>.download.completed — the
key plex consumes to rescan; completion is keyed off real success (nzbget
history SUCCESS, qbittorrent progress reaching 1), not mere queue disappearance,
so a failed or deleted item is not reported as done. Typecheck; manifests parse.
jschoubben