There is valid scenarios to NOT have certain keys in /etc/resolved.conf, e.g. WSL mDNS.
This was reported in https://github.com/NixOS/nixpkgs/pull/535649#issuecomment-5103574775.
Empty configs can still be achieved passing an empty list (`[]`) or empty string (`""`),
while passing `null` will now remove the key from the config file.
In a previous change the transformSettings function was modified to look
at the Resolve section, but since it got a second consumer in the mean
time this regressed. We now target the resolved.conf explicitly instead.
This reverts commit 66353ca989.
In the meantime a new option was added that consumes the
`transformSettings` function, which broke by looking at just at the
Resolve section.
Because all options are below the [Resolve] section, and we nest them as
such below `settings.Resolve` we need to apply the transformations one
level down for it to match the relevant keys.
Fixes#353225
The value of `networking.resolvconf.enable` was previously
predicated on the existence `environment.etc."resolv.conf"`.
This could lead to infinite recursion when an attribute defined
within the resolvconf module was also required to define
`environment.etc` (see example below).
Instead, set the default to an explicit true and set the value to
false where required in-tree. This turns out to only be two places:
systemd-resolved and tetrd.
Example infrec (from building .#nixosTests.containers-hosts):
```
… while evaluating definitions from `/nix/store/5djjm1dipmdh82issrmpfjdplp7hk0pp-source/nixos/modules/services/logging/logrotate.nix':
… while evaluating the option `containers.netmask.services.logrotate.enable':
… while evaluating the option `containers.netmask.users.groups':
… while evaluating definitions from `/nix/store/5djjm1dipmdh82issrmpfjdplp7hk0pp-source/nixos/modules/config/resolvconf.nix':
… while evaluating the option `containers.netmask.networking.resolvconf.enable':
… while evaluating the option `containers.netmask.environment.etc':
… while evaluating definitions from `/nix/store/5djjm1dipmdh82issrmpfjdplp7hk0pp-source/nixos/modules/services/logging/logrotate.nix':
(stack trace truncated; use '--show-trace' to show the full, detailed trace)
error: infinite recursion encountered
at /nix/store/5djjm1dipmdh82issrmpfjdplp7hk0pp-source/lib/modules.nix:1512:13:
1511| _type = "if";
1512| inherit condition content;
| ^
1513| };
```
With the options being only set when `services.resolved.enable` was
enabled, they were only available if the host resolver was resolved. That
broke the resolved config used when initrd networking is enabled.
A good indicator that something is wrong is if the config section of
a module configures the options itself. That means non introspectable
settings are being put in place.
Additionally DNS= and Domains= need to be space-separated lists. The
manpage does not indicate that they can be set multiple times.
I decided not to port the LLMNR enablement over, since it never gained
widespread traction and is generally being phased out in favor of mDNS.
Fixes: #480964
These daemons should not be stopped, as they're foundational to a
proper functioning of the system. When switching configurations, they
only need a restart instead of that stop/start cycle.
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev b32a094368
result/bin/apply-formatting $NIXPKGS_PATH
Otherwise we get a clash when generating the initrd since the initrd tmpfiles
options create a symlink at /etc/tmpfiles.d/ and any subsequent writes inside
this directory because of initrd.systemd.contents will cause a permission denied
error.
these changes were generated with nixq 0.0.2, by running
nixq ">> lib.mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> Inherit >> mdDoc[remove]" --batchmode nixos/**.nix
two mentions of the mdDoc function remain in nixos/, both of which
are inside of comments.
Since lib.mdDoc is already defined as just id, this commit is a no-op as
far as Nix (and the built manual) is concerned.
The previous code did not apply any changes to the upstream defaults on being presented with an empty list.
This changes the code to use the above behaviour on a `null` value while an empty list is passed through as normal which yields a systemd configuration line with empty value which resets it to an empty value.
Signed-off-by: benaryorg <binary@benary.org>
Historically, we allowed downgrade of DNSSEC, but some folks argue
this may decrease actually the security posture to do opportunistic DNSSEC.
In addition, the current implementation of (opportunistic) DNSSEC validation
is broken against "in the wild" servers which are usually slightly non-compliant.
systemd upstream recommended to me (in personal communication surrounding
the All Systems Go 2023 conference) to disable DNSSEC validation until
they work on it in a significant capacity, ideally, by next year.
This query yielded no results on search.nixos.org.
I don't think I can make all options magically appear, but you can
the other options by reading the text.
- The order of NSS (host) modules has been brought in line with upstream
recommendations:
- The `myhostname` module is placed before the `resolve` (optional) and `dns`
entries, but after `file` (to allow overriding via `/etc/hosts` /
`networking.extraHosts`, and prevent ISPs with catchall-DNS resolvers from
hijacking `.localhost` domains)
- The `mymachines` module, which provides hostname resolution for local
containers (registered with `systemd-machined`) is placed to the front, to
make sure its mappings are preferred over other resolvers.
- If systemd-networkd is enabled, the `resolve` module is placed before
`files` and `myhostname`, as it provides the same logic internally, with
caching.
- The `mdns(_minimal)` module has been updated to the new priorities.
If you use your own NSS host modules, make sure to update your priorities
according to these rules:
- NSS modules which should be queried before `resolved` DNS resolution should
use mkBefore.
- NSS modules which should be queried after `resolved`, `files` and
`myhostname`, but before `dns` should use the default priority
- NSS modules which should come after `dns` should use mkAfter.
This will make dbus socket activation for it work
When `systemd-resolved` is restarted; this would lead to unavailability
of DNS lookups. You're supposed to use DBUS socket activation to buffer
resolved requests; such that restarts happen without downtime
This will make dbus socket activation for it work
When `systemd-resolved` is restarted; this would lead to unavailability
of DNS lookups. You're supposed to use DBUS socket activation to buffer
resolved requests; such that restarts happen without downtime
This is a refactor of how resolvconf is managed on NixOS. We split it
into a separate service which is enabled internally depending on whether
we want /etc/resolv.conf to be managed by it. Various services now take
advantage of those configuration options.
We also now use systemd instead of activation scripts to update
resolv.conf.
NetworkManager now uses the right option for rc-manager DNS
automatically, so the configuration option shouldn't be exposed.
Rather than special-casing the dns options in networkmanager.nix, use
the module system to let unbound and systemd-resolved contribute to
the newtorkmanager config.
This shuts up this error from dbus:
May 11 13:52:16 machine dbus-daemon[259]: Unknown username "systemd-network" in message bus configuration file
May 11 13:52:16 machine dbus-daemon[259]: Unknown username "systemd-resolve" in message bus configuration file
which happens because the D-Bus config for networkd/resolved is
enabled unconditionally, and we don't have an easy way to turn it off.
(cherry picked from commit f19b58fb6a)
Otherwise, the enabled -> disabled transition won't be handled
correctly (switch-to-configuration currently assumes that if a unit is
running and exists, it should be restarted).
