tritonadm self-update and channel

tritonadm self-update replaces the running tritonadm binary with the one the signed release channel advertises for this binary's target triple. tritonadm channel revisions lists the sealed revisions of a channel, which are the identifiers --revision accepts.

tritonadm self-update

Replace this tritonadm binary from the signed release channel. The command takes no positional arguments.

Options

Option	Default	Effect
--channel-url <URL>	none	Use this manifest URL verbatim. Wins over --channel.
--channel <NAME>	stable	Expand a channel name to https://tritoncloud.nyc3.digitaloceanspaces.com/channels/<NAME>.json.
--revision <REV>	none	Retarget the resolved URL to that revision's frozen snapshot.
--install-dir <DIR>	directory of the running executable	Directory the binary is swapped into.
--check	off	Report installed against candidate and exit. Downloads and replaces nothing.
--image-dir <DIR>	none	Self-update from a local tritonadm-<STAMP>.tar.gz instead of the channel. Conflicts with --channel-url, --channel, and --revision.

All options are long form. There are no short forms.

What the command does

On the channel path, in this order:

1. Resolves the channel URL from --channel-url, --channel, and --revision.
2. Fetches the manifest and its detached signature at <CHANNEL_URL>.minisig.
3. Verifies the signature against the publisher public key compiled into the binary.
4. Parses the manifest, refusing any manifest whose schema field is above 1.
5. Looks up the manifest's tritonadm entry for this binary's target triple. The triple is baked in at compile time as TRITONADM_TARGET, not detected at run time.
6. Prints the installed stamp and the candidate stamp and size. Equal stamps end the run here.
7. Downloads the candidate tarball and verifies its SHA-256 against the signed manifest entry.
8. Extracts the tarball, requires a tritonadm binary at its top level, and sets mode 0755.
9. Swaps the binary into the install directory.

The stamp comparison is equality, not ordering. Pinning --revision to an older sealed revision installs the older binary.

Output

The two status lines are printed on every run before any download starts:

installed: <INSTALLED_STAMP>
candidate: <CANDIDATE_STAMP> (<SIZE> bytes)

When the stamps match, one further line is printed and the command exits without touching the disk:

already up to date

After a successful swap:

tritonadm updated at <INSTALL_DIR>/tritonadm
previous binary preserved at <INSTALL_DIR>/tritonadm.prev (manually delete when satisfied)

Exit status

--check exits zero when the installed stamp equals the candidate stamp, and non-zero otherwise, with this message:

tritonadm is outdated (installed <INSTALLED_STAMP>, candidate <CANDIDATE_STAMP>)

--check still fetches the manifest and verifies its signature, so it fails on an unreachable channel or a signature that does not verify.

Binary swap and rollback

Three paths inside the install directory take part in the swap.

Path	Role
<INSTALL_DIR>/tritonadm.new	Staging copy of the new binary, mode 0755.
<INSTALL_DIR>/tritonadm.prev	The binary that was live before this run. A stale .prev is deleted first.
<INSTALL_DIR>/tritonadm	The live binary. Replaced by renaming tritonadm.new over it.

tritonadm.prev survives until the next self-update overwrites it. Nothing deletes it automatically, so a bad release is rolled back by renaming that file back over tritonadm without re-fetching anything.

When no binary exists at <INSTALL_DIR>/tritonadm, the swap logs a warning and installs the new binary fresh.

Local artifacts with --image-dir

--image-dir <DIR> reads the newest tritonadm-<STAMP>.tar.gz in DIR. Stamps sort chronologically, so the highest stamp wins. Files that do not match that exact prefix and suffix are ignored, including sibling agent tarballs such as tritonagent-<STAMP>.tar.gz.

This path performs no signature check and no SHA-256 check. It compares the filename's stamp against the running binary's build stamp, then extracts and swaps. The candidate line names the file instead of a byte count:

candidate: <CANDIDATE_STAMP> (<PATH_TO_TARBALL>)

When the directory holds no matching tarball, the command fails:

no tritonadm-<stamp>.tar.gz in --image-dir <DIR>

tritonadm channel revisions

List a channel's sealed revisions, newest first, and mark the one the moving channel pointer currently advertises. revisions is the only subcommand of tritonadm channel.

Options

Option	Default	Effect
--channel-url <URL>	none	Use this manifest URL verbatim. Wins over --channel.
--channel <NAME>	stable	Expand a channel name to its canonical manifest URL.

The command reads the revision index that sits beside the channel pointer, then reads the pointer itself to learn which revision is current. Reading the pointer is best effort: a channel that has never been sealed still lists its index, without a current line.

Output

The listing is printed in this shape. One line per sealed revision, oldest last:

channel: <CHANNEL_NAME>
current: <REVISION>

=== revisions (newest first) ===
  <REVISION>  sealed=<PUBLISHED_AT>  by=<PUBLISHER>  <- current
  <REVISION>  sealed=<PUBLISHED_AT>  by=<PUBLISHER>

Field	Source
channel	The channel field of the revision index.
current	The revision field of the channel pointer manifest. Omitted when the pointer carries none.
<REVISION>	A revision id, equal to the build stamp it was sealed under. This is the value --revision takes.
sealed=	The revision's published_at timestamp.
by=	The revision's publisher string.
<- current	Marks the revision the pointer advertises.

Channel URL resolution

Both commands resolve the manifest URL the same way, highest priority first:

