novox/mesh-catalog

sonarr: its config dir is placed, its image is the one ace runs #157

Closed

mesh-admin wants to merge 7 commits from feat/sonarr-for-ace into main

Author	SHA1	Message	Date
jschoubben	28b756f1c9	sonarr: reach nzbget, qbittorrent and jackett through the mesh sonarr reached its download clients as nzbget:6789 and qbittorrent:8112 and its indexers through jackett:9117 or indexers.zurag.be - HAL container names and a public route, typed into its database by hand. Nothing on the mesh answers those names. It now requires nzbget-api, qbittorrent-api and jackett-api. A run-once step (downloads/, declared last, restart-on its bindings, credentials and settings) writes host, port, TLS, base path, user and credential into sonarr through sonarr's own API: - A download client is the mesh's when its name is downloads.<provision>.name and its kind the provider's; it is registered when missing. A jackett feed is the mesh's when its host is the bound one, one the step bound before, or one in downloads.jackett-api.adopt-hosts; the jackett indexers in downloads.jackett-api.indexers are registered when missing. Every other entry is left alone, and nothing is ever deleted. - Only connection fields, only when they differ. The stored password is masked, so the app tests the entry with the credential it holds; only if that fails is the delivered one written. Categories, priorities and "enabled" are never touched. - Each credential is tried against its provider first. A minted value (nothing accepted yet) is never written; the step exits 1 naming the exact secret accept. The step is byte-identical in sonarr, radarr, lidarr and bookshelf (the same Servarr API, v3 or v1): each module builds from its own directory, so each carries a copy, and test/downloads.test.ts fails if a sibling's copy differs. Verified: strict typecheck, the Dockerfile build, 14 unit tests; and the compiled step against fresh pinned sonarr/radarr/lidarr/bookshelf with throwaway nzbget, qBittorrent and jackett - minted credentials refused with nothing written, accepted ones registered and tested by the app, a migration-shaped radarr repointed, reruns unchanged.	2026-09-30 13:07:10 +02:00
jschoubben	d543defae6	sonarr: its config dir is placed, its image is the one ace runs The manifest named /services/sonarr/config and /var/lib/mesh/sonarr/route.json, host paths ADR 0112 takes out of definitions. The config dir is now a pathless ${dir:config} (0700, 1000:1000) mounted into the server and, read-only, into the runtime that reads the API key from config.xml; the route binding lives in a placed state dir, as jackett and searxng do. /var/lib/mesh/sonarr stays for the broker secret. The image is pinned to 4.0.20.3014-ls325, the digest ace runs today. The old pin (4.0.19.2979-ls322) was older than the running version, and Sonarr migrates its database forward on start, so pointing the older build at ace's data is not safe. The container mount points stay /series, /anime and /downloads: Sonarr's database stores its root folders and the download clients' reported paths under exactly those names, and there are no remote path mappings to absorb a change. The generic access paths stay; ace's (/storage/media/*, /storage/downloads) and its media owner 1001:2000 wait on hq 153. Based on feat/servarr-api-provision (#156), which makes sonarr provide sonarr-api. Verified: catalogue key tests with MESH_CATALOGUE set (73 manifests parsed, not skipped); a throwaway container of the pinned image on a fresh 0700 1000:1000 config dir answers /ping, serves the v3 API with the key it generated and refuses a wrong one (401), accepts /series as a writable root folder; the runtime's client discovers the key from that config.xml and reads the queue.	2026-09-30 11:53:43 +02:00
jschoubben	f14c763463	ombi: reach sonarr, radarr and lidarr through the mesh ombi keeps its Servarr connections in its own database, so the mesh has no file to write them into. A run-once step reads the three bindings and pair credentials and writes host, port, TLS, base path and key into ombi through ombi's own API - only when they differ, and nothing else ombi keeps. Until the operator accepts an app's key for this pair the mesh delivers a value it minted, which no Servarr app accepts. The step tries the key against the app first and, refused, writes nothing and fails naming the secret accept that fixes it, so the old working key in ombi is never replaced by a dead one. Declared last so its failing gates nothing else of ombi (ADR 0136), and restart-on its six inputs so it runs again when a provider moves (ADR 0099).	2026-09-30 00:39:19 +02:00
jschoubben	ab44ff02e1	sonarr, radarr, lidarr: provide their API to the mesh A consumer on another machine (ombi first; jackett, bazarr and home-assistant later) reached these by container name on HAL's shared network, which the mesh does not have. Each app now provides <app>-api at mesh scope and serves the software port, so the mesh tells a consumer where it is and redirects the port to where the machine published it. Named per app, not one servarr-api: a requirement is matched by name and answered by exactly one provider per node, so a consumer cannot require one name from three providers - and ombi's code is written against each app's own API version (ADR 0027). No grants and no provisioner: a Servarr instance has one API key, which the mesh cannot mint. The operator accepts it as the pair credential for each consumer (ADR 0092).	2026-09-30 00:39:19 +02:00
jschoubben	c4c44efb1b	Merge remote-tracking branch 'origin/fix/sidecars-dial-the-port-they-were-given' into feat/servarr-api-provision	2026-09-30 00:25:55 +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
jschoubben	21f5301268	ombi: its config is placed, its image is the one ace runs ombi's definition named /services/ombi/config (a HAL machine path) in three places and pinned an image older than the one ace runs. Ombi migrates its own SQLite schema, so a take onto the older pin (v4.53.10-ls267) would start it on a database the newer build (ls269) already touched. - config is a pathless placed directory, mounted as ${dir:config} - a state directory placed at the assignment root carries route.json - image pinned to the digest ace runs today (v4.53.10-ls269) - the sidecar reaches ombi on the machine port the mesh assigns (${port:3579}) rather than assuming 3579 is free - the sidecar no longer mounts ombi's data directory: MESH_OMBI_CONFIG_DIR is read by no code, and the mount exposed the databases for nothing Verified: catalogue tests (MESH_CATALOGUE set, 6 pass, none skipped); the pinned image starts as PUID 1000 in a 0700 dir and answers /api/v1/Status 200; data owned 1001:2000 (ace's media ids) under a 1000:1000 dir is re-owned by the image's init and serves 200; a minted ApiKey is refused (401) - the api-key secret must be accepted from ombi's own settings.	2026-09-29 23:38:56 +02:00