Typically services have a `package` option, so it can be set externally
if users are running the stable version but want the package from
unstable, or devs want to test a package from their flake in production.
Really useful in many situations!
Also, the previous implementation was using `pkgs.runCommand` which is
discouraged due to
[IFD](https://nix.dev/manual/nix/2.26/language/import-from-derivation)
(import from derivation) leading to potential slowdowns during
evaluation. I opted for reading the json file and using
[lib.attrsets.recursiveUpdate](https://ryantm.github.io/nixpkgs/functions/library/attrsets/#function-library-lib.attrsets.recursiveUpdate)
to update the default values with the user provided ones.
Resolves the installer failing on devices that include this hardware, as
broadcom_sta was marked as insecure due to being unmaintained and having
active CVE's.
This commit be reverted when/if the installer has a mechanism for allowing
insecure packages.
This brings our `run0` in line with the upstream defaults:
bcc73cafdb/src/run/systemd-run0.in
While working on `auditd`, i noticed differences in how `run0` behaves
in regard to `/proc/$pid/sessionid` and `/proc/$pid/loginuid`. Particularly,
both files were set to `4294967295`, the magic value denoting `unset`.
While the manual page says elevators such as sudo should not set the loginuid,
run0 is a bit of a special case: The unit spawned by it is not child of
the running user session, and as such there is no id to inherit.
`systemd` upstream uses `pam_loginuid`, and for consistency we should too.
Especially because it prevents a whole lot of pain when working with `auditd`.
As to pam mounts:
On nixos we enable those if they are globally enabled. Upstream does not.
Considering the password entered into polkit is usually not the user password
of the account which will own the unit, pam mount will fail for any partition
which requires a password. Thus it makes sense to also disable pam mounts
for our run0, it prevents unnecessary unexpected pain.
According to emilazy these were the only usages of sha1 in nixpkgs:
```
pkgs/servers/mx-puppet-discord/node-packages.nix
111: sha1 = "532e01241dbcb0f2769f1b9a7cde313d30101173";
120: sha1 = "68018cab4f59834b3fef2e59fbfd52938403e001";
129: sha1 = "52b0e8bb808a1202602899af67939b049dd42402";
138: sha1 = "0a37a3f9430ff7c29512d29882e25ae738a31283";
```
Anyone motivated to maintain it can feel free to restore this, it's just
not maintained at the moment, and the sha1 hashes need to go.
This was found after Ericson proposed implementing something like
https://github.com/NixOS/nix/issues/13544 in Lix, which led to the
question "who is using sha1 anyway?" and the realization we could just
*remove* support for it outside of .. the known chromium crimes.
This will ensure reproducibility between different nixos systems, where
one system has store optimization enabled (which will hardling similar
files in the nix store) and the other doesn't. Without the flag, the
same image, built on the two different systems, will have a different
number of inodes. The flag will dereference hardlinks and copy them
into the image as different inodes.
Signed-off-by: Paul Meyer <katexochen0@gmail.com>
Same as with other services giving postfix access, this needs to happen
for the postfix user. Adding supplementary group permissions to the
systemd unit does not propagate to child processes that ultimately call
the unix domain socket.
Upstream stores the model cache in the config directory, which is
unnecessarily messy. The cache directory is still the correct place for
these, since they can be pruned and redownloaded, we just don't want it
to happen on every restart.
Fixes: #427714
- fixes#426282
- current implementation breaks generation of strategies,
when strategies are not defined by user.
- minimal working config with `strategies.default = null`:
```nix
hardware.fw-fanctrl = {
enable = true;
config.strategies = { };
};
```
- User should be able to start the service, when only `hardware.fw-fanctrl.enable`
is enabled.
