Bug#995189: RFH: isc-dhcp

Martin-Éric Racine

unread,

Sep 27, 2021, 1:30:03 PM9/27/21

to

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian...@lists.debian.org
Control: affects -1 src:isc-dhcp

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

The ISC DHCP suite has a lenghty list of bug reports that have been left unattended. Some bugs date back to DHCP 3 or even earlier.

Additionally, recent upstream releases are still unpackaged. One release came out well ahead of the Bullseye freeze, a bug report requesting its packaging was filed, but it remains unanswered.

Leaving a package with a priority Important in such utter state of neglect is unacceptable.

At this point, it has become clear that, at the very least, its maintainers need help, hence why I filed this WNPP bug.

- -- Martin-Éric

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

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmFR/noACgkQrh+Cd8S0
17apRA/9EnsfZnMsWBz07360Z8fqdoZWteKo3Weqfa7lhfVXqHaaWKR1k83uY3gO
DEP+NGdDqMs5LVhQ4eDvEeMze2utCx52C2GFHebksI1QyaGruj9PSEu0j5CIBlKu
v/fXdk9BXk3oQ4bJoKM8HBifNVx/ICb1X/4wdr78dy4ZYQLB+XLkbQ5DGn/UJ4mr
VQctq/uxjFFY1zD+C5Mu7jG/X8eEbSXcshtMkxcoO3GW0c/Bmmy7Rm2exs1zHOkX
fAiULeThKPJkpYgbiw6+iPZiJqWeeoDtXo8gInuw8riP3sua9PxhEwKnZBEcACJ3
BAT5ethXxAhC5Ecd+pzuqzlTrP9FYDqPyie3If0A9XK1sDPsnnn5yERWeuAn8L2E
7tZ5BAuBCEskQ+Z9Q1MqgK8/yeabzZRzmd2VCy+FXMfENjhDeGm1YefPSD80mebG
UGVbN1MC9274pv6oomPkM6fQidIcbUIZDlBj2qJOxFWgXuv3jcnzWs4+XV9VssiD
s/B5+YC9XvItCpZKjAUBaXDUX/hzPqFoseRygRPChxgrzyvP7ChWSz1JY9G73EYg
ITe7KHQ9wqAMPJYmUp0ZmcACn9tCWH/xSt99KLrnYURPxNHcYpG8+Pwr5r9swJ50
fjkEyEZWCNUu6u8uUvSx5sPrc29aIpuk+QXeBJIsAB24roy8ONo=
=5hUD
-----END PGP SIGNATURE-----

Noah Meyerhans

unread,

Sep 27, 2021, 6:50:03 PM9/27/21

to

On Mon, Sep 27, 2021 at 08:25:14PM +0300, Martin-Éric Racine wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> The ISC DHCP suite has a lenghty list of bug reports that have been left unattended. Some bugs date back to DHCP 3 or even earlier.
>
> Additionally, recent upstream releases are still unpackaged. One release came out well ahead of the Bullseye freeze, a bug report requesting its packaging was filed, but it remains unanswered.
>
> Leaving a package with a priority Important in such utter state of neglect is unacceptable.
>
> At this point, it has become clear that, at the very least, its maintainers need help, hence why I filed this WNPP bug.

It's worth noting also that ISC's DHCP client, packaged as
isc-dhcp-client from the isc-dhcp source package, is considered EOL
upstream. As it's still the first recommended DHCP client by ifupdown,
and ifupdown is still Priority: important, most systems are likely to be
installing isc-dhcp-client.

We may want to start a broader conversation about the default DHCP
client package in Debian. The maintainers of these packages should
obviously be involved.

For what it's worth, my preference would be transition to
systemd-networkd with bookworm. If we keep the ifup/ifdown commands
from ifupdown at all, I think they should be fairly this wrappers around
their networkd equivalents. I don't think we should install something
like netplan by default.

And, of course, environments that currently pull in NetworkManager
should continue to do so if it makes sense. Although by default, I
believe that NetworkManager uses the ISC dhclient as its DHCP client, so
we may want to make changes there. It has a built-in DHCP client, but
seems to prefer an external client if one is available.

(Of course, this conversation may already be taking place, but if so
I've missed it. Please feel free to point me in the right direction.)

noah

signature.asc

Marco d'Itri

unread,

Sep 28, 2021, 2:00:07 AM9/28/21

to

On Sep 28, Noah Meyerhans <no...@debian.org> wrote:

Should it be mentioned what the new recommended DHCP server for general
use will be?

> For what it's worth, my preference would be transition to
> systemd-networkd with bookworm.

I think that a good default would be systemd-networkd for servers and
NetworkManager for systems with Wi-Fi or a GUI.

> If we keep the ifup/ifdown commands
> from ifupdown at all, I think they should be fairly this wrappers around
> their networkd equivalents.

This should be quite easy.

> I don't think we should install something
> like netplan by default.

I agree: it only adds complexity.

> (Of course, this conversation may already be taking place, but if so
> I've missed it. Please feel free to point me in the right direction.)

No, I think that we did not have this flamewar yet.

--
ciao,
Marco

signature.asc

Richard Laager

unread,

Sep 28, 2021, 2:50:03 AM9/28/21

to

On 9/27/21 9:15 PM, Marco d'Itri wrote:
> On Sep 28, Noah Meyerhans <no...@debian.org> wrote:
>
> Should it be mentioned what the new recommended DHCP server for general
> use will be?

ISC Kea?

I haven't converted to it, but that's their replacement for dhcpd.

> I think that a good default would be systemd-networkd for servers and
> NetworkManager for systems with Wi-Fi or a GUI.

That seems reasonable.

>> I don't think we should install something
>> like netplan by default.

> I agree: it only adds complexity.

I personally use netplan everywhere.

As to what should be the distro default, I'm not sure I am convinced
either way, but to argue the other side... There is some value in using
netplan by default. Some random thoughts:

This default would match Ubuntu. (I value reducing that delta. Not
everyone does, and that's fine.)

netplan can configure both systemd-networkd and NetworkManager (though
I've only used it with systemd-networkd).

In my non-trivial configurations, the netplan YAML input is half as many
lines as its networkd output. This is with the input including a bit of
comments and the boilerplate, disabling dhcp, and using YAML's more
verbose list syntax (separate lines vs one line). I don't see anything
wrong with its output that I could simplify.

Again, in this non-trivial configuration, I think it's more useful to
have one netplan YAML file than 24 separate networkd files. This is
especially true when I'm building this file from an Ansible template and
most of it (by volume) is built by loops.

In the trivial case, it's 19 lines of netplan (16 if you exclude the
stock comment) vs 25 lines of systemd-networkd, both in single files.
That's not a huge difference.

--
Richard

Andrej Shadura

unread,

Sep 28, 2021, 5:40:03 AM9/28/21

to

Hi,

On Tue, 28 Sep 2021, at 08:29, Richard Laager wrote:
>>> I don't think we should install something
>>> like netplan by default.
>> I agree: it only adds complexity.

> I personally use netplan everywhere.
>
> As to what should be the distro default, I'm not sure I am convinced
> either way, but to argue the other side... There is some value in using
> netplan by default. Some random thoughts:
>
> This default would match Ubuntu. (I value reducing that delta. Not
> everyone does, and that's fine.)
>
> netplan can configure both systemd-networkd and NetworkManager (though
> I've only used it with systemd-networkd).

As the downstream maintainer of netplan in Debian, I’d like to use this opportunity to invite more people to co-maintain it in Debian :) I like the idea of netplan, but unfortunately I never started using it myself, to it would only be fair if someone who actually uses it could help keeping it up-to-date in Debian.

--
Cheers,
Andrej

Marc Haber

unread,

Sep 28, 2021, 7:10:03 AM9/28/21

to

On Tue, 28 Sep 2021 04:15:58 +0200, Marco d'Itri <m...@Linux.IT> wrote:
>On Sep 28, Noah Meyerhans <no...@debian.org> wrote:
>> For what it's worth, my preference would be transition to
>> systemd-networkd with bookworm.
>I think that a good default would be systemd-networkd for servers and
>NetworkManager for systems with Wi-Fi or a GUI.

Afaik, NetworkManager uses an external DHCP client and thus is not a
solution for the problemt hat ISC DHCP client is EOL.

Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Marc Haber

unread,

Sep 28, 2021, 7:10:03 AM9/28/21

to

On Mon, 27 Sep 2021 15:48:25 -0700, Noah Meyerhans <no...@debian.org>
wrote:

>It's worth noting also that ISC's DHCP client, packaged as
>isc-dhcp-client from the isc-dhcp source package, is considered EOL
>upstream.

Same applies to the relay, doesn't it?

Vincent Blut

unread,

Sep 28, 2021, 7:40:03 AM9/28/21

to

Hi,

Le 2021-09-28 13:00, Marc Haber a écrit :
> On Tue, 28 Sep 2021 04:15:58 +0200, Marco d'Itri <m...@Linux.IT> wrote:
> >On Sep 28, Noah Meyerhans <no...@debian.org> wrote:
> >> For what it's worth, my preference would be transition to
> >> systemd-networkd with bookworm.
> >I think that a good default would be systemd-networkd for servers and
> >NetworkManager for systems with Wi-Fi or a GUI.
>
> Afaik, NetworkManager uses an external DHCP client and thus is not a
> solution for the problemt hat ISC DHCP client is EOL.

Starting with version 1.19.90-2, NetworkManager uses its internal DHCP client:

* Demote isc-dhcp-client to Suggests.
The DHCP client now defaults to "internal". This default can be
overridden at run time by setting the main.dhcp option in the
configuration file. The old default was "dhclient" and required
isc-dhcp-client. (Closes: #933545)

>
> Greetings
> Marc

Cheers,
Vincent

signature.asc

Michael Biebl

unread,

Sep 28, 2021, 7:50:03 AM9/28/21

to

Am 28.09.21 um 13:00 schrieb Marc Haber:

> On Tue, 28 Sep 2021 04:15:58 +0200, Marco d'Itri <m...@Linux.IT> wrote:
>> On Sep 28, Noah Meyerhans <no...@debian.org> wrote:
>>> For what it's worth, my preference would be transition to
>>> systemd-networkd with bookworm.
>> I think that a good default would be systemd-networkd for servers and
>> NetworkManager for systems with Wi-Fi or a GUI.
>
> Afaik, NetworkManager uses an external DHCP client and thus is not a
> solution for the problemt hat ISC DHCP client is EOL.

Not quite. Quoting man NetworkManager.conf

> dhcp
> This key sets up what DHCP client NetworkManager will use. Allowed values are dhclient, dhcpcd, and internal. The
> dhclient and dhcpcd options require the indicated clients to be installed. The internal option uses a built-in DHCP
> client which is not currently as featureful as the external clients.
>
> If this key is missing, it defaults to internal. If the chosen plugin is not available, clients are looked for in this
> order: dhclient, dhcpcd, internal.

In Debian, we do compile in support for dhclient and internal.
For dhcpcd there is a stale bug report [1]. If someone is interested in
that: I'd be ok in enabling support for dhcpcd if that someone adds an
autopkgtest for that.

Regards,
Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810151

OpenPGP_signature

Santiago Ruano Rincón

unread,

Sep 28, 2021, 9:10:03 AM9/28/21

to

El 28/09/21 a las 13:01, Marc Haber escribió:

> On Mon, 27 Sep 2021 15:48:25 -0700, Noah Meyerhans <no...@debian.org>
> wrote:
> >It's worth noting also that ISC's DHCP client, packaged as
> >isc-dhcp-client from the isc-dhcp source package, is considered EOL
> >upstream.
>
> Same applies to the relay, doesn't it?

Indeed. Just to give some references:

https://gitlab.isc.org/isc-projects/dhcp/:

Please note that this project is in maintenance mode - we are not
actively adding new functionality and may not respond to non-critical
issues.

https://www.isc.org/dhcp/:

ISC is developing a new DHCP server, Kea, which we intend to
eventually replace ISC DHCP in most server implementations. We
recommend that new implementers use Kea and implement ISC DHCP only if
Kea does not meet their needs. The Kea distribution does not currently
include either a client or a relay.

Regarding the server, I don't find very appealing to have to install a
relational DB along with the DHCP server.

About the client and server, if I am not wrong, about 3 years ago ISC
dhcp was the only implementation able to configure DHCPv6 clients by
their MAC addresses (thing that I needed at work). It is a pity that ISC
is giving less love to it. That said, the EOL date is still TBA
(https://www.isc.org/dhcp/)

-- Santiago

signature.asc

Vincent Bernat

unread,

Sep 28, 2021, 9:50:02 AM9/28/21

to

❦ 28 September 2021 01:29 -05, Richard Laager:

> As to what should be the distro default, I'm not sure I am convinced
> either way, but to argue the other side... There is some value in
> using netplan by default. Some random thoughts:

[...]

OTOH, netplan is just an abstraction above existing systems and does not
allow proper reconfiguration. ifupdown2 is also written in Python and
has an implementation of "ifreload -a" which just works.
--
Use statement labels that mean something.
- The Elements of Programming Style (Kernighan & Plauger)

Richard Laager

unread,

Sep 28, 2021, 12:30:03 PM9/28/21

to

On 9/28/21 8:44 AM, Vincent Bernat wrote:
> ❦ 28 September 2021 01:29 -05, Richard Laager:
>
>> As to what should be the distro default, I'm not sure I am convinced
>> either way, but to argue the other side... There is some value in
>> using netplan by default. Some random thoughts:
> [...]
>
> OTOH, netplan is just an abstraction above existing systems

Agreed.

> and does not
> allow proper reconfiguration.

What do you mean?

--
Richard

Vincent Bernat

unread,

Sep 28, 2021, 12:50:04 PM9/28/21

to

❦ 28 September 2021 11:16 -05, Richard Laager:

>>> As to what should be the distro default, I'm not sure I am convinced
>>> either way, but to argue the other side... There is some value in
>>> using netplan by default. Some random thoughts:
>> [...]
>> OTOH, netplan is just an abstraction above existing systems
>
> Agreed.
>
>> and does not
>> allow proper reconfiguration.
> What do you mean?

Make a change, reload your configuration, everything breaks. ifupdown2
is smart and will converge to the new configuration. Network Manager can
restart and minimize impact. AFAIK, systemd-networkd is as dumb as
ifupdown and does not know how to converge.

My point is that ifupdown2 was a possible successor to ifupdown but was
never adopted because written in Python. As netplan is written in
Python, ifupdown2 seems a far better replacement.
--
... A solemn, unsmiling, sanctimonious old iceberg who looked like he
was waiting for a vacancy in the Trinity.
-- Mark Twain

Richard Laager

unread,

Sep 28, 2021, 2:30:03 PM9/28/21

to

On 9/28/21 11:49 AM, Vincent Bernat wrote:
> ❦ 28 September 2021 11:16 -05, Richard Laager:
>
>>>> As to what should be the distro default, I'm not sure I am convinced
>>>> either way, but to argue the other side... There is some value in
>>>> using netplan by default. Some random thoughts:
>>> [...]
>>> OTOH, netplan is just an abstraction above existing systems
>>
>> Agreed.
>>
>>> and does not
>>> allow proper reconfiguration.
>> What do you mean?
>
> Make a change, reload your configuration, everything breaks.

Are you saying "everything breaks" as in:
A) the change is not applied (correctly) in the way that it would be if
the system was rebooted, or
B) the change is applied, but the human made a mistake in the config and
the change breaks things, or
C) B + the human gets cut off from e.g. SSH due to the error?

I would say (generally) that A is a bug, B is inherent to any tooling
applying a human's instructions, and C can be addressed by a rollback
function.

`netplan try` covers C (and thus also B).

`netplan apply` (and thus `netplan try`) have a caveat that they don't
remove virtual devices that are no longer described in the config. This
feels like an example of A, though it's arguable how much it matters.

> ifupdown2
> is smart and will converge to the new configuration. Network Manager can
> restart and minimize impact. AFAIK, systemd-networkd is as dumb as
> ifupdown and does not know how to converge.

What does converge mean in this context? Is something needing to apply
parts of the changes iteratively to arrive at the desired state?

> My point is that ifupdown2 was a possible successor to ifupdown but was
> never adopted because written in Python. As netplan is written in
> Python, ifupdown2 seems a far better replacement.

Am I understanding correctly that ifupdown2 is an alternative to
systemd-networkd and NetworkManager (as opposed to netplan, which is a
layer on top of them)?

Can you articulate why ifupdown2 is better than e.g. systemd-networkd +
netplan? I'm not looking for an exhaustive comparison or anything, but
just a brief statement or two if you're willing?

I've never used it, and if it's better than systemd-networkd + netplan,
I might consider switching.

--
Richard

Vincent Bernat

unread,

Sep 28, 2021, 3:50:03 PM9/28/21

to

❦ 28 September 2021 13:04 -05, Richard Laager:

> Are you saying "everything breaks" as in:
> A) the change is not applied (correctly) in the way that it would be if
> the system was rebooted, or
> B) the change is applied, but the human made a mistake in the config and
> the change breaks things, or
> C) B + the human gets cut off from e.g. SSH due to the error?
>
> I would say (generally) that A is a bug, B is inherent to any tooling
> applying a human's instructions, and C can be addressed by a rollback
> function.
>
> `netplan try` covers C (and thus also B).
>
> `netplan apply` (and thus `netplan try`) have a caveat that they don't
> remove virtual devices that are no longer described in the config.
> This feels like an example of A, though it's arguable how much it
> matters.

