ekklesiaandClaude Opus 5
886f8a70d2
https://updates.riverofglorymn.org/stable/latest.deb https://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]>
113 lines
4.5 KiB
Markdown
113 lines
4.5 KiB
Markdown
# Provisioning
|
|
|
|
Some things a classroom needs cannot be installed by the classroom
|
|
package itself: they need the network, and they need the apt lock that
|
|
dpkg is holding for the whole of the package's `postinst`.
|
|
|
|
`ekklesia-classroom-provision.service` runs after every boot and does
|
|
them. It is a `oneshot` unit that nothing else waits on, so it never
|
|
holds the classroom up, and **it is not allowed to fail the boot**: a
|
|
machine with no DVD codecs is still a working classroom.
|
|
|
|
The package `postinst` enables the service and schedules a delayed start after
|
|
the outer apt transaction has had time to release its lock. It never runs
|
|
provisioning synchronously inside dpkg. If an OTA reboot happens before the
|
|
delayed job, the enabled service runs normally on the next boot.
|
|
|
|
To provision without waiting for a reboot:
|
|
|
|
```
|
|
sudo classroom-provision
|
|
```
|
|
|
|
Each step checks whether it is already done and returns immediately if
|
|
so. A provisioned machine costs nothing; a machine that was offline the
|
|
first time gets another go at the next boot.
|
|
|
|
```
|
|
journalctl -u ekklesia-classroom-provision
|
|
```
|
|
|
|
## Google Chrome
|
|
|
|
Chrome is not in Debian and a classroom is not usable without it, so a
|
|
fresh machine installs it itself rather than waiting for someone to do it
|
|
by hand on every box.
|
|
|
|
`classroom-chrome-setup` adds Google's signing key to
|
|
`/etc/apt/keyrings/google-chrome.gpg` and their repository to
|
|
`/etc/apt/sources.list.d/google-chrome.list` — the same path Google's own
|
|
package manages, so the two cannot become two copies of the same
|
|
repository — then installs `google-chrome-stable`. Using the repository
|
|
rather than a one-off `.deb` means Chrome keeps getting security updates.
|
|
|
|
Run it by hand with `sudo classroom-chrome-setup`. It returns
|
|
immediately if Chrome is already installed.
|
|
|
|
The Chrome policies in `/etc/opt/chrome/policies/` are shipped by the
|
|
classroom package and apply as soon as Chrome exists.
|
|
|
|
## DVD codecs
|
|
|
|
Only for rooms with `DVD_ENABLED=true`. See [dvd.md](dvd.md).
|
|
|
|
## Networking and printing
|
|
|
|
NetworkManager and CUPS are Debian package dependencies, not deferred network
|
|
provisioning steps. Their services are enabled by the package and neither
|
|
requires Internet access or hardware to be present.
|
|
|
|
- Wi-Fi administration: [networking.md](networking.md)
|
|
- Church color printer setup: [printing.md](printing.md)
|
|
|
|
The printer helper is part of every provisioning pass. It is capped at 30
|
|
seconds and only configures the local scheduler, so an offline Ricoh cannot
|
|
hold boot or provisioning open. Failures are logged and retried on the next
|
|
boot. A correctly configured queue is a quick no-op.
|
|
|
|
## What provisioning does not do
|
|
|
|
The boot provisioning command never upgrades or reconfigures anything already installed, and it
|
|
never touches a repository it did not add. Classroom software updates
|
|
are the OTA channel's job, not this.
|
|
|
|
## Permanent download addresses
|
|
|
|
```
|
|
https://updates.riverofglorymn.org/stable/latest.deb
|
|
https://updates.riverofglorymn.org/canary/latest.deb
|
|
```
|
|
|
|
One address per channel that never changes. Each is a symlink beside that
|
|
channel's manifest, pointing at the versioned package the manifest names,
|
|
so there is still exactly one record of which version is current — the
|
|
manifest. Nothing here is a second version database.
|
|
|
|
The versioned files under `/packages/` are never rewritten. A release
|
|
uploads its package, then the manifest, then swaps the pointer by rename.
|
|
Renaming is atomic, so nothing downloads a half-written pointer, and
|
|
going last means `latest.deb` can lag the manifest by a moment but can
|
|
never lead it: it will never offer a package the channel has not
|
|
published.
|
|
|
|
`latest.deb` and `manifest.json` are served `no-store, no-cache,
|
|
must-revalidate`. That header matters more than it looks: Cloudflare sits
|
|
in front of this server and caches `.deb` by extension, so without it a
|
|
room could be handed the previous release from an edge for hours. The
|
|
versioned packages are deliberately left cacheable — they are immutable.
|
|
|
|
**Installing from a channel URL does not move a machine onto that
|
|
channel.** `CHANNEL` in device.conf is the only thing that decides which
|
|
manifest the updater follows, and the package's postinst only ever
|
|
appends settings that are missing. Downloading the canary package to fix
|
|
a machine by hand leaves it on stable, and the next automatic update
|
|
brings it back to stable.
|
|
|
|
Verify a download against the channel it came from:
|
|
|
|
```
|
|
curl -fsSL -o c.deb https://updates.riverofglorymn.org/canary/latest.deb
|
|
sha256sum c.deb
|
|
curl -fsS https://updates.riverofglorymn.org/canary/manifest.json
|
|
```
|