dhdpcd 9 support privilege separation with a dedicated user and seccomp
filtering. this has been enabled for a while in other distributions as
well.
if the dhcpcd module is not used and the _dhcpcd user/group isn't
definied otherwise dhcpcd will fall back to not using privsep.
by @erictapen:
- Removed note about testing and moved it to passthru.tests
- Removed patch, as it is probably the same as
56b2bb17d2ec67e1f93950944211f6cf8c40e0fb, wich landed in upstream.
other changes:
- changed PIDFile in the module, since dhcpcd 9 changed the location
Systemd dependencies for scripted mode
were refactored according to analysis in #34586.
networking.vswitches can now be used with systemd-networkd,
although they are not supported by the daemon, a nixos receipe
creates the switch and attached required interfaces (just like
the scripted version).
Vlans and internal interfaces are implemented following the
template format i.e. each interface is
described using an attributeSet (vlan and type at the moment).
If vlan is present, then interface is added to the vswitch with
given tag (access mode). Type internal enabled vswitch to create
interfaces (see openvswitch docs).
Added configuration for configuring supported openFlow version on
the vswitch
This commit is a split from the original PR #35127.
This change ensures that `dhcpcd.service` is restarted as soon as the
exit hook changes. I use this hook to do additional configuration for my
network (like setting a route via the given gateway to my WireGuard) and
when changing parts of this exit hook I'd expect to get this activated
when switching to my new configuration.
As the comment notes, restarts/exits of dhcpcd generally require
restarting the NTP service since, if name resolution fails for a pool of
servers, the service might break itself. To be on the safe side, try
restarting Chrony in these instances, too.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This reverts a change applied in PR #18491. When interfaces are
configured by DHCP (typical in a cloud environment), ordering after
network.target cause trouble to applications expecting some network to
be present on boot (for example, cloud-init is quite brittle when
network hasn't been configured for `cloud-init.service`) and on
shutdown (for example, collectd needs to flush metrics on shutdown).
When ordering after network.target, we ensure applications relying on
network.target won't have any network reachability on boot and
potentially on shutdown.
Therefore, I think ordering before network.target is better.
We want to wait for both stacks to be active before declaring that network is active.
So either both default gateways must be specified or only IPv4 if IPv6 is disabled to
avoid dhcpcd for network-online.target.
Previously services depending on network-online.target would wait until
dhcpcd times out if it was enabled and a static network address
configuration was used. Setting the default gateway statically is enough
for the networking to be considered online.
This also adjusts the relevant networking tests to wait for
network-online.target instead of just network.target.
When dhcpcd instead of networkd is used, the network-online.target behaved
the same as network.target, resulting in broken services that need a working
network connectivity when being started.
This commit makes dhcpcd wait for a lease and makes it wanted by
network-online.target. In turn, network-online.target is now wanted by
multi-user.target, so it will be activated at every boot.
See #18319 for details. Starting network-online.target manually does not
work as it hangs indefinitely.
Additionally, don't treat avahi and dhcpcd special and sync their systemd units
with the respective upstream suggestion.
Systemd upstream provides targets for networking. This also includes a target network-online.target.
In this PR I remove / replace most occurrences since some of them were even wrong and could delay startup.
The networkd implementation sets systemd.services.dhcpcd.enable to
false in nixos/modules/tasks/network-interfaces-systemd.nix. So we need
to respect that in the dhcpcd module.
If we don't, the resumeCommand is set nevertheless, which causes the
post-resume.service to fail after resuming:
Failed to reload dhcpcd.service: Unit dhcpcd.service is masked.
post-resume.service: main process exited, code=exited, status=1/FAILURE
Failed to start Post-Resume Actions.
Dependency failed for Post-Resume Actions.
Unit post-resume.service entered failed state.
post-resume.service failed.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This fixes several problems in the dhcpcd service:
* A segfault during startup, due to a race with udev (dhcpcd would get
an ADD event from udev, causing it to re-add an interface that it
already had, leading to a segfault later on).
* A hang/segfault processing "dhcpcd rebind" (which NixOS calls after
waking up from suspend).
Also, add "lo" to the list of ignored interfaces. It usually ignores
"lo", but apparently not when it gets an ADD event from udev.