I am saying: remove the IP address from an interface, move it to a VLAN
instead. You'll get a duplicate IP.

>> ifupdown2
>> is smart and will converge to the new configuration. Network Manager can
>> restart and minimize impact. AFAIK, systemd-networkd is as dumb as
>> ifupdown and does not know how to converge.
>
> What does converge mean in this context? Is something needing to apply
> parts of the changes iteratively to arrive at the desired state?

It makes a diff between the current system state and the desired state
and applies actions to move to this state. The current system state
could be from a previous application of the tool or from manual action
from the operator, it does not matter (this is a second advantage of
such a tool). The above situation is handled perfectly.

>> My point is that ifupdown2 was a possible successor to ifupdown but was
>> never adopted because written in Python. As netplan is written in
>> Python, ifupdown2 seems a far better replacement.
> Am I understanding correctly that ifupdown2 is an alternative to
> systemd-networkd and NetworkManager (as opposed to netplan, which is a
> layer on top of them)?

Yes.
--
Don't use conditional branches as a substitute for a logical expression.

Marc Haber

unread,

Sep 29, 2021, 4:30:03 AM9/29/21

to

On Tue, 28 Sep 2021 13:34:12 +0200, Vincent Blut
<vincent...@free.fr> wrote:
>Le 2021-09-28 13:00, Marc Haber a écrit :
>> On Tue, 28 Sep 2021 04:15:58 +0200, Marco d'Itri <m...@Linux.IT> wrote:
>> >On Sep 28, Noah Meyerhans <no...@debian.org> wrote:
>> >> For what it's worth, my preference would be transition to
>> >> systemd-networkd with bookworm.
>> >I think that a good default would be systemd-networkd for servers and
>> >NetworkManager for systems with Wi-Fi or a GUI.
>>
>> Afaik, NetworkManager uses an external DHCP client and thus is not a
>> solution for the problemt hat ISC DHCP client is EOL.
>
>Starting with version 1.19.90-2, NetworkManager uses its internal DHCP client:

