isc-dhcp: should we start phasing it out?

[Dan Streetman]

On Tue, May 24, 2022 at 5:06 AM Dimitri John Ledkov
<dimitri.ledkov at canonical.com> wrote:
>
> On Mon, 16 May 2022 at 20:22, Dan Streetman <ddstreet at ieee.org> wrote:
> >
> > On Mon, May 16, 2022 at 3:06 PM Steve Langasek
> > <steve.langasek at ubuntu.com> wrote:
> > >
> > > 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.
> >
> > There are still users of 'dhclient', especially in some cloud environments.
> >
> > I suspect there will be a demand for it until someone updates systemd
> > to be able to replace its functionality, with something like:
> >
> > $ networkctl dhclient eth0
> >
> > That would require an upstream discussion to figure out the exact
> > usage and implement it, of course.
>
> $ sudo netplan set ethernets.eth0.dhcp4=true; sudo netplan apply

that's permanent, though. I think the use case (at least a significant
amount, if not majority amount) is for transient dhcp on an interface.
For example, I want to run dhcp on eth1 but I don't want that happen
next boot, just temporarily right now.

>
> Maybe we want to add `--apply` flag.
>
> A networkctl command that creates an ephemeral .network file in /run
> and reconfigures the link might be ok as well, similar to what
> systemd-run does. But I very much prefer netplan.
>
> >
> > > 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
> > >
>
> We already have some netplan compatibility in our initramfs. At one
> point I was experimenting to add full netplan & networkd to the
> initramfs, but that side project stalled.
>
> The largest chunks of work to switch to systemd-based initramfs would
> be migrating installer initramfs features (casper &
> cloud-initramfs-tools).
>
> --
> okurrr,
>
> Dimitri
>
> > >  - 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
> > > --
> > > ubuntu-devel mailing list
> > > ubuntu-devel at lists.ubuntu.com
> > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
> >
> > --
> > ubuntu-devel mailing list
> > ubuntu-devel at lists.ubuntu.com
> > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel