Files

T

Worph 39f82e1f96 Import the MetaMesh app family from Worph/AppStore

23 apps (MetaCore, the library/network/client tiers and 13 MetaFeeder*)
move out of the general-purpose Worph/AppStore into their own store so the
MetaMesh family releases on its own cadence.

- asset URLs repointed to cdn.jsdelivr.net/gh/Worph/MetaAppStore@main
- store scaffolding added (category/recommend/featured lists, licence,
  contributing, gitattributes)
- psd-source/meta-icons-v2 icon generator follows the apps

MetaMCP stays in Worph/AppStore: it is third-party metatool-ai software,
not part of MetaMesh.

2026-09-13 16:18:29 +00:00

2.6 KiB

Raw Blame History

MetaFeeder · Prowlarr — Rationale

What deviation / exception is being requested

metafeederprowlarr-feeder runs user: 0:0.

Why it is necessary

The feeder publishes its resolved records to the shared MetaCore over HTTP and writes its own service registration and plugin artwork through MetaCore's WebDAV endpoint. Those writes land in directories created and owned by MetaCore's root-running container; a uid-1000 process is refused. The feeder image also runs a small supervised process group (fetcher + enrichment plugin clients) that expects to be able to signal its children.

Security mitigations in place

Public ingress terminates at the AppShield sidecar (ghcr.io/yundera/appshield:2.0.9), which gates every path behind the PCS's Authelia SSO over OIDC. The feeder carries no Caddy labels and publishes no host port, so it is reachable only from the pcs Docker network.
The container mounts no user directories — not /DATA/Documents, /DATA/Downloads, /DATA/Media or /DATA/Gallery. Its only bind is its own state under /DATA/AppData/metafeederprowlarr/, declared in x-compose-app.folders and owned $PUID:$PGID.
cpu_shares set on every service; image tags pinned; no :latest.
The enrichment sidecars (-filename-parser, -tmdb) run unprivileged — no user: field, so Yundera starts them as $PUID:$PGID. -filename-parser is on the app-private metafeederprowlarr bridge only; -tmdb also joins pcs because MetaCore calls back into it, and it carries an app-prefixed container_name so it cannot collide with another app's service in the shared DNS namespace. Neither carries Caddy labels or publishes a host port.

Alternatives considered and rejected

Run as $PUID:$PGID. Writes into MetaCore's root-owned /meta-core tree and through its WebDAV endpoint fail, and the feeder starts but silently publishes nothing.
Have MetaCore relax the ownership of its shared directory. That would loosen permissions for every MetaMesh app at once, which is strictly worse than one root container with no user-data mounts.
Drop privileges after startup inside the image. Upstream change; tracked, not available in the shipped image.

Data protection

The feeder holds no user media. Its entire state — configuration, cursor position, and (where applicable) the TMDB cache — lives under /DATA/AppData/metafeederprowlarr/, which is the unit Maison archives on uninstall and restores from backup, so an uninstall/reinstall with "keep user data" resumes where it left off rather than re-indexing from scratch.

2.6 KiB Raw Blame History