Ah, cool. I didn even realize that, congrats for the painless
migration.

Marc Haber

unread,

Sep 29, 2021, 4:30:03 AM9/29/21

to

On Tue, 28 Sep 2021 18:49:31 +0200, Vincent Bernat <ber...@debian.org>
wrote:

>Make a change, reload your configuration, everything breaks. ifupdown2
>is smart and will converge to the new configuration. Network Manager can
>restart and minimize impact. AFAIK, systemd-networkd is as dumb as
>ifupdown and does not know how to converge.

systemd-networkd is a really nice tool for the server market, as its
configuration file structure is really easy to use with configuration
management tools like ansible or puppet. And, server configuration
rarely changes.

Michael Biebl

unread,

Sep 30, 2021, 10:50:04 AM9/30/21

to

Hi Noah

Am 28.09.21 um 00:48 schrieb Noah Meyerhans:

> For what it's worth, my preference would be transition to
> systemd-networkd with bookworm.

Something I've been meaning to look into but never found the time for it
is to have d-i support systemd-networkd.

Anyone interested in hacking on that?

Michael

OpenPGP_signature

Lukas Maerdian

unread,

Sep 30, 2021, 12:10:04 PM9/30/21

to

Hi,

Thank you for considering netplan as the distro default in Debian!
I am the upstream netplan maintainer (and downstream maintainer of the
netplan.io package in Ubuntu) and would be happy to help with
implementing this switch to netplan. Also, I do have a few thoughts to
share wrt. this discussion.

>> Are you saying "everything breaks" as in:
>> A) the change is not applied (correctly) in the way that it would be if
>> the system was rebooted, or
>> B) the change is applied, but the human made a mistake in the config and
>> the change breaks things, or
>> C) B + the human gets cut off from e.g. SSH due to the error?
>>
>> I would say (generally) that A is a bug, B is inherent to any tooling
>> applying a human's instructions, and C can be addressed by a rollback
>> function.
>>
>> `netplan try` covers C (and thus also B).
>>
>> `netplan apply` (and thus `netplan try`) have a caveat that they don't
>> remove virtual devices that are no longer described in the config.
>> This feels like an example of A, though it's arguable how much it
>> matters.

B & C: ACK

Regarding A: We have just recently landed a change in upstream netplan
that allows to mitigate this exact problem, by passing the previous
state. netplan can then calculate the delta of virtual interfaces and
cleanup after itself (in some cases this can and is done automatically):
https://github.com/canonical/netplan/pull/231

>
> I am saying: remove the IP address from an interface, move it to a VLAN
> instead. You'll get a duplicate IP.

This sounds like another bug, that should be addressable in a similar
way to the fix mentioned above.

>
>>> ifupdown2
>>> is smart and will converge to the new configuration. Network Manager can
>>> restart and minimize impact. AFAIK, systemd-networkd is as dumb as
>>> ifupdown and does not know how to converge.
>>

