home  bbs  files  messages ]

      ZZLI4422             linux.debian.devel             1179 messages      

[ previous | next | reply ]

[ list messages | list forums ]

  Msg # 1133 of 1179 on ZZLI4422, Thursday 10-22-25, 10:17  
  From: SIMON RICHTER  
  To: ALL  
  Subj: Re: Finishing deprecation of isc-dhcp-cl  
 From: sjr@debian.org 
  
 Hi, 
  
 On 10/22/25 4:13 AM, Daniel Gr€€ber wrote: 
  
 > tl;dr: ifupdown + dhcpcd-base in Trixie is broken in all but the most 
 > defaultest configurations, consequently isc-dhcp-client deprecation is a 
 > wash. It's a mess. Lets fix it. 
  
 Yay. 
  
 The biggest obstacle I see is actually making sure at least one of ISC 
 dhcp-client or dhcpcd is installed when using DHCP. 
  
 Would it make sense to make ifupdown prefer dhcpcd if both it and the 
 ISC client are installed, then make the ISC client package pull in 
 dhcpcd? This way, anyone currently using dhclient through ifupdown would 
 get dhcpcd installed, but people with a static configuration would not 
 need to install a DHCP client (the ifupdown package only Recommends a 
 DHCP client, so doing a proper transition is difficult). 
  
 > Proposed ifupdown unstable upload: 
 >    https://salsa.debian.org/debian/ifupdown/-/merge_requests/28 
  
 I'll take a look this weekend. 
  
 > After a comprehensive review of the situation I see the following problems 
 > with ifupdown + dhcpcd-base: 
  
 >   - [Independent control] over IPv6 and IPv4 operation from ifupdown is 
 >     broken. A single `inet` stanza will enable both, so `inet6 static` also 
 >     does SLAAC/DHCPv6. 
  
 The default interface config has "accept_ra" enabled, so SLAAC is 
 enabled as soon as the link is up. If we "fix" that, it will be about as 
 controversial as systemd's decision to drop into an emergency shell if a 
 non-root filesystem fails to mount, when the sysvinit script failed to 
 pass the exit code along and just continued booting. 
  
 >   - Non-deterministic [daemon conflics] between ifup's dhcpcd instances and 
 >     dhcpcd.service may cause boot or renew problems. 
  
 Horrible idea: can we build a systemd generator that creates units to 
 resolve these conflicts? 
  
 > As a reminder: starting with Trixie dhcpcd-base is now Priority:important 
 > (#1038882) instead of isc-dhcp-client. AFACT this only affects new 
 > installations, not upgrades so we've split the userbase. 
  
 The important change, I think, was changing the first preference in 
 ifupdown's Recommends field, but the effect is the same. 
  
 > The dhcpd *package* additionally provides a system service that will start 
 > dhcpcd in dual-stack global manager mode at boot. It will bring UP most 
 > interfaces automatically with IPv4 DHCP, IPv4-LL and IPv6 SLAAC and/or 
 > Stateful DHCPv6 as appropriate, but regardless of ifupdown configuration or 
 > whether a per-iface instance is already running(!), see [daemon conflicts]. 
  
 I think that is a bug in dhcpcd -- other tools make sure to ignore 
 interfaces configured through ifupdown. 
  
 As before, I fully expect a lot of installations to depend on this bug. 
  
 > A dhcpcd patch could be suitable for Trixie even, but so far dhcpd's 
 > maintainer has refused to consider downstream changes -- else I'd have 
 > fixed this well before Trixie already :-]. Truth be told I'm pretty annoyed 
 > I had to spend more than a full blown focused work week on designing, 
 > implementing, documenting this hacky fix on the ifupdown side instead of 
 > spinning a 10 LoC dhcpcd patch in half an hour, but here we are. Ugh. 
  
 FWIW, I think that kind of integration work is the job of a 
 distribution, so I'm totally fine shipping a patched package even if 
 upstream does not accept the patch. 
  
 We'd also need to define a conflict resolution policy for dhcpcd vs 
 systemd-networkd if we are touching dhcpcd. 
  
 My favourite policy would be 
  
 1. explicit configuration wins over autodetection 
 2. clear hierarchy for the rest, documented in Debian Policy 
  
 So, anyone autodetecting interfaces needs to consult either all the 
 other configuration files (which is bullshit, but doable), or we create 
 another interface between packages (e.g. /var/run/managed_interfaces) 
 and document it in Debian Policy. I would not feel confident deploying 
 the latter in a stable update, though. 
  
     Simon 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2) 

[ list messages | list forums | previous | next | reply ]

search for:

328,081 visits
(c) 1994,  bbs@darkrealms.ca