Re: Finishing deprecation of isc-dhcp-client in ifupdown*
>> (@all please keep me in Cc, d-devel is too high-volume to subscribe)
On Thu, 23 Oct 2025, Daniel Gröber wrote:
>(merging this back into the main thread)
Huh. Funny, because while I set the References header so it would
merge into the main thread, you managed to clear it out completely,
starting a new thread.
I’ve added References again, hoping MUAs will be good enough to
merge threads again.
>On Wed, Oct 22, 2025 at 08:22:07PM +0200, Thorsten Glaser wrote:
>> … but there’s a fourth: just “inet dhcp” and no inet6 stanza,
[…]
>Right. I don't explicitly reason about that configuration since kernel
>defaults apply so it's just not really managed by ifupdown at this point,
Yes, precisely: ifupdown and the DHCP client it calls should not
change kernel defaults to break this, as it’s the default.
>Thinking about this some more I may consider requiring `inet6 auto` in the
>future for this configuration, but not without a proper transition and
>ample notice.
That directly contradicts what you wrote above. That would mean
ifupdown would break kernel defaults without the user explicitly
asking for it, by merely the user specifying IPv4 configuration.
This will be a net loss because at the moment, IPv6 “just works”
with no configuration for many people because of the kernel default,
and this should not change to the worse.
>> (I’ve been bitten by ifup/ifdown issues when listing both inet
>> and inet6 for the same interface in the past.)
>
>Can you elaborate here?
Unfortunately not, it’s been a while.
>> I’ve never seen inet6 auto used anywhere, only inet6 static (and
>> I’ve not personally encountered inet6 dhcp yet, and given rtadvd
>> and rtsol work, I don’t quite see the use for most networks).
>
>Strange, given that this is what d-i will produce by default -- if the
>installation network has IPv6 RAs at least.
As of which release? ;-)
I’m _somewhat_ sure the bullseye installer didn’t, and I’ve since
switched away from d-i to just debootstrap plus a small shell script
that does what d-i does to the installed system (except it doesn’t
copy the live CD’s network config), as has been a growing trend
among (at least) Grml enthusiasts for years.
>My ifupdown now overrides the --slaac config for the interface it's upping
>so you can revert this to get a clean config or leave it, doesn't
>matter. It'll work.
OK.
>> While there, I do have more questions related to it.
>>
>> +option ntp_servers
>>
>> Where would that be handled? If I wanted to, where do I have
>> to look to write integration for this for? (I use a custom
>> OpenNTPD packaging.)
>
>See dhcpcd-run-hooks(1). Unfortunately we don't have .d support there yet
>see #1101003.
Ah, okay. (Not needed at this time, so just curiosity.)
>> +# hands off
>> +nohook resolv.conf, hostname, timezone, lookup-hostname
>>
>> Is there a way to control this from ifupdown (for both ISC
>> and dhcpcd)?
>
>Not at the moment, no.
OK.
>IMO if you need to make changes that deep it's alright to have to go to the
>dhcp client config files to do it honestly, unless you disagree?
I find “hands off my resolv.conf” (the standard config tends to not
change the system hostname, domain and timezone, but since I saw this
in the manpage I added it) is the one single change to DHCP client
configuration I need in most places where I need any. This could also
be handled by the hooks or something, but if there isn’t any mechanism
for this at the moment, don’t lose any time for this, the other issues
are more important.
Just I don’t consider “hands off my hostname, domain and timezone”
something I should even *have* to specify, and “hands off my resolv.conf”
the one useful high-level toggle here (defaulting to write it is okay,
but perhaps I run a recursive resolver myself and have that in the conf).
>> Note that it could also be started from /etc/init.d/dhcpcd, so
>> ordering there also needs to be correct.
>
>Naturally, but I do think that should also be possible. I'm just not
>familliar with sysvinit's ways.
Yes, I was just pointing out that not everyone uses systemd.
An X-Start-Before: in the LSB pseudoheader should suffice, but
the debian-init-diversity mailing list is available to help,
once you have a concrete setup.
>> Likely not going to happen, as it has no security support.
>
>Well given that we've shipped isc-dhcp-client in Trixie already without
>properly moving all users over that ship has kinda already sailed. Now we
>have to support it. See #1106121.
It’s not the first package we ship in a stable release for users’
convenience that has no support. (And it allows people to decouple
“upgrade to trixie” from “switch to kea”, as kea in bookworm was…
not quite ready.)
>If we remove the release-notes notice at least fewer users might try to
>switch and consequently run into problems. Idk. if that'd really be a
>good idea its just a thought.
If the SRM agree and you manage to get this fixed in sid, I’d like
for the fixes to end up in trixie, so less people run the unsupported
software (and it’d look bad for Debian if we recommended people to
stay on it for one more release, when the client is already… four?
years dead upstream).
>Eeeeerm. Well. I've seen dhclient crash mysteriously after long runtime
>leaving systems without IPs somehow. So that's not a sure bet
How? If it crashes it won’t remove the currently working IPs.
But at least IPv6 will still work in that case, as it’s kernel-
managed ;) (see above…), so it’s recoverable.
>Yeah, thats how things should look now. LMK if you see something different.
OK, I’ll give this a shot.
Thanks,
//Thorsten
--
Thorsten Glaser
Linux / Unix Developer
Tel.: +49 160 91168501
E-Mail: tglaser@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / https://www.b1-systems.de/
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt, HRB 3537
Reply to: