novox/mesh-catalog

qbittorrent: placed config, the build ace runs, a login 5.2 accepts, its ports as announced #168

Closed

mesh-admin wants to merge 4 commits from feat/qbittorrent-for-ace into main

Author	SHA1	Message	Date
jschoubben	52578737f0	Merge remote-tracking branch 'origin/fix/sidecars-dial-the-port-they-were-given' into feat/qbittorrent-for-ace # Conflicts: # modules/qbittorrent/module.json	2026-09-30 13:18:00 +02:00
jschoubben	412d7bc377	qbittorrent: it listens on the port the mesh gave it, rather than fixing it The manifest published 8112:8112 and 6881:6881 because qBittorrent refuses a Host naming another port and announces its torrent port to peers — so the machine port must equal the software's. Fixing the number in the manifest states a machine port in a definition. Instead the server runs on the host network and listens where the mesh put it (WEBUI_PORT=${port:8112}, TORRENTING_PORT=${port:6881}): the two are equal by construction on every machine, and an assignment still pins 8112/6881 where clients know them. Verified: the pinned image on the host network with WEBUI_PORT=18710 and TORRENTING_PORT=18711 served the web UI on 18710 (200, no Host mismatch) and listened for peers on 18711 tcp+udp.	2026-09-30 12:32:16 +02:00
jschoubben	5012f61b00	qbittorrent: placed config, the build ace runs, a login 5.2 accepts, its ports as announced 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.	2026-09-30 12:00:41 +02:00
jschoubben	5cc6258326	Sidecars dial the port they were given, not the software's A host-network sidecar reaches its service over the machine's loopback, and the mesh publishes that service on a machine port it assigns (ADR 0038) — so dialling the software's port reaches whatever else holds it. On ace, searxng's sidecar dialled 127.0.0.1:8080 and got unifi's inform port. The same shape in bazarr, bookshelf, lidarr, nzbget, qbittorrent, radarr and sonarr; each now asks with ${port:N} (hq 088). Found in review of ace's module preparation.	2026-09-29 23:50:19 +02:00