This key is an alias for net.ipv4.ip_forward. The kernel default is
already 0, so emitting `=0` from sysctl.d is at best a no-op.
It is actively harmful when systemd-networkd manages forwarding via
`networkd.conf [Network] IPv4Forwarding=yes`: on a cold boot
systemd-sysctl runs before networkd and networkd's write wins, but on
a `nixos-rebuild switch` that restarts both services (any systemd
package change does, since kernel.poweroff_cmd in 60-nixos.conf
follows the systemd store path) the ordering is undefined and sysctl
can run last, silently flipping a router back to ip_forward=0.
Only emit the sysctl when at least one interface has proxyARP=true,
matching every other in-tree setter of this key (nat, docker,
tailscale, netbird, ...) which only ever write `true`. The previous
value was already mkDefault, so nothing could have been relying on it
to force forwarding off anyway.
Reverts #481473, fixes#509254
Turns out this breaks scripted networking with systemd stage 1. Even
if we assumed that systemd stage 1 wasn't now the default, I still
think that makes this worthy of a revert, in the absence of a fix. But
now that systemd stage 1 is the default, this is also a channel
blocker.
The problem is that wantedBy = [ "foo.device" ]; doesn't work as
hoped. If the device appears in stage 1, then the systemd device unit
becomes active in stage 1 without pulling in any dependency for
configuring it (because that only exists in stage 2). When we
transition to stage 2, systemd maintains its information about unit
state between stages and remembers that the device units were already
active. They do not become reactivated, and consequently their new
stage 2 dependencies do not get pulled in.
The fix is probably to do this with SYSTEMD_WANTS= in udev rules,
rather than with wantedBy. The udev rules will re-fire during stage 2,
though I'm not 100% clear on exactly which events that includes
(e.g. if we'll get new add events or if we need to look for a
different ACTION or anything like that). This is going to require some
experimentation and testing that I don't have time for today.
Given that this is addressing a channel blocker, I think this revert
should be merged if a fix can't be merged instead before the next
unstable-small eval. In either case, staging-nixos should be merged to
master right after.
This change solves some big design flaws in the scripted networking
backend.
1. When the module was reworked in 072c1dcc4a to use the new systemd
targets, network-setup.service was used to:
a. order the services and link network.target to the boot sequence
b. perform some perform final network configuration, specifically
setting the default gateways and nameservers (/etc/resolv.conf).
Later (ec00b4bb11) however, network-setup.service was made
optional: if resolvconf is not used and a default gateway is not set,
the service is not be defined (because it would result in an empty
script). Doing so, however, has the unintended effect of unlinking
network.target from multi-uset.target, meaning no network
configuration at all is performed.
Note: this can be easily seen by adding `networking.resolvconf.enable
= false` to the nixosTests.networking.scripted.static test.
2. The network-addresses-*.service are linked to network.target, which,
in turn, is linked to multi-uset.target. This means that if a
hardware interface is not found, the boot will hang until this
service times out (issue #154737).
To solve issue 1. this change removes network-target entirely while
- moving the default gateway setup into the relative
network-addresses-*.service unit;
- moving the nameservers setup into networking.localCommands;
(incidentally, this also fixes issue #445496)
- directly linking network.target to multi-user.target.
To solve issue 2. this removes the Wants=network.target dependency of
network-addresses-*.service and solely relies on the underlying
interface unit (*-netdev.service for virtual, *.device for physical) to
start the service.
Note: for NixOS containers, the dependency is kept, because the .device
unit are not available in this case.
Finally, if an interface is the default gateway, network-online.target
is added as an extra dependency, so the target is not reached until the
interface has been plugged in and configured.
null will not set owner, allowing any user to access the virtual
device. Previously, this behavior can be achieved by using
systemd.network.netdevs.* options direcly and leaving
systemd.network.netdevs.<name>.tapConfig.User unset. With this patch,
this behavior can be achieved using the generic
networking.interfaces.* options by setting
networking.interfaces.<name>.virtualOwner to null.
If needed, we can change the default value from "root" to null in the
future to be consistent with systemd-networkd's default behavior.
iw and wirelesstools (iwconfig, iwlist, etc.) are not required by
networking.wireless and rarely used manually, so they should not be
installed by default.
This change rework a bit the documentation on networking.sits to explain
what they actually are. In fact, there are three different protocols
being collectively called "SIT", which itself is a nonstandard term.
There is no canonical way to set a system domain name any longer. The one
we previously used was the NIS/YP one, but that is pointless these days.
The hostname is set up through /etc/hostname, but hostname(5) states that
it should only contain 64 7-bit ASCII characters, so it cannot be used
to cover the domain name.
We still support setting the domain name to complete the `fqdn` option
and as a central option to reference the domain name from. If anyone
wants a NIS/YP domain name set, do it yourself..
We then clarify that the domain option has nothing to do with DNS
resolution anymore and search should be configured instead.
Finally explain the purpose of the ndots option in the context of search
domains, since they decide when we stop considering the search domains
when querying names with more than one dot.
The `domainname` utility uses setdomainname (see getdomainname(2)) to
configure the NIS[1] (also known as YP) domain name.
It provided a central directory for various objects that are resolved via
nsswitch in the late 1990s and early 2000s.
It is however not a safe nor common deployment scenario anymore.
[1] https://en.wikipedia.org/wiki/Network_Information_Service
This is first and foremost to provide compat with scripts that call the
hostname executable to retrieve the hostname, an assumptions we probably
should not be breaking.
Format all Nix files using the officially approved formatter,
making the CI check introduced in the previous commit succeed:
nix-build ci -A fmt.check
This is the next step of the of the [implementation](https://github.com/NixOS/nixfmt/issues/153)
of the accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166).
This commit will lead to merge conflicts for a number of PRs,
up to an estimated ~1100 (~33%) among the PRs with activity in the past 2
months, but that should be lower than what it would be without the previous
[partial treewide format](https://github.com/NixOS/nixpkgs/pull/322537).
Merge conflicts caused by this commit can now automatically be resolved while rebasing using the
[auto-rebase script](8616af08d9/maintainers/scripts/auto-rebase).
If you run into any problems regarding any of this, please reach out to the
[formatting team](https://nixos.org/community/teams/formatting/) by
pinging @NixOS/nix-formatting.
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
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.
In 759ec111 the ping setuid wrapper was removed in favour of giving
permissions to perform ICMP echo requests to all users.
The problem is that the systemd file that was supposed to change the
`net.ipv4.ping_group_range` sysctl is not always installed, specifically
only if systemd.coredump.enable.
In that case the range is "0 1", which is effectively restricts ping to
only root.
This change explicitely sets the range to "0 2^31-1", as systemd does.
The networkd backend logic for setting DHCP= on an interface is bugged
and inconsistent with the scripted logic. Consider this simple NixOS
configuration:
{
networking.useNetworkd = true;
networking.interfaces.eth0.wakeOnLan.enable = true;
}
The default value of networking.useDHCP is true, so we expect our eth0
interface to have DHCP enabled. With the scripted backend, this works.
But the networkd backend generates the following 40-eth0.network file:
[Match]
Name=eth0
[Network]
DHCP=no
IPv6PrivacyExtensions=kernel
This is happening because the wakeOnLan configuration creates a key in
networking.interfaces, and the networkd backend erroneously checks that
instead of for explicitly configured IP addresses as in the scripted
backend. The documentation is also inconsistent across various options.
This change aligns the networkd backend and option documentation to the
actual behavior of the scripted backend, and updates a test to account
for this behavior for both backends.
