kometa: a nightly scheduled run against plex, its credentials as files

Conversation 2 Commits 2 Files Changed 1

+66

2 Commits

Author	SHA1	Message	Date
jschoubben	2ee77de706	kometa: dial plex on the scheme plex-api serves The url's scheme was typed as http while its host and port came from the binding. plex now serves plex-api with its scheme (#162), so the whole address is the mesh's: a plex that one day serves https is followed rather than dialled on the wrong protocol.	2026-09-30 12:55:34 +02:00
jschoubben	7ad255d71a	kometa: a nightly scheduled run against plex, its credentials as files ace runs Kometa under HAL as a long-lived container whose own scheduler wakes at 03:00, with the Plex token and the TMDb key in its environment (KOMETA_PLEX_TOKEN, KOMETA_TMDB_APIKEY). This is the case ADR 0053 was written for: the module is one container marked "schedule": "0 3 * * *" that runs kometa --run to completion, so nothing stays up between runs. Secrets are files (ADR 0086): config.yml is rendered by the mesh, 0600 and root-owned (Kometa runs as root), with ${secret:plex-api} and ${secret:tmdb} in it, and mounted read-only. KOMETA_READ_ONLY_CONFIG stops Kometa writing its defaults back into it (without it the run dies on EROFS); the file already carries every attribute Kometa filled in on ace, so behaviour is unchanged. Plex is reached through provisioning, not a URL: kometa requires plex-api and reads ${bound:plex-api:at\|port}; the token is that pair's credential, which the operator accepts (ADR 0092). The provider half (plex provides and serves plex-api, 32400) is NOT in this change: plex is outside this work, so until plex declares it kometa cannot be assigned. The TMDb key is an operator-accepted vault secret. Which libraries Kometa manages is per machine: the manifest ships "libraries": {}, and config.yml is the module's one merge:json file, so the assignment supplies them (ace: the Formula 1 library, whose metadata file comes from f1-circuits' public name). Verified: catalogue tests with MESH_CATALOGUE pointed here, on mesh-controller main and on #149; a resolution with stub providers renders the binding, the two secret files and config.yml with the assignment's library merged in; the pinned digest (the one ace runs, 2.4.8) in a throwaway container with the rendered file root-owned 0600 read-only: config parses, the "endpoints" key is tolerated, no write-back with the read-only flag, and the run stops only at TMDb refusing the dummy key.	2026-09-30 11:57:42 +02:00

Author

SHA1

Message

Date

jschoubben

2ee77de706

kometa: dial plex on the scheme plex-api serves

The url's scheme was typed as http while its host and port came from the
binding. plex now serves plex-api with its scheme (#162), so the whole
address is the mesh's: a plex that one day serves https is followed rather
than dialled on the wrong protocol.

2026-09-30 12:55:34 +02:00

jschoubben

7ad255d71a

kometa: a nightly scheduled run against plex, its credentials as files

ace runs Kometa under HAL as a long-lived container whose own scheduler wakes
at 03:00, with the Plex token and the TMDb key in its environment
(KOMETA_PLEX_TOKEN, KOMETA_TMDB_APIKEY). This is the case ADR 0053 was written
for: the module is one container marked "schedule": "0 3 * * *" that runs
kometa --run to completion, so nothing stays up between runs.

Secrets are files (ADR 0086): config.yml is rendered by the mesh, 0600 and
root-owned (Kometa runs as root), with ${secret:plex-api} and ${secret:tmdb}
in it, and mounted read-only. KOMETA_READ_ONLY_CONFIG stops Kometa writing its
defaults back into it (without it the run dies on EROFS); the file already
carries every attribute Kometa filled in on ace, so behaviour is unchanged.

Plex is reached through provisioning, not a URL: kometa requires plex-api
and reads ${bound:plex-api:at|port}; the token is that pair's credential,
which the operator accepts (ADR 0092). The provider half (plex provides and
serves plex-api, 32400) is NOT in this change: plex is outside this work, so
until plex declares it kometa cannot be assigned. The TMDb key is an
operator-accepted vault secret.

Which libraries Kometa manages is per machine: the manifest ships
"libraries": {}, and config.yml is the module's one merge:json file, so the
assignment supplies them (ace: the Formula 1 library, whose metadata file
comes from f1-circuits' public name).

Verified: catalogue tests with MESH_CATALOGUE pointed here, on mesh-controller
main and on #149; a resolution with stub providers renders the binding, the
two secret files and config.yml with the assignment's library merged in; the
pinned digest (the one ace runs, 2.4.8) in a throwaway container with the
rendered file root-owned 0600 read-only: config parses, the "endpoints" key is
tolerated, no write-back with the read-only flag, and the run stops only at
TMDb refusing the dummy key.

2026-09-30 11:57:42 +02:00

kometa: a nightly scheduled run against plex, its credentials as files #159