I've been trying to make sense of the NEWS item in isc-dhcp-client (that alternatives are needed) in combination with the functionality of
ifupdown and what the implications are for debian upgrades generally.

isc-dhcp-client as of the last upgrade is telling users to stop using it
(the default dhcp client for debian).

ifupdown (the traditional tool for managing networking on debian
systems) has a Recommends on "isc-dhcp-client | dhcp-client".
"dhcp-client" is a virtual package provided by "dhcpcanon" (version
0.8.5, which hasn't been touched in 4 years), "isc-dhcp-client", and
"dhcpcd5" (which will trash a working configuration managed by ifupdown
if installed, as it will try to take over interfaces currently set,
e.g., to manual). This seems suboptimal at best.

I believe that ifupdown will attempt to use udhcpd if installed, which
should be a mostly-transparent change (except for the potential loss of
lease information and any customization of dhclient scripts) but it
isn't even on the ifupdown recommends list.

ifupdown also (used to?) use pump, but that package went away a long
time ago.

So what's the path forward, maintaining compatibility and not breaking
systems upgrading from current stable? Do we come up with a dhcpcd5
variant that *only* touches interfaces it is directed to touch via /etc/network/interfaces? Do we add udhcpcd to the "dhcp-client" virtual
package and/or make it the default for ifupdown? Do we fork isc's dhcp
suite and just continue to use dhclient? Revive pump? Something else?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[apologies to package aliases getting this twice due to autocomplete fail]

I've been trying to make sense of the NEWS item in isc-dhcp-client
(that alternatives are needed) in combination with the functionality
of ifupdown and what the implications are for debian upgrades
generally.

isc-dhcp-client as of the last upgrade is telling users to stop using
it (the default dhcp client for debian).

ifupdown (the traditional tool for managing networking on debian
systems) has a Recommends on "isc-dhcp-client | dhcp-client".
"dhcp-client" is a virtual package provided by "dhcpcanon" (version
0.8.5, which hasn't been touched in 4 years), "isc-dhcp-client", and
"dhcpcd5" (which will trash a working configuration managed by
ifupdown if installed, as it will try to take over interfaces
currently set, e.g., to manual). This seems suboptimal at best.

I believe that ifupdown will attempt to use udhcpd if installed, which
should be a mostly-transparent change (except for the potential loss
of lease information and any customization of dhclient scripts) but it
isn't even on the ifupdown recommends list.

ifupdown also (used to?) use pump, but that package went away a long
time ago.

So what's the path forward, maintaining compatibility and not breaking
systems upgrading from current stable? Do we come up with a dhcpcd5
variant that *only* touches interfaces it is directed to touch via /etc/network/interfaces? Do we add udhcpcd to the "dhcp-client"
virtual package and/or make it the default for ifupdown? Do we fork
isc's dhcp suite and just continue to use dhclient? Revive pump?
Something else?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

El 08/05/22 a las 11:24, Michael Stone escribió:

[apologies to package aliases getting this twice due to autocomplete fail]

I've been trying to make sense of the NEWS item in isc-dhcp-client (that alternatives are needed) in combination with the functionality of ifupdown and what the implications are for debian upgrades generally.

isc-dhcp-client as of the last upgrade is telling users to stop using it
(the default dhcp client for debian).

ifupdown (the traditional tool for managing networking on debian systems)
has a Recommends on "isc-dhcp-client | dhcp-client". "dhcp-client" is a virtual package provided by "dhcpcanon" (version 0.8.5, which hasn't been touched in 4 years), "isc-dhcp-client", and "dhcpcd5" (which will trash a working configuration managed by ifupdown if installed, as it will try to take over interfaces currently set, e.g., to manual). This seems suboptimal at best.

I believe that ifupdown will attempt to use udhcpd if installed, which
should be a mostly-transparent change (except for the potential loss of
lease information and any customization of dhclient scripts) but it isn't even on the ifupdown recommends list.

ifupdown also (used to?) use pump, but that package went away a long time ago.

So what's the path forward, maintaining compatibility and not breaking systems upgrading from current stable? Do we come up with a dhcpcd5 variant that *only* touches interfaces it is directed to touch via /etc/network/interfaces? Do we add udhcpcd to the "dhcp-client" virtual package and/or make it the default for ifupdown? Do we fork isc's dhcp suite and just continue to use dhclient? Revive pump? Something else?

OpenBSD maintains its own fork of dhclient, just to list another
alternative.
I haven't been able to take the time to work on this, but it is on the
top of my ToDo list.

Cheers,

-- S

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRZVjztY8b+Ty43oH1itBCJKh26HQUCYngWtgAKCRBitBCJKh26 HacNAQD+p+wCVD+CowQbWW6KAPe+Nc5A9efLUAEbSKRXfUmcHgD+Mw0FmmzSnUyu SuJESRy7AsxLG0eNTpT3Yniz1KAS0A8=
=0mji
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

08.05.2022 18:24, Michael Stone wrote:

[apologies to package aliases getting this twice due to autocomplete fail]

I've been trying to make sense of the NEWS item in isc-dhcp-client (that alternatives are needed) in combination with the functionality of ifupdown
and what the implications are for debian upgrades generally.

isc-dhcp-client as of the last upgrade is telling users to stop using it (the default dhcp client for debian).

ifupdown (the traditional tool for managing networking on debian systems) has a Recommends on "isc-dhcp-client | dhcp-client". "dhcp-client" is a
virtual package provided by "dhcpcanon" (version 0.8.5, which hasn't been touched in 4 years), "isc-dhcp-client", and "dhcpcd5" (which will trash a
working configuration managed by ifupdown if installed, as it will try to take over interfaces currently set, e.g., to manual). This seems suboptimal
at best.

I believe that ifupdown will attempt to use udhcpd if installed, which should be a mostly-transparent change (except for the potential loss of lease
information and any customization of dhclient scripts) but it isn't even on the ifupdown recommends list.

Yes ifupdown knows about udhcpd. I dunno how seriuos this one is, the udhcpcd from busybox.
We use it in many different cases locally, and a few times I used it on a regular linux
client in various public networks, it is scriptable (it relies on the script to do the
actual work). It is maintained, - well, hopefully, - and in debian, I maintained this
package for quite some years locally before, next stepped up as debian maintainer of
busybox package, and continue to maintain it locally for another several years. Recently
I thought about giving it another try to make it in good shape in debian, and others
are doing their work there too.

busybox is recommended by initramfs-tools, so it is installed on all debian systems
where install-recommends is not explicitly set to false, so it is always available,
more or less (the udhcpcd package is just a symlink to busybox).

But I never really thought about it as an alternative to "big" dhcp client. I dunno
why, maybe because I always treated busybox as a "small brother" not ready for anything serious.

Overall it just works, especially after some tweaks to its script. Maybe I should
give it another try too, I dunno.

What's up with ISC dhclient?

Thanks,

/mjt

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, May 08, 2022 at 11:24:12AM -0400, Michael Stone wrote:

[apologies to package aliases getting this twice due to autocomplete fail]

I've been trying to make sense of the NEWS item in isc-dhcp-client (that alternatives are needed) in combination with the functionality of ifupdown and what the implications are for debian upgrades generally.

isc-dhcp-client as of the last upgrade is telling users to stop using it
(the default dhcp client for debian).

ifupdown (the traditional tool for managing networking on debian systems)
has a Recommends on "isc-dhcp-client | dhcp-client". "dhcp-client" is a virtual package provided by "dhcpcanon" (version 0.8.5, which hasn't been touched in 4 years), "isc-dhcp-client", and "dhcpcd5" (which will trash a working configuration managed by ifupdown if installed, as it will try to take over interfaces currently set, e.g., to manual). This seems suboptimal at best.

I believe that ifupdown will attempt to use udhcpd if installed, which
should be a mostly-transparent change (except for the potential loss of
lease information and any customization of dhclient scripts) but it isn't even on the ifupdown recommends list.

ifupdown also (used to?) use pump, but that package went away a long time ago.

So what's the path forward, maintaining compatibility and not breaking systems upgrading from current stable? Do we come up with a dhcpcd5 variant that *only* touches interfaces it is directed to touch via /etc/network/interfaces? Do we add udhcpcd to the "dhcp-client" virtual package and/or make it the default for ifupdown? Do we fork isc's dhcp suite and just continue to use dhclient? Revive pump? Something else?

Not an answer to your question, but a related issue I'll mention here.

Ubuntu no longer uses isc-dhcp by default, because it no longer uses
ifupdown; NetworkManager and networkd both have their own implementations of dhcp clients which are used by preference. *However*, isc-dhcp is still installed as part of all Ubuntu systems, because it is the only client implementation that integrates with initramfs-tools (/usr/share/initramfs-tools/hooks/zz-dhclient) so if you are using nfsroot
or any other network-based rootfs, it appears to still be the only game in town. It would be a good idea to make sure as part of the deprecation of isc-dhcp-client that we get initramfs integration of whatever is the
preferred replacement.

--
Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErEg/aN5yj0PyIC/KVo0w8yGyEz0FAmJ4IuUACgkQVo0w8yGy Ez2Jew/+IhDZt7RsJODUxImbDXRmSIYL0WbkeVPcoUDDpIdrMwIC96nrFrmswcGC uJQHdD3cs8u6CT/Vm/z/xX7jIEscCvDcDZOVoeE+Y7JSgTHknNrrV/EWqiigqQrt W3SX+S9haso7I3O2+8fW2Td3WR3Vi/9L1FVWkbkl5yDHHK1h9afrEiXOQwxDg/JX WZ+WchFsXuM/N4ApMXjjh0vz3BuQNJr6t6U2CJcCD+HVEVg0QwBdHyqLcImDdCT+ jgac/wf/JKRDqFTDEg9NbY+FdUhIkb1kM4hVqHjNeH1I8xcpDmR9rUDsBiDNGaa9 iAMr0TOOowVREyMUT4T+E4kD9L64OOaArQ6FHyaHDg2iGmEKcUuHyEsp9/k0SXHW Nk3Gbds8XFEOrKOGWTOIQnY/nE/crLBLJPcgQPTfJj11Pevsuf1FJA3TT6aGQcwf kotbxo5jmiedTIU+v09VlmnZetjeSdO31C342RT7OPOCyAUnnqU+lKx1xpaIl8Vj oq5SZe78KkHgxSrUZV518x5tAK7GzEWhSoztxawhYqOESD76nan9jamIFHtbScIf 6RmJ1hkwtmeTDqOTxZdh

On 2022-05-08 2:07 p.m., Steve Langasek wrote:

On Sun, May 08, 2022 at 11:24:12AM -0400, Michael Stone wrote:

I've been trying to make sense of the NEWS item in isc-dhcp-client (that
alternatives are needed) in combination with the functionality of ifupdown >> and what the implications are for debian upgrades generally.

I figure I'll copy the ifupdown2 package in here as well, as they are a replacement for ifupdown in some installations. [if they aren't tracking changes to ifupdown]

isc-dhcp-client as of the last upgrade is telling users to stop using it
(the default dhcp client for debian).

ifupdown (the traditional tool for managing networking on debian systems)
has a Recommends on "isc-dhcp-client | dhcp-client". "dhcp-client" is a
virtual package provided by "dhcpcanon" (version 0.8.5, which hasn't been
touched in 4 years), "isc-dhcp-client", and "dhcpcd5" (which will trash a
working configuration managed by ifupdown if installed, as it will try to
take over interfaces currently set, e.g., to manual). This seems suboptimal >> at best.

I believe that ifupdown will attempt to use udhcpd if installed, which
should be a mostly-transparent change (except for the potential loss of
lease information and any customization of dhclient scripts) but it isn't
even on the ifupdown recommends list.

ifupdown also (used to?) use pump, but that package went away a long time
ago.

So what's the path forward, maintaining compatibility and not breaking
systems upgrading from current stable? Do we come up with a dhcpcd5 variant >> that *only* touches interfaces it is directed to touch via
/etc/network/interfaces? Do we add udhcpcd to the "dhcp-client" virtual
package and/or make it the default for ifupdown? Do we fork isc's dhcp suite >> and just continue to use dhclient? Revive pump? Something else?

Not an answer to your question, but a related issue I'll mention here.

Ubuntu no longer uses isc-dhcp by default, because it no longer uses ifupdown; NetworkManager and networkd both have their own implementations of dhcp clients which are used by preference. *However*, isc-dhcp is still installed as part of all Ubuntu systems, because it is the only client implementation that integrates with initramfs-tools (/usr/share/initramfs-tools/hooks/zz-dhclient) so if you are using nfsroot
or any other network-based rootfs, it appears to still be the only game in town. It would be a good idea to make sure as part of the deprecation of isc-dhcp-client that we get initramfs integration of whatever is the preferred replacement.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael Hudson-Doyle <michael.hudson@canonical.com> writes:

Well busybox's udhcpc would seem a likely candidate here -- but its IPv6 support (iirc the reason we switch to dhclient from klibc's ipconfig in Ubuntu's initramfs, at least) is described as incomplete.

udhcpc is a very good IPv4 candidate indeed. The ability to run over
any IP interface makes it better than the ISC dhclient IMHO.

As for DHCPv6 - we do have both dibbler and WIDE clients which are both
DHCPv6 only. Unfortunately, the upstream state and future of both aren't
any better than the ISC dhclient.

Maybe look at the OpenWrt odhcp6c? Needs packaging, but at least it has
an upstream. https://github.com/openwrt/odhcp6c The combined RA +
DHCPv6 handling is a bit weird. But it does fill a hole in the current ifupdown where RA handling (and specifically dynamically assigned
default routers) is left out. Yes, it is handled by the kernel, but
that's not what users expect or what other alternatives like NM or
networkd does. So ifupdown + odhcp6c will look like more of an
NM/networkd alternative than any of the existing DHCPv6 pakcages.

Having different clients for v4 and v6 isn't a problem - one could even
see it as a feature. The protocols do have a few things in common, but
the differences are big enough to make a combined client look like
something Frankenstein created.

Makes more sense to try to standardise file system locations for the few settings which makes sense in both protocols, like the DUID (for RFC
4361 compliant client identifiers).

BTW, how about replacements for isc-dhcp-relay? We have
wide-dhcpv6-relay and dibbler-relay for DHCPv6, with the same issue as
the clients, but are there any DHCP alternatives?


.
Bjørn

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 2022-05-11 at 11:38 +0200, Bjørn Mork wrote:

Michael Hudson-Doyle <michael.hudson@canonical.com> writes:

Well busybox's udhcpc would seem a likely candidate here -- but its IPv6 support (iirc the reason we switch to dhclient from klibc's ipconfig in Ubuntu's initramfs, at least) is described as incomplete.

udhcpc is a very good IPv4 candidate indeed. The ability to run over
any IP interface makes it better than the ISC dhclient IMHO.

As for DHCPv6 - we do have both dibbler and WIDE clients which are both DHCPv6 only. Unfortunately, the upstream state and future of both aren't
any better than the ISC dhclient.

Maybe look at the OpenWrt odhcp6c? Needs packaging, but at least it has
an upstream. https://github.com/openwrt/odhcp6c

[...]

I already packaged this because I wanted prefix delegation, but I never
got around to integrating it with ifupdown. For that reason I only
uploaded it to experimental. I would be happy to hand over to a more
active maintainer, or to co-maintain it.

Ben.


--
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmKC9ysACgkQ57/I7JWG EQmSmhAAsRl9UgETzjYyeTJKMOs8Tpn4nJClAmWknC+RCFeprP1Cz6G4V2tiYEHm /KhyqjwWU8dyo/W0auUVfBGPwaGqC60gtzV8qKICPOT321n+1417z8QFjjZ51iaJ PSdBOPh6n6XMBuWl5Q4fpMizIk2Pnn830xvV7k3GWGx0daWAy8s4fUFdmmjMLLBr h5F13IkdBs3JuWOhQE/EnU7vEbVGztsmtA4KjrMWaQiEgNfGCyS6hE5a1JsDRRQf 1uO8+FgtrtQgzCclQ5onVCegyW3cxzVBliSIck2N2HjWEOZKU45Qe3LiPkCqtL/C F9xoC+C4s2ySl4WrtjNk8L0wymt7gJnHGJlV+1xH6+E1rnS0xZybuWhnXYSK68bO O7nOQAArc/cIySjKKYafNCQ+RzQg2JpbgUt63SnFOfA4+P/m0LeSoGFL/TXIofx4 xldVUqM6kdyc7QlreZwmn0icAluIiLrQ4FmEeGJdgXcigXre8Dgh2NHjeGFHs22a u9VBxeQc4m8ePjqCCA1j+CuPHm6E9q9pJHRKHa9PACO0SsUtq3pcw5FJVO4Q+a1V Xu20Imddq4mLJnHzQ02/wbFonUK/wQ1YwpZabxelP3ta8eyoQgsF5QhunTaUTolR a2PryfPCY+FqzmS2grukMOFSpvNb0rWQbxkPvL6dWiZhVf3Y97I=
=a8eH
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)