Feature request: Pure systemd service implementation

[Titaniumtown]

The use of activationScripts for decryption is very limiting for cases when the key is not static or is provided by an external source. It would be very useful to be able to be able to have agenix's decryption step done via a systemd service so dependencies can be added.

In my usecase, I want a systemd service to attempt to mount a usb drive (containing the key), then after succeeding, trigger agenix. I dug around in the actual module, and it seems there is a systemd service that is created, but only when systemd-sysusers is enabled. I am not familiar with sysusers at all so I can't comment on it's functionality. But I think it could be useful to have this systemd service on non-sysuser setups.

Thoughts?

[nwf]

I find myself wanting something similar (agenix secrets decrypted by use of age-plugin-yubikey, which depends on pcscd running, which... well, maybe I could figure out how to do that in an activation script, but that sounds painful and besides I don't find myself wanting to configure user passwords or such via agenix... yet). Before I go and turn my prototype into something worthy of a PR, I wonder what people would think of allowing individual secrets to be configured as having an associated systemd unit. Such secrets would probably skip the "generation" mechanism in agenix (stop the service to delete the plaintext file or restart it if the ciphertext has changed) and could also be configured to depend on other systemd services (say, pcscd).

[DerRockWolf]

I would also benefit from this.

I provision hosts using nixos-anywhere and am using services.tailscale.authKeyFile. This will fail on the first activation on new hosts and requires a manual restart of the oneshot service when the secrets are available after the second activation.

The easiest solution would be to add a after agenix to the tailscale-autoconnect service.
Such setups are already possible with the agenix home-manager module, just not with the nixos module.

[reasonableperson]

Note that #255 added a systemd service which runs the activation script. The feature is described as adding support for sysusers, but will be enabled if either systemd.sysusers or services.userborn is enabled. So, while the "pure" systemd implementation proposed in #367 is probably a good idea, if you just want to make another service depend on the availability of agenix secrets, enabling userborn will give you an agenix-install-secrets.service now.