This change is to support LEGO's capability to spawn an external process that
solves the DNS-01 challenge. In particular, this enables a setup where LEGO
runs a shell script that uses nsd-control to add an appropriate zone to a
local NSD instance.
It was being created with the default home permissions of 700, and then
set to 755 at runtime by something either some script or systemd as
part of service startup.
It worked fine without sysusers, but when it's enabed with:
systemd.sysusers.enable = true;
systemd-tmpfiles is resetting permissions on each activation, which
breaks, for example, nginx reload, because it cannot load certificates
anymore, because it doesn't have any access to `/var/lib/acme`.
Fix this by setting `homeMode = "755";` explicitely so that it's set to
the final value from the beginning.
Add enable switch to make it possible to disable all wrappers but then
also re-enable all at once by forcing the option to be true.
By default the wrappers are enabled and thus the default behaviour
doesn't change.
I have no idea what this escape sequence even is, but it breaks the nix parser with cryptic errors if not used in a comment.
A friend let me know MacOS is prone to input weird spaces, not sure if that is the source.
Candidates were located and created with:
chr="$(echo -e '\xc2\xa0')"; rg -F "$chr" -l | xe sd -F "$chr" " "
There are some examples left, most being example output from `tree` in various markdown documents, some patches which we can't really touch, and `pkgs/tools/nix/nixos-render-docs/src/tests/test_commonmark.py` which I'm not sure if should be addressed
> evaluation warning: pkgs.writeText "motd": The second argument should be a string, but it's a null instead, which is deprecated. Use `toString` to convert the value to a string first.
this ensures PAM users always get the intended version of a module when
multiple versions of the same module exist on a system.
most packages which consume `pam` and link against `libpam.so` do so only
to access its API, and not because they care about the specific
`pam_<xyz>.so` modules provided by that `pam`. but when specifying
modules by name only, PAM-capable applications may well load the
`pam_<xyz>.so` from the `pam` they were compiled against instead of the
pam declared in `security.pam.package`. by fully qualifying `modulePath`
we ensure that users can actually swap out pam modules without rebuilding
the world.
this can be used to swap out which pam package is actually used by the
system for things like `pam_limits`, `pam_tty_audit`, etc, without forcing
a mass rebuild the way an overlay would.
