It is difficult to propagate key changes to other parts of a system

[exarkun]

Is your feature request related to a problem? Please describe.

When using the keys feature to put secret values into /var/keys it is difficult to cause other parts of the system to be updated with the new key values.

My understanding is that the old keys are first deleted from the remote system and then the new keys are uploaded and written to the correct location. After this, the build and instantiate steps are performed.

This means that the old system configuration is briefly exposed to the new keys but then (arbitrarily quickly) it is interrupted to be replaced by the new system. When the new system is fully in place, the new keys have already been written and it's difficult or impossible to know if they are new or not.

A systemd.path unit watching the keys doesn't help because it triggers too early in the process (when the old system and the new keys are in place).

The specific motivating use-case I have is that I am trying to deploy Matomo using the NixOS Matomo service. The NixOS service doesn't have a lot of configuration affordances. Instead, there's just a config.ini.php file that needs to be rewritten when configuration/secrets change. My goal is to rewrite this file whenever the Matomo secrets I'm deloying w/ deploy_nixos and the keys feature change.

Describe the solution you'd like

I'm not going to be very picky. Anything that provides a straightforward way to run some code on a system that has "settled" (ie, has completely switched to the new configuration) after keys have changed should resolve this issue. Ideally, it wouldn't involve writing a lot of custom systemd units or shell scripts to use this feature.

One idea is that there could be a "keys-in-place" unit that is (re-)started after the new configuration has settled whenever the keys were rewritten earlier in the same deploy. I'm not exactly sure how the rest of this idea goes, though. Other units declare they're required by and run after this unit?

Another possibility entirely is that it's actually already easy to do this if you know One Weird Systemd Trick™. In this case, perhaps this trick could just be added near the keys documentation so non-systemd wizards can use it.