Skip to content

v0.3.0

Choose a tag to compare

View all tags
@github-actions github-actions released this 21 Aug 07:28
· 187 commits to main since this release
v0.3.0
dc6482b
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Changelog

The manifest gains a runtime dimension. runtimes: names the substrate a bundle
is written for and carries that runtime's files, profiles and options — Compose
is still the only runtime this manager drives, so what changed is that a bundle
now says so rather than the manager assuming it. An installation is fixed to its
runtime when it is created and never transitions.

A bundle written for 0.2.0 does not install on this release. The runtime:
block stopped being read: move its files under runtimes.compose.files, any
runtime.project under runtimes.compose.options.project, and raise
compatibility.min_manager_version to 0.3.0. The refusal names all three, so
a bundle meeting this manager is told what to write instead of failing as an
unrecognised field. This is a withdrawn compatibility promise rather than a
moved date — runtimes: ships here for the first time, so 0.2.0 and earlier
read only the old spelling and this release reads only the new one. No version
ever read both, which is why the grace period first announced for 0.4.0 was a
window no release could have opened.

Upgrading is automatic — the installation schema moves 8 → 10 on the first read
and converts nothing. Going back is not, and here the refusal earns its keep: an
older manager meeting a state file that names a runtime it has never heard of
has exactly one adapter and would drive the installation with it, operating the
wrong substrate while reporting success.

Added

  • A release declares which runtimes it supports, under runtimes:. Each key names a runtime and carries that runtime's own files and profiles, so a bundle states the substrate it is written for instead of leaving the manager to assume the only one that has ever existed. An installation records the runtime it was created against and never transitions to another, which is what lets a later manager tell a machine that chose Compose from one that predates the question being askable. A release declaring more than one runtime is refused at init rather than chosen between, because choosing needs a second adapter to choose with and that arrives alongside it.

  • A release can set per-runtime options with runtimes.<name>.options. The compose runtime reads project there — the namespace its volumes, networks and containers live in — and defaults to the product name. The manager carries these without interpreting them, and the runtime refuses a key it does not understand.

  • morzer doctor reports the runtime an installation is fixed to, and fails when this manager drives a different one. There is no fix on the machine, since a runtime never transitions, so the check names the two ways out instead. With no installation yet, it asks the runtime which tools init will need.

  • A support bundle is signed, and morzer support inspect reads one back. The signature is this installation's own key and lands beside the archive as a .minisig, checkable with minisign -Vm <archive> -P <key> like any release. It covers the file that leaves rather than the plaintext inside it, so an encrypted bundle's origin can be established by whoever receives it before anything decrypts — and by an intake holding no recipient key at all. A machine that has never minted a key still writes the archive, unsigned and saying so, because withholding evidence from the installation that has the least of it is the wrong failure.

  • morzer support inspect will not tell you a bundle is authentic on the bundle's own say-so. The archive names the key that signed it, and that name proves nothing: whoever wrote the archive wrote the name beside the signature they made. So the check runs against this installation's recorded keys when you inspect your own archive, or against --key when somebody sent you one — a key you got from the operator rather than from the file. With neither, it prints the claimed key and says the signature was not checked. Nothing is extracted: an encrypted bundle is read in memory, so inspecting one leaves no readable copy behind.

Changed

  • A planned operation's steps report planned rather than pending in --json. A dry run's steps were never going to run, and pending means not yet, so the record was the one part of the output still claiming work was owed. The operation status is unchanged at succeeded: planning is what succeeded.

  • morzer release new scaffolds a bundle using runtimes: rather than the runtime: block this release stops reading, and declares the manager version that spelling needs. A bundle scaffolded now therefore requires 0.3.0 or newer, which is stated by the manifest rather than discovered as a decoding error.

  • A release that changes a runtime option an installation was created with is refused. Under Compose the project prefixes every volume, so such a release would bring the product up against storage nothing has written to and leave the real data unreferenced. The way through is a backup, a fresh init and a restore.

  • <PRODUCT>_COMPOSE_PROJECT is supplied by the runtime rather than by the core hook ABI. Unchanged for every Compose installation, and absent under a runtime that has no projects instead of carrying a value it cannot mean. Hooks that need it should test for it.

  • morzer installation import refuses an export whose runtime this manager does not drive, before anything on the new host is created. A runtime is fixed when an installation is created and never transitions, so importing one this binary cannot operate would rebuild a machine no command could use.

Removed

  • The runtime: manifest block is no longer read. A bundle carrying it is refused, naming what to write instead: files under runtimes.compose.files, project under runtimes.compose.options.project, and min_manager_version raised to 0.3.0.

Fixed

  • A release bundle no longer carries the vendor's version-control directory. release build summed and release archive packed whatever sat in the bundle directory, so a bundle built inside a git repository shipped .git — history and .git/config included — under the signature. Bundles already published are unaffected and still verify.

  • morzer init --release <bundle>.tar.zst works without --product. Reading the product name from an archive's manifest built a path inside the archive file, so the primary install path failed on a valid bundle. The manifest is now read from the archive's first entry, which the format guarantees is the manifest.

  • The init wizard offers the profiles of a bundle written with runtimes:. It read the deprecated block directly, so from the moment the new spelling existed it offered nothing — indistinguishable from a release that declares no profiles.

  • A release that spells out a runtime option already in force is no longer refused. An installation with no project runs under its product name, so a release naming that same value changes nothing, and dropping such a line is equally harmless. A value that really changes the namespace is refused as before.

  • morzer init --dry-run names the product it would create. The summary read the installation out of engine state, which a plan never populates, so it closed with installation created for — two empty slots and a creation claimed in the past tense, directly beneath the line saying nothing had changed. Under --json, data.product was empty for the same reason. --repair says repaired rather than created on both paths too: a repair on the wrong machine and a first install differ in exactly what that line reports.

Installing this release

curl -fsSL https://morzecrew.github.io/morzer/install.sh | sh -s -- --version 0.3.0

The script verifies the checksum always and the signature whenever
minisign is present; --require-signature makes a missing minisign fatal,
which is what a production runbook sets. --print-only shows everything it
detected and would do, and changes nothing. install.sh is an asset of this
release and is covered by SHA256SUMS below.

Verifying this release by hand

ARCHIVE=morzer_0.3.0_linux_amd64.tar.zst   # the one you downloaded

curl -fsSLO https://raw.githubusercontent.com/morzecrew/morzer/main/morzer.pub
minisign -Vm SHA256SUMS -p morzer.pub
grep " ${ARCHIVE}$" SHA256SUMS | sha256sum -c -

SHA256SUMS covers every architecture, so checking it whole fails on the
archives you did not download — and --ignore-missing, the usual way
around that, reports OK when no archive is present at all. Pulling out
the line for the file you have fails when there is nothing to check.

The signing key is the same for every release. If you have verified a
morzer release before, use the copy you already have rather than fetching
it again — a key that changes between releases is the thing worth noticing.

Release bundles are a separate artifact with their own signature and their
own key; see
https://morzecrew.github.io/morzer/reference/release-commands/#verification

Assets 7
Loading