Default to updating via bootc to update system if compatible

[jlebon]

Feature Request

Desired Feature

We want to start de-emphasizing rpm-ostree when possible. bootc status has an incompatible flag we could use to know if the system can be managed by bootc or not (read: some rpm-ostree specific features like package layering are used).

This would allow people to use bootc features like LBIs and kargs (though that means a derivation, which today if you want to also use Zincati implies owning the graph but see coreos/fedora-coreos-tracker#1872).

I think the biggest blocker for this today is the zincati user actually being able to use bootc. It's not great, but we could ship our own bootc shim that supports just what we need and a polkit rule to allow Zincati to use the shim.

[cgwalters]

. It's not great, but we could ship our own bootc shim that supports just what we need and a polkit rule to allow Zincati to use the shim.

I think a nicer pattern for systemd services is to avoid polkit - it's only natural to use for DBus based services and weird to install something global that is intended only for one thing.

Instead, use e.g.

DynamicUser=yes
ExecStart=-/usr/bin/zincati-backend
ExecStart=/usr/bin/zincati
RuntimeDirectory=zincati

And then the privileged code and unprivileged code can communicate via e.g. a unix domain socket stored in $XDG_RUNTIME_DIR/zincati.sock or so i.e. the unpriv service can make API calls.

[jlebon]

Interesting idea. Is that pattern used anywhere?

ExecStart=-/usr/bin/zincati-backend

I guess you mean ExecStart=!/usr/bin/zincati-backend here?

ExecStart=-/usr/bin/zincati-backend
ExecStart=/usr/bin/zincati

Are you sure this works? Only Type=oneshot supports multiple ExecStarts. At least per the docs.

Hmm, the docs for ! say:

Note that this setting may be combined with DynamicUser=, in which case a dynamic user/group pair is allocated before the command is invoked, but credential changing is left to the executed process itself.

So I guess we could start privileged and fork off the unprivileged daemon ourselves. Not great.

Or just two separate systemd units using the same dynamic user should work I think.