Skip to content
Sinter

Rocky Linux

Rocky Linux 9 x86_64 has been supported since v0.2.0; Rocky Linux 10 x86_64 since v0.4.0. Both lines are acceptance-tested in v1.3.0 and use the dnf package backend.

Acceptance references: Rocky Linux 9.8 x86_64 with DNF 4.14.0 — verified for package install/remove/idempotency, file, service, and command resources over real SSH with sudo -n — and Rocky Linux 10.2 x86_64 with DNF 4.20.0 and rpm 4.19, verified for the same five resource types plus converge-back purge idempotency. Rocky 9/10 are the supported version lines; 9.8 and 10.2 are the verified references, not independent evidence for every other minor release.

Unified Linux x86_64 distribution

Section titled “Unified Linux x86_64 distribution”

Sinter v1.3.0 uses one sinter-v<VERSION>-linux-x86_64.tar.gz for all supported x86_64 version lines. The executable is unified; runtime platform detection still selects APT on Ubuntu and DNF on RHEL-family targets. This is not a claim of support for arbitrary Linux systems or architectures.

The Sinter v1.3.0 release artifact passed eight-real-host acceptance on Ubuntu 24.04.5 LTS, Ubuntu 26.04.1 LTS, Rocky Linux 9.8, Rocky Linux 10.2, RHEL 9.8, RHEL 10.2, AlmaLinux 9.8, and AlmaLinux 10.2 — all x86_64, 3,980 checks passed, 0 failed. Other and future point releases have not each been independently validated. Historical v0.2.1 retains its distro-specific assets; see Installation for current downloads.

Requirements

Section titled “Requirements”
Requirement Notes
Rocky Linux 9 or 10 x86_64
OpenSSH server Strict known_hosts verification
systemd Required for service resources
/bin/sh Target-side shell
attr package /usr/bin/getfattr; check on the target; install attr with dnf if missing
sudo -n Passwordless sudo when using --sudo
dnf Package backend

Package management

Section titled “Package management”

type: package recipes are platform-neutral — the same recipe runs under dnf on Rocky:

resources:
  - id: nano
    type: package
    with:
      name: nano
      state: present

How dnf installs work

Section titled “How dnf installs work”

A dnf install never lets the mutating dnf process touch the network for metadata:

  1. A private snapshot of the DNF metadata cache is created under /var/tmp/sinter-dnf.* with mode 0700.
  2. Transaction resolution and metadata validation run cache-only against the snapshot, freezing the exact resolved package identities.
  3. The resolved RPM payloads are downloaded into the snapshot through the native dnf/librepo transport — repository authentication stays with dnf/librepo — and each payload’s RPM identity is verified against the frozen transaction set.
  4. The final mutation runs dnf -C --setopt=cachedir=<snapshot> — cache-only.
  5. The snapshot is removed afterward, including on failure.

If payload completeness or identity cannot be proven, the install fails closed before any mutation.

Platform detection

Section titled “Platform detection”

/etc/os-release ID=rocky (RHEL family) selects the dnf backend. Unknown or unsupported platforms are capability errors — Sinter does not guess a backend.

Limitations

Section titled “Limitations”
  • Only x86_64 is validated; do not assume aarch64 support.
  • Rocky 9.8 is the acceptance reference — other 9.x minors share the same interfaces but are not individually verified.
  • Hashed known_hosts entries are not supported (same as all targets).