Dhcpcd replacing dhclient for Debian Trixie or perhaps networkd?(q-funk.blogspot.com)
q-funk.blogspot.com
Dhcpcd replacing dhclient for Debian Trixie or perhaps networkd?
http://q-funk.blogspot.com/2024/07/dhcpcd-replacing-dhclient-for-trixie-or.html
33 comments
Isn't this about just the client, while your concern is only about the server?
[deleted]
TIL that networkd has built-in DHCP server. I don't think that this matters here, using networkd for client configuration shouldn't prevent using something else for server.
I noticed that tailscale magic DNS appears to not be able to understand that /etc/resolv.conf doesn't need to be manually overwritten when using dhcpcd whereas there is no such problem when using the ISC dhcp client.
Obviously, tailscale is in the wrong for trying to infer whether or not /etc/resolv.conf is under system control rather than just providing a knob to tune that behavior but that doesn't change the fact that my DNS gets subtly broken when using dhcpcd.
Obviously, tailscale is in the wrong for trying to infer whether or not /etc/resolv.conf is under system control rather than just providing a knob to tune that behavior but that doesn't change the fact that my DNS gets subtly broken when using dhcpcd.
"Conclusion: networkd works well enough for someone configuring an IPv4-only network from 20 years ago, but is utterly inadequate for IPv6 or dual-stack installations, doubly so on a software distribution that claims to care about privacy and network security."
Great to see some sanity in Debian again. Now please also get rid of systemd altogether and generally simplify the IP address configuration and routing to the level of OpenBSD.
But this is a very good start.
Great to see some sanity in Debian again. Now please also get rid of systemd altogether and generally simplify the IP address configuration and routing to the level of OpenBSD.
But this is a very good start.
At this point more people would be pissed off that systemd is missing then using another init system. Its too late in the game for most major distros to get away from systemd. Systemd is here to stay, the most we can do is fight to try and make it better.
> Its too late in the game for most major distros to get away from systemd.
Oddly, this is the same rationale for keeping the established setup that was dismissed when systemd was introduced.
Oddly, this is the same rationale for keeping the established setup that was dismissed when systemd was introduced.
Because someone actually did the work that provided what people wanted and needed.
which so far no one else has done
which so far no one else has done
The established setup (initd) did a lot less. Systemd has a huuuge sprawling interface and is more like a challenge to POSIX itself than some script folders.
There aren't that many alternatives either [1], and honestly I'd love to never ever have to see a shellscript initfile ever again.
[1] https://wiki.gentoo.org/wiki/Comparison_of_init_systems
[1] https://wiki.gentoo.org/wiki/Comparison_of_init_systems
> At this point more people would be pissed off that systemd is missing then using another init system.
Maybe systemd should stick with being an init system rather than a network interface management system.
> Systemd is here to stay, the most we can do is fight to try and make it better.
Perhaps we need to get the government involved for anti-trust actions to break up this monopoly.
Maybe systemd should stick with being an init system rather than a network interface management system.
> Systemd is here to stay, the most we can do is fight to try and make it better.
Perhaps we need to get the government involved for anti-trust actions to break up this monopoly.
systemd is, but it has a well integrated ecosystem of other binaries that are managed in the same project (ie. systemd-networkd, systemd-resolvd, etc.). These generally follow the unix philosophy of doing one thing and doing it well and are almost all completely optional.
I personally find systemd-networkd to be a tiny fraction of the headache that NetworkManager is, so I'm glad it exists.
I personally find systemd-networkd to be a tiny fraction of the headache that NetworkManager is, so I'm glad it exists.
> I personally find systemd-networkd to be a tiny fraction of the headache that NetworkManager...
I find this take interesting, because NM automagically gets out of the way in both Debian and RedHat.
Any interface you define in /etc/network/interfaces is automatically "unmanaged" by NM in Debian, and since RedHat stores NM configs in /etc/sysconfig/network-scripts files directly, you can either create your own files, or edit already existing ones.
systemd-* doesn't have this magick and loves to compete and override other daemons silently and wreak havoc in the process.
I find this take interesting, because NM automagically gets out of the way in both Debian and RedHat.
Any interface you define in /etc/network/interfaces is automatically "unmanaged" by NM in Debian, and since RedHat stores NM configs in /etc/sysconfig/network-scripts files directly, you can either create your own files, or edit already existing ones.
systemd-* doesn't have this magick and loves to compete and override other daemons silently and wreak havoc in the process.
I maintain pretty tight control over all of my systems. I don't typically want miscellaneous daemons floating around with configs strewn about /etc, so systemd's ecosystem fits nicely with that. Sure, that's personal preference, but there's something to be said about cohesive system configuration.
NM is not a miscellaneous daemon which throws configuration files around. It's under "/etc/NetworkManager" for Debian, and it uses standard sysconfig/network-scripts folder in RedHat. So it's pretty cohesive since it integrates with everything pretty nicely from get go. All the config files are pretty human readable, and there are tons of tools plus your favorite editor to work with it.
Of course you can prefer to use the tools from the same toolbox, it's your system, it's your choice. However, my experience shows me that using full-featured stacks even if they are not that tightly integrated is better in the long run.
E.g. I used to use DHCP options in my home network in the past, and we use them at work. So even if systemd-networkd feels good, it means nothing if I can't configure my system the way it should be.
When I have thousand servers to tend, I want my configs to work the way they should. I can't get emotional about how using all my tools from a single toolbox, or this and that. I just want my systems installed, work reliably over long periods of time, and just sleep at night.
Network manager proved to be both helpful and reliable in that regard, so I'm a happy camper.
Of course you can prefer to use the tools from the same toolbox, it's your system, it's your choice. However, my experience shows me that using full-featured stacks even if they are not that tightly integrated is better in the long run.
E.g. I used to use DHCP options in my home network in the past, and we use them at work. So even if systemd-networkd feels good, it means nothing if I can't configure my system the way it should be.
When I have thousand servers to tend, I want my configs to work the way they should. I can't get emotional about how using all my tools from a single toolbox, or this and that. I just want my systems installed, work reliably over long periods of time, and just sleep at night.
Network manager proved to be both helpful and reliable in that regard, so I'm a happy camper.
Good to hear! I'm glad NM (and other tools) exist, and I'm not saying they shouldn't. My needs are adequately met by the tools systemd-networkd provides, and I find it works well. Again, it's optional.
I also wasn't really referring to NM itself, but about other ancillary daemons that were referenced in the GP.
I also wasn't really referring to NM itself, but about other ancillary daemons that were referenced in the GP.
> I don't typically want miscellaneous daemons floating around with configs strewn about /etc, so systemd's ecosystem fits nicely with that.
Ironically resolved running is another miscellaneous daemon, and it messing around with /etc/resolv.conf makes systemd's ecosystem super annoying to me.
Ironically resolved running is another miscellaneous daemon, and it messing around with /etc/resolv.conf makes systemd's ecosystem super annoying to me.
> I personally find systemd-networkd to be a tiny fraction of the headache that NetworkManager is, so I'm glad it exists.
And I just want my Debian/Ubuntu interfaces(5) file back.
Once I set up a server I want it to stay still, and static text files are the best way to do that IMHO. I also found manipulating them much easier than the messy that is YAML (where whitespace is important—which is one of dumbest notions I've come across: given me {}s for better context any day of the week).
And I just want my Debian/Ubuntu interfaces(5) file back.
Once I set up a server I want it to stay still, and static text files are the best way to do that IMHO. I also found manipulating them much easier than the messy that is YAML (where whitespace is important—which is one of dumbest notions I've come across: given me {}s for better context any day of the week).
> These generally follow the unix philosophy of doing one thing and doing it well and are almost all completely optional.
So I can take just systemd-networkd or just systemd-resolvd and install it on a FreeBSD box?
Just because these are different binaries does not make them 'separate'. All the things in the systemd code base are tightly coupled together. That is the opposite of the Unix philosophy.
So I can take just systemd-networkd or just systemd-resolvd and install it on a FreeBSD box?
Just because these are different binaries does not make them 'separate'. All the things in the systemd code base are tightly coupled together. That is the opposite of the Unix philosophy.
For the record, it turned out this was just a series of misunderstandings on the part of the OP on how configuring networking works on Linux, and the differences between how the kernel and how userspace manage and configure addresses. These points have all been clarified by myself and another maintainer on https://github.com/systemd/systemd/issues/33866
- the assertion is made that networkd creates link local addresses - it does not, the kernel does.
- the assertion is made that configuring how the _kernel_ sets up link local addresses must automatically and silently affect how userspace network managers configure global addresses. This is of course not the case, and one might ask for such a feature, but its absence most definitely does not mean that it is "utterly inadequate for IPv6 or dual-stack installations".
- the assertion is made that userspace network managers independently listening on RA packets and creating SLAAC global addresses independently of the kernel must set the stable-privacy interface flag. This is not the case, such flags are owned by the kernel and cannot be set by userspace. Being absent does not mean the the addresses are not private or stable, it just means they are not kernel managed, and thus a different (RFC 7217 compliant) algorithm is used as explained on https://www.freedesktop.org/software/systemd/man/latest/syst...
- the assertion is made that the suffixes generated by the _kernel_ to set up link local addresses must automatically and silently be copied by userspace network managers to configure global addresses on the respective interfaces. This is also of course not the case, the algorithm is described in the link above, and again asking for such a new feature is fine, but its absence does not mean that it is "utterly inadequate for IPv6 or dual-stack installations".
- the assertion is made that certain defaults must be changed to meet the OP's personal preferences. This of course cannot really be done in a project like systemd, where we try our best to keep backward compatibility, even if we don't always succeed. The desired configuration is very easy to setup, for example this should suffice:
[Network] IPv6PrivacyExtensions=yes IPv6LinkLocalAddressGenerationMode=stable-privacy
[IPv6AcceptRA] Token=prefixstable
As usual, it would be best to ask clarification questions and investigate how things actually work _before_ making definitive assertions on a blog post about a component for which one has a cursory understanding at best, but that's not nearly as much fun as a good ol' systemd bashing blog post, right?
- the assertion is made that networkd creates link local addresses - it does not, the kernel does.
- the assertion is made that configuring how the _kernel_ sets up link local addresses must automatically and silently affect how userspace network managers configure global addresses. This is of course not the case, and one might ask for such a feature, but its absence most definitely does not mean that it is "utterly inadequate for IPv6 or dual-stack installations".
- the assertion is made that userspace network managers independently listening on RA packets and creating SLAAC global addresses independently of the kernel must set the stable-privacy interface flag. This is not the case, such flags are owned by the kernel and cannot be set by userspace. Being absent does not mean the the addresses are not private or stable, it just means they are not kernel managed, and thus a different (RFC 7217 compliant) algorithm is used as explained on https://www.freedesktop.org/software/systemd/man/latest/syst...
- the assertion is made that the suffixes generated by the _kernel_ to set up link local addresses must automatically and silently be copied by userspace network managers to configure global addresses on the respective interfaces. This is also of course not the case, the algorithm is described in the link above, and again asking for such a new feature is fine, but its absence does not mean that it is "utterly inadequate for IPv6 or dual-stack installations".
- the assertion is made that certain defaults must be changed to meet the OP's personal preferences. This of course cannot really be done in a project like systemd, where we try our best to keep backward compatibility, even if we don't always succeed. The desired configuration is very easy to setup, for example this should suffice:
[Network] IPv6PrivacyExtensions=yes IPv6LinkLocalAddressGenerationMode=stable-privacy
[IPv6AcceptRA] Token=prefixstable
As usual, it would be best to ask clarification questions and investigate how things actually work _before_ making definitive assertions on a blog post about a component for which one has a cursory understanding at best, but that's not nearly as much fun as a good ol' systemd bashing blog post, right?
> Temporary addresses are not enabled by default. Worse, the setting is ignored if it was enabled by sysctl during bootup. This is a major privacy issue.
Yeah that's a hard pass.
> Adding IPv6PrivacyExtensions=yes to the above exposed another issue: instead of using the fe80 address generated by the kernel, networkd adds a new one.
But... I'm not sure this is a big problem? One of the big ideas of IPv6 is that you can have many IPs on an interface; throwing on one more isn't ideal, but I don't think it's a hard blocker.
Yeah that's a hard pass.
> Adding IPv6PrivacyExtensions=yes to the above exposed another issue: instead of using the fe80 address generated by the kernel, networkd adds a new one.
But... I'm not sure this is a big problem? One of the big ideas of IPv6 is that you can have many IPs on an interface; throwing on one more isn't ideal, but I don't think it's a hard blocker.
FE80::/10 is the link-local space.
It's fucking insane for systemd to be creating a second link-local address. Additionally, those addresses are only used on the local link, making any "privacy" address scrambling pretty silly.
It's fucking insane for systemd to be creating a second link-local address. Additionally, those addresses are only used on the local link, making any "privacy" address scrambling pretty silly.
To be clear, I'm not saying I think this is a good idea, but it's legal. AFAIK, you can assign a single machine 192.168.1.2 and 192.168.1.3 at the same time, and you can likewise give a single machine/interface multiple fe80:: addresses. As to privacy... yeah, probably not super useful, but I don't see it hurting anything and if you're implementing IPv6 assignment logic it's probably just as well to always default to privacy protection.
How about just shipping a networkd.conf(.d) config snippet and .network file with the wanted defaults. This is just another instance of I-hate-systemd-for-no-reason whining
Networkd is still missing the most crucial part of DHCP protocol: DHCP OPTIONS leg of the DHCP negotiation stage.
You've shown up twice to neg about this, but this isn't a problem with systemd-networkd's DHCP client.
Right now there's no rules engine for the DHCP server to dynamically generate options. Sure, you can't embed Lua scripts in the server at this point.
But bro, this has nothing to do with the discussion here. The DHCP client works fine, has no such concerns or issues. Stop blowing smoke.
Right now there's no rules engine for the DHCP server to dynamically generate options. Sure, you can't embed Lua scripts in the server at this point.
But bro, this has nothing to do with the discussion here. The DHCP client works fine, has no such concerns or issues. Stop blowing smoke.
When having displaced the ISP-supplied DSL/ADSL/SDSL router at a premise using DHCP OPTIONS using a FreeBSD/Linux and ISC dhclient at many locations, and that is the client-side of DHCP.
And ISP likes to have their custom routers (which is a DHCP client, BTW) respond in all sorts of funky ISP-specific DHCP key/value sets.
Not just smoke. FIRE!
And ISP likes to have their custom routers (which is a DHCP client, BTW) respond in all sorts of funky ISP-specific DHCP key/value sets.
Not just smoke. FIRE!
> This is just another instance of I-hate-systemd-for-no-reason whining
This is a person actually examining it and specifically spelling out reasons why it's unsuitable.
This is a person actually examining it and specifically spelling out reasons why it's unsuitable.
> This is just another instance of I-hate-systemd-for-no-reason whining
systemd appears to (whether deliberately, or through incompetence) ignore kernel configuration and do its own thing. That's a good reason to complain, don't you think?
systemd appears to (whether deliberately, or through incompetence) ignore kernel configuration and do its own thing. That's a good reason to complain, don't you think?
[deleted]
DHCP OPTIONS feature (that systemd-network does not have) still has major places within enterprise and homelab networks.
Example of Nintendo DHCP Workaround using ISC DHCP: https://github.com/egberts/isc-dhcp-server-nintendo
So, excuse me while I vehemently resist systemd-networkd.