-----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.
For what it's worth, my preference would be transition toI think that a good default would be systemd-networkd for servers and NetworkManager for systems with Wi-Fi or a GUI.
systemd-networkd with bookworm.
If we keep the ifup/ifdown commandsThis should be quite easy.
from ifupdown at all, I think they should be fairly this wrappers around their networkd equivalents.
I don't think we should install somethingI agree: it only adds complexity.
like netplan by default.
(Of course, this conversation may already be taking place, but if soNo, I think that we did not have this flamewar yet.
I've missed it. Please feel free to point me in the right direction.)
On Sep 28, Noah Meyerhans <noahm@debian.org> wrote:
Should it be mentioned what the new recommended DHCP server for general
use will be?
I think that a good default would be systemd-networkd for servers and NetworkManager for systems with Wi-Fi or a GUI.
I don't think we should install something
like netplan by default.
I agree: it only adds complexity.
I don't think we should install somethingI agree: it only adds complexity.
like netplan by default.
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).
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.
On Sep 28, Noah Meyerhans <noahm@debian.org> wrote:
For what it's worth, my preference would be transition toI think that a good default would be systemd-networkd for servers and >NetworkManager for systems with Wi-Fi or a GUI.
systemd-networkd with bookworm.
On Tue, 28 Sep 2021 04:15:58 +0200, Marco d'Itri <md@Linux.IT> wrote:
On Sep 28, Noah Meyerhans <noahm@debian.org> wrote:
For what it's worth, my preference would be transition toI think that a good default would be systemd-networkd for servers and
systemd-networkd with bookworm.
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.
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.
On Tue, 28 Sep 2021 04:15:58 +0200, Marco d'Itri <md@Linux.IT> wrote:
On Sep 28, Noah Meyerhans <noahm@debian.org> wrote:
For what it's worth, my preference would be transition toI think that a good default would be systemd-networkd for servers and >NetworkManager for systems with Wi-Fi or a GUI.
systemd-networkd with bookworm.
Afaik, NetworkManager uses an external DHCP client and thus is not a
solution for the problemt hat ISC DHCP client is EOL.
Greetings
Marc
On Mon, 27 Sep 2021 15:48:25 -0700, Noah Meyerhans <noahm@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?
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:
⦠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 notWhat do you mean?
allow proper reconfiguration.
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 notWhat do you mean?
allow proper reconfiguration.
⦠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 notWhat do you mean?
allow proper reconfiguration.
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 wasAm I understanding correctly that ifupdown2 is an alternative to systemd-networkd and NetworkManager (as opposed to netplan, which is a
never adopted because written in Python. As netplan is written in
Python, ifupdown2 seems a far better replacement.
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 wasAm I understanding correctly that ifupdown2 is an alternative to systemd-networkd and NetworkManager (as opposed to netplan, which is a
never adopted because written in Python. As netplan is written in
Python, ifupdown2 seems a far better replacement.
layer on top of them)?
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.
Le 2021-09-28 13:00, Marc Haber a écrit :
On Tue, 28 Sep 2021 04:15:58 +0200, Marco d'Itri <md@Linux.IT> wrote:
On Sep 28, Noah Meyerhans <noahm@debian.org> wrote:
For what it's worth, my preference would be transition toI think that a good default would be systemd-networkd for servers and
systemd-networkd with bookworm.
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:
For what it's worth, my preference would be transition toSomething I've been meaning to look into but never found the time for it
systemd-networkd with bookworm.
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 wasAm I understanding correctly that ifupdown2 is an alternative to
never adopted because written in Python. As netplan is written in
Python, ifupdown2 seems a far better replacement.
systemd-networkd and NetworkManager (as opposed to netplan, which is a
layer on top of them)?
Yes.
Hi,someone who actually uses it could help keeping it up-to-date in Debian.
On Tue, 28 Sep 2021, at 08:29, Richard Laager wrote:
I don't think we should install somethingI agree: it only adds complexity.
like netplan by default.
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
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/)
On Mar 07, Philipp Hahn <pmhahn@pmhahn.de> wrote:
I do not think that it should be removed at this point, since there isIs 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
a need for the complex features that isc-dhcpd can provide and there are is no obvious replacement: Kea is super complex (and I do not know if it has all the features) and everything else is too much simple.
On Tue, 2023-03-07 at 11:55 +0100, Marco d'Itri wrote:
On Mar 07, Philipp Hahn <pmhahn@pmhahn.de> wrote:
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
I do not think that it should be removed at this point, since there is
a need for the complex features that isc-dhcpd can provide and there are
is no obvious replacement: Kea is super complex (and I do not know if it
has all the features) and everything else is too much simple.
Only the client and relay are no longer maintained upstream. The server
is still maintained and there is no need to drop it from Debian.
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.
Do we do our users a service by keeping that dead horse alive for another 2+ years? While being quite stable it had a steady stream of security issues:Yes, unless you know of other implementations with that features set.
El 08/03/23 a las 10:45, Philipp Hahn escribió:
Am 07.03.23 um 20:26 schrieb Ansgar:
On Tue, 2023-03-07 at 11:55 +0100, Marco d'Itri wrote:
On Mar 07, Philipp Hahn <pmhahn@pmhahn.de> wrote:
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
I do not think that it should be removed at this point, since there is >>>> a need for the complex features that isc-dhcpd can provide and there are >>>> is no obvious replacement: Kea is super complex (and I do not know if it >>>> has all the features) and everything else is too much simple.
Only the client and relay are no longer maintained upstream. The server
is still maintained and there is no need to drop it from Debian.
Are you sure the *server* is still maintained? Sadly my quote from
<https://www.isc.org/dhcp/> got dropped, so here again:
From README:
RELEASE STATUS
Version 4.4.3-P1 is a maintenance release of the DHCP client, relay and server. It is the final release for the client and relay components,
which have reached end-of-life and will no longer be maintained.
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.
You can still read an equivalent sentence from the dhcp upstream url:
"DHCP is available for free download under the terms of the MPL 2.0
license. The client and relay portions of ISC DHCP are no longer
maintained."
Hello Ansgar,
Am 07.03.23 um 20:26 schrieb Ansgar:
On Tue, 2023-03-07 at 11:55 +0100, Marco d'Itri wrote:
On Mar 07, Philipp Hahn <pmhahn@pmhahn.de> wrote:
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
I do not think that it should be removed at this point, since there is
a need for the complex features that isc-dhcpd can provide and there are is no obvious replacement: Kea is super complex (and I do not know if it has all the features) and everything else is too much simple.
Only the client and relay are no longer maintained upstream. The server
is still maintained and there is no need to drop it from Debian.
Are you sure the *server* is still maintained? Sadly my quote from <https://www.isc.org/dhcp/> got dropped, so here again:
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.
Previously ISC announced EoL *only for client and relay*, but — at least for
my reading of the above statement — they no longer do and *ended all of DHCP*. Or do we (Debian) have access to that "professional support services" to get future patches we can apply?
Do we do our users a service by keeping that dead horse alive for another 2+ years? While being quite stable it had a steady stream of security issues: <https://security-tracker.debian.org/tracker/source-package/isc-dhcp>
Philipp
Hello Santiago,
Am 08.03.23 um 11:17 schrieb Santiago Ruano Rincón:
El 08/03/23 a las 10:45, Philipp Hahn escribió:
Am 07.03.23 um 20:26 schrieb Ansgar:
On Tue, 2023-03-07 at 11:55 +0100, Marco d'Itri wrote:
On Mar 07, Philipp Hahn <pmhahn@pmhahn.de> wrote:
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
I do not think that it should be removed at this point, since there is
a need for the complex features that isc-dhcpd can provide and there are
is no obvious replacement: Kea is super complex (and I do not know if it
has all the features) and everything else is too much simple.
Only the client and relay are no longer maintained upstream. The server is still maintained and there is no need to drop it from Debian.
Are you sure the *server* is still maintained? Sadly my quote from <https://www.isc.org/dhcp/> got dropped, so here again:
From README:
RELEASE STATUS
Version 4.4.3-P1 is a maintenance release of the DHCP client, relay and server. It is the final release for the client and relay components,
which have reached end-of-life and will no longer be maintained.
That does not help: they did a maintenance release in the past. So *past* issues were addressed. Excellent!
But what happens in the future? Will we get *future* updates:
- client: No, as officially EoL
- relay: No, as officially EoL
- server: through "providing professional support services"
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.
You can still read an equivalent sentence from the dhcp upstream url:
"DHCP is available for free download under the terms of the MPL 2.0 license. The client and relay portions of ISC DHCP are no longer maintained."
Again does not help: I can even still download older releases with unfixed issues.
But I want to know if I should still base my environment/work on ISC-DHCP-server in the future, that is: Will it be maintained in the future and will we get patches for security issues?
Do you "Debian ISC DHCP Maintainers <isc-dhcp@packages.debian.org>" have enough expertise and willingness to maintain it for another 2+ years ("without" support from upstream ISC)?
Philipp
Only the client and relay are no longer maintained upstream. The server
is still maintained and there is no need to drop it from Debian.
Are you sure the *server* is still maintained? Sadly my quote from <https://www.isc.org/dhcp/> got dropped, so here again:
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.
Previously ISC announced EoL *only for client and relay*, but — at
least for my reading of the above statement — they no longer do and *ended all of DHCP*.
Do we do our users a service by keeping that dead horse alive for
another 2+ years?
They pulled the plug on relay and client from now to immediately, with
no obvious replacement on the relay side, and then announced EOL for
the server for end of 2022, leaving the world without the reference implementation.
This is really bad.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 73:52:01 |
Calls: | 6,489 |
Calls today: | 2 |
Files: | 12,096 |
Messages: | 5,275,926 |