sops-nix/modules/sops
Maximilian Bosch 645fa1c3ef
modules/sops: re-run sops-install-secrets.service at sysinit-reactivation.target
Consider the following case: a service (`gitlab-runner.service` in this case) gets
a new secret that is installed via sops and will be reloaded on a switch. Right
now this would fail like this:

    machine | updating GRUB 2 menu...
    machine | stopping the following units: sops-install-secrets.service
    machine | activating the configuration...
    machine | setting up /etc...
    [...]
    machine | restarting sysinit-reactivation.target
    machine | reloading the following units: dbus-broker.service, gitlab-runner.service
    machine | restarting the following units: polkit.service
    machine | starting the following units: sops-install-secrets.service

Here, the reload happens _before_ running `sops-install-secrets.service`
which means that the newly added secret doesn't exist yet and thus the
reload fails.

This change makes sure the service is started when running
`sysinit-reactivation.target`, i.e. before stc-ng reloads other
services. This is what sysusers already does, so the objective of
running after sysusers is still met.

Also, added an `After=userborn.service` to make sure it's also ordered
after userborn if necessary.

Thank you WilliButz for reminding me that `sysinit-reactivation.target`
exists and is most likely the culprit of that!
2025-12-11 11:56:01 +01:00
..
secrets-for-users secrets-for-users: set HOME envvar to avoid warnings on sops >= 3.10.0 2025-04-04 10:42:50 +02:00
templates add uid and gid to templates 2025-03-17 20:29:15 +01:00
default.nix modules/sops: re-run sops-install-secrets.service at sysinit-reactivation.target 2025-12-11 11:56:01 +01:00
manifest-for.nix fix home-manager module 2025-03-17 10:54:23 +01:00
with-environment.nix reformat code base with nixfmt 2024-11-17 12:22:59 +01:00