isc-dhcp: should we start phasing it out?

[Steve Langasek]

Hi Andreas,

On Mon, May 16, 2022 at 02:34:30PM -0300, Andreas Hasenack wrote:
> Alternatives that come to mind are:
> - kea, of course (from ISC). dhcp server only.
> - dnsmasq (for small installations?), also server
> - systemd-networkd itself obviously does the client part
> - others?

> isc-dhcp is such a classic that it is undoubtedly referenced in many
> places, so phasing it out might be difficult. On the server, Kea is
> not a drop-in replacement.

As I mentioned at
<https://lists.debian.org/debian-devel/2022/05/msg00047.html>, isc-dhcp is
no longer used out of the box as the DHCP client in Ubuntu, on either
desktop or server; server uses systemd-networkd's internal dhcp client
implementation, and desktop uses NetworkManager's.  The only reason that
isc-dhcp is still installed by default is for the initramfs: because we
support nfsroot, iscsi, remote disk unlock via dropbear, etc.

Several suggestions of path forward on support for dhcp in the initramfs, in
no particular order:

 - work with klibc upstream to extend ipconfig to be a suitable DHCP client
   for the initramfs (requires DHCP support)

 - migrate to a systemd-based initramfs everywhere, and use systemd-networkd

 - Repackage isc-dhcp to provide an 'isc-dhcp-initramfs' package that no
   longer provides integration with the main system, so that it can continue
   to be used for initramfs without having a large ongoing support surface
   (but, this doesn't remove the need for security support)


> We also have the udebs, but with subiquity being the installer now we
> probably don't need to worry about these anymore?

We definitely don't need to worry about udebs in future Ubuntu releases;
they aren't even built in Launchpad in the current series.

> rdeps at https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.kinetic/rdepends/isc-dhcp/

> Removing isc-dhcp would also allow us to reduce the need of old compat
> src:bind9-libs package, probably even drop it.

Ugh

> Could we perhaps start with phasing out the client, get its rdeps to
> use alternatives, and then stop building it, and eventually get to the
> server? This could be a lot of work, as I said, isc-dhcp is a classic,
> but if upstream is shifting its focus elsewhere, soon we will be
> alone.

I think you'll find that phasing out the client is much more work than
phasing out the server, given the ways the client is integrated in other
packages.

> Reverse-Depends
> * cloud-init

Another example of client integration that's going to require attention;
cloud-init uses isc-dhcp-client to be able to query specific dhcp attributes
in early boot used to identify the cloud metadata service.

> * dracut-network
> * isc-dhcp-client-ddns [amd64 arm64 armhf ppc64el s390x]
> * libguestfs0 [amd64 arm64 armhf ppc64el s390x]
> * netscript-2.4
> * network-manager [amd64 arm64 armhf ppc64el s390x]

I think network-manager's dependency on isc-dhcp-client is vestigial.  You
will not find any instances of isc-dhcp-client running on an Ubuntu 22.04
desktop system.

Cheers,
-- 
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 at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20220516/51e53720/attachment.sig>