swarm-matrix-ctl appservice render now reads the registration's tokens from the store and renders swarm.yaml under /run/swarm-matrix-appservice, which tuwunel loads through LoadCredential. It mints a pair only when the store answers and holds none; a host that has the old files stores their pair once instead. A store that does not answer fails the unit and keeps tuwunel down; sync starts it once the store answers. Refs #4998 (item 3)
1.6 KiB
swarm-matrix-ctl
The rust that runs inside containers.hive-matrix, beside the homeserver.
One binary with subcommands rather than one binary per job. Running code in that container is not free: it needs its own store identity, its own cert role and its own bind mounts, and every one of those is per-container, not per-task. A second single-purpose crate would have had to duplicate that plumbing to add one action, so the next thing that has to run in here is a verb, not a new crate.
Verbs
appservice render
Renders the swarm appservice registration tuwunel loads from the store's tokens
onto the container's tmpfs, minting a pair only when the store answers and holds
none. Runs before the homeserver, which stays down while the store does not
answer. Tokens an earlier version kept in the container's /var/lib are stored
first when the store holds none; the files stay, unused.
appservice sync
The store holds the registration's tokens. This rewrites the rendered copy
when they differ, restarts the homeserver whenever the registration is
newer than its last start, and publishes the as_token for swarm-controller.
It runs the same reconciliation as render, and starts a homeserver that
failed because render could not reach the store.
Both are configured entirely by the MATRIX_APPSERVICE_* environment the units
set — no flags. A systemd Environment= block is what a nix module can render; a
command line full of paths is not.
🩸 A secret is a path, never a value
Nothing here logs, prints or interpolates a token. The one identifier this binary logs is the store path it wrote.