dtourolle
6c0c80f20b
DR-015, DR-016. §8 already shipped a static binary and an optional container; this adds the third form, and it packages the SAME binary the musl job proved static rather than building its own. Two builds of the same commit could diverge, and the whole point of that assertion is that the artifact an operator installs is the one that was checked. Built with dpkg-deb from an explicit staging tree rather than cargo-deb. debconf's `config` script and `templates` live in the control archive next to the maintainer scripts, and controlling that archive directly beats discovering what a wrapper will copy into it. dpkg-dev is on every Debian builder, so this adds no build dependency. Why debconf at all: two settings fail SILENTLY when unset. Without JRAY_TMDB_API_KEY every upload stays `pending` and is never listed; without JRAY_TRUSTED_PROXIES the X-Forwarded-For header is ignored, so every client shares one rate-limit bucket and every abuse report points at the proxy. Both leave a server that works and is quietly doing the wrong thing — the worst thing to leave to a README nobody reads. Three properties, each a way packaging usually goes wrong: The generated config is NOT a dpkg conffile. It is written from the debconf answers, so shipping it as one would make dpkg prompt on every upgrade about changes the package itself had made. Hand edits survive. postinst rewrites only the keys debconf manages; comments, ordering and any other setting are left alone. A blank key on reconfigure keeps the existing one. Otherwise pressing Enter through a dpkg-reconfigure would unpublish every future upload. The seeding guard is worth its comment, because the obvious version is wrong twice over. `config` seeds unanswered questions from the env file so a reconfigure shows what is actually in force. Seeding unconditionally overwrites a preseed — debconf-set-selections marks what it sets as seen — so every unattended install would quietly reconfigure itself back to whatever was on disk. Guarding on an empty value does not work either: server-id and bind carry template Defaults, so db_get returns "localhost" for a question nobody answered. The test is the `seen` flag, which is the actual question being asked. Purge keeps the database, knowingly departing from the expectation that purge removes everything. Manifests are the output of real CV compute on media the operator may no longer have, and §8 says federation is explicitly not a backup. Destroying that during an `apt purge` is not a trade worth making for tidiness; postrm names the path instead. The nginx example is documentation, not installed configuration. The proxy usually runs on a different host from the server, so a file dropped into this machine's nginx would be in the wrong place — and §8 leaves the edge to the operator deliberately. Verified by running it, not by reading it: a full lifecycle in a bookworm container — build, preseeded install, mode-600 env file, key absent from debconf's database afterwards, `systemd-analyze verify` on the unit, the installed binary answering /health and /ready, reconfigure preserving both the key and an unmanaged setting, and purge leaving the database. It failed on the seeding bug above the first time, which is why that guard exists. CI runs the same checks against every build. TRACES: DR-015, DR-016 | PR-004
65 lines
2.7 KiB
Plaintext
65 lines
2.7 KiB
Plaintext
Template: jray-server/server-id
|
|
Type: string
|
|
Default: localhost
|
|
Description: Public hostname of this JRay server:
|
|
Identifies this instance in federation (SPEC section 9a) and is recorded on
|
|
every manifest it originates, so peers can tell whose judgement they are
|
|
replicating.
|
|
.
|
|
Use the name operators will reach you on, for example jray.example.org.
|
|
Leaving it as "localhost" is fine for a private trial and wrong for anything
|
|
federated.
|
|
|
|
Template: jray-server/bind
|
|
Type: string
|
|
Default: 127.0.0.1:8080
|
|
Description: Address and port to listen on:
|
|
The server speaks plain HTTP and expects TLS to be terminated by your reverse
|
|
proxy (SPEC section 8).
|
|
.
|
|
Keep the default if the proxy runs on this same host. If the proxy is
|
|
elsewhere - a separate container or VM, which is the common case - this must
|
|
be an address that host can reach, for example 0.0.0.0:8080. Firewall the
|
|
port to the proxy if you do that: the default is loopback precisely so an
|
|
unconfigured install is not reachable.
|
|
|
|
Template: jray-server/trusted-proxies
|
|
Type: string
|
|
Description: Trusted reverse proxy addresses (comma-separated):
|
|
Rate limiting and abuse-report attribution both key on the client IP, so
|
|
X-Forwarded-For is honoured only from addresses listed here. A header trusted
|
|
unconditionally would let any client mint itself a fresh rate-limit budget and
|
|
pin its reports on someone else.
|
|
.
|
|
If the proxy runs on this host, enter 127.0.0.1. If it runs elsewhere, enter
|
|
the address it connects from - not the address you reach it on.
|
|
.
|
|
Leaving this empty is safe but coarse: X-Forwarded-For is then ignored
|
|
entirely and every request is attributed to the proxy, so all clients share
|
|
one rate-limit bucket.
|
|
|
|
Template: jray-server/tmdb-api-key
|
|
Type: password
|
|
Description: TMDB API key:
|
|
Uploaded manifests are cross-checked against the TMDB cast list before being
|
|
published (SPEC section 6, stage 3). Without a key the server still serves
|
|
reads normally, but every upload stays in "pending" and is never listed -
|
|
the correct failure mode, but a silent one.
|
|
.
|
|
Leave blank to configure later with: dpkg-reconfigure jray-server
|
|
If a key is already configured, leaving this blank keeps it.
|
|
|
|
Template: jray-server/contact
|
|
Type: string
|
|
Description: Operator contact (optional):
|
|
Published so other operators can arrange peering out of band. An email
|
|
address or a URL. Leave blank to publish no contact.
|
|
|
|
Template: jray-server/publish-peer-directory
|
|
Type: boolean
|
|
Default: false
|
|
Description: Publish this server's peer directory?
|
|
Section 9a makes this deliberately optional: publishing lists the peers you
|
|
replicate from, which discloses your federation topology. A server that would
|
|
rather not disclose it simply does not, and federation still works.
|