• Re: Bug#995189: RFH: isc-dhcp

    From Noah Meyerhans@21:1/5 to All on Tue Sep 28 00:50:01 2021
    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


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

    iQIzBAABCgAdFiEE65xaF5r2LDCTz+zyV68+Bn2yWDMFAmFSSjIACgkQV68+Bn2y WDNZ+g//XbtoVyVOQZOhxLXbGPO8rOgDZ55HXUNml9CMnvjbP+E6ORISy3lq/9wj /b6eQH2ZILUUnQIk1AtxwBKt758qd4KpP67WsdlA75d2wRaQdJvrXrEj8IEUmyNC 72iVmWETsyrM9x08A5JddVcVhHDgoLINTlFDER1EnaYA3KI+XXsQrqJfdY3oXO9N iQ822TjBL3hnKD411n5g9zW/86/SB6wEaAU20hGxbgnx327wdbO68Ve+JX6Oy4zA vv3tLdXWsQjYs3hejIzJ+7WB455qijbI9EAGh8S8fhkTQ60GKYTNj7yTGdMk8uaS 8NocQ6eL3TDUNmMZ9NBEz/KiF599dSovik78SO/mF+b1XKJMO27oxMM+0wNDxdIa rhFKCi8GPvIfJbAJsJ/764uEewTccuVxJo724njOmYisq9+o2wfVnYELnBmiDnDp Pw93fe0exp4xmw443xi0VgkcVRCaidhRAp4aHL8gdpS8I16x/9TOAwtTeYiieWuF yKha44lrTfp6hsV171hs5678GCR3EvoBlV7eCPdPYx/8cGBw3vUGAIXkXxDIuvrE hOMYUewdOuEcY5Ia0E/1rNMnmOCZzxahpKW2ZK7QgE5Zolf6oHL8KDX2AZG+b7AI gdJtKoXAoF3XKc8UTqfX+QIgZuP3G2n+vPy+LZ4gbU/CtzJqUgY=
    =kVUW
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco d'Itri@21:1/5 to All on Tue Sep 28 08:00:05 2021
    On Sep 28, Noah Meyerhans <noahm@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

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

    iHUEABYIAB0WIQQnKUXNg20437dCfobLPsM64d7XgQUCYVJ63QAKCRDLPsM64d7X gXG7AP92OYSHGaIzs09uRWdxl6AKNbQRO1CMQK7HmB9pXNv6OQD/ZkU6zwthwzjs rxqEuArElDR2viojUhvANxVu3jxHdAE=
    =VQly
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Laager@21:1/5 to Marco d'Itri on Tue Sep 28 08:50:01 2021
    On 9/27/21 9:15 PM, Marco d'Itri wrote:
    On Sep 28, Noah Meyerhans <noahm@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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrej Shadura@21:1/5 to Richard Laager on Tue Sep 28 11:40:01 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Haber@21:1/5 to All on Tue Sep 28 13:10:01 2021
    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?

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Haber@21:1/5 to Marco d'Itri on Tue Sep 28 13:10:02 2021
    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 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Biebl@21:1/5 to Marc Haber on Tue Sep 28 13:50:01 2021
    To: debian-devel@lists.debian.org

    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pxTGnTqzwJ6NgPXJnOj1RGGGRVNZPV5V1
    Content-Type: text/plain; charset=utf-8; format=flowed
    Content-Language: en-US
    Content-Transfer-Encoding: quoted-printable

    Am 28.09.21 um 13:00 schrieb Marc Haber:
    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 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


    --pxTGnTqzwJ6NgPXJnOj1RGGGRVNZPV5V1--

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

    wsF5BAABCAAjFiEECbOsLssWnJBDRcxUauHfDWCPItwFAmFTAAgFAwAAAAAACgkQauHfDWCPItwQ +Q/+KQFjbEZAQ5qJAk0K3j7dm16bovkRJUgWITFQLk6AAOfMJXkCZiv5Mimejz1fBww8YRj1dnVa 3ykXntaISIZ0YtAhgcPnTCki90/5dDn8kZ+C4PByt550kWH9Z2suwz2VzmeeuCVtNg3kSUAcOVKD G+cC1Wx6tRrVm2jTmMiZ8nFqU8LSCfAngJ/0T8xTlJGb0WC8AWuEZhiHkiAzxdwojPJxlERGXyoL AsXhRpxX0UTx4SqMY5nQmC7Ea78HDZzMtRxhsRGeFSPQd82o5WKx/PzsxR6PM4TQ9Ljz541+MUvA /FuVj5aYzR7xclHnBp9G0yO3gtCXCxg8/RiUKpGGttuogtmqZVhRvjzM3Dezr9OR3be0OedOZx8A hlTVSv86y8hhkSwNtMYA3abHJaolu4rKivKmImUHBKDRZXIvcoxHrUJ/p1nIjSrHwwE1DUA6ez+m Vlci6/YlaFqcFqukh/36KT4Va7jCtm+0Ib0BoZdRHDS2dwLaoFjUA7fWLjwrhCmD3ZPYcYLb99bl WMVs2Chn4rSKLGeMjFvXa7ASzic+ocRBg3Us6+GC6kXUWX6pnBzvTDKEUqCIw8o87zyA0H4y9bSl bG/5oCJHEIxoOgssVRQCQX2Q+2I4nWqL+DIeKwOlAS/0DQDIjhKDYGZrztW75QwWrcm7P7BmXLU1 zuQ=
    =/yvu
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Vincent Blut@21:1/5 to All on Tue Sep 28 13:34:12 2021
    Hi,

    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 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

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

    iHUEABYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCYVL9tAAKCRAQn1qAt/bg Ad51AQDXgrs+64TB+GejyFHPSxf77vwnIzzVLL0VWD5W4/ElUgD+M264TxCfgUeI N3JXSBXmPQz6XlkPITsS1742wBy3fA0=
    =0yNH
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Santiago Ruano =?iso-8859-1?Q?Rinc=@21:1/5 to All on Tue Sep 28 15:10:01 2021
    El 28/09/21 a las 13:01, Marc Haber escribió:
    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?

    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

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

    iHUEABYIAB0WIQRZVjztY8b+Ty43oH1itBCJKh26HQUCYVMT4gAKCRBitBCJKh26 Han2AQDYn/xs29nJIB/ST8vjEbL+VqTjTuZeCB5t/Iyh8oGhoAEA/Ap2fFpl9P+k NoWnZAm+Q216oayNkLkKojluFupuhAE=
    =HFN2
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Vincent Bernat@21:1/5 to All on Tue Sep 28 15:50:01 2021
    ⦠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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Laager@21:1/5 to Vincent Bernat on Tue Sep 28 18:30:01 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Vincent Bernat@21:1/5 to All on Tue Sep 28 18:50:02 2021
    ⦠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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Laager@21:1/5 to Vincent Bernat on Tue Sep 28 20:30:01 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Vincent Bernat@21:1/5 to All on Tue Sep 28 21:50:01 2021
    ⦠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.
    - The Elements of Programming Style (Kernighan & Plauger)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Haber@21:1/5 to All on Wed Sep 29 10:30:02 2021
    On Tue, 28 Sep 2021 18:49:31 +0200, Vincent Bernat <bernat@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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Haber@21:1/5 to vincent.debian@free.fr on Wed Sep 29 10:30:01 2021
    On Tue, 28 Sep 2021 13:34:12 +0200, Vincent Blut
    <vincent.debian@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 <md@Linux.IT> wrote:
    On Sep 28, Noah Meyerhans <noahm@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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Biebl@21:1/5 to Noah Meyerhans on Thu Sep 30 16:50:02 2021
    To: debian-devel@lists.debian.org

    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GPOo4buogj3lYxOaSVJv0emOSZ3sIJgIW
    Content-Type: text/plain; charset=windows-1252; format=flowed
    Content-Language: en-US
    Content-Transfer-Encoding: quoted-printable

    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


    --GPOo4buogj3lYxOaSVJv0emOSZ3sIJgIW--

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

    wsF5BAABCAAjFiEECbOsLssWnJBDRcxUauHfDWCPItwFAmFVzZkFAwAAAAAACgkQauHfDWCPItxC NQ/9FMM8AjpfXmP0S6xJDAnOlrENiPGnZ/P62KiHIG29aDnaA2AGLMLIZNzLWS/iD5JbfkDUReWb ziWLeOvmdI8/TTtN/cXBJWs+yCPh6Jk6b9es55kIgF2cwoqXO4qyVlhVWsPFH8u6oMug/6ndc0ds NcF675/iciAHtZ+BbeIlRJMd4b4vZjZZ2mvnOhDuca4gPwh8we4BHwymcmzdD/eHQFvd4uvOWPn5 zAvOqSE0zQfhAYwvmAuqL4QL7h0EN4OqjXucJt3Ljud+gXZMLqKxVc7lqzh4LRmufiPO0wOHvi9q WLKC8QCPMBNEAQrTM23WKFw/G2GjWr8LQuNdmLdhc8H2XHKMWJV33wYka5DtKz+I53b5kSqmOddm EjN9OrI3GJz6XVXWnxRFfYwc3/wgNHnObXJIEG17UYbbAQH51OOn1nYhtSZ6ei+tEUzLu/u0c9/Z J2Ds16x9stVMC62UhA5jMuAzQjYA2qrsiPqOUMBdZPCEA2Vrja3mtp8vFNXkBo0OIZ81yMMiiSXk HW/BSg4/nYOwYPAetmBAJbqNJsyasUCVxMusbn1nNTh3r+LwhfI5DmcyusKt9CovATB+IGicTW9X kUCv+90r6iTOr26+EhmNJChDKm9IapVSjUA9MoOjPcnpaX/ZF5OJsYkcOgwxblR2H+UM6RyBoAXr iR4=
    =lfQT
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lukas Maerdian@21:1/5 to All on Thu Sep 30 18:10:02 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lukas Maerdian@21:1/5 to All on Thu Sep 30 18:10:02 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bernhard Schmidt@21:1/5 to All on Wed Jan 26 16:50:01 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lucas Castro@21:1/5 to All on Wed Oct 19 20:10:01 2022
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------TOYvg5lXv37OUS4Oj2VEb94y
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

    DQpFbSAyOC8wOS8yMDIxIDAzOjI5LCBSaWNoYXJkIExhYWdlciBlc2NyZXZldToNCj4gT24g OS8yNy8yMSA5OjE1IFBNLCBNYXJjbyBkJ0l0cmkgd3JvdGU6DQo+PiBPbiBTZXAgMjgsIE5v YWggTWV5ZXJoYW5zIDxub2FobUBkZWJpYW4ub3JnPiB3cm90ZToNCj4+DQo+PiBTaG91bGQg aXQgYmUgbWVudGlvbmVkIHdoYXQgdGhlIG5ldyByZWNvbW1lbmRlZCBESENQIHNlcnZlciBm b3IgZ2VuZXJhbA0KPj4gdXNlIHdpbGwgYmU/DQo+DQo+IElTQyBLZWE/DQo+DQo+IEkgaGF2 ZW4ndCBjb252ZXJ0ZWQgdG8gaXQsIGJ1dCB0aGF0J3MgdGhlaXIgcmVwbGFjZW1lbnQgZm9y IGRoY3BkLg0KDQpJIGhhZCBuZXZlciBleHBlcmllbmNlIElTQyBLZWEsIGJ1dCBpdHMgZmVh dHVyZXMgZG9uJ3QgbWVudGlvbiBsZGFwIA0Kc3VwcG9ydCwNCg0KSSBkb24ndCB0aGluayBn b29kIGlkZWEgZGVwbG95bWVudCBpbiBJU1AgYW5kIGVudGVycHJpc2UgZGVwbG95bWVudC4N Cg0KDQpCVFcgSSBkb24ndCB0aGluayB0aGUgdGhyZWFkIGZvY3VzIGlzIG9uIHRoZSBzZXJ2 ZXIgc2lkZS4NCg0KQnkgZGVmYXVsdCBvbiBkZWJpYW4gaW5zdGFsbGF0aW9uLCBteSBndWVz cyBpcyB0aGUgdGluaWVzdCwgYmV0dGVyLg0KDQoNCj4NCj4+IEkgdGhpbmsgdGhhdCBhIGdv b2QgZGVmYXVsdCB3b3VsZCBiZSBzeXN0ZW1kLW5ldHdvcmtkIGZvciBzZXJ2ZXJzIGFuZA0K Pj4gTmV0d29ya01hbmFnZXIgZm9yIHN5c3RlbXMgd2l0aCBXaS1GaSBvciBhIEdVSS4NCg0K V291bGQgc3lzdGVtZC0qIGp1c3Qgd2FwcGVkIHdoYXQgc2VydmljZS9zeXN0ZW0vY29tbWFu ZCBhbmQgcnVuIHdoYXQgDQppdCdzIG5lZWRlZD8NCg0KSWYgc28sIEl0IHNob3VsZCBzdGls bCByZXF1aXJlZCBzZXJ2aWNlL3N5c3RlbSBiZWhpbmQgdGhlIHNjZW5lLg0KDQo+DQo+IFRo YXQgc2VlbXMgcmVhc29uYWJsZS4NCj4NCj4+PiBJIGRvbid0IHRoaW5rIHdlIHNob3VsZCBp bnN0YWxsIHNvbWV0aGluZw0KPj4+IGxpa2UgbmV0cGxhbiBieSBkZWZhdWx0Lg0KPg0KPj4g SSBhZ3JlZTogaXQgb25seSBhZGRzIGNvbXBsZXhpdHkuDQo+DQo+IEkgcGVyc29uYWxseSB1 c2UgbmV0cGxhbiBldmVyeXdoZXJlLg0KPg0KPiBBcyB0byB3aGF0IHNob3VsZCBiZSB0aGUg ZGlzdHJvIGRlZmF1bHQsIEknbSBub3Qgc3VyZSBJIGFtIGNvbnZpbmNlZCANCj4gZWl0aGVy IHdheSwgYnV0IHRvIGFyZ3VlIHRoZSBvdGhlciBzaWRlLi4uIFRoZXJlIGlzIHNvbWUgdmFs dWUgaW4gDQo+IHVzaW5nIG5ldHBsYW4gYnkgZGVmYXVsdC4gU29tZSByYW5kb20gdGhvdWdo dHM6DQo+DQo+IFRoaXMgZGVmYXVsdCB3b3VsZCBtYXRjaCBVYnVudHUuIChJIHZhbHVlIHJl ZHVjaW5nIHRoYXQgZGVsdGEuIE5vdCANCj4gZXZlcnlvbmUgZG9lcywgYW5kIHRoYXQncyBm aW5lLikNCj4NCj4gbmV0cGxhbiBjYW4gY29uZmlndXJlIGJvdGggc3lzdGVtZC1uZXR3b3Jr ZCBhbmQgTmV0d29ya01hbmFnZXIgKHRob3VnaCANCj4gSSd2ZSBvbmx5IHVzZWQgaXQgd2l0 aCBzeXN0ZW1kLW5ldHdvcmtkKS4NCj4NCj4gSW4gbXkgbm9uLXRyaXZpYWwgY29uZmlndXJh dGlvbnMsIHRoZSBuZXRwbGFuIFlBTUwgaW5wdXQgaXMgaGFsZiBhcyANCj4gbWFueSBsaW5l cyBhcyBpdHMgbmV0d29ya2Qgb3V0cHV0LiBUaGlzIGlzIHdpdGggdGhlIGlucHV0IGluY2x1 ZGluZyBhIA0KPiBiaXQgb2YgY29tbWVudHMgYW5kIHRoZSBib2lsZXJwbGF0ZSwgZGlzYWJs aW5nIGRoY3AsIGFuZCB1c2luZyBZQU1MJ3MgDQo+IG1vcmUgdmVyYm9zZSBsaXN0IHN5bnRh eCAoc2VwYXJhdGUgbGluZXMgdnMgb25lIGxpbmUpLiBJIGRvbid0IHNlZSANCj4gYW55dGhp bmcgd3Jvbmcgd2l0aCBpdHMgb3V0cHV0IHRoYXQgSSBjb3VsZCBzaW1wbGlmeS4NCj4NCj4g QWdhaW4sIGluIHRoaXMgbm9uLXRyaXZpYWwgY29uZmlndXJhdGlvbiwgSSB0aGluayBpdCdz IG1vcmUgdXNlZnVsIHRvIA0KPiBoYXZlIG9uZSBuZXRwbGFuIFlBTUwgZmlsZSB0aGFuIDI0 IHNlcGFyYXRlIG5ldHdvcmtkIGZpbGVzLiBUaGlzIGlzIA0KPiBlc3BlY2lhbGx5IHRydWUg d2hlbiBJJ20gYnVpbGRpbmcgdGhpcyBmaWxlIGZyb20gYW4gQW5zaWJsZSB0ZW1wbGF0ZSAN Cj4gYW5kIG1vc3Qgb2YgaXQgKGJ5IHZvbHVtZSkgaXMgYnVpbHQgYnkgbG9vcHMuDQo+DQo+ IEluIHRoZSB0cml2aWFsIGNhc2UsIGl0J3MgMTkgbGluZXMgb2YgbmV0cGxhbiAoMTYgaWYg eW91IGV4Y2x1ZGUgdGhlIA0KPiBzdG9jayBjb21tZW50KSB2cyAyNSBsaW5lcyBvZiBzeXN0 ZW1kLW5ldHdvcmtkLCBib3RoIGluIHNpbmdsZSBmaWxlcy4gDQo+IFRoYXQncyBub3QgYSBo dWdlIGRpZmZlcmVuY2UuDQo+DQo=

    --------------TOYvg5lXv37OUS4Oj2VEb94y--

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

    wsF5BAABCAAjFiEE3JygVPfnkc6KD9fzQveaXgpNVZgFAmNQOcUFAwAAAAAACgkQQveaXgpNVZhE xw//Rcm0fAF2bUUaFDNE6REnaE4lBz8lmopNJwVT8yxc8BU0Wi+lDBeqZ96nW6zD7xxj16alQUGx 0XQAZCCaFEMDCNP81UotR6w88KPf9XDhSuqgt/GM/FDs/4ZcKscW9IGxUQSqxQFyyj9zHhSaCIws bRDJx901Mi2uaaRxFH2NdJyylWuVYw0W0gcmPowVK8fGXrljWQA3G0qaxmStWZm1wRyUlckAc/Wm 4OT5JKcA/JDbhYefDFWSqulVJZiS2KQAfmezOQTDBu/3M8Dz7soQw1PjtBNrYV4FCvZaBAV5E7CF 9L1JufnnMSXID1i9BqWL3PcJ4kfNICOGhSQ+zZpOVQ8HTKJecDwtggYVuG1+kvg7qkaE14697L6w 07aoAPgJVk1cPr9aZSZ0N6+DEzSBkOiTNgRk93kLQaix7tnGqNEXfmfEX2G7oGftKHt2sHeJYp6r PoxpxjYxm6n/9Yx4GrWhpzv5+PrwU35nZXJBgoVeZZSjO9mWEsK0/jDG0ZNEDdovQXTfihoq74Uf ZBGmvnRcOhvjAP8u1txdC80IcJkdGUi6TNeXCdiZ/r75rEv4B9v/FLlodqJySWnM0HA30AV83def Oox2r1E6izvjQQt5PblGBjA4546TnN+vTLsbnlADFdfNrnkDAzsDm0NBqbxBBv5Ogck3wlclmj7I epw=
    =g1B/
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ansgar@21:1/5 to Marco d'Itri on Tue Mar 7 20:30:01 2023
    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.

    But it is too late to remove isc-dhcp-client from bookworm as well
    (IHMO): it would need migration away to alternatives such as systemd-
    networkd or NetworkManager, including relevant changes in the installer
    and other reverse dependencies.

    Ansgar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Philipp Hahn@21:1/5 to All on Wed Mar 8 11:10:01 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco d'Itri@21:1/5 to Philipp Hahn on Wed Mar 8 11:20:01 2023
    On Mar 08, Philipp Hahn <pmhahn@pmhahn.de> wrote:

    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.

    --
    ciao,
    Marco

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

    iHUEABYIAB0WIQQnKUXNg20437dCfobLPsM64d7XgQUCZAhdvAAKCRDLPsM64d7X gSD+AP9IbyYCC9bPgGaqeSeQ5FkpQ8dYne1t4+eA2TfRhl18/AEAhJNKohBsFCgB zDCXtCAHvVoTKYnRvuaR25IxGUE+0AM=
    =AFuZ
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Philipp Hahn@21:1/5 to All on Wed Mar 8 12:00:01 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Santiago Ruano =?iso-8859-1?Q?Rinc=@21:1/5 to All on Wed Mar 8 11:20:01 2023
    Hi Philipp,

    El 08/03/23 a las 10:45, Philipp Hahn escribió:
    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:

    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."


    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


    -- Santiago

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

    iHUEABYIAB0WIQRZVjztY8b+Ty43oH1itBCJKh26HQUCZAhgrgAKCRBitBCJKh26 Ha78AQDd4YnjFh2wJnRMSk2QxBN9COtEDF1p5JlWVptWyB+3WQEAmtmKG4C+0EPg 0YFP8X0xJR0uEyQauaBKAMezSTrF6go=
    =iCJb
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Santiago Ruano =?iso-8859-1?Q?Rinc=@21:1/5 to as already on Wed Mar 8 15:00:01 2023
    El 08/03/23 a las 11:37, Philipp Hahn escribió:
    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"

    OK, I see your point. And I must said I missed this: https://lists.isc.org/pipermail/dhcp-users/2022-October/022786.html https://www.isc.org/blogs/isc-dhcp-eol/


    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?

    "... If we become aware of a significant security vulnerability, we
    might make an exception to this (no future maintenance versions), but it
    is our intention to cease actively maintaining this codebase."

    It is clear that users should migrate. But it is difficult to find the
    same set of features, as already said in this thread.


    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)?

    No, sorry. At least not me, without upstream support.


    Philipp


    Cheers,

    -- Santiago

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

    iHUEABYIAB0WIQRZVjztY8b+Ty43oH1itBCJKh26HQUCZAiS4QAKCRBitBCJKh26 HZcVAQCVBexxpiOsv/CpdENrrOZKn9dXTpmD8s+J/ggbbo8xuQD/TYgHA97EVbCi UmwvA+WqGNnti6XCeznx5bnP0ptyRgM=
    =7Hsl
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Haber@21:1/5 to Ansgar on Wed Mar 8 14:20:01 2023
    On Tue, 07 Mar 2023 20:26:20 +0100, Ansgar <ansgar@43-1.org> wrote:
    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.

    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.

    Grüße
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ansgar@21:1/5 to Philipp Hahn on Thu Mar 9 01:50:01 2023
    Hi,

    On Wed, 2023-03-08 at 10:45 +0100, Philipp Hahn wrote:
    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*.

    No, I missed that and only read the parts where upstream said client
    and relay is no longer supported. I now checked again and [1] looks
    clear enough: the title is "ISC DHCP Server has reached EOL" (it
    mentions the earlier EOL for client and relay at the end).

    [1]: https://www.isc.org/blogs/isc-dhcp-eol/

    Do we do our users a service by keeping that dead horse alive for
    another 2+ years?

    I still think it is too late for major changes for Debian 12/bookworm.

    Ansgar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Daniel Baumann@21:1/5 to Marc Haber on Thu Mar 9 16:00:01 2023
    On 3/8/23 14:11, Marc Haber wrote:
    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.

    that was unfortunate, however..

    This is really bad.

    ..we've switched last october the whole University network (both campus
    and infrastructure) to isc-kea, it was a tough, but now that we're ~6
    month in production, it's really much better (especially
    kea-dhcp6-server is a relief compared to isc-dhcpd6) and was well worth
    the effort.

    Regards,
    Daniel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)