1. --channel-url <URL>, used verbatim.
2. --channel <NAME>, expanded to https://tritoncloud.nyc3.digitaloceanspaces.com/channels/<NAME>.json.
3. The default channel, stable, expanded the same way.

--revision <REV> then rewrites the resolved URL by replacing the trailing .json with /<REV>.json. A base URL that does not end in .json is returned unchanged. channel revisions does not accept --revision.

The resulting URLs follow this scheme, where <BASE> is https://tritoncloud.nyc3.digitaloceanspaces.com/channels:

Object	URL
Channel pointer	<BASE>/<CHANNEL>.json
Pointer signature	<BASE>/<CHANNEL>.json.minisig
Frozen revision snapshot	<BASE>/<CHANNEL>/<REVISION>.json
Snapshot signature	<BASE>/<CHANNEL>/<REVISION>.json.minisig
Revision index	<BASE>/<CHANNEL>/index.json
Index signature	<BASE>/<CHANNEL>/index.json.minisig

A frozen snapshot is a complete manifest, signed by the same key as the pointer, so pinning to a revision changes no other behavior.

Channel names

--channel accepts any name and expands it to a URL. Two names are published by CI.

Channel	Published from	Contents
edge	pushes to main	Rolling pre-release.
stable	tags matching v*	Released builds. Present only after a tagged build.

stable is the default when neither --channel nor --channel-url is given. Each CI publish seals its build stamp as a revision, writing the frozen snapshot, updating the pointer, and recording the revision in the index.

CI publishes one tritonadm entry per build, for the x86_64-unknown-illumos target. A binary built for another target triple finds no entry and fails.

Signature and integrity verification

Every channel fetch in tritonadm performs two independent checks.

Check	Applies to	Mechanism
minisign signature	The channel manifest and the revision index	Verified against the publisher public key compiled into the binary with include_str! from cli/tritonadm/publisher.pub.
SHA-256	The downloaded tritonadm tarball	Compared against the sha256 field of the already-verified manifest entry.

The committed publisher key is a minisign public key with key id 6A95AFF9C8B898E7.

Expected SHA-256 values must be exactly 64 lowercase hexadecimal characters. Uppercase or mixed case is rejected as malformed rather than normalized, so a comparison failure always means the bytes differ.

The bootstrap script install.sh verifies the artifact's SHA-256 against the manifest it fetched over TLS, and does not check the minisign signature. Running tritonadm self-update --check after a bootstrap install is the path that enforces the publisher signature.

self-update builds its own blocking HTTPS client with no timeout overrides. The channel fetch path used by install, update, and channel revisions uses the host-resources client, which disables the whole-request timeout and sets a 30-second connect timeout. Both clients trust the bundled webpki-roots certificate set rather than a system trust store, because the SmartOS global zone has no system CA bundle.

Channel manifest fields

The manifest schema version this release understands is 1.

Field	Meaning
channel	Channel name, for example edge or stable.
schema	Schema version. A manifest above 1 is refused.
updated_at	When this snapshot was published.
publisher	Identifier of the operator or pipeline that signed the snapshot.
revision	Revision id this snapshot was sealed under. Absent on a channel that has never been sealed.
images	Zone images, keyed by image name.
agents	Global-zone tarball artifacts, keyed by agent name.
services	Zone-resident service binaries, keyed by service name.
tritonadm	tritonadm tarballs, keyed by Rust target triple.

Each entry under tritonadm carries four fields.

Field	Meaning
stamp	Build stamp in YYYYMMDDTHHMMSSZ form, compared against the running binary's compile-time stamp.
url	URL of the tarball.
sha256	Lowercase hex SHA-256 of the tarball.
size_bytes	Size of the tarball, printed on the candidate: line.

The revision index carries channel, schema, updated_at, and a revisions array sorted oldest first. Each element carries revision, published_at, and publisher.

Error messages

Message	Condition
channel signature did NOT verify against publisher pubkey	The manifest's detached signature failed verification.
revision index signature did NOT verify against publisher pubkey	The revision index's signature failed verification.
channel manifest schema is <N>, this client only understands up to 1; update your client and retry	The manifest declares a newer schema.
channel has no tritonadm entry for target <TARGET>	The manifest carries no entry for this binary's compile-time target triple.
tritonadm is outdated (installed <A>, candidate <B>)	--check found differing stamps.
downloaded tarball sha256 does NOT match channel manifest	The downloaded bytes do not match the signed manifest entry.
tarball did not contain a `tritonadm` binary at the top level	The extracted archive has no top-level tritonadm.
no tritonadm-<stamp>.tar.gz in --image-dir <DIR>	--image-dir holds no matching tarball.
GET <URL> -> <STATUS>	An HTTP fetch returned a non-success status.

Relationship to tritonadm update

tritonadm update tritonadm and tritonadm update --all delegate to the same self-update code, passing the run's resolved channel URL or --image-dir and leaving --install-dir at its default. tritonadm is last in the --all order because it replaces the running binary.

Two behaviors differ inside an update run. The self-update action is not counted in the "updates available" total, and it does not trigger the confirmation prompt, because the swap is reversible through tritonadm.prev. Under tritonadm update --check, the tritonadm component is reported as an instruction rather than being checked:

  tritonadm: run `tritonadm self-update --check` (self-update replaces the running binary)

With --image-dir, that instruction carries the directory. An --image-dir run whose directory holds no tritonadm tarball reports not in --image-dir; skip.

See also

• tritonadm command index
• tritonadm install
• tritonadm setup
• Updates and channels
• Bootstrap tritonadm