la 14. syysk. 2024 klo 15.30 Daniel Gröber (d...@darkboxed.org) kirjoitti: > On Sat, Sep 14, 2024 at 08:31:06AM +0300, Martin-Éric Racine wrote: > > Let's start with changing the ifupdown dependencies and DHCP stack > > search order to effectively deprecate ISC. > > I don't think we're ready yet. I have some concerns: > > 1) How do you deal with the mismatch between dhcpd being a system daemon > vs. ifudown wanting a per-interface process?
It's not a daemon unless it's started as one. dhcpcd-base doesn't include the init script or systemd unit. > 2) I'm worried about the behavioural change regarding inet/inet6 stanzas > outlined in #1065085 with a patch by ktetzlaff pending. That's largely a non-issue. The separate stanzas largely is the result of IPv6 being an afterthought that had to be incorporated into ifupdown later on. Simply removing inet6 stanzas fixes it. Anyhow, in most cases, people don't even bother with explicitly configuring IPv6 unless they have a static IP, which therefore doesn't affect DHCP/RA cases. > 3) dhcpcd-base enables IPv6 privacy addressess by default. Which is a good thing. > 1) Looking at the packaging I see that `dhcpcd-base`, unlike `dhcpcd` > (which was renamed from dhcpcd5), does not ship the daemon part of dhcpcd, > which takes over dhcp duties on all interfaces by default as soon as it's > installed. This may be problematic because on upgrade dhcpcd may take over > an interface dhclient is still running on, causing havoc. Perhaps the > sockets are bound such that this wouldn't succeed but I'm not sure. It's not problematic. Someone who wants to use it as a daemon would not keep ifupdown anyhow. > Looking at ifupdown's inet.defn I see dhcpcd being operated in per-iface > mode, like `dhcpcd [-h,-i,-I,-l options...] $IFACE`. In my experience > dhcpcd is very finicky when you try to use it in a dhclient style > one-per-interface mode. When I played with this a while back and found that > the logic is such that dhcpcd will always connect to the system-wide daemon > if one is running even if you ask it to operate on just one > interface. Martin, Santiago: how have you done testing in this dark corner? > My upstream issue is here: > https://github.com/NetworkConfiguration/dhcpcd/issues/241 It works fine here on my laptop. I have separate lines for Ethernet and wireless (with a known SSID and PSK), both of which get activated if Ethernet happens to be plugged in. > one-process-per-interface is going away in v11 does it make sense to rely > on it in the first place? v11 is unlikely to happen. Too many people explicitely told Roy that it's not desirable. > So even with the dhcpcd-base approach of not shipping the daemon, I am > concerned that as soon as a user installs the daemon part ifupdown will > stop working properly because we're not prepared for the daemon taking > over. I just did a quick test and if a per-interface dhcpcd is running and > indeed -k will stop working as soon as the system-wide daemon is started. That's already the case. That's why ifupdown should Conflicts with the package providing the init script and systemd unit (dhcpcd). > 2) I see two problems with the "you only need the inet stanza" change: > Firstly users are loosing control over whether v4/v6 is enabled on dhcp > interfaces. IMO that's not just a break in backwards-compatibility but also > loss of an important feature needed by network operators in complex > environments. Secondly, IPv4 is legacy and will go away eventually so if > anything starting the DHCP client should be attached to the inet6 stanza ;) > Since remaining IPv4 users are going to disagree vehemently here I would > suggest that either choice is utterly broken. We must support dhcp > enablement seperately for each address family. Control over which one currently works fine via dhcpcd.conf. It could also be implemented via command options passed by ifupdown. As for the day IPv4 becomes obsolete, dhcpcd will simply fork once it has reached its timeout and presume an IPv6-only conenction. > 3) Since ifupdown is mainly used in the server/embedded sorts of > enviornments I'm not sure privacy addressing is the right default. > (cf. /etc/dhcpcd.conf having `slaac private` thus enabling RFC 7217 > addressing). We can assume NM will be in use for most Desktop users so I > believe it's safe in principle to retain the current MAC based SLAAC > address behaviour we used to get from the kernel RA implementation. > Thoughts? Privacy by default is desirable. Globally traceable hosts is not. > Further Martin raised the issue that "an upgrade would result in both > remaining installed" while also noting this can be mitigated by changing > ifupdown's dhcp client search order. Fair enough, but I'd like us to at > least make an attempt at removing isc-dhcp-client from user systems that > haven't manually installed it, unless there is simply no viable mechanism > for us to do that? Martin notes a Conflicts against isc-dhcp-client (from > dhcpcd-base I assume?) was tried but this was deemed the "incorrect > approach" (by who, why?). Leaving the previous binary on upgrade is not a problem. Besides, if apt-get is used with --auto-remove, ISC would be removed once dhcpcd-base has been pulled in. Martin-Éric
