Option to apply presets from systemctl preset-all to /usr instead of /etc

[septatrix]

The users of mkosi are often redistributors whose config/presets should be placed under usr instead of etc. Furthermore, this also helps with sysupdate images where usr is updated but the root is a persistent volume. New default presets are not applied in that case as machine-id already exists leading to inconsistent states.

I am aware of the existence of systemd-update-done.service which could be used to call systemctl preset-all upon booting after an update, however, using that unit is more complex than simply having the correct presets on the usr partition. Another argument against that approach is that systemctl preset-all will touch configs from the user when the distributor wants to enable new stuff and disable old stuff. In that case configs from the user will be overwritten (either reenabled, or disabled). Also there are a few correctness problems with systemctl preset-all when using templated units (systemd/systemd#18825, systemd/systemd#15065) which are easier to workaround in a finalize script than having to perform that before the systemd-update-done.service unit.

[septatrix]

Or should this be raised as an RFE over at the systemd repo?

[behrmann]

That sounds like something to raise in the systemd repo. Maybe an option to choose between /usr/lib/, /usr/local/lib, /runand/etc`.

Another argument against that approach is that systemctl preset-all will touch configs from the user when the distributor wants to enable new stuff and disable old stuff.

I'm not entirely sure I understand that point. I assume "configs from the users" means "config in /etc/. When running systemctl preset-allI think it's reasonable to assume, that things one has written, might be overwritten by other config and if one wants to be sure, give it a sufficiently low number. For units there was issue systemd/systemd#30439, we should maybe add a similar note to thesystemd.presetman page. With something like that in place usingsystemd-update-done.serviceto callsystemctl preset-all` would be sufficent, but maybe I'm missng part of the picture.

[septatrix]

I'm not entirely sure I understand that point. I assume "configs from the users" means "config in /etc/". When running systemctl preset-all I think it's reasonable to assume, that things one has written, might be overwritten by other config and if one wants to be sure, give it a sufficiently low number. For units there was issue systemd/systemd#30439, we should maybe add a similar note to the systemd.preset man page. With something like that in place using systemd-update-done.service to call systemctl preset-all would be sufficent, but maybe I'm missng part of the picture.

My problem is that it touches units which were manually enabled/disabled. When invoking systemctl enable they will get overwritten, especially if the presets contain disable * as a fallback which is quite common. In my case this resulted in the removal of openvpn@<foobar>.service nearly locking me out of the device. And including these templated units in the presets file does not really seem feasible. But I agree that this is just a limitation of how unit enabling/disabling works. Therefore the option to preset units under /usr would be much appreciated. I will open an RFE over at the systemd repo for that.

[septatrix]

I opened systemd/systemd#33373 over at the systemd repo

[behrmann]

Just for completeness:

1. preset files have ignore directives in addition to enable and disable, which seem to be what you want at least for some cases
2. you can add templates in preset files, e.g. [email protected] bar qux for the instances bar and qux.

[septatrix]

Just for completeness:

1. preset files have `ignore` directives in addition to `enable` and `disable`, which seem to be what you want at least for some cases

Oh I did not knew that. That might make some things easier though ultimately having the symlinks shipped under /usr is still preferrable IMO.

2. you can add templates in preset files, e.g. `[email protected] bar qux` for the instances `bar` and `qux`.

Yeah I already saw that in your bug report I linked above (systemd/systemd#15065). However, this does not really work for me as I do not have control over the templated name but I guess in this case I might be able to get away with using ignore [email protected]?