Installation

The RPM builds, installs and runs on Rocky Linux 10, and still on 9. The whole scenario below — install, configure, start, run a workload, kill the agent with -9, watch the workload survive — is a script, packaging/rocky/acceptance.sh, and CI runs it on every push alongside the full test suite against a real systemd as PID 1 on both releases.

Rocky Linux 10 is what soli-one is set up and documented on: the tutorial runs on it, and the Soli runtimes the cluster installs — soli, soli-proxy, solidb, solikv — are published for Rocky 10 only. They are those projects' release binaries, built against glibc 2.39, which is Rocky 10's and not Rocky 9's.

soli-one itself still runs on Rocky 9. Its package is built on Rocky 9 and runs on 9 and 10. The binaries need at most GLIBC_2.34 — measured, not assumed — and Rocky 10 ships 2.39, so forward compatibility is free. The reverse is not: build on 10 and the result links against 2.39 and does not start on 9. That is why packaging/rpm/build.sh refuses to build anywhere but inside a Rocky container, and why the container is 9 even though both releases are supported.

Rocky 10 needs no code changes: nothing in the tree reads /etc/os-release or branches on a release number, and systemd capabilities are probed from the bus rather than derived from a version, so every gate is a >= that systemd 257 satisfies.

One thing to check at your provider rather than here: RHEL 10 raised the CPU baseline to x86-64-v3, so the oldest and cheapest instance generations may not run Rocky 10 at all.

rpm --import <base>/el10/RPM-GPG-KEY-soli-one
cat > /etc/yum.repos.d/soli-one.repo   # packaging/repo/soli-one.repo
dnf -y install soli-one

Signed packages and signed repository metadata: gpgcheck=1 refuses a package this key did not sign, and repo_gpgcheck=1 refuses metadata it did not sign. Without the second, someone who can write to the bucket can serve yesterday's metadata and have every node reinstall a version you have already fixed — no package is tampered with in that attack, so gpgcheck alone does not see it.

one cluster create puts a new machine on the channel while it is already logged in, when ONE_REPO_BASE is set. Installing from a file and never configuring a repository is how a fleet ends up with five versions and no way to tell which.

curl -LO <release>/soli-one-linux-amd64.tar.gz
curl -LO <release>/soli-one-linux-amd64.tar.gz.sha256
sha256sum -c <<<"$(cat soli-one-linux-amd64.tar.gz.sha256)  soli-one-linux-amd64.tar.gz"
tar -xzf soli-one-linux-amd64.tar.gz -C /usr/local/bin soli-oned one

Two binaries and nothing else: no unit, no tmpfiles, no SELinux contexts, no firewalld service. Use it for a workstation that only needs one --host, or for a node you are configuring some other way — not as the normal way onto a cluster node, where everything the RPM installs besides the binaries is the part that makes confinement and the directory modes correct.

Unpacked out of the signed RPM by CI rather than built beside it, so the tarball and the package cannot contain different bytes. It carries a .sha256 because, unlike the RPM, it has no signature of its own — verify it before you run it.

A binary linked against Ubuntu 24.04's glibc 2.39 does not start on Rocky 9, which ships glibc 2.34. Measured on this codebase, not assumed:

$ objdump -T target/debug/soli-oned | grep -o 'GLIBC_[0-9.]*' | sort -Vu | tail -1
GLIBC_2.39
$ docker run --rm rockylinux:9 ldd --version | head -1
ldd (GNU libc) 2.34

The stack's CI convention builds x86_64-unknown-linux-gnu on ubuntu-latest, which would ship a broken RPM on day one — one that installs cleanly and then fails at systemctl start. So the toolchain lives in the same image as the bench, and building it wrong by accident is not possible.

SELinux enforcing and firewalld need a second bench, a real Rocky VM under KVM: packaging/rocky/vm.sh test. The full acceptance has passed there with zero AVC denials — and the note at the end of this page says what that run covered, which is less than “everything”.

It is the one gate CI cannot hold, so it is a per-release step a person takes rather than something a push proves.

A container could never do it. SELinux is a kernel feature and a container shares the host kernel — a workstation whose kernel has no SELinux cannot run enforcing in one, however privileged.

A firewalld service definition ships in the RPM at /usr/lib/firewalld/services/soli-one.xml: firewall-cmd --add-service=soli-one. Never open these to the world — bind them to a zone restricted to peer CIDRs. The HMAC envelope is the real boundary and the firewall is defence in depth, not the other way round; an exposed gossip port still leaks the cluster's membership from the traffic pattern alone.

The workload that VM supervised was a shell command. The file contexts above exist for a different case — a container handed an artifact bind mount — and the RPM was not installing them at all. So “zero AVC denials” was a true statement about a run that never exercised the thing the labels are for, and the reassuring number sat beside the untested case for months.

acceptance.sh now checks the contexts directly, reading the expected type out of soli-one.fc rather than repeating it — so editing one without the other fails the run — and it says out loud when it is running somewhere they cannot be checked at all, which is every container.