fix(lemmy): the bundle starts, and the generated admin can log in (lemmy 1.0.4)

[kh0pper]

This replaces #510. #510 was stacked on #504, which has since been squash-merged to main (3a5c7be, together with #505). This PR has the same two Lemmy commits, rebased onto main with nothing from #504 repeated. The tree matches #510's head, so #510's live proof and reviews still apply. The details are in #510's description and comment; here is the summary.

Why Lemmy never started (checked against the pinned images)

1. The entrypoint ran exec /app/lemmy. dessalines/lemmy:0.19.17 has no /app: the binary is /usr/local/bin/lemmy_server, and the image runs as uid 1000.
2. The entrypoint wrote /config/config.hjson into ./config, which was mounted :ro.
3. Both health checks used wget, and neither image ships it (both have curl). Lemmy never became healthy, so lemmy-ui never started.
4. pict-rs runs as uid 991 on a host folder that the Docker daemon creates as root.
5. Config keys that 0.19 ignores (federation.enabled, captcha) and pict-rs 0.4 names that 0.5 ignores did nothing. tls_enabled: false gave http:// actor ids behind Caddy's https.

Fix

• Entrypoint: writes a mode-600 config into the container's own /tmp at every start, then exec lemmy_server.
• Hostname and secrets: these reach the script only through the environment. The hostname is checked to be a bare lowercase name, and a test runs the entrypoint's real pattern.
• Health checks: use curl.
• Data: Postgres and pict-rs data live in the project's own volumes.
• Config: holds only keys that 0.19 reads, with tls_enabled: true.
• Removed: LEMMY_FEDERATION_ENABLED and LEMMY_OPEN_REGISTRATION. These are site settings in 0.19.
• backup.sh: fails loudly instead of writing an empty archive.
• Version and registry: manifest 1.0.4, registry and skill ledger rebuilt.

Live proof (scratch home only; details in #510)

• Setup:
  • All data paths were in a scratch directory, and the run refused to start if any of them were under ~/.crow*.
  • The compose project had a unique name, used its own network, and published loopback-only ports.
  • An out-of-process deadman would have torn everything down.
  • The run was registered in the box schedule.
• Install path: the gateway's own install code ran in this order: generate secrets, save to the keychain first, write .env, then run checkBundleCompose, which returned {"valid":true}.
• Result:
  • All 4 containers came up healthy, and /api/v3/site returned 200.
  • Logging in with the admin password read back from the keychain returned a JWT with admin: true. A wrong password returned 401.
  • A pict-rs upload worked.
  • The secret did not appear in argv or the logs.
  • After a restart, the admin was not created again.
• Teardown: nothing was left behind.

Follow-ups (not fixed here)

• lemmy-ui does not proxy the API (404). The public site needs a split route to lemmy:8536, which caddy_add_federation_site can't express yet.
• The host-run MCP server can't resolve the default LEMMY_URL=http://lemmy:8536. The sibling federated bundles have the same pattern.

Licensing

• Lemmy, lemmy-ui and pict-rs are AGPL-3.0 (pict-rs is AGPL-3.0-only). Postgres uses the PostgreSQL License.
• They run as unmodified, separate containers, so Crow's MIT code is not affected.
• A hosted Crow offering that runs Lemmy for others must offer them the source of the Lemmy version it runs (AGPL §13).

Tests

• tests/lemmy-bundle.test.js (11 tests) and fix(bundles): the install security check reads what Compose applies, on every compose-up path; our own bundles pass it #508's tests/bundle-compose-gate.test.js pass. The full suite passed on the pre-rebase tree, which is identical.

https://claude.ai/code/session_01N9fXzvNy8rCEArj1y5p6fp