Dhcpcd replacing dhclient for Debian Trixie or perhaps networkd?
q-funk.blogspot.com
q-funk.blogspot.com
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.
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.
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.
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.
I personally find systemd-networkd to be a tiny fraction of the headache that NetworkManager is, so I'm glad it exists.
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.
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.
I also wasn't really referring to NM itself, but about other ancillary daemons that were referenced in the GP.
Ironically resolved running is another miscellaneous daemon, and it messing around with /etc/resolv.conf makes systemd's ecosystem super annoying to me.
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.
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).
Oddly, this is the same rationale for keeping the established setup that was dismissed when systemd was introduced.
which so far no one else has done
- 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?
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.
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.
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?
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.
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 a person actually examining it and specifically spelling out reasons why it's unsuitable.