Skip to content

kuma v0.14.0

Choose a tag to compare

View all tags
@github-actions github-actions released this 20 Aug 22:23
v0.14.0
4020eef

A declaration describes a system; it never described your files. [backup] copies them somewhere else, and kuma install --restore puts a machine back.

Added

  • [backup] copies what [snapshots] keeps to a restic repository, on a timer, reading from a snapshot so nothing changes mid-copy. Requires [snapshots].enable; kuma check says so rather than the unit failing at 3am.

  • The credential is named, not held. secret = "backup" points at /var/lib/kuma/secrets/backup.env, mode 0600, which you create. A declaration is committed and baked world-readable, so it is the wrong place for a password; a repository address containing one is refused. Recovering a machine therefore needs two things: this file and that credential.

  • network_connections carries /etc/NetworkManager/system-connections, and is off by default. Those files hold a passphrase per network and nothing else can recreate them, so kuma doctor names which way it is set.

  • kuma backup: bare reports without touching the network, --init seeds the first copy, --list asks the repository, --restore brings a path back after a dry run.

  • kuma install --restore <file> rebuilds a machine from the repository. One file carries the address and its credentials. The restore runs at first boot, after /var/home becomes a subvolume; if the repository is unreachable that boot, the next one tries again.

  • kuma doctor grades backups on a stamp only a run that copied something writes, so a machine that has quietly stopped is visible. Staleness follows your declared interval. It also grades the credential's mode.

Changed

  • Retention applies every copy; pruning runs weekly, because pruning repacks and moves far more data than forgetting a snapshot does.
  • kuma check on a valid declaration now names the next command, and its JSON carries actions either way.
  • kuma init no longer pins system.base, so a first declaration composes its own base like every published image.
  • doctor's dangling-enablement check reports as enablement rather than units, which the failed-unit check already used.
  • kuma switch pipes the image into root storage instead of staging 1.5 GB through a temp file, and doctor runs its podman probes concurrently.

Fixed

  • kuma install --restore left the repository credential world-readable for the length of an install.
  • kuma install --json emitted no JSON on failure and printed progress into the document.
  • backup.repo reached generated shell without validation.
  • kuma install --groups was unvalidated where a declaration's groups are.
  • kuma-brew-setup wrote as root into a directory tree a normal account owns; it refuses a prefix it does not own.
  • A live session no longer arms kuma's timers or converges Flatpak permissions.
  • [system.ca_certificates], added in 0.13, was documented nowhere.

Static x86_64 binary, no runtime dependencies.

$ curl -LO https://github.com/Letdown2491/kuma-linux/releases/download/v0.14.0/kuma-x86_64-unknown-linux-musl
$ chmod +x kuma-x86_64-unknown-linux-musl && sudo mv kuma-x86_64-unknown-linux-musl /usr/local/bin/kuma

Verify it came from this workflow:

$ cosign verify-blob \
    --bundle kuma-x86_64-unknown-linux-musl.bundle \
    --certificate-identity-regexp '^https://github.com/Letdown2491/kuma-linux/' \
    --certificate-oidc-issuer https://token.actions.githubusercontent.com \
    kuma-x86_64-unknown-linux-musl

Built from 4020eef29e413a6d305c4d0587971cd0e89e2ffd.

Assets 8
Loading