Install the tritonadm CLI
tritonadm is the operator CLI. The rest of the installation runs through
it. The bootstrap script install.sh downloads the tritonadm build for
this host's operating system and architecture from the release channel. The
script verifies the SHA-256 of the download against the channel manifest and
extracts the binary.
Before you start
The script supports four platform pairs. It reads uname -s and uname -m
and maps them to a Rust target triple and a default install directory.
uname -s / uname -m | Target triple | Default install directory |
|---|---|---|
SunOS / i86pc | x86_64-unknown-illumos | /opt/triton/bin |
Darwin / arm64 | aarch64-apple-darwin | $HOME/.local/bin |
Darwin / x86_64 | x86_64-apple-darwin | $HOME/.local/bin |
Linux / x86_64 | x86_64-unknown-linux-gnu | $HOME/.local/bin |
For any other pair the script exits with
install.sh: unsupported platform: <OS>/<ARCH>.
The host also needs these tools on PATH:
curl. The script exits ifcurlis missing.- A tar. The script prefers
gtar. It uses plaintarwhen thattaraccepts-C. Otherwise the script changes directory in a subshell and extracts there. - One SHA-256 tool. The script tries them in this order:
sha256sum,gsha256sum,shasum(asshasum -a 256),digest(asdigest -a sha256). With none of them present the script exits withinstall.sh: no sha256 tool found (need one of: sha256sum, gsha256sum, shasum, digest). jqis optional. Withoutjq, anawkparser reads the channel manifest.
The release pipeline publishes tritonadm for x86_64-unknown-illumos
only. When the channel has no entry for the resolved target triple, the
script exits with install.sh: channel has no tritonadm entry for <TARGET>.
Run the bootstrap script
On the founder, in the global zone, as root:
curl -fsSL https://tritoncloud.nyc3.digitaloceanspaces.com/install.sh | TRITON_CHANNEL=edge sh
TRITON_CHANNEL=edge is required today. The script defaults to stable,
and no stable channel has been published. The default fetch returns 404,
and the script then prints the edge form of the command.
The script prints ==> progress lines as it fetches the channel manifest,
downloads the tarball, verifies the SHA-256, and extracts the binary into the
install directory. It exits non-zero on the first failure. A SHA-256 mismatch
reports both the expected and the computed digest.
Read the script before you pipe it to a shell
Download the script, read it, and run it as a separate step. Read the channel URL it resolves and the verification it performs. On the founder, as root:
curl -fsSL https://tritoncloud.nyc3.digitaloceanspaces.com/install.sh -o install.sh
less install.sh
sh install.sh
Select a channel
stable is the released channel. The publisher builds it from v* tagged
builds. edge is the rolling pre-release channel. The publisher builds it
from the main branch. The script defaults to stable, which exists only
after a tagged build has run.
Set the channel on the shell that runs the script, not on curl.
Three environment variables change what the script does.
| Variable | Default | Effect |
|---|---|---|
TRITON_CHANNEL | stable | Channel name. Expands to https://tritoncloud.nyc3.digitaloceanspaces.com/channels/<NAME>.json. |
TRITON_CHANNEL_URL | derived from TRITON_CHANNEL | Full manifest URL, for an air-gapped mirror or an alternate publisher. Takes precedence over TRITON_CHANNEL. |
TRITON_INSTALL_DIR | /opt/triton/bin on illumos, $HOME/.local/bin elsewhere | Directory the tarball extracts into. The script creates it with mkdir -p. |
The publisher updates edge on every main-branch build, so the build that
edge installs changes without notice. tritonadm self-update --revision <REVISION>
pins a sealed snapshot instead. See Updates and channels.
When the platform image has no trust store
A fresh platform image may have no CA bundle. Then curl cannot complete a
TLS handshake, and the script fails with:
curl: (77) error adding trust anchors from file: /etc/ssl/certs/ca-certificates.crt
This failure affects only the bootstrap. tritonadm uses the Mozilla roots
that are compiled into the binary. To install a CA bundle you need the TLS
that is broken. Instead, download the binary on a host where TLS works, and
pin it by hash.
On a workstation:
curl -fsSL https://tritoncloud.nyc3.digitaloceanspaces.com/channels/edge.json
curl -fsSL -o tritonadm.tar.gz https://tritoncloud.nyc3.digitaloceanspaces.com/tritonadm/<STAMP>-x86_64-unknown-illumos.tar.gz
shasum -a 256 tritonadm.tar.gz
scp tritonadm.tar.gz root@<FOUNDER>:/var/tmp/
Read <STAMP> and the expected sha256 from the tritonadm entry for
x86_64-unknown-illumos in the manifest. Stop if the digest you computed
differs.
On the founder, as root:
digest -a sha256 /var/tmp/tritonadm.tar.gz
mkdir -p /opt/triton/bin
tar xzf /var/tmp/tritonadm.tar.gz -C /var/tmp
mv /var/tmp/tritonadm /opt/triton/bin/
chmod 755 /opt/triton/bin/tritonadm
The hash check on both hosts is what makes this path safe. The manifest came over verified TLS, so the binary is pinned to the manifest.
Where the binary lands
The channel tarball holds one file: the tritonadm binary at the top level
of the archive. The script extracts it into the install directory and then
checks that the binary is present and executable. If it is not, the script
exits with
install.sh: tarball extracted but <INSTALL_DIR>/tritonadm is not present.
When the install directory is not on PATH, the script writes a note to
stderr. On an illumos founder, add /opt/triton/bin to PATH in your shell
startup file, or call the binary by its full path. The commands below assume
the install directory is on PATH.
Check the install
Check that the binary runs and reports its version. On the founder, as root:
tritonadm --version
Then verify the publisher signature. tritonadm self-update --check fetches
the channel manifest and its detached .minisig. It verifies the signature
against the publisher key compiled into the binary. It then compares the
channel's build stamp with the stamp compiled into this binary. On the
founder, as root:
tritonadm self-update --check --channel edge
self-update reads the stable channel unless you pass --channel. Name
the channel you installed from.
The command prints an installed: line with the stamp of the running binary.
It prints a candidate: line with the channel's stamp and artifact size.
When the two stamps match, the command prints already up to date and exits
zero. When they differ, --check exits non-zero with
tritonadm is outdated (installed <STAMP>, candidate <STAMP>). The command
changes nothing on disk in either case. Account for that exit code in a
script that runs under set -e.
A signature that does not verify stops the command with
channel signature did NOT verify against publisher pubkey. The bootstrap
script cannot perform this check.
What the bootstrap script verifies, and what it does not
The script's trust model is TLS to the channel host, plus the SHA-256 of the downloaded tarball compared against the channel JSON fetched over TLS from the same host. The script has no publisher key and performs no minisign verification. This keeps the script free of a minisign dependency, because SmartOS platform images do not include one.
tritonadm is stricter. Every channel fetch it makes, in self-update,
install, update, and setup apply, downloads the manifest and its
.minisig. It verifies the detached signature against the publisher public
key compiled into the binary before it downloads any artifact or compares
any SHA-256. That key is a minisign public key with key id
6A95AFF9C8B898E7. For TLS, tritonadm uses the Mozilla root certificates
compiled into the binary, not a system trust store. It does not need a CA
bundle in the global zone.
The publisher also uploads a detached signature for the bootstrap script, at
https://tritoncloud.nyc3.digitaloceanspaces.com/install.sh.minisig. To
verify it you need a minisign implementation and the publisher public key.
The script provides neither. tritonadm self-update --check, run directly
after the bootstrap, is the verification path that needs nothing else on the
host.
Next steps
The script's last ==> line points at <INSTALL_DIR>/tritonadm setup. That
is not a complete command. setup requires a subcommand, and genesis is
tritonadm setup bootstrap.
- Requirements covers what the founder needs before genesis.
- Genesis on the founder runs
tritonadm setup bootstrap. - Updates and channels covers changes of channel and revision after the first install.
tritonadm self-updateis the full flag reference for the update path.