>> What does converge mean in this context? Is something needing to apply
>> parts of the changes iteratively to arrive at the desired state?
>
> It makes a diff between the current system state and the desired state
> and applies actions to move to this state. The current system state
> could be from a previous application of the tool or from manual action
> from the operator, it does not matter (this is a second advantage of
> such a tool). The above situation is handled perfectly.
>
>>> My point is that ifupdown2 was a possible successor to ifupdown but was
>>> never adopted because written in Python. As netplan is written in
>>> Python, ifupdown2 seems a far better replacement.
>> Am I understanding correctly that ifupdown2 is an alternative to
>> systemd-networkd and NetworkManager (as opposed to netplan, which is a
>> layer on top of them)?
>
> Yes.

Well.. netplan is not actually written in Python. But is primarily
implemented in C, consisting of the libnetplan library that contains all
the parsing and YAML progressing logic and a small "generate" binary
that is usually executed during bootup as a systemd-generator [0] to
prepare any systemd-networkd / NetworkManager / OVS / SR-IOV
configuration that might be needed.

Only the interactive and user facing CLI is implemented in Python,
calling into libnetplan and executing the 'generate' binary if need be.

I'm not a Debian Developer, so it's not my call, but still I'd like to
provide a few more points as to why netplan should be the distro default
in Debian:

* Netplan is under active development, providing several new releases
per year and supported by Canonical.

* Licensed under GPL v3.0 without any CLA.

* Implemented as an efficient C binary (systemd-generator)

* It provides a single place for network configurations in /etc/netplan,
independently of it being used on a server (systemd-networkd) or
desktop/wifi setup (NetworkManager). This increases usability as the
documentation does not need to differentiate too much between different
scenarios.

* Reducing the delta to Ubuntu and making use of the big knowledge base
that grew since 2018 when Ubuntu switched to netplan by default (e.g.
https://askubuntu.com/questions/tagged/netplan?tab=Frequent). Many
scenarios have already been discussed in this time and solutions have
been found.

* Smaller configuration files (in comparison to (networkd/NM), that can
be split up into multiple files if wanted or needed, can be overwritten
by the user or admin (via /{lib,etc,run}/netplan overrides) and other
packages can ship drop-in snippets that provide a certain piece of
network configuration on installation.

Cheers,
Lukas

[0] https://www.freedesktop.org/software/systemd/man/systemd.generator.html

Lukas Maerdian

unread,

Sep 30, 2021, 12:10:04 PM9/30/21

to

Hi,

> Hi,
>
> On Tue, 28 Sep 2021, at 08:29, Richard Laager wrote:
>>>> I don't think we should install something
>>>> like netplan by default.
>>> I agree: it only adds complexity.
>
>> I personally use netplan everywhere.
>>

>> As to what should be the distro default, I'm not sure I am convinced
>> either way, but to argue the other side... There is some value in using
>> netplan by default. Some random thoughts:
>>

>> This default would match Ubuntu. (I value reducing that delta. Not
>> everyone does, and that's fine.)
>>
>> netplan can configure both systemd-networkd and NetworkManager (though
>> I've only used it with systemd-networkd).
>
> As the downstream maintainer of netplan in Debian, I’d like to use this opportunity to invite more people to co-maintain it in Debian :) I like the idea of netplan, but unfortunately I never started using it myself, to it would only be fair if someone who actually uses it could help keeping it up-to-date in Debian.

As the upstream maintainer of netplan (and downstream maintainer in
Ubuntu) I'd like to step up and volunteer to help with the maintenance
of the netplan.io package in Debian!

I'd also be happy to support the switch to netplan as the distro
default. But as I'm only starting to re-activate my Debian activities
after some longer break and I'm not a Debian Developer (yet?) this is
not my call.

Please let me know if I can help out with any specific things wrt.
netplan! Otherwise, I will get back to Andrew, discussing some changes
that we landed in the recent netplan releases: Most of the integration
tests can nowadays be run inside containers and can thus be used as
autopkgtests inside the Debian infrastructure. I think it would be a
good first step for me to enable those tests.

Cheers,
Lukas

Bernhard Schmidt

unread,

Jan 26, 2022, 10:50:03 AM1/26/22

to

Hi,

> About the client and server, if I am not wrong, about 3 years ago ISC
> dhcp was the only implementation able to configure DHCPv6 clients by
> their MAC addresses (thing that I needed at work). It is a pity that ISC
> is giving less love to it. That said, the EOL date is still TBA
> (https://www.isc.org/dhcp/)

The EOL timeline has now been announced.

https://www.isc.org/blogs/dhcp-client-relay-eom/

---
Q1 2022 - We intend to produce an 4.4.3 release, which will declare in
its release notes that it is expected to be the last release containing
the client and relay components of ISC DHCP. We hope this message will
reach any additional active users who are not subscribed to the
DHCP-announce or DHCP-users lists.

H1 2022 - After the last update to the client and relay in 4.4.3, we
plan to issue ISC DHCP 4.4.4, removing the client- and relay-specific
code from the distribution.
---

Bernhard

Lucas Castro

unread,

Oct 19, 2022, 2:10:03 PM10/19/22

to

Em 28/09/2021 03:29, Richard Laager escreveu:
> On 9/27/21 9:15 PM, Marco d'Itri wrote:
>> On Sep 28, Noah Meyerhans <no...@debian.org> wrote:
>>
>> Should it be mentioned what the new recommended DHCP server for general
>> use will be?
>
> ISC Kea?
>
> I haven't converted to it, but that's their replacement for dhcpd.

I had never experience ISC Kea, but its features don't mention ldap
support,

I don't think good idea deployment in ISP and enterprise deployment.

BTW I don't think the thread focus is on the server side.

By default on debian installation, my guess is the tiniest, better.

>
>> I think that a good default would be systemd-networkd for servers and
>> NetworkManager for systems with Wi-Fi or a GUI.

Would systemd-* just wapped what service/system/command and run what
it's needed?

If so, It should still required service/system behind the scene.

OpenPGP_signature

Philipp Hahn

unread,

Mar 7, 2023, 4:30:05 AM3/7/23

to

Hello,

Am 26.01.22 um 16:47 schrieb Bernhard Schmidt:

>> About the client and server, if I am not wrong, about 3 years ago ISC
>> dhcp was the only implementation able to configure DHCPv6 clients by
>> their MAC addresses (thing that I needed at work). It is a pity that ISC
>> is giving less love to it. That said, the EOL date is still TBA
>> (https://www.isc.org/dhcp/)
>
> The EOL timeline has now been announced.
>
> https://www.isc.org/blogs/dhcp-client-relay-eom/

ISC-DHCP is end-of-life since end-of-2022, both client, relay and server:

> ISC has announced the end of life for ISC DHCP as of the end of 2022. ISC will continue providing professional support services for existing subscribers, but does not intend to issue any further maintenance releases.

Is it a good idea to keep it alive for another 2+ years in
Debian-12-Bookworm or should it be removed now?
https://packages.debian.org/source/bookworm/isc-dhcp

Philipp