update: one command that updates a machine and cannot strand it

[myobie]

fabric update replaces this machine's fabric with a verified build, then re-renders the service and restarts it.

What it replaces

A shell script that lived on one machine and was base64-encoded across the wire to the others, plus two more copies of the same recipe in install.sh and the README. Each copy knew a trap the others did not. This is one copy, in the binary, with the traps as tests.

fabric update [--tag T] [--url U --sha256 H]
              [--check] [--dry-run] [--no-restart] [--rollback]

What it refuses

--url without --sha256 — installing bytes nobody checked is remote code execution with good manners, and there's nothing sensible to default to. Two sources at once. An archive that isn't exactly one member named fabric. A staged binary whose --version disagrees with the tag that promised it. Every refusal happens before anything is moved.

--check has three exit states, not two

0 up to date, 1 update available, 2 error. The error path is special-cased in main rather than left to propagate — propagating would exit 1, and a fleet sweep would read an unreachable release server as work to do.

What the checksum does and does not do

With --url and an explicit hash it proves the bytes are the ones the caller named. On the release paths the sidecar comes from the same server as the artifact, so it catches corruption and truncation and not a compromised release. A test fails if that wording disappears from --help, because "verify" reads as security to whoever arrives next.

Two traps carried over from the shell script

It installs at the path the service manager runs, read from the plist or ExecStart, not from $PATH. Installing at the wrong one leaves the daemon on the old binary while --version reports the new.

On Linux the restart supervises itself. Nothing outside can reach a machine whose daemon is down — fabric exec stops working and the tool that would repair it is the tool that broke it. A transient unit runs the rollback binary, the copy already proven to work there, waits for the control socket, and puts the old binary back if the daemon doesn't return. It can't run in the updating process, which dies with the cgroup.

A bug I almost shipped

Found by reading, not by a failing test. service::install renders the unit from env::current_exe(), so re-rendering during an update would have pointed the daemon at whatever binary ran the update — a target/debug build while testing. That's the wrong-path trap entered from the other side. install_at now takes the exe explicitly, and a test asserts the rendered unit names the binary it was given and specifically not the one rendering it.

And a test that was proving nothing

The ./fabric case was passing against an archive that said fabric, because tar::Builder normalises the name on the way in. It now builds a 512-byte header by hand and asserts the fixture really carries the dot-slash before testing anything.

I also claimed in a comment that comparing raw bytes fixed a bug there. Mutating the code back proved it did not — the crate normalises on write, not read, and both forms reject it. The comparison stays as belt and braces, and the comment says so. A flattering explanation of a change is worse than none.

Verified on Silber, against the real release server

--check	up to date, exit 0
--check --tag <older>	update available, exit 1
--check --tag <nonexistent>	exit 2
--dry-run	binary byte-identical, no temp files left
--url file:///…	local artifact fetched, hashed, unpacked
--url with no hash / wrong hash	refused, nothing touched

Full suite green: 267 lib, plus every integration target including the new update one, which is wired into CI as the #76 guard requires.

Dependencies

tar and flate2 are new. reqwest, rustls and sha2 were already compiled under iroh, so naming them costs no crates; the reqwest feature pin keeps aws-lc-rs out from beside the ring provider iroh already uses.

Builds on #80.

Agent: Silber.fabric