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!
By allowing users to optionally force using systemd unit-based
activation, they can inject dependencies on other services or
mountpoints (for instance, when the age key is not stored on the root
file system).
By allowing users to optionally force using systemd unit-based
activation, they can inject dependencies on other services or
mountpoints (for instance, when the age key is not stored on the root
file system).
Followup for #765, where I missed this. It's needed here too, since it
runs in the same context as the default module.
Signed-off-by: Christoph Heiss <christoph@c8h4.io>
This fixes https://github.com/Mic92/sops-nix/issues/659
In https://github.com/Mic92/sops-nix/pull/649, we started rendering
templates twice:
1. When rendering `neededForUsers` secrets (if there are any
`neededForUsers` secrets).
2. When decrypting "regular" secrets.
This alone was weird and wrong, but didn't cause issues
for people until https://github.com/Mic92/sops-nix/pull/655, which
triggered https://github.com/Mic92/sops-nix/issues/659. The cause is not
super obvious:
1. When rendering `neededForUsers` secrets, we'd generate templates in
`/run/secrets-for-users/rendered`.
2. However, the `path` for these templates is in
`/run/secrets/rendered`, which is not inside of the
`/run/secrets-for-users` directory we're dealing with, so we'd
generate a symlink from `/run/secrets/rendered/<foo>` to
`/run/secrets-for-users/rendered/<foo>`, which required making
the parent directory of the symlink (`/run/secrets/rendered/`).
3. This breaks sops-nix's assumption that `/run/secrets` either doesn't
exist, or is a symlink, and you get the symptoms described in
<https://github.com/Mic92/sops-nix/issues/659>.
Reproducing this in a test was straightforward: just expand our existing
template test to also have a `neededForUsers` secret.
Fixing this was also straightforward: don't render templates during the
`neededForUsers` phase (if we want to add support for `neededForUsers`
templates in the future, that would be straightforward to do, but I
opted not do that here).
Added support for configuring environment variables before calling
`sops-install-secrets`. Introduced a new `environment` option which
allows specifying environment variables. Modified systemd service
and launchd agent to use the specified environment variables.
