tools/release-gate.sh is the one gate: a fresh install, and the upgrade
from what canary and stable serve, each on a room of that channel, plus
any older release rooms are still on (RELEASE_GATE_FROM). The releases it
upgrades from are fetched over HTTPS and checked against their manifests,
so it needs no credential and a CI runner can run it.
update_canary.sh VERSION PACKAGE gates and publishes that file without
rebuilding it, since a second build is a second, untested file; the hash
is taken before the gate and checked after it. update_stable.sh VERSION
SHA256 refuses anything but the file that was approved.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
0.2.6.1 is a maintenance release of 0.2.6. The build refused four
parts, update_canary.sh's automatic bump could not add one to "6.1", and
neither publish script would have noticed a version being published
twice — which is what happened to 0.2.6 this morning: it was rebuilt
with the Presentations hardening and uploaded over the first 0.2.6, and
a room that had installed the first can never be offered the second.
One release library now holds the version pattern (three or four parts,
no leading zeros, no .0 maintenance), orders by dpkg --compare-versions,
refuses a version that has ever been published or is not newer than all
of them, uploads with --ignore-existing and checks the server's
checksum, writes a manifest only for a package the server holds, and
reads the channel back over HTTPS afterwards. update_canary.sh takes the
version explicitly; update_stable.sh refuses to go backwards.
The classroom updater refuses a manifest whose version, package name or
checksum is malformed, and refuses a download whose own control file is
not the version the manifest promised, so a room can never loop on
reinstalling and rebooting.
tests/test-release-versions.sh: 87 checks against a stand-in server and
real dpkg. The Trixie gate now also rehearses a stable room: 0.2.2 to an
interim 0.2.6.1 upgraded with settings, channel and Presentations=false
intact, and the installed updater answering correctly.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
https://updates.riverofglorymn.org/stable/latest.debhttps://updates.riverofglorymn.org/canary/latest.deb
A symlink beside each channel's manifest, pointing at the versioned
package the manifest names. Deliberately not a second record of which
version is current — the manifest stays the only answer to that, and the
publish scripts derive the pointer from it rather than from anything they
know themselves.
The versioned files are never rewritten. A release uploads its package,
then the manifest, then swaps the pointer by rename. Atomic, so nothing
downloads a half-written pointer; and last, so the pointer can lag the
manifest by a moment and can never lead it. A pointer that led the
manifest would offer a package the channel had not published.
Both latest.deb and manifest.json are served no-store on the update
server. Cloudflare sits in front of it and caches .deb by extension, so
without that header a room could be handed the previous release from an
edge for hours. The versioned packages keep no such header because they
are immutable and worth caching.
The server change is one matcher in the Caddyfile's updates block, and it
took three attempts to land for a reason worth recording: the Caddyfile is
a FILE bind mount, so `mv` over it replaces the inode and the container
goes on serving the old one. Two apparently successful reloads changed
nothing. It is written through the mount now, and the host copy is
identical so the next container restart is a no-op. Caddy was reloaded,
never restarted; the church's other sites were not interrupted.
Installing from a channel URL still does not move a machine onto that
channel. CHANNEL in device.conf decides which manifest the updater
follows, and the postinst only appends settings that are missing, so
fetching the canary package by hand to repair a machine leaves it on
stable.
Verified end to end against the live server: both URLs deliver bytes whose
sha256 matches their channel's manifest, both carry the no-store header,
and the versioned package does not.
Co-Authored-By: Claude Opus 5 <[email protected]>
