Hi Martin, On Sat, Sep 14, 2024 at 06:28:36PM +0300, Martin-Éric Racine wrote: > la 14. syysk. 2024 klo 15.30 Daniel Gröber (d...@darkboxed.org) kirjoitti: > > 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.
I'm sorry, but were you involved in ifupdown's development at the time to be speaking with authority here? I get the impression you just don't want to think about different use-cases, associated tradeoffs and edge-cases so you dismiss the concern(s) out of hand. It's also clearly an issue for users as we have an ifupdown bug about it and it's enough of a pain that it even came with a patch: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065085 (thanks ktetzlaff). > > 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. > > > 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). That is one solution. The other would be to patch dhcpcd to give per-interface daemons precendence when the client is looking for a socket to connect to. If there's a running per-interface process, clearly that's what it should be talking to so long as there's no potential for the global daemon to interfere. I was unsuccessful in convincing Roy but my gut says it's because his intent was still to remove the pre-interface dhcpcd mode entirely at the time. > > 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. Erm, that doesn't sound like the right behaviour to me. Why should an unrelated interface bring down dhcp on another ifa? > > 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. I'm not so sure. Roy seems stubborn and I don't think there was another public statement on the matter after the discussion. > > 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. I'm tending towards fixing this in ifupdown. I don't think users should have to do this via dhcpcd.conf now. > As for the day IPv4 becomes obsolete, dhcpcd will simply fork once it has > reached its timeout and presume an IPv6-only conenction. Have a look at IPv6-mostly (DHCP option 108/v6-only-preferred) that's the preferred mechanism to disable IPv4 going forward ATM. > > 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. For machines closely associated with humans, sure. Privacy is desirable. For one among thousands of servers in an organization, not so much. Operatability becomes more important then. Personally I wish there was a RA flag to indicate what the network prefers, but since an RFC for that never ended up materializing (see https://datatracker.ietf.org/doc/html/draft-yhb-6man-ra-privacy-flag-02) we have to define some default instead. I think we're doing a disservice to our users by giving more weight to our personal use-case for dhcpcd/ifupdown. Expert users are always going to be able to figure whether they have privacy addressess enabled. We have to consider whats best for the majority of our users. IMO that's server operators. What I'd like to try to resolve the conflicting use-cases is to add drop-in support to dhcpcd.conf and add a new dhcpcd-privacy package that activates `slaac private`. We can then Suggest it from ifudown and document in release notes etc. to make users aware of it. > > 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. Oh that's true, I forgot about auto-remove. So switching the dependencies in ifupdown around should do the trick for existing installs. --Daniel
signature.asc
Description: PGP signature
