From e068a573c6ba381ec9e00787dfe40397cbdc7dbb Mon Sep 17 00:00:00 2001 From: Michael Vogt Date: Thu, 15 Oct 2026 09:31:09 +0200 Subject: [PATCH] sysupdate: replace the remote machine-tags setting with local tags We used to set the machine tags based on a remote TUF tags file. In the most recent discussions we decided that we would instead make this more client focused. So this commit drops setting the tags from a remote resource and instead relies on something else setting them. In our case that is a confext using /etc/tags.d [1]. Without this commit the machine tags from the confext would be reset by quarry every run. This also enables `Wants=systemd-sysupdate-auto-enable.service` now so that we get the auto-enable of components/features based on machine-tags. It does not do the loop-until-things-settled, that is a bigger change and our current 2min timer will do okay but we really need this soon too. Signed-off-by: Michael Vogt [1] https://github.com/amutable-systems/amutablectl/pull/194 --- cmd/quarry-sysupdate/update.go | 8 -------- contrib/systemd/quarry-sysupdate.service | 6 ++++++ docs/getting-started.md | 4 ++-- 3 files changed, 8 insertions(+), 10 deletions(-) diff --git a/cmd/quarry-sysupdate/update.go b/cmd/quarry-sysupdate/update.go index 983721b..b5d9a24 100644 --- a/cmd/quarry-sysupdate/update.go +++ b/cmd/quarry-sysupdate/update.go @@ -24,14 +24,6 @@ var updateCommand = withExtensionDirFlag(withQuarryUserFlag(withQuarryProxyFlag( &xsysupdate.TransferFileExtension{ OverrideSourcePathURL: ctxQuarryProxyURL(ctx), }, - &xsysupdate.TagsExtension{ - // TODO: There is no ownership model for machine tags yet, so - // as a temporary workaround we take full control of the acp.* - // and amutable.* tag namespaces. These tags always exactly - // match the set shipped by the configured repositories, and - // tags outside them are never touched. - AllowedNamespaces: []string{"acp.", "amutable."}, - }, } ctx, err := exts.DoInit(ctx) if err != nil { diff --git a/contrib/systemd/quarry-sysupdate.service b/contrib/systemd/quarry-sysupdate.service index c61f682..ea7feeb 100644 --- a/contrib/systemd/quarry-sysupdate.service +++ b/contrib/systemd/quarry-sysupdate.service @@ -7,6 +7,12 @@ Description=Quarry-Based Automatic System Update Wants=network-online.target After=network-online.target +# Features gated on machine tags (SuggestOnMachineTag=) become enabled only +# when `systemd-sysupdate enable-feature --feature-suggested` runs, which is +# what systemd-sysupdate-auto-enable.service does. Run it ahead of every +# update: a tag that arrives with this run's confext is picked up by the next. +Wants=systemd-sysupdate-auto-enable.service +After=systemd-sysupdate-auto-enable.service # For containers we assume that the manager will handle updates. And we likely # can't even access our backing block device anyway. diff --git a/docs/getting-started.md b/docs/getting-started.md index a6e658d..7987be5 100644 --- a/docs/getting-started.md +++ b/docs/getting-started.md @@ -392,8 +392,8 @@ directly, but for those who are interested: local HTTP server as a source in transfer files. * `quarry sysupdate update` wraps `systemd-sysupdate` and does some pre-update - and post-update steps (such as installing tags and instantiating transfer - files from the TUF repository). + and post-update steps (such as instantiating transfer files from the TUF + repository). In most cases, you should avoid interacting with these tools -- these are intended to be used by a `systemd-sysupdate`-managed operating system directly.