Hi Paul, Martin, (CC ktetzlaff, see below) On Thu, Dec 12, 2024 at 05:30:29PM +0100, Paul Gevers wrote: > > Context: dhcpcd-base has taken over DHCP duties from isc-dhcp-client in > > ustable via priority override at Martin's request. This changes a Debian > > installs DHCP behaviour in a number of ways which I think will cause people > > problems when they upgrade to trixie, this is one of them. > > We do have Release Notes to (also) document important changes like this.
Ofc. However I'm concerned for people that skip reading that kind of paperwork and when it comes to something as critical as networking I'm not taking chances on taking changes lightly :-). I see release notes only as a last resort if we can't come to a working compromise. > I have no idea, how common is DDNS where the hostname is needed? (At least > from the time I still used DDNS, I don't recall that was part of it, but I > admit that's long time ago). There are two ways to do DDNS that I'm aware of: either the DHCP server does it for a whole LAN (cf. what dnsmasq does by default) or a user manually configures a machine to send DNS updates to some service (cf. ddclient). We're talking about the former case that's where the DHCP server needs to know the hostname. It's a common deployment type in organizational environments (where Debian is popular wouldn't ya know it!) as you can do it network-wide and don't have to touch every machine. > Side note, reading the bug log, can you comment on why you say > """ > I'd previously thought perhaps we can programmatically change dhcpcd.conf > in postinst, but this is explicitly forbidden by RC policy: > """ > Are you talking here about changing it from another package than the one > that ships it? Right. I was specifically thinking ifupdown (which I'm involved with) could change dhcpcd.conf to retain the previous behaviour we had with isc-dhcp-client, but it's clear to me now this was an awful idea without explicit support from dhcpcd's side besides being against policy. On Fri, Dec 13, 2024 at 09:34:07AM +0200, Martin-Éric Racine wrote: > I don't think that not advertising the hostname and thus not > implementing DDNS by default is a significant change. The release team > is of course welcome to document it. Alternately, if the release team > thinks that DDNS should work out of the box, this can be enforced > using the --hostname option in the ifupdown command line. I didn't know about that --hostname option! That should actually make it possible to override the hostname behaviour from ifupdown's dhcpcd integration. Great! However: I am concerned that this would override user's settings concerning how the hostname should be formatted (fqdn vs short) from dhcpcd.conf and ifupdown would have to grow these settings instead (ugh for me and unexpected for users tbh). See dhcpcd.conf `hostname_fqdn` and `hostname_short`. It's also not clear from docs how this cmdline option interacts with the case where the DHCP server pushes the hostnames to the machine i.e. the force_hostname=YES or $(uname -n) = '(none)' case. Even if those details work out that doesn't take care of the entire dispute unfortunately. The hostname change isn't the only upgrade issue I have with dhcpcd, it was just the most egrigous one that motivated me to write this up. In the interest of not burying the lede let me also dive into the other two existing points of contention with Martin: 1) inet/inet6 stanza change already mentioned and 2) switching to IPv6 privacy addressess on by default ## Context For more context on both please see https://lists.debian.org/debian-devel/2024/09/msg00194.html. LMK if you need me to file bugs, I just haven't had the energy to write it up again for the BTS after the (frankly exhausting) d-devel discussion around ifupdown that this came out of. More detail on 1) is already described in an ifupdown bug (as it always receives the blame ;-) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065085 -- some additional commentary is on the corresponding MR: https://salsa.debian.org/debian/ifupdown/-/merge_requests/21. ## RC issue? To me these are also severity: serious as both cause networking to stop working on existing systems one way or another if a user doesn't intervene before/after the upgrade. I expect the stanza change to affect almost all users, the IPv6 privacy change is only problematic for a more narrow (but IMO important) group of users. In the case of 1) the stanza change my understanding (I haven't tested this myself yet) is this causes networking to break entirely if a user doesn't intervene before the upgrade -- even if that weren't the case it's still removing a feature ifupdown had previously: user's ability to control IPv4 and IPv6 stacks independenly. 2) Enabling IPv6 SLAAC privacy addressing can cause problems in restrictive network environement as the source address of connections from the affected machine will change and may no longer fit network/service ACLs causing breakage and needing intervention. ## Fixes and responsibility I'm not sure how to fix 1) yet we may be able to do it entirely in ifupdown (CCing ktetzlaff who wrote a patch here), but it's not clear that's the right approach yet and we'd apreciate a more collaborative spirit from Martin on the dhcpcd side so this doesn't end up being a gian hack. 2) Has a relatively simple config fix: change the `slaac private` option in dhcpcd.conf one way or another. If Martin insists on keeping the privacy addressing for existing dhcpcd users (understandable if so) I'd go for adding dhcpcd.conf.d support and installing an override in ifupdown, but other less patch'y approaches are possible. > > We do have Release Notes to (also) document important changes like this. > > From the Release Notes' perspective, the only meaningful change that > dhcpcd-base brings is that, in most cases, a separate inet6 stanza > won't be required in /etc/network/interfaces since both IPv4 and IPv6 > stacks are handled by the same binary. > dhcpcd-base's README.Debian tells more. I don't see a README.Debian, I think you meant NEWS? https://salsa.debian.org/debian/dhcpcd/-/blob/debian/sid/debian/NEWS?ref_type=heads: > dhcpcd (1:10.0.10-1) unstable; urgency=medium > > * Please note that, as per upstream defaults, SLAAC uses privacy > extensions. This can be changed to use EUI64 (hwaddr) instead via > </etc/dhcpcd.conf>. > > * Since Debian 12 (Bookworm), dhcpcd uses Predictable Network Interface > Names on Linux ports. This brings dhcpcd in line with other > networking tools. You seem to have moved that one from a previous NEWS entry (I'm looking on my bookworm system). I don't think thats quite right as it's not new in v10 but already happend much earlier, no? > This change is only noticeable on hosts where networking is > controlled by 'ifupdown' via </etc/network/interfaces>. For example: > > Before: > > iface eth0 inet dhcp > > After: > > iface enp4s0 inet dhcp > > 'sudo dmesg | grep -i renamed' shows available Predictable Interface > Names. > > * Please note that, since dhcpcd handles IPv4 and IPv6 stacks > simultaneously, no separate inet6 line is needed in > </etc/network/interfaces>. > > -- Martin-Éric Racine <martin-eric.rac...@iki.fi> Sun, 15 Sep 2024 18:58:46 > +0300 Thanks, --Daniel
signature.asc
Description: PGP signature
