isc-dhcpd vs udhcpd

[Ondřej Surý]

Hi,

while revising bind9 udebs, KiBi suggested that non-Linux architectures
might be using isc-dhcpd instead of udhcpd due some problems and it
might be a good idea to revise the decision now that we have a busybox
maintainer?

Cheers,

[James Clarke]

Post by Ondřej Surý
Hi,
while revising bind9 udebs, KiBi suggested that non-Linux architectures
might be using isc-dhcpd instead of udhcpd due some problems and it
might be a good idea to revise the decision now that we have a busybox
maintainer?

That's not going to work right now for two reasons:

1. Busybox still FTBFS on these (I have a patch series submitted upstream that
needs minor revisions, so this should resolve itself soon).

2. udhcp's Config.src has "select PLATFORM_LINUX", so building udhcp{c,d}
isn't even attempted (it includes linux/filter.h and linux/if_packet.h).

I'm sure it could be ported, but someone would need to do that work.

Regards,
James

[Chris Boot]

Post by Ondřej Surý
Hi,
while revising bind9 udebs, KiBi suggested that non-Linux architectures
might be using isc-dhcpd instead of udhcpd due some problems and it
might be a good idea to revise the decision now that we have a busybox
maintainer?

I presume you actually mean the DHCP client here (isc-dhcp-client and
udhcpc) as opposed to the server implementation. Please correct me if
I'm wrong about this.

Speaking as one of the two busybox maintainers, we'd certainly be happy
to help make sure udhcpc is usable across as many systems as possible in
Debian. As James has mentioned the udhcpc code is Linux-specific
currently so needs additional porting work to non-Linux architectures,
but we'd be happy to work with porters and liaise with upstream to get
patches integrated.

I'm going to personally refrain from suggesting one option over another
as I feel it represents a conflict of interest, but I'm definitely
interested in levelling the playing field and making it more difficult
to pick between the two!

Cheers,
Chris

[Samuel Thibault]

Hello,

Post by Chris Boot
Speaking as one of the two busybox maintainers, we'd certainly be happy
to help make sure udhcpc is usable across as many systems as possible in
Debian. As James has mentioned the udhcpc code is Linux-specific
currently so needs additional porting work to non-Linux architectures,
but we'd be happy to work with porters and liaise with upstream to get
patches integrated.

We'll be happy to work with you on this. Divergence between linux and
non-linux ports have always provided headaches to us :)

Samuel

[Ondřej Surý]

Just to rephrase my original request then...

Personally, I don't really care about the DHCP client used in d-i, but I
do care about complexity in the bind9 packaging.

The --without-openssl support will go away (probably in BIND 9.13) and I
would rather unify the two sets of libraries into one. If that means
shuffling symbols around, so we don't end up with libxml2, libjson and
libgeoip in d-i, then I will rather make it happen in upstream

So the main difference between export and non-export libraries are:

Are these a problem?
* krb5 / gssapi # guess this is a problem, as krb5 has not udebs
* libcap2 # guess not, there's a udeb

These have to definitely go:
* libgeoip1 (I have no idea why it's linked to libisc)
* libxml2 (I have no idea why it's linked to libisc)

Cheers,
Ondrej
--

Post by Ondřej Surý
while revising bind9 udebs, KiBi suggested that non-Linux architectures
might be using isc-dhcpd instead of udhcpd due some problems and it
might be a good idea to revise the decision now that we have a busybox
maintainer?

Ubuntu has used dhclient for a long time now in d-i. I think there are
at least two parts to it: a) consistency across architectures - it is
weird to support two completely different implementations and b)
actually use the same implementation than the installed system would
rather than something embedded that has less features.
I recall times at work where we had severe issues with dhclient not
staying around in the background refreshing the lease. I have no idea if
this is still the case, I just recall that -1 behavior was kind of a
mess. Back then we bumped the lease duration. If picking udhcpc means
that we can address such issues more easily, that's better.
At the same time people know how to configure dhclient and can use a
similar config as in the installed system. My understanding is that
udhcpc has essentially no options at all (like sending additional DHCP
options).
netcfg also did not receive that much love in recent times and I wonder
if something more integrated wouldn't be better than the hacks layered
on top of each other to make it work we have today. But at the same time
I know that something modern like systemd-networkd won't work for d-i
either because of architecture consistency. :/
Kind regards
Philipp Kern

[Philipp Kern]

Post by Ondřej Surý
while revising bind9 udebs, KiBi suggested that non-Linux architectures
might be using isc-dhcpd instead of udhcpd due some problems and it
might be a good idea to revise the decision now that we have a busybox
maintainer?

Ubuntu has used dhclient for a long time now in d-i. I think there are
at least two parts to it: a) consistency across architectures - it is
weird to support two completely different implementations and b)
actually use the same implementation than the installed system would
rather than something embedded that has less features.

I recall times at work where we had severe issues with dhclient not
staying around in the background refreshing the lease. I have no idea if
this is still the case, I just recall that -1 behavior was kind of a
mess. Back then we bumped the lease duration. If picking udhcpc means
that we can address such issues more easily, that's better.

At the same time people know how to configure dhclient and can use a
similar config as in the installed system. My understanding is that
udhcpc has essentially no options at all (like sending additional DHCP
options).

netcfg also did not receive that much love in recent times and I wonder
if something more integrated wouldn't be better than the hacks layered
on top of each other to make it work we have today. But at the same time
I know that something modern like systemd-networkd won't work for d-i
either because of architecture consistency. :/

Kind regards
Philipp Kern