Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, 11 Mar 2024 07:02:38 +0200, Martin-Éric Racine wrote: >Meanwhile a bare minimal system needs a non-GUI solution and swaping >which DHCP client gets pulled by ifupdown is the simplest, least >disruptive way of accomplishing this. Most bare minimal non-GUI systems run fine with systemd-networkd in my world. Greetings Marc -- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
ma 11. maalisk. 2024 klo 1.29 Bernd Zeimetz (be...@bzed.de) kirjoitti: > On Mon, 2023-06-19 at 13:54 +0300, Martin-Éric Racine wrote: > > I hereby propose bin:dhcpcd-base: > > > > 1) already supported by ifupdown. > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > separation. > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > configure both stacks. > > > > why not switch to systemd-networkd + networkmanager for gui installs? NM already is pulled by most desktop environments. Meanwhile a bare minimal system needs a non-GUI solution and swaping which DHCP client gets pulled by ifupdown is the simplest, least disruptive way of accomplishing this. Martin-Éric
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Hi, On Mon, 2023-06-19 at 13:54 +0300, Martin-Éric Racine wrote: > I hereby propose bin:dhcpcd-base: > > 1) already supported by ifupdown. > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > separation. > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > 5) a mere inet line in /etc/network/interfaces is sufficient to > configure both stacks. > why not switch to systemd-networkd + networkmanager for gui installs? I'm not sure how well NM is integrated with systemd-networkd now, but I would rather spend time on supporting such a combination and getting rid of all the old ways of configuring networking stuff than implementing yet another "client" solution. Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
su 10. maalisk. 2024 klo 18.54 Santiago Ruano Rincón (santiag...@riseup.net) kirjoitti: > > Hi there, > > El 20/11/23 a las 19:44, Martin-Éric Racine escribió: > > (non-subscriber - please keep me in CC) > > On Sat, Nov 18, 2023 at 4:26 PM Martin-Éric Racine > > wrote: > > > > > > On Sat, Jul 22, 2023 at 2:55 PM Martin-Éric Racine > > > wrote: > > > > > > > > On Fri, Jul 7, 2023 at 12:55 PM Martin-Éric Racine > > > > wrote: > > > > > > > > > > On Thu, Jul 6, 2023 at 3:06 AM Santiago Ruano Rincón > > > > > wrote: > > > > > > > > > > > > El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió: > > > > > > > El 20/06/23 a las 08:29, Martin-Éric Racine escribió: > > > > > > > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón > > > > > > > > wrote: > > > > > > > > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > > > > > > > > > Greetings, > > > > > > > > > > > > > > > > > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now > > > > > > > > > > might be a > > > > > > > > > > good time to re-visit Debian's choice of standard DHCP > > > > > > > > > > client shipping > > > > > > > > > > with priority:important. > > > > > > > > > > > > > > > > > > > > I hereby propose bin:dhcpcd-base: > > > > > > > > > > > > > > > > > > > > 1) already supported by ifupdown. > > > > > > > > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with > > > > > > > > > > privilege separation. > > > > > > > > > > 3) writes both IPv4 and IPv6 name servers to > > > > > > > > > > /etc/resolv.conf > > > > > > > > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > > > > > > > > > 5) a mere inet line in /etc/network/interfaces is > > > > > > > > > > sufficient to > > > > > > > > > > configure both stacks. > > > > > > > > > ... > > > > > > > > > > > > > > > > > > I agree that dhcpcd seems the best alternative to > > > > > > > > > isc-dhcp-client for > > > > > > > > > the moment, and I'll make the relevant changes in ifupdown as > > > > > > > > > soon as I > > > > > > > > > can. Josué, any thoughts? > > > > > > > > > > > > > > > > 1) As someone pointed out in the thread, the reason why > > > > > > > > isc-dhcp-client had priority:important probably was to ensure > > > > > > > > that > > > > > > > > debootstrap would pull it, since debootstrap ignores Recommends > > > > > > > > and > > > > > > > > packages with a priority lower than standard. > > > > > > > > > > > > > > > > 2) However, as long as ifupdown explictly depends on a package, > > > > > > > > it can > > > > > > > > also pull dependencies with a lower priority. Right now ifupdown > > > > > > > > Recommends "isc-dhcp-client | dhcp-client" which debootstrap > > > > > > > > would > > > > > > > > ignore. It would have to Depends "dhcpcd-base | dhcp-client" > > > > > > > > instead. > > > > > > > > > > > > > > > > 3) At that point, swapping the priority of isc-dhcp-client and > > > > > > > > dhcpcd-base merely becomes "nice to have". Heck, the priority > > > > > > > > of both > > > > > > > > could, in principle, be optional, just as long as ifupdown > > > > > > > > explicitly > > > > > > > > Depends on a DHCP client, and the first alternative is a real > > > > > > > > package. > > > > > > > > > > > > > > I was about to bump dhcpcd-base as ifupdown dependency, but... if > > > > > > > isc-client-dhcp is a Recommends, is because not all users want a > > > > > > > dhcp > > > > > > > client installed, where all the ipv4 is handled statically, and > > > > > > > ipv6 is > > > > > > > done via SLAAC. As a user, I don't want/need to pull in > > > > > > > dhcpcd-base the > > > > > > > next upgrade. > > > > > > > > > > > > > > So I'd prefer to go forward with the steps proposed by Simon, and > > > > > > > s/isc-dhcp-client/dhcpcd-base in ifupdown's Recommends: > > > > > > > Unless there is a strong objection, I'll file the override bug > > > > > > > report. > > > > > > > > > > > > (sorry for taking so long to come back to this) > > > > > > > > > > > > For the moment, ifupdown is still installed by the debian-installer > > > > > > as > > > > > > default network interfaces manager. And after sleeping over it, and > > > > > > discussing with debian fellows, I would like to call for consensus > > > > > > to > > > > > > rise Priority: Important to dhcpcd-base (as initially requested in > > > > > > #1038882), and switch to Recommends: dhcpcd-base | dhcp-client. > > > > > > > > > > > > This addresses two scenarios: keep some systems as small as possible > > > > > > (ifupdown users can remove dhcpcd if they want) and having a useful > > > > > > dhcp > > > > > > client available after installing/bootstrapping. > > > > > > > > > > > > So I would like to retitle #1038882 back as originally reported. > > > > > > (Sorry > > > > > > for going back and forth) Objections? > > > > > > > > > > > > The situation regarding the default network interfaces manager could > > > > > > change, even in the short term. But that could be discussed in > > >
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Hi there, El 20/11/23 a las 19:44, Martin-Éric Racine escribió: > (non-subscriber - please keep me in CC) > On Sat, Nov 18, 2023 at 4:26 PM Martin-Éric Racine > wrote: > > > > On Sat, Jul 22, 2023 at 2:55 PM Martin-Éric Racine > > wrote: > > > > > > On Fri, Jul 7, 2023 at 12:55 PM Martin-Éric Racine > > > wrote: > > > > > > > > On Thu, Jul 6, 2023 at 3:06 AM Santiago Ruano Rincón > > > > wrote: > > > > > > > > > > El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió: > > > > > > El 20/06/23 a las 08:29, Martin-Éric Racine escribió: > > > > > > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón > > > > > > > wrote: > > > > > > > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > > > > > > > > Greetings, > > > > > > > > > > > > > > > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now > > > > > > > > > might be a > > > > > > > > > good time to re-visit Debian's choice of standard DHCP client > > > > > > > > > shipping > > > > > > > > > with priority:important. > > > > > > > > > > > > > > > > > > I hereby propose bin:dhcpcd-base: > > > > > > > > > > > > > > > > > > 1) already supported by ifupdown. > > > > > > > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with > > > > > > > > > privilege separation. > > > > > > > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > > > > > > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > > > > > > > > 5) a mere inet line in /etc/network/interfaces is sufficient > > > > > > > > > to > > > > > > > > > configure both stacks. > > > > > > > > ... > > > > > > > > > > > > > > > > I agree that dhcpcd seems the best alternative to > > > > > > > > isc-dhcp-client for > > > > > > > > the moment, and I'll make the relevant changes in ifupdown as > > > > > > > > soon as I > > > > > > > > can. Josué, any thoughts? > > > > > > > > > > > > > > 1) As someone pointed out in the thread, the reason why > > > > > > > isc-dhcp-client had priority:important probably was to ensure that > > > > > > > debootstrap would pull it, since debootstrap ignores Recommends > > > > > > > and > > > > > > > packages with a priority lower than standard. > > > > > > > > > > > > > > 2) However, as long as ifupdown explictly depends on a package, > > > > > > > it can > > > > > > > also pull dependencies with a lower priority. Right now ifupdown > > > > > > > Recommends "isc-dhcp-client | dhcp-client" which debootstrap would > > > > > > > ignore. It would have to Depends "dhcpcd-base | dhcp-client" > > > > > > > instead. > > > > > > > > > > > > > > 3) At that point, swapping the priority of isc-dhcp-client and > > > > > > > dhcpcd-base merely becomes "nice to have". Heck, the priority of > > > > > > > both > > > > > > > could, in principle, be optional, just as long as ifupdown > > > > > > > explicitly > > > > > > > Depends on a DHCP client, and the first alternative is a real > > > > > > > package. > > > > > > > > > > > > I was about to bump dhcpcd-base as ifupdown dependency, but... if > > > > > > isc-client-dhcp is a Recommends, is because not all users want a > > > > > > dhcp > > > > > > client installed, where all the ipv4 is handled statically, and > > > > > > ipv6 is > > > > > > done via SLAAC. As a user, I don't want/need to pull in dhcpcd-base > > > > > > the > > > > > > next upgrade. > > > > > > > > > > > > So I'd prefer to go forward with the steps proposed by Simon, and > > > > > > s/isc-dhcp-client/dhcpcd-base in ifupdown's Recommends: > > > > > > Unless there is a strong objection, I'll file the override bug > > > > > > report. > > > > > > > > > > (sorry for taking so long to come back to this) > > > > > > > > > > For the moment, ifupdown is still installed by the debian-installer as > > > > > default network interfaces manager. And after sleeping over it, and > > > > > discussing with debian fellows, I would like to call for consensus to > > > > > rise Priority: Important to dhcpcd-base (as initially requested in > > > > > #1038882), and switch to Recommends: dhcpcd-base | dhcp-client. > > > > > > > > > > This addresses two scenarios: keep some systems as small as possible > > > > > (ifupdown users can remove dhcpcd if they want) and having a useful > > > > > dhcp > > > > > client available after installing/bootstrapping. > > > > > > > > > > So I would like to retitle #1038882 back as originally reported. > > > > > (Sorry > > > > > for going back and forth) Objections? > > > > > > > > > > The situation regarding the default network interfaces manager could > > > > > change, even in the short term. But that could be discussed in another > > > > > thread. > > > > > > > > No objection. Raising the priority of dhcpcd-base to important works > > > > for me. > > > > > > Have we reached a conclusion? Are we moving ahead with this or not? > > > > What is the current situation? > > Michael replied that an upgrade would result in both remaining > installed. That is precisely the situation that I previously
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
(non-subscriber - please keep me in CC) On Sat, Nov 18, 2023 at 4:26 PM Martin-Éric Racine wrote: > > On Sat, Jul 22, 2023 at 2:55 PM Martin-Éric Racine > wrote: > > > > On Fri, Jul 7, 2023 at 12:55 PM Martin-Éric Racine > > wrote: > > > > > > On Thu, Jul 6, 2023 at 3:06 AM Santiago Ruano Rincón > > > wrote: > > > > > > > > El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió: > > > > > El 20/06/23 a las 08:29, Martin-Éric Racine escribió: > > > > > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón > > > > > > wrote: > > > > > > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > > > > > > > Greetings, > > > > > > > > > > > > > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now > > > > > > > > might be a > > > > > > > > good time to re-visit Debian's choice of standard DHCP client > > > > > > > > shipping > > > > > > > > with priority:important. > > > > > > > > > > > > > > > > I hereby propose bin:dhcpcd-base: > > > > > > > > > > > > > > > > 1) already supported by ifupdown. > > > > > > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with > > > > > > > > privilege separation. > > > > > > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > > > > > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > > > > > > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > > > > > > > configure both stacks. > > > > > > > ... > > > > > > > > > > > > > > I agree that dhcpcd seems the best alternative to isc-dhcp-client > > > > > > > for > > > > > > > the moment, and I'll make the relevant changes in ifupdown as > > > > > > > soon as I > > > > > > > can. Josué, any thoughts? > > > > > > > > > > > > 1) As someone pointed out in the thread, the reason why > > > > > > isc-dhcp-client had priority:important probably was to ensure that > > > > > > debootstrap would pull it, since debootstrap ignores Recommends and > > > > > > packages with a priority lower than standard. > > > > > > > > > > > > 2) However, as long as ifupdown explictly depends on a package, it > > > > > > can > > > > > > also pull dependencies with a lower priority. Right now ifupdown > > > > > > Recommends "isc-dhcp-client | dhcp-client" which debootstrap would > > > > > > ignore. It would have to Depends "dhcpcd-base | dhcp-client" > > > > > > instead. > > > > > > > > > > > > 3) At that point, swapping the priority of isc-dhcp-client and > > > > > > dhcpcd-base merely becomes "nice to have". Heck, the priority of > > > > > > both > > > > > > could, in principle, be optional, just as long as ifupdown > > > > > > explicitly > > > > > > Depends on a DHCP client, and the first alternative is a real > > > > > > package. > > > > > > > > > > I was about to bump dhcpcd-base as ifupdown dependency, but... if > > > > > isc-client-dhcp is a Recommends, is because not all users want a dhcp > > > > > client installed, where all the ipv4 is handled statically, and ipv6 > > > > > is > > > > > done via SLAAC. As a user, I don't want/need to pull in dhcpcd-base > > > > > the > > > > > next upgrade. > > > > > > > > > > So I'd prefer to go forward with the steps proposed by Simon, and > > > > > s/isc-dhcp-client/dhcpcd-base in ifupdown's Recommends: > > > > > Unless there is a strong objection, I'll file the override bug report. > > > > > > > > (sorry for taking so long to come back to this) > > > > > > > > For the moment, ifupdown is still installed by the debian-installer as > > > > default network interfaces manager. And after sleeping over it, and > > > > discussing with debian fellows, I would like to call for consensus to > > > > rise Priority: Important to dhcpcd-base (as initially requested in > > > > #1038882), and switch to Recommends: dhcpcd-base | dhcp-client. > > > > > > > > This addresses two scenarios: keep some systems as small as possible > > > > (ifupdown users can remove dhcpcd if they want) and having a useful dhcp > > > > client available after installing/bootstrapping. > > > > > > > > So I would like to retitle #1038882 back as originally reported. (Sorry > > > > for going back and forth) Objections? > > > > > > > > The situation regarding the default network interfaces manager could > > > > change, even in the short term. But that could be discussed in another > > > > thread. > > > > > > No objection. Raising the priority of dhcpcd-base to important works for > > > me. > > > > Have we reached a conclusion? Are we moving ahead with this or not? > > What is the current situation? Michael replied that an upgrade would result in both remaining installed. That is precisely the situation that I previously tried to avoid by having a Conflicts against other dhcp-clients. I've been told that this was the incorrect approach, so I removed the Conflicts. Rhys asked what happens if both are installed. As per interfaces(5): dhclient, udhcpc, dhcpcd - in order of precedence. Basically, ensuring that dhcpcd gets used would require a change to ifupdown's search
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
If both are installed, does one work and one fail? Do they both work and basically do extra work? Or can the installation package run a script that disables itself if the other is installed and enabled? --J Sent from my mobile device. From: Michael Biebl Sent: Saturday, November 18, 2023 14:10 To: debian-devel@lists.debian.org Subject: Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie Am 18.11.23 um 15:26 schrieb Martin-Éric Racine: > What is the current situation? I don't think we reached a consensus yet. One particular aspect I don't like of the current proposal is that users upgrading from bookworm will end up with both, isc-dhcp-client and dhcpcd-base being installed.
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Am 18.11.23 um 15:26 schrieb Martin-Éric Racine: What is the current situation? I don't think we reached a consensus yet. One particular aspect I don't like of the current proposal is that users upgrading from bookworm will end up with both, isc-dhcp-client and dhcpcd-base being installed. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Sat, Jul 22, 2023 at 2:55 PM Martin-Éric Racine wrote: > > On Fri, Jul 7, 2023 at 12:55 PM Martin-Éric Racine > wrote: > > > > On Thu, Jul 6, 2023 at 3:06 AM Santiago Ruano Rincón > > wrote: > > > > > > El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió: > > > > El 20/06/23 a las 08:29, Martin-Éric Racine escribió: > > > > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón > > > > > wrote: > > > > > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > > > > > > Greetings, > > > > > > > > > > > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now might > > > > > > > be a > > > > > > > good time to re-visit Debian's choice of standard DHCP client > > > > > > > shipping > > > > > > > with priority:important. > > > > > > > > > > > > > > I hereby propose bin:dhcpcd-base: > > > > > > > > > > > > > > 1) already supported by ifupdown. > > > > > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with > > > > > > > privilege separation. > > > > > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > > > > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > > > > > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > > > > > > configure both stacks. > > > > > > ... > > > > > > > > > > > > I agree that dhcpcd seems the best alternative to isc-dhcp-client > > > > > > for > > > > > > the moment, and I'll make the relevant changes in ifupdown as soon > > > > > > as I > > > > > > can. Josué, any thoughts? > > > > > > > > > > 1) As someone pointed out in the thread, the reason why > > > > > isc-dhcp-client had priority:important probably was to ensure that > > > > > debootstrap would pull it, since debootstrap ignores Recommends and > > > > > packages with a priority lower than standard. > > > > > > > > > > 2) However, as long as ifupdown explictly depends on a package, it can > > > > > also pull dependencies with a lower priority. Right now ifupdown > > > > > Recommends "isc-dhcp-client | dhcp-client" which debootstrap would > > > > > ignore. It would have to Depends "dhcpcd-base | dhcp-client" instead. > > > > > > > > > > 3) At that point, swapping the priority of isc-dhcp-client and > > > > > dhcpcd-base merely becomes "nice to have". Heck, the priority of both > > > > > could, in principle, be optional, just as long as ifupdown explicitly > > > > > Depends on a DHCP client, and the first alternative is a real package. > > > > > > > > I was about to bump dhcpcd-base as ifupdown dependency, but... if > > > > isc-client-dhcp is a Recommends, is because not all users want a dhcp > > > > client installed, where all the ipv4 is handled statically, and ipv6 is > > > > done via SLAAC. As a user, I don't want/need to pull in dhcpcd-base the > > > > next upgrade. > > > > > > > > So I'd prefer to go forward with the steps proposed by Simon, and > > > > s/isc-dhcp-client/dhcpcd-base in ifupdown's Recommends: > > > > Unless there is a strong objection, I'll file the override bug report. > > > > > > (sorry for taking so long to come back to this) > > > > > > For the moment, ifupdown is still installed by the debian-installer as > > > default network interfaces manager. And after sleeping over it, and > > > discussing with debian fellows, I would like to call for consensus to > > > rise Priority: Important to dhcpcd-base (as initially requested in > > > #1038882), and switch to Recommends: dhcpcd-base | dhcp-client. > > > > > > This addresses two scenarios: keep some systems as small as possible > > > (ifupdown users can remove dhcpcd if they want) and having a useful dhcp > > > client available after installing/bootstrapping. > > > > > > So I would like to retitle #1038882 back as originally reported. (Sorry > > > for going back and forth) Objections? > > > > > > The situation regarding the default network interfaces manager could > > > change, even in the short term. But that could be discussed in another > > > thread. > > > > No objection. Raising the priority of dhcpcd-base to important works for me. > > Have we reached a conclusion? Are we moving ahead with this or not? What is the current situation? Martin-Éric
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
El 10/07/23 a las 14:52, Helmut Grohne escribió: > On Sun, Jul 09, 2023 at 05:58:07PM +0100, Luca Boccassi wrote: > > On top of that, a minimal installation chroot doesn't need a > > fully-featured dhcp client. As Simon said already, busybox is there > > for any reason for a minimal one. For the rest - installer and whatnot > > - the installer and tasklets should pull in the required stack as > > needed. > > I contend that currently a debootstrap includes a dhcp client and this > is more of a migration from one dhcp implementation to another. Since > dhcp is the most common way of configuring a network, supporting it in > ifupdown by default also seems like a reasonable choice. > > > So I think not only we should not bump the priority of dhcpd-base, but > > we should also change ifupdown's down to optional. I would like to just echo this: > > I don't quite see consensus on this yet, but I already see significant > interest in changing the default network configuration method. I hope > that it is out of question that we'd demote the priority of the > recommended dhcp client when demoting the priority of ifupdown. Demotion > of ifupdown needs to come with a proposed replacement and/or with > changes to the debian-installer. I do hope that we can get that > discussion going and implemented before trixie. However, this is about > changing the default dhcp client for use with debootstrap and moving the > priority from one package to another seems like an incremental > improvement that is not blocking the bigger goal of changing the default > network configuration tool in any way. > > I expect that dhcpcd will not be important in trixie, but for now that > move makes sense to me, because it is as easily reverted as it is > implemented. This is an instance of "The perfect is the enemy of the > good." [snip] Could we just give a shorter step right now to make things move forward, and let the discussion about the default network interfaces configuration tool for later? Thanks, -- S signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Fri, Jul 7, 2023 at 12:55 PM Martin-Éric Racine wrote: > > On Thu, Jul 6, 2023 at 3:06 AM Santiago Ruano Rincón > wrote: > > > > El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió: > > > El 20/06/23 a las 08:29, Martin-Éric Racine escribió: > > > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón > > > > wrote: > > > > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > > > > > Greetings, > > > > > > > > > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now might > > > > > > be a > > > > > > good time to re-visit Debian's choice of standard DHCP client > > > > > > shipping > > > > > > with priority:important. > > > > > > > > > > > > I hereby propose bin:dhcpcd-base: > > > > > > > > > > > > 1) already supported by ifupdown. > > > > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > > > > > separation. > > > > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > > > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > > > > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > > > > > configure both stacks. > > > > > ... > > > > > > > > > > I agree that dhcpcd seems the best alternative to isc-dhcp-client for > > > > > the moment, and I'll make the relevant changes in ifupdown as soon as > > > > > I > > > > > can. Josué, any thoughts? > > > > > > > > 1) As someone pointed out in the thread, the reason why > > > > isc-dhcp-client had priority:important probably was to ensure that > > > > debootstrap would pull it, since debootstrap ignores Recommends and > > > > packages with a priority lower than standard. > > > > > > > > 2) However, as long as ifupdown explictly depends on a package, it can > > > > also pull dependencies with a lower priority. Right now ifupdown > > > > Recommends "isc-dhcp-client | dhcp-client" which debootstrap would > > > > ignore. It would have to Depends "dhcpcd-base | dhcp-client" instead. > > > > > > > > 3) At that point, swapping the priority of isc-dhcp-client and > > > > dhcpcd-base merely becomes "nice to have". Heck, the priority of both > > > > could, in principle, be optional, just as long as ifupdown explicitly > > > > Depends on a DHCP client, and the first alternative is a real package. > > > > > > I was about to bump dhcpcd-base as ifupdown dependency, but... if > > > isc-client-dhcp is a Recommends, is because not all users want a dhcp > > > client installed, where all the ipv4 is handled statically, and ipv6 is > > > done via SLAAC. As a user, I don't want/need to pull in dhcpcd-base the > > > next upgrade. > > > > > > So I'd prefer to go forward with the steps proposed by Simon, and > > > s/isc-dhcp-client/dhcpcd-base in ifupdown's Recommends: > > > Unless there is a strong objection, I'll file the override bug report. > > > > (sorry for taking so long to come back to this) > > > > For the moment, ifupdown is still installed by the debian-installer as > > default network interfaces manager. And after sleeping over it, and > > discussing with debian fellows, I would like to call for consensus to > > rise Priority: Important to dhcpcd-base (as initially requested in > > #1038882), and switch to Recommends: dhcpcd-base | dhcp-client. > > > > This addresses two scenarios: keep some systems as small as possible > > (ifupdown users can remove dhcpcd if they want) and having a useful dhcp > > client available after installing/bootstrapping. > > > > So I would like to retitle #1038882 back as originally reported. (Sorry > > for going back and forth) Objections? > > > > The situation regarding the default network interfaces manager could > > change, even in the short term. But that could be discussed in another > > thread. > > No objection. Raising the priority of dhcpcd-base to important works for me. Have we reached a conclusion? Are we moving ahead with this or not? Martin-Éric
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Tue, Jul 11, 2023 at 03:06:57PM -0600, Sam Hartman wrote: > However, there are some significant disadvantages to netplan: > 1) It's an extra layer. You can ignore it when reading the config (at > least if you aren't too surprised by your config ending up in /run). > But it is extra complexity, especially in a situation like " run dhcp on > my ethernet" that is relatively simple. > 2) It's a layer that you cannot ignore when editing the config. Netplan > is one way. It takes in config in its format and spews out either > NetworkManager config or systemd-networkd config. You can generate > extra config on top of what netplan does, but in my experience if you > want to edit the config that netplan controls, you need to either do it > through netplan or remove netplan and generate those config chunks by > hand (possibly after looking at how netplan did it). > It's possible there are some netplan modes I missed and some other ways > of doing things. It's also possible netplan has evolved since I looked > at it. > In the non-wifi case I think d-i's networking is too simple to justify > netplan. > A simple .network unit for systemd-networkd sounds like a better option. I am not unbiased here, but I'd like to offer a counterargument: to a user, there is value in consistency. Yes, netplan is an additional layer. But having a layer that a user can rely on being present on any Debian system, whether it's a cloud instance, a server, or a desktop install with wifi, can be a big help. As someone who learned what a netmask is in 1997 or earlier, I have been surprised to learn over the course of netplan's development just how many people configuring networks on Linux systems - including on servers and routers - don't actually know thing #1 about IPv4 and are trying to configure their networks based on the recipes they find on the Internet. Which also means their lives are made significantly easier when the recipes they find are more broadly applicable across different types of installs, and significantly harder if they have to separately search how to configure networking for clouds, servers, or desktops. The design goal of netplan is that it's a layer that you shouldn't have to peek underneath, because it exposes everything you would need to configure in networkd or NetworkManager. Granted it's not *completely* there yet, but with the work to make NetworkManager use netplan as its config backend (which means: in the next release of Ubuntu you can happily use nmcli, nm-applet, etc. to manage your network connections and get human-editable netplan files out), it's certainly close. And I can say that I am a happy user of netplan across multiple systems, with no need to manage networkd configuration directly. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Fri, Jul 14, 2023 at 09:33:12AM -0400, Jeremy Bícha wrote: > On Wed, Jul 12, 2023 at 8:32 AM Lukas Märdian wrote: > > (We're also working on a bidirectional Netplan-NetworkManager integration, > > that allows NM to feed back it's configuration into Netplan YAML format. It > > is > > a small patch for NetworkManager and is purely optional.) > > Does that already exist in Ubuntu 23.10 "Mantic"? Yes, we enabled it in Ubuntu just recently. The code can be found here: https://git.launchpad.net/network-manager/tree/debian/patches/netplan Cheers, Lukas signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Sat, Jul 15, 2023 at 02:04:57PM -0400, nick black wrote:
> Sam Hartman left as an exercise for the reader:
> > I consider anything that requires me to write wpa_supplicant config to
> > be a bad idea (unless I'm running an AP) and NetworkManager driving
> > wpa_supplicant is a better idea.
>
> i think everyone's agreed on this part.
For my part I tend to prefer writing wpa_supplicant configs, as they're
dead simple and allow for easy setting of priorities. Including them from
/etc/network/interfaces is also trivial.
Example /etc/network/interfaces and /etc/wpa_supplicant/wpa_supplicant.conf
from my laptop, with just the names changed:
---
source /etc/network/interfaces.d/*
auto eth0
iface eth0 inet dhcp
pre-up /sbin/mii-tool eth0 | /bin/grep -qv "no link"
auto wlan0
iface wlan0 inet dhcp
pre-up /sbin/mii-tool eth0 | /bin/grep -q "no link"
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
---
---
network={
ssid="Home"
psk="home password"
# Can also be this, via wpa_passphrase:
# psk=15bd59d568643e6781dd12f7e160b0589242472d3cc299bb5b0c4289d40c01af
priority=20
}
network={
ssid="CoffeeShop"
#psk="coffee password"
psk=ccd48495b2a1b7502f0bb0c5ca3689f6847b4f8532ce195ec17080308acb6bcd
priority=10
}
network={
key_mgmt=NONE
}
---
So, not quite everyone agrees. An advantage to using wpa_supplicant.conf
directly is that it works everywhere, and can generally be distributed as-
is across different operating systems.
--
Mason Loring Bliss ma...@blisses.orghttp://blisses.org/
For more enjoyment and greater efficiency, consumption is being standardized.
signature.asc
Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Sam Hartman left as an exercise for the reader: > > "nick" == nick black writes: > I consider anything that requires me to write wpa_supplicant config to > be a bad idea (unless I'm running an AP) and NetworkManager driving > wpa_supplicant is a better idea. i think everyone's agreed on this part. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe.
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Wed, Jul 12, 2023 at 8:32 AM Lukas Märdian wrote: > (We're also working on a bidirectional Netplan-NetworkManager integration, > that allows NM to feed back it's configuration into Netplan YAML format. It is > a small patch for NetworkManager and is purely optional.) Does that already exist in Ubuntu 23.10 "Mantic"? Thank you, Jeremy Bícha
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
> "Lukas" == Lukas Märdian writes: Lukas> That would lead to a situation where users would need to Lukas> differentiate what system they are on when doing their Lukas> network configuration: Debian Cloud (Netplan) No, I think if the user is feeding configuration into a cloud image other than through cloud-init, we don't need netplan unless the user wants it. If they want netplan they can install it. Ifg you are feeding config through cloud-init, you are already differentiating your config because of cloud-init. Lukas> vs Desktop Lukas> (NetworkManager) vs Server (systemd-networkd) I think this differentiation is valuable. Because of the following two issues, I retract my support for d-i outputting netplan config in the wifi case: 1) It already generates NetworkManager config 2) As Simon points out, generating raw NetworkManager config is going to have better user experience if the user later edits the config. --Sam
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
> "nick" == nick black writes: I consider anything that requires me to write wpa_supplicant config to be a bad idea (unless I'm running an AP) and NetworkManager driving wpa_supplicant is a better idea. --Sam
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Sam Hartman left as an exercise for the reader: > In the wifi case though, I agree that netplan is a good idea. > It doesn't look like systemd-networkd supports setting up the > authentication for a wireless network. So, you'd need to be using > wpa_supplicant directly and systemd-networkd. I think using I might be misunderstanding your use of "directly" here, but systemd-networkd certainly supports driving wifi authentication through wpa_supplicant (though yes, the configuration is outsourced to wpa_supplicant, which seems desirable since it can then be picked up and used easily by other tools). It's not tightly integrated, though, so you usually need some "IgnoreCarrierLoss" chicanery if you don't want to reinitialize the interface when switching between BSSIDs. This is probably what you meant, but just wanted to be clear. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Wed, Jul 12, 2023 at 01:33:02PM +0200, Andrey Rakhmatullin wrote: > On Wed, Jul 12, 2023 at 12:26:52PM +0100, Simon McVittie wrote: > > > From the discussions above, it seems that NetworkManager is relevant as > > > well, > > > though, and is being pulled in whenever a desktop task is installed (in > > > addition to ifupdown or future systemd-networkd). > > > > What happens at the moment is: > > > > - if the tasks install NetworkManager, then d-i translates the install-time > > networking into NetworkManager configuration, together with essentially > > blank ifupdown configuration that makes ifupdown mostly a no-op (it > > might still try to bring up `lo`, but systemd brings that up as an "API" > > interface anyway, and probably so does NM if systemd didn't already) > Something also enables the ifupdown plugin in NM (and does something about > managed=true/false? I'm not familiar with this integration). If we remove > ifupdown this should be changed I think. We could save that translation step in d-i when using Netplan. We'd just need the network-manager package ship a /usr/lib/netplan/00-network-manager-all.yaml ``` network: version: 2 renderer: NetworkManager ``` > > - otherwise, d-i translates the install-time networking into ifupdown > > configuration > > > > Doing that, but with s/ifupdown/systemd-networkd/ throughout, makes > > sense to me. Is that what others in this thread had in mind? > > > > The practical result would be NM on desktop/laptop class systems, and > > systemd-networkd on server/embedded systems, which as it happens is what > > I'm already doing on my own machines. > I also wonder how complicated would it be to get WiFi configured in the > GUI-less setup. Currently it's easy if NM was installed for some reason > (with nmtui) and not easy otherwise. That would lead to a situation where users would need to differentiate what system they are on when doing their network configuration: Debian Cloud (Netplan) vs Desktop (NetworkManager) vs Server (systemd-networkd) All using different formats and locations to store their configuration. On Wed, Jul 12, 2023 at 12:26:52PM +0100, Simon McVittie wrote: > > Therefore, I'd love to see Netplan to be used in combination with this! > > It's a clean, declarative configuration language not specifically tied to > > systemd-networkd as an implementation. So it could also be used on desktop > > installs where NetworkManager is important, for example to handle roaming > > between varying WiFi networks. > > One of the major reasons why the desktop tasks use NetworkManager > is that it's well-integrated in desktop environments (particularly > our default GNOME desktop, but also others like KDE Plasma). If GNOME > controls NetworkManager directly, using its client library and D-Bus > API, is that going to conflict/collide with Netplan also trying to > control/configure NetworkManager? If I'm understanding Netplan correctly, > it treats NM and networkd configuration as essentially "write-only" > (like a compiler that inputs its own syntax and outputs NM or networkd > syntax), which doesn't seem compatible with GNOME going behind its back? > > It seems unlikely that GNOME upstream is going to switch to using > a Netplan API and having it as a dependency unless it has extremely > compelling benefits, because they are happy with their design choice to > have tight integration with NetworkManager; and the Debian GNOME team > already does not have the resources to maintain GNOME in Debian as well > as we would like to, so I think I can safely say we aren't going to be > able to maintain a patch for GNOME to use Netplan APIs downstream. I'm > sure other major desktops like KDE Plasma are in the same situation. I fully agree on NetworkManager being very well integrated in desktop environments and I don't want to force the Netplan API onto anybody. It isn't needed. Netplan plays nicely side-by-side with NetworkManager. When Netplan's default "renderer" is set to be "NetworkManager" (see config snippet above, which could be shipped by the network-manager package), Netplan would just feed NM connection profiles into /run/NetworkManager/, while NM is still free to choose which connection profile to use, or add additional profiles in /etc/NetworkManager/ as usual. (We're also working on a bidirectional Netplan-NetworkManager integration, that allows NM to feed back it's configuration into Netplan YAML format. It is a small patch for NetworkManager and is purely optional.) -- Lukas signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Hi Lukas, * Lukas Märdian [2023-07-12 12:53]: Thank you for pointing this out. It's been on my TODO list for a while to split the netplan.io package, and make the Python-CLI parts optional. They are not strictly required to configure a system at boot time. I took your mail as an occation to finally draft something up along those lines: https://salsa.debian.org/debian/netplan.io/-/merge_requests/9 I hope to land that package-split in the not too distant future. Just be aware that you you will likely have to move files from / to /usr for the merged-/usr transition during the trixie release cycle as well. That might become slightly more complicated if you also split the package. (I'm not saying it can't be done, just that it might be less straight forward and require some extra care.) Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Wed, Jul 12, 2023 at 12:26:52PM +0100, Simon McVittie wrote: > > From the discussions above, it seems that NetworkManager is relevant as > > well, > > though, and is being pulled in whenever a desktop task is installed (in > > addition to ifupdown or future systemd-networkd). > > What happens at the moment is: > > - if the tasks install NetworkManager, then d-i translates the install-time > networking into NetworkManager configuration, together with essentially > blank ifupdown configuration that makes ifupdown mostly a no-op (it > might still try to bring up `lo`, but systemd brings that up as an "API" > interface anyway, and probably so does NM if systemd didn't already) Something also enables the ifupdown plugin in NM (and does something about managed=true/false? I'm not familiar with this integration). If we remove ifupdown this should be changed I think. > - otherwise, d-i translates the install-time networking into ifupdown > configuration > > Doing that, but with s/ifupdown/systemd-networkd/ throughout, makes > sense to me. Is that what others in this thread had in mind? > > The practical result would be NM on desktop/laptop class systems, and > systemd-networkd on server/embedded systems, which as it happens is what > I'm already doing on my own machines. I also wonder how complicated would it be to get WiFi configured in the GUI-less setup. Currently it's easy if NM was installed for some reason (with nmtui) and not easy otherwise.
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Tue, 11 Jul 2023 at 17:48:40 +0200, Lukas Märdian wrote: > From the discussions above, it seems that NetworkManager is relevant as well, > though, and is being pulled in whenever a desktop task is installed (in > addition to ifupdown or future systemd-networkd). What happens at the moment is: - if the tasks install NetworkManager, then d-i translates the install-time networking into NetworkManager configuration, together with essentially blank ifupdown configuration that makes ifupdown mostly a no-op (it might still try to bring up `lo`, but systemd brings that up as an "API" interface anyway, and probably so does NM if systemd didn't already) - otherwise, d-i translates the install-time networking into ifupdown configuration Doing that, but with s/ifupdown/systemd-networkd/ throughout, makes sense to me. Is that what others in this thread had in mind? The practical result would be NM on desktop/laptop class systems, and systemd-networkd on server/embedded systems, which as it happens is what I'm already doing on my own machines. > Therefore, I'd love to see Netplan to be used in combination with this! > It's a clean, declarative configuration language not specifically tied to > systemd-networkd as an implementation. So it could also be used on desktop > installs where NetworkManager is important, for example to handle roaming > between varying WiFi networks. One of the major reasons why the desktop tasks use NetworkManager is that it's well-integrated in desktop environments (particularly our default GNOME desktop, but also others like KDE Plasma). If GNOME controls NetworkManager directly, using its client library and D-Bus API, is that going to conflict/collide with Netplan also trying to control/configure NetworkManager? If I'm understanding Netplan correctly, it treats NM and networkd configuration as essentially "write-only" (like a compiler that inputs its own syntax and outputs NM or networkd syntax), which doesn't seem compatible with GNOME going behind its back? It seems unlikely that GNOME upstream is going to switch to using a Netplan API and having it as a dependency unless it has extremely compelling benefits, because they are happy with their design choice to have tight integration with NetworkManager; and the Debian GNOME team already does not have the resources to maintain GNOME in Debian as well as we would like to, so I think I can safely say we aren't going to be able to maintain a patch for GNOME to use Netplan APIs downstream. I'm sure other major desktops like KDE Plasma are in the same situation. smcv
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Tue, Jul 11, 2023 at 03:06:57PM -0600, Sam Hartman wrote: > > "Lukas" == Lukas Märdian writes: > > > Lukas> Therefore, I'd love to see Netplan to be used in combination > Lukas> with this! It's a clean, declarative configuration language > Lukas> not specifically tied to systemd-networkd as an > Lukas> implementation. So it could also be used on desktop installs > Lukas> where NetworkManager is important, for example to handle > Lukas> roaming between varying WiFi networks. It would also allow > Lukas> for d-i to install a single, common default network > Lukas> configuration, independently of the underlying daemon. > > I currently use netplan.io when I need to interact with cloud-init and > network configs. > > I think netplan is a great tool when > > 1) You need to interact with cloud-init > > or > > 2) When a human is generating systemd-networkd config or NetworkManager > config. > systemd-network splits its config across multiple files in a way that's > really nice when you have some provisioning system generating it, but > isn't so nice when you are wanting to look at the config all in one > place as a human. > NetworkManager's config is a bit fiddly to generate by hand, much less > so than netplan.io. I agree, cloud-init is a strong use-case. And another one is the ability to support systemd-networkd and NetworkManager with a common configuration file, which can be amended by a human or another package (like NetworkManager) shipping a drop-in config, to amend which networking daemon is configured. Let me give a specific example below... > However, there are some significant disadvantages to netplan: > > 1) It's an extra layer. You can ignore it when reading the config (at > least if you aren't too surprised by your config ending up in /run). > But it is extra complexity, especially in a situation like " run dhcp on > my ethernet" that is relatively simple. It is an extra layer, but this also brings the benefit of being compatible with networkd and NetworkManager. Let me give an example: D-i could install a basic Netplan config to "run dhcp on my ethernet", e.g. /etc/netplan/90-default.yaml: ``` network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ``` This would generate systemd-networkd (Netplan's default backend) configuration at boot time in /run/systemd/network/10-netplan-eth0.network Now, if a desktop task is pulling in the network-manager package, that could ship a /usr/lib/netplan/00-network-manager-all.yaml Netplan drop-in config: ``` network: version: 2 renderer: NetworkManager ``` Which would change the default setup to now generate NetworkManager config in /run/NetworkManager/system-connections/netplan-eth0.nmconnection instead. This is without any changes to the installation system or the file shipped in /etc/netplan/90-default.yaml. Of course, users can still override that decision (even on the interface level) by specifying the "renderer" setting explicitly in some /etc/netplan/ config. > 2) It's a layer that you cannot ignore when editing the config. Netplan > is one way. It takes in config in its format and spews out either > NetworkManager config or systemd-networkd config. You can generate > extra config on top of what netplan does, but in my experience if you > want to edit the config that netplan controls, you need to either do it > through netplan or remove netplan and generate those config chunks by > hand (possibly after looking at how netplan did it). Yes, you can easily define your own /etc/systemd/network/* config besides any /etc/netplan/* config that generates files in /run/systemd/network. Netplan tries to always play nice with any interfaces configured outside of /etc/netplan/, for example manually configured Open vSwitch bridges. In fact, you can also easily amend or override systemd-networkd configuration generated by Netplan, using systemd's usual override-config approach. Picking up the example above, you could create a file in: /etc/systemd/network/10-netplan-eth0.network.d/override.conf Which can add or change anything configured by Netplan in: /run/systemd/network/10-netplan-eth0.network > It's possible there are some netplan modes I missed and some other ways > of doing things. It's also possible netplan has evolved since I looked > at it. Netplan has evolved a lot since its early days in 2016 and there are many more possiblities, e.g. a libnetplan.so for deeper integration in other tools (e.g. to validate Netplan YAML configs from a 3rd party tool). > In the non-wifi case I think d-i's networking is too simple to justify > netplan. > A simple .network unit for systemd-networkd sounds like a better option. > > In the wifi case though, I agree that netplan is a good idea. > It doesn't look like systemd-networkd supports setting up the > authentication for a wireless network. So, you'd need to be using > wpa_supplicant directly and systemd-networkd. I think
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Jul 11, Sam Hartman wrote: > 1) It's an extra layer. You can ignore it when reading the config (at > least if you aren't too surprised by your config ending up in /run). > But it is extra complexity, especially in a situation like " run dhcp on > my ethernet" that is relatively simple. I agree. I do not really see the value of netplan in a default install and it brings a lot of complexity (and Python!) which is not usually needed. -- ciao, Marco signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On 2023-07-12 07:54, Gioele Barabucci wrote: 1) It's an extra layer. [...] 2) It's a layer that you cannot ignore when editing the config. [...] I'd also add 3) It requires Python and various Python libraries. At least the CLI tool does. In some circumstances installing Python and a bunch of libraries is not going to be a big issue (e.g., in desktop installs), but for many server installations that is an unnecessary new burden. (To be fair, Lukas opened his email stating that for minimal installations sd-netwokd is a more fitting alternative. I just wanted to explicitly mention one reason supporting that statement.) If Python is an option, ifupdown2 is IMO a far better candidate than netplan: 1. It reuses the familiar syntax we have with ifupdown 2. It knows how to converge to the provided configuration from the running configuration (this makes notably the trivial workflow "let's modify the IP address of this interface" just works, but more complex scenario like "let's put this interface and IP address in a VLAN on a bond devices"). It has been some time since the latest release (almost 3 years), but it looks still maintained.
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On 11/07/23 23:06, Sam Hartman wrote: However, there are some significant disadvantages to netplan: 1) It's an extra layer. [...] 2) It's a layer that you cannot ignore when editing the config. [...] I'd also add 3) It requires Python and various Python libraries. At least the CLI tool does. In some circumstances installing Python and a bunch of libraries is not going to be a big issue (e.g., in desktop installs), but for many server installations that is an unnecessary new burden. (To be fair, Lukas opened his email stating that for minimal installations sd-netwokd is a more fitting alternative. I just wanted to explicitly mention one reason supporting that statement.) Regards, -- Gioele Barabucci
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
> "Lukas" == Lukas Märdian writes: Lukas> Therefore, I'd love to see Netplan to be used in combination Lukas> with this! It's a clean, declarative configuration language Lukas> not specifically tied to systemd-networkd as an Lukas> implementation. So it could also be used on desktop installs Lukas> where NetworkManager is important, for example to handle Lukas> roaming between varying WiFi networks. It would also allow Lukas> for d-i to install a single, common default network Lukas> configuration, independently of the underlying daemon. I currently use netplan.io when I need to interact with cloud-init and network configs. I think netplan is a great tool when 1) You need to interact with cloud-init or 2) When a human is generating systemd-networkd config or NetworkManager config. systemd-network splits its config across multiple files in a way that's really nice when you have some provisioning system generating it, but isn't so nice when you are wanting to look at the config all in one place as a human. NetworkManager's config is a bit fiddly to generate by hand, much less so than netplan.io. However, there are some significant disadvantages to netplan: 1) It's an extra layer. You can ignore it when reading the config (at least if you aren't too surprised by your config ending up in /run). But it is extra complexity, especially in a situation like " run dhcp on my ethernet" that is relatively simple. 2) It's a layer that you cannot ignore when editing the config. Netplan is one way. It takes in config in its format and spews out either NetworkManager config or systemd-networkd config. You can generate extra config on top of what netplan does, but in my experience if you want to edit the config that netplan controls, you need to either do it through netplan or remove netplan and generate those config chunks by hand (possibly after looking at how netplan did it). It's possible there are some netplan modes I missed and some other ways of doing things. It's also possible netplan has evolved since I looked at it. In the non-wifi case I think d-i's networking is too simple to justify netplan. A simple .network unit for systemd-networkd sounds like a better option. In the wifi case though, I agree that netplan is a good idea. It doesn't look like systemd-networkd supports setting up the authentication for a wireless network. So, you'd need to be using wpa_supplicant directly and systemd-networkd. I think using NetworkManager is going to provide a better user experience than directly configuring wpa_supplicant, and I think netplan has significant added value for automatic configuration of NetworkManager. signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, Jul 10, 2023 at 09:39:52AM -0400, nick black wrote: > Helmut Grohne left as an exercise for the reader: > > And yeah, please work on changing that ifupdown by default. I'm faced > > with having to uninstall it from more and more systems. In case, you > > do a straw poll, I vote for systemd-networkd, which happens to be > > installed by default. Would there be any volunteers doing the d-i > > integration? > > I'd be interested in taking this on, though I wouldn't want to > step on anyone's toes, so if someone with a feeling of ownership > would rather take it, please let yourself be known. I'd want > clarity as to whose approval I need to merge code (and their > buy-in to the effort overall) before starting. > > I've messed with d-i and systemd-networkd both a good bit, and > like you (I assume) believe systemd-networkd to be the best > option at this time, and also moving forward. Having touched both of those projects sounds like a good starting point! I agree we should be going with systemd-networkd for minimal/server setups. It is slim and comes pre-included with systemd, so is already part of many Debian installations. From the discussions above, it seems that NetworkManager is relevant as well, though, and is being pulled in whenever a desktop task is installed (in addition to ifupdown or future systemd-networkd). Therefore, I'd love to see Netplan to be used in combination with this! It's a clean, declarative configuration language not specifically tied to systemd-networkd as an implementation. So it could also be used on desktop installs where NetworkManager is important, for example to handle roaming between varying WiFi networks. It would also allow for d-i to install a single, common default network configuration, independently of the underlying daemon. The Netplan + systemd-networkd stack is already being used in Bookworm cloud-images [1]. So going with that in d-i as well, would have the additonal benefit of common network configuration accorss different variants. Cheers, Lukas [1] https://blog.slyon.de/2023/07/10/netplan-and-systemd-networkd-on-debian-bookworm/ signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Helmut Grohne left as an exercise for the reader: > And yeah, please work on changing that ifupdown by default. I'm faced > with having to uninstall it from more and more systems. In case, you > do a straw poll, I vote for systemd-networkd, which happens to be > installed by default. Would there be any volunteers doing the d-i > integration? I'd be interested in taking this on, though I wouldn't want to step on anyone's toes, so if someone with a feeling of ownership would rather take it, please let yourself be known. I'd want clarity as to whose approval I need to merge code (and their buy-in to the effort overall) before starting. I've messed with d-i and systemd-networkd both a good bit, and like you (I assume) believe systemd-networkd to be the best option at this time, and also moving forward. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Sun, Jul 09, 2023 at 05:58:07PM +0100, Luca Boccassi wrote: > On top of that, a minimal installation chroot doesn't need a > fully-featured dhcp client. As Simon said already, busybox is there > for any reason for a minimal one. For the rest - installer and whatnot > - the installer and tasklets should pull in the required stack as > needed. I contend that currently a debootstrap includes a dhcp client and this is more of a migration from one dhcp implementation to another. Since dhcp is the most common way of configuring a network, supporting it in ifupdown by default also seems like a reasonable choice. > So I think not only we should not bump the priority of dhcpd-base, but > we should also change ifupdown's down to optional. I don't quite see consensus on this yet, but I already see significant interest in changing the default network configuration method. I hope that it is out of question that we'd demote the priority of the recommended dhcp client when demoting the priority of ifupdown. Demotion of ifupdown needs to come with a proposed replacement and/or with changes to the debian-installer. I do hope that we can get that discussion going and implemented before trixie. However, this is about changing the default dhcp client for use with debootstrap and moving the priority from one package to another seems like an incremental improvement that is not blocking the bigger goal of changing the default network configuration tool in any way. I expect that dhcpcd will not be important in trixie, but for now that move makes sense to me, because it is as easily reverted as it is implemented. This is an instance of "The perfect is the enemy of the good." And yeah, please work on changing that ifupdown by default. I'm faced with having to uninstall it from more and more systems. In case, you do a straw poll, I vote for systemd-networkd, which happens to be installed by default. Would there be any volunteers doing the d-i integration? Helmut
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Sat, 8 Jul 2023 at 08:39, Bastian Blank wrote: > > On Fri, Jul 07, 2023 at 06:07:58PM -0600, Sam Hartman wrote: > > > "Bastian" == Bastian Blank writes: > > Bastian> Why do we need to have the priority adjusted instead of fix > > Bastian> d-i to install what it knows the user needs? > > Because it's not just D-I, it's bootstrapping in general. > > For that reason I support raising the priority. > > No, it isn't. Bootstrapping does not magically enable ifupdown to do > dhcp, this requires explicit config, as done by d-i. And you can expect > the tool doing the config to make sure the appropriate packages are > installed. On top of that, a minimal installation chroot doesn't need a fully-featured dhcp client. As Simon said already, busybox is there for any reason for a minimal one. For the rest - installer and whatnot - the installer and tasklets should pull in the required stack as needed. So I think not only we should not bump the priority of dhcpd-base, but we should also change ifupdown's down to optional. Kind regards, Luca Boccassi
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Fri, Jul 07, 2023 at 06:07:58PM -0600, Sam Hartman wrote: > > "Bastian" == Bastian Blank writes: > Bastian> Why do we need to have the priority adjusted instead of fix > Bastian> d-i to install what it knows the user needs? > Because it's not just D-I, it's bootstrapping in general. > For that reason I support raising the priority. No, it isn't. Bootstrapping does not magically enable ifupdown to do dhcp, this requires explicit config, as done by d-i. And you can expect the tool doing the config to make sure the appropriate packages are installed. Bastian -- It is undignified for a woman to play servant to a man who is not hers. -- Spock, "Amok Time", stardate 3372.7
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
> "Bastian" == Bastian Blank writes: Bastian> On Wed, Jul 05, 2023 at 09:06:24PM -0300, Santiago Ruano Rincón wrote: >> For the moment, ifupdown is still installed by the >> debian-installer as default network interfaces manager. And after >> sleeping over it, and discussing with debian fellows, I would >> like to call for consensus to rise Priority: Important to >> dhcpcd-base (as initially requested in #1038882), and switch to >> Recommends: dhcpcd-base | dhcp-client. Bastian> Why do we need to have the priority adjusted instead of fix Bastian> d-i to install what it knows the user needs? Because it's not just D-I, it's bootstrapping in general. For that reason I support raising the priority.
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Wed, Jul 05, 2023 at 09:06:24PM -0300, Santiago Ruano Rincón wrote: > For the moment, ifupdown is still installed by the debian-installer as > default network interfaces manager. And after sleeping over it, and > discussing with debian fellows, I would like to call for consensus to > rise Priority: Important to dhcpcd-base (as initially requested in > #1038882), and switch to Recommends: dhcpcd-base | dhcp-client. Why do we need to have the priority adjusted instead of fix d-i to install what it knows the user needs? Bastian -- Where there's no emotion, there's no motive for violence. -- Spock, "Dagger of the Mind", stardate 2715.1
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Thu, Jul 6, 2023 at 3:06 AM Santiago Ruano Rincón wrote: > > El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió: > > El 20/06/23 a las 08:29, Martin-Éric Racine escribió: > > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón > > > wrote: > > > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > > > > Greetings, > > > > > > > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a > > > > > good time to re-visit Debian's choice of standard DHCP client shipping > > > > > with priority:important. > > > > > > > > > > I hereby propose bin:dhcpcd-base: > > > > > > > > > > 1) already supported by ifupdown. > > > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > > > > separation. > > > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > > > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > > > > configure both stacks. > > > > ... > > > > > > > > I agree that dhcpcd seems the best alternative to isc-dhcp-client for > > > > the moment, and I'll make the relevant changes in ifupdown as soon as I > > > > can. Josué, any thoughts? > > > > > > 1) As someone pointed out in the thread, the reason why > > > isc-dhcp-client had priority:important probably was to ensure that > > > debootstrap would pull it, since debootstrap ignores Recommends and > > > packages with a priority lower than standard. > > > > > > 2) However, as long as ifupdown explictly depends on a package, it can > > > also pull dependencies with a lower priority. Right now ifupdown > > > Recommends "isc-dhcp-client | dhcp-client" which debootstrap would > > > ignore. It would have to Depends "dhcpcd-base | dhcp-client" instead. > > > > > > 3) At that point, swapping the priority of isc-dhcp-client and > > > dhcpcd-base merely becomes "nice to have". Heck, the priority of both > > > could, in principle, be optional, just as long as ifupdown explicitly > > > Depends on a DHCP client, and the first alternative is a real package. > > > > I was about to bump dhcpcd-base as ifupdown dependency, but... if > > isc-client-dhcp is a Recommends, is because not all users want a dhcp > > client installed, where all the ipv4 is handled statically, and ipv6 is > > done via SLAAC. As a user, I don't want/need to pull in dhcpcd-base the > > next upgrade. > > > > So I'd prefer to go forward with the steps proposed by Simon, and > > s/isc-dhcp-client/dhcpcd-base in ifupdown's Recommends: > > Unless there is a strong objection, I'll file the override bug report. > > (sorry for taking so long to come back to this) > > For the moment, ifupdown is still installed by the debian-installer as > default network interfaces manager. And after sleeping over it, and > discussing with debian fellows, I would like to call for consensus to > rise Priority: Important to dhcpcd-base (as initially requested in > #1038882), and switch to Recommends: dhcpcd-base | dhcp-client. > > This addresses two scenarios: keep some systems as small as possible > (ifupdown users can remove dhcpcd if they want) and having a useful dhcp > client available after installing/bootstrapping. > > So I would like to retitle #1038882 back as originally reported. (Sorry > for going back and forth) Objections? > > The situation regarding the default network interfaces manager could > change, even in the short term. But that could be discussed in another > thread. No objection. Raising the priority of dhcpcd-base to important works for me. Martin-Éric
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió: > El 20/06/23 a las 08:29, Martin-Éric Racine escribió: > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón > > wrote: > > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > > > Greetings, > > > > > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a > > > > good time to re-visit Debian's choice of standard DHCP client shipping > > > > with priority:important. > > > > > > > > I hereby propose bin:dhcpcd-base: > > > > > > > > 1) already supported by ifupdown. > > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > > > separation. > > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > > > configure both stacks. > > > ... > > > > > > I agree that dhcpcd seems the best alternative to isc-dhcp-client for > > > the moment, and I'll make the relevant changes in ifupdown as soon as I > > > can. Josué, any thoughts? > > > > 1) As someone pointed out in the thread, the reason why > > isc-dhcp-client had priority:important probably was to ensure that > > debootstrap would pull it, since debootstrap ignores Recommends and > > packages with a priority lower than standard. > > > > 2) However, as long as ifupdown explictly depends on a package, it can > > also pull dependencies with a lower priority. Right now ifupdown > > Recommends "isc-dhcp-client | dhcp-client" which debootstrap would > > ignore. It would have to Depends "dhcpcd-base | dhcp-client" instead. > > > > 3) At that point, swapping the priority of isc-dhcp-client and > > dhcpcd-base merely becomes "nice to have". Heck, the priority of both > > could, in principle, be optional, just as long as ifupdown explicitly > > Depends on a DHCP client, and the first alternative is a real package. > > I was about to bump dhcpcd-base as ifupdown dependency, but... if > isc-client-dhcp is a Recommends, is because not all users want a dhcp > client installed, where all the ipv4 is handled statically, and ipv6 is > done via SLAAC. As a user, I don't want/need to pull in dhcpcd-base the > next upgrade. > > So I'd prefer to go forward with the steps proposed by Simon, and > s/isc-dhcp-client/dhcpcd-base in ifupdown's Recommends: > Unless there is a strong objection, I'll file the override bug report. (sorry for taking so long to come back to this) For the moment, ifupdown is still installed by the debian-installer as default network interfaces manager. And after sleeping over it, and discussing with debian fellows, I would like to call for consensus to rise Priority: Important to dhcpcd-base (as initially requested in #1038882), and switch to Recommends: dhcpcd-base | dhcp-client. This addresses two scenarios: keep some systems as small as possible (ifupdown users can remove dhcpcd if they want) and having a useful dhcp client available after installing/bootstrapping. So I would like to retitle #1038882 back as originally reported. (Sorry for going back and forth) Objections? The situation regarding the default network interfaces manager could change, even in the short term. But that could be discussed in another thread. Cheers, -- Santiago signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Thu, 2023-06-22 at 20:51 +0200, Philipp Kern wrote: > On 22.06.23 16:03, Marco d'Itri wrote: > > > TBH time is too short to manually provision IP addresses on servers. > IP addresses are just one of many things that can be instantiated by /etc/network/interfaces, /etc/network/interfaces.d/, and /etc/netplan/whatever.yaml. Will dhcpcd-base provision an IP address for a one interface and not interfere with any existing interfaces or routes (e.g. bridged interfaces, static VPN routes, containers, etc.) -Jim P.
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Thu, Jun 22, 2023 at 08:51:01PM +0200, Philipp Kern wrote: > TBH time is too short to manually provision IP addresses on servers. And DHCP is gladly enough entirely optional since SLAAC exists. But for that you need systemd-networkd/systemd-resolved or a whole bunch of other software. Bastian -- "... freedom ... is a worship word..." "It is our worship word too." -- Cloud William and Kirk, "The Omega Glory", stardate unknown
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On 22.06.23 16:03, Marco d'Itri wrote: On Jun 22, Martin-Éric Racine wrote: The point has always been to ship some ifupdown-supported DHCP client by default. This can be done either by keeping the default client's priority to important or by making ifupdown Depends on one. I prefer the later. It would be totally unacceptable to make ifupdown Depend on a DHCP client, because this would bloat most server installations. But I would be happy with a Recommends. It's not like the people whose server needs a DHCP client do not know that they need to install one. TBH time is too short to manually provision IP addresses on servers. Kind regards Philipp Kern
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Marco d'Itri writes: > On Jun 22, Martin-Éric Racine wrote: > >> The point has always been to ship some ifupdown-supported DHCP client >> by default. This can be done either by keeping the default client's >> priority to important or by making ifupdown Depends on one. I prefer >> the later. > It would be totally unacceptable to make ifupdown Depend on a DHCP > client, because this would bloat most server installations. > But I would be happy with a Recommends. It's not like the people whose > server needs a DHCP client do not know that they need to install one. The DHCP client I have to hand says: Installed-Size: 686 ...so while I can see an argument about bloating a server install, I'm not sure it's strong enough to warrant "totally unacceptable"? Regards, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Jun 22, Martin-Éric Racine wrote: > The point has always been to ship some ifupdown-supported DHCP client > by default. This can be done either by keeping the default client's > priority to important or by making ifupdown Depends on one. I prefer > the later. It would be totally unacceptable to make ifupdown Depend on a DHCP client, because this would bloat most server installations. But I would be happy with a Recommends. It's not like the people whose server needs a DHCP client do not know that they need to install one. -- ciao, Marco signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Thu, Jun 22, 2023 at 3:58 PM Santiago Ruano Rincón wrote: > El 20/06/23 a las 08:29, Martin-Éric Racine escribió: > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón > > wrote: > > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > > > Greetings, > > > > > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a > > > > good time to re-visit Debian's choice of standard DHCP client shipping > > > > with priority:important. > > > > > > > > I hereby propose bin:dhcpcd-base: > > > > > > > > 1) already supported by ifupdown. > > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > > > separation. > > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > > > configure both stacks. > > > ... > > > > > > I agree that dhcpcd seems the best alternative to isc-dhcp-client for > > > the moment, and I'll make the relevant changes in ifupdown as soon as I > > > can. Josué, any thoughts? > > > > 1) As someone pointed out in the thread, the reason why > > isc-dhcp-client had priority:important probably was to ensure that > > debootstrap would pull it, since debootstrap ignores Recommends and > > packages with a priority lower than standard. > > > > 2) However, as long as ifupdown explictly depends on a package, it can > > also pull dependencies with a lower priority. Right now ifupdown > > Recommends "isc-dhcp-client | dhcp-client" which debootstrap would > > ignore. It would have to Depends "dhcpcd-base | dhcp-client" instead. > > > > 3) At that point, swapping the priority of isc-dhcp-client and > > dhcpcd-base merely becomes "nice to have". Heck, the priority of both > > could, in principle, be optional, just as long as ifupdown explicitly > > Depends on a DHCP client, and the first alternative is a real package. > > I was about to bump dhcpcd-base as ifupdown dependency, but... if > isc-client-dhcp is a Recommends, is because not all users want a dhcp > client installed, where all the ipv4 is handled statically, and ipv6 is > done via SLAAC. As a user, I don't want/need to pull in dhcpcd-base the > next upgrade. > > So I'd prefer to go forward with the steps proposed by Simon, and > s/isc-dhcp-client/dhcpcd-base in ifupdown's Recommends: > Unless there is a strong objection, I'll file the override bug report. The point has always been to ship some ifupdown-supported DHCP client by default. This can be done either by keeping the default client's priority to important or by making ifupdown Depends on one. I prefer the later. Martin-Éric
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
El 20/06/23 a las 08:29, Martin-Éric Racine escribió: > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón > wrote: > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > > Greetings, > > > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a > > > good time to re-visit Debian's choice of standard DHCP client shipping > > > with priority:important. > > > > > > I hereby propose bin:dhcpcd-base: > > > > > > 1) already supported by ifupdown. > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > > separation. > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > > configure both stacks. > > ... > > > > I agree that dhcpcd seems the best alternative to isc-dhcp-client for > > the moment, and I'll make the relevant changes in ifupdown as soon as I > > can. Josué, any thoughts? > > 1) As someone pointed out in the thread, the reason why > isc-dhcp-client had priority:important probably was to ensure that > debootstrap would pull it, since debootstrap ignores Recommends and > packages with a priority lower than standard. > > 2) However, as long as ifupdown explictly depends on a package, it can > also pull dependencies with a lower priority. Right now ifupdown > Recommends "isc-dhcp-client | dhcp-client" which debootstrap would > ignore. It would have to Depends "dhcpcd-base | dhcp-client" instead. > > 3) At that point, swapping the priority of isc-dhcp-client and > dhcpcd-base merely becomes "nice to have". Heck, the priority of both > could, in principle, be optional, just as long as ifupdown explicitly > Depends on a DHCP client, and the first alternative is a real package. I was about to bump dhcpcd-base as ifupdown dependency, but... if isc-client-dhcp is a Recommends, is because not all users want a dhcp client installed, where all the ipv4 is handled statically, and ipv6 is done via SLAAC. As a user, I don't want/need to pull in dhcpcd-base the next upgrade. So I'd prefer to go forward with the steps proposed by Simon, and s/isc-dhcp-client/dhcpcd-base in ifupdown's Recommends: Unless there is a strong objection, I'll file the override bug report. Cheers, -- Santiago signature.asc Description: PGP signature
Re: Default network configuration system (was Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie)
On Thu, Jun 22, 2023 at 01:39:02PM +0800, Paul Wise wrote: > On Tue, 2023-06-20 at 11:19 +0200, Lukas Maerdian wrote: > > > Netplan allows to configure both of those tools and is already being > > used across Ubuntu and in Debian cloud-images for this purpose. All > > while keeping full flexibility to use the underlying tool's native > > config files, should Netplan's simple YAML settings not be enough for > > a given complex usecase. > > Is Netplan able to parse an existing native config for each of the > tools and then output either Netplan configs or native configs for each > of the other network config tools? For example could you use Netplan to > auto-migrate from ifupdown to systemd-networkd or NetworkManager etc? Netplan is implemented as a systemd-generator [1] and primarily intended to be used as a one-directional genreator from Netplan YAML -> native config. We've been making some moves in adding bidirectional parsing capabilities for NetworkManager's keyfiles, though, e.g.: NM keyfile <-> Netplan YAML And there's also an ifupdown migration prototype, but that is pretty limited, didn't see much love in the recent years and might not live up to expectations, e.g.: ENABLE_TEST_COMMANDS=1 netplan migrate Cheers, Lukas [1] https://manpages.debian.org/testing/systemd/systemd.generator.7.en.html signature.asc Description: PGP signature
Re: Default network configuration system (was Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie)
On Tue, 2023-06-20 at 11:19 +0200, Lukas Maerdian wrote: > Netplan allows to configure both of those tools and is already being > used across Ubuntu and in Debian cloud-images for this purpose. All > while keeping full flexibility to use the underlying tool's native > config files, should Netplan's simple YAML settings not be enough for > a given complex usecase. Is Netplan able to parse an existing native config for each of the tools and then output either Netplan configs or native configs for each of the other network config tools? For example could you use Netplan to auto-migrate from ifupdown to systemd-networkd or NetworkManager etc? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On 2023-06-19 Sven Joachim wrote: [...] > If my above statements about debootstrap are correct, this will result > in no dhcp-client being installed at all by debootstrap unless the > override bug also requests bumping dhcpcd-base's priority from optional > to important. Not complety true. debootstrap would still install systemd which includes systemd-networkd. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Tue, Jun 20, 2023 at 10:23:58AM +0100, Matthew Vernon wrote: > We might be using slightly different terms, but for desktops I still > tend to use ifupdown (since the network config is easily configured > thus, and essentially never changes); laptops I have ifupdown & > network-manager (since the latter makes joining wireless networks on my > travels easier). ifupdown everywhere here, as on the one side it simplifies bridge configuration and makes for a minimal/transparent config, and on the other I find it pretty convenient to add new networks to wpa_supplicant.conf, where it's also easy to set per-network priorities if I'm going to have a particular preference of wireless network for any measure of time. For my laptop, jumping between the two modes is quite literally effortless: auto eth0 iface eth0 inet dhcp pre-up /sbin/mii-tool eth0 | /bin/grep -qv "no link" auto wlan0 iface wlan0 inet dhcp pre-up /sbin/mii-tool eth0 | /bin/grep -q "no link" wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf -- (defun main () (format t "Mason Loring Bliss - ma...@blisses.org - ") (format t "By the mysgydynge of the sterysman, he was set vpon the pylys") (format t " of the brydge, and the barge whelmyd. - Chronicle of Fabyan~%")) signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Simon McVittie left as an exercise for the reader: > I was using "desktop" in the sense of task-gnome-desktop and friends, more > than as a class of hardware. Laptops and other portable computers are the > main thing that really needs easily user-configurable networking. > I think it makes sense for desktop/workstation hardware to be treated like > an oddly-shaped laptop by default, which means it gets the benefit of the > wider testing that goes into NM and its various user interfaces, rather > than having laptops and desktops behave differently for reasons that are > unlikely to be obvious to a new user. since sending that mail, i've looked into gnome, and it seems to have pretty deep integration with NM. given gnome's positioning in debian, that seems to satisfy my question in and of itself. it's clearly at a level well above wpa_gui etc. (which i don't use, but might have proffered for consideration). thanks as always for your detailed and thoughtful mails. > A secondary benefit of NM is that it works on non-systemd-booted systems, > whereas systemd-networkd isn't designed for that use. I'm personally > happy with systemd as pid 1, but some people consider requiring systemd > as pid 1 to be a deal-breaker, and if NM is a good candidate for being > our default *anyway* then we might as well get that secondary benefit too. i hadn't even considered this, thanks. one nice thing about systemd-networkd is that it's pretty extensive in terms of structured configurability; i've currently got two machines with "CombinedChannels 1" to run XDP programs which bind to queue 0, for instance. of course, these are advanced options and thus can assume non-default effort. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: Default network configuration system (was Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie)
On Tue, 20 Jun 2023 at 10:19, Lukas Maerdian wrote:
>
> Am 19.06.23 um 20:01 schrieb Simon McVittie:
> > On Mon, 19 Jun 2023 at 14:13:11 +0200, Ansgar wrote:
> >> On Mon, 2023-06-19 at 13:35 +0200, Michael Biebl wrote:
> >>> Why does isc-dhcp-client have priority:important to begin with?
> >>> I don't think users care so much about a dhcp client but rather a
> >>> network configuration system
> >>
> >> The priority question isn't the important one. The real question is:
> >>
> >> What network configuration system should users end up with (by
> >> default)?
>
> Indeed, this is the correct question to ask!
>
> > Yes, whatever DHCP client ifupdown would prefer to use, that seems
> > like an implementation detail of ifupdown: it should pull it in via
> > an appropriate level of dependency, and that's orthogonal to whether a
> > particular class of installation has its networking managed by ifupdown,
> > NetworkManager, systemd-networkd or something else by default.
>
> ACK.
>
> > At the moment I believe the status quo for d-i is that networking is
> > managed by NetworkManager if a desktop task happens to have pulled it in,
> > or ifupdown otherwise? And that seems reasonable (although I personally
> > prefer to set up systemd-networkd on servers).
> >
> > Of our desktop tasks, all except possibly LXDE and LXQT pull in
> > NetworkManager via Recommends or stronger, which seems right. LXDE
> > and LXQT might pull in connman as a higher preference than NM, via an
> > alternative dependency that includes connman-gtk or cmst: it's not
> > immediately obvious to me what actually happens, and I don't have a
> > recent installation of either one to look at right now.
>
> As the maintainer of Netplan, I have a strong interest in this topic. I agree
> with bluca, going with systemd-networkd on servers and NetworkManager on
> desktops, the pooling & sharing of resources between Debian and Ubuntu will
> be a win-win situation! I'd propose to use Netplan.io on top of that, to seed
> the configuration for either network configuration tool in a common way,
> which should make life easier for the d-i team.
>
> Netplan allows to configure both of those tools and is already being used
> across Ubuntu and in Debian cloud-images for this purpose. All while keeping
> full flexibility to use the underlying tool's native config files, should
> Netplan's simple YAML settings not be enough for a given complex usecase.
> E.g. /etc/netplan/*.yaml will generate configuration in
> /run/systemd/network/... and/or /run/NetworkManager/system-connections/...
> while /etc/systemd/network/... and /etc/NetworkManager/system-connections/...
> are still there for native (or override) configurations!
>
> I think we shaped up the Netplan package in Debian [2] pretty nicely in the
> recent 1-2 years, e.g. having extensive autopkgtest coverage. Last but not
> least, at the Netplan project we're happy to help out with any rough edges
> that Debian might run into, as we might have already seen those in Ubuntu and
> of course we're also open for contributions!
>
> > The other possible reason to have a DHCP client is for recovery, but
> > most bootable Debian systems will have busybox (via Recommends from
> > initramfs-tools-core), and that has a small DHCP client included anyway.
> >
> >> I also think that installing both ifupdown and NetworkManager on
> >> desktop environments is worse than only NM.
> >
> > ifupdown should be fairly harmless when not configured to manage any
> > non-loopback interfaces (which is what d-i does when NM is installed),
> > but I agree that it seems better not to have it if it's not needed.
>
> ifupdown is mostly in "life support" mode, as stated by andrewsh at Debian
> Reunion Hamburg [2].
> ifupdown2 is implemented in Python and has some backing by CumulusNetworks.
> ifupdown-ng has only ever seen a single upload in Debian, but was deemed to
> be the best ifupdown implementation currently.
>
> IMHO ifupdown{2,-ng} is the "old world" and when doing such change we should
> rather go the systemd-networkd (server) + NetworkManager (desktop) path,
> potentially in combination with Netplan, in order to switch to a more modern
> and future proof network configuration tool, that also supports advanced
> features such as WiFi regulatory domain settings or SR-IOV network
> virtualization, to cover today's usecases. We'd also get nice CLI tools to
> control this stack for free, such as "networkctl", "nmcli" or "netplan
> status".
>
> Cheers,
> Lukas
>
> [1] https://tracker.debian.org/pkg/netplan.io
> [2]
> https://hamburg-2023.mini.debconf.org/talks/5-network-configuration-on-debian-systems/
Yeah I think it would be nice to do some experiments there, at least
starting with networkd and eventually considering netplan as an
additional step on top - thanks for volunteering :-P
Ultimately it seems to me that the defaults should be driven by
tasklets rather than priority - ie, make ifupdown and
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Tue, 20 Jun 2023 at 11:42, Simon McVittie wrote: > > On Tue, 20 Jun 2023 at 05:03:19 -0400, nick black wrote: > > Simon McVittie left as an exercise for the reader: > > > At the moment I believe the status quo for d-i is that networking is > > > managed by NetworkManager if a desktop task happens to have pulled it in, > > > or ifupdown otherwise? And that seems reasonable (although I personally > > > prefer to set up systemd-networkd on servers). > > > > i don't wish to start an argument, but just to ask: everyone has > > recommended NetworkManager for workstations. i've been running > > systemd-networkd on everything (servers, laptops, and > > workstations) for several years now, usually in conjunction with > > dnsmasq and wpa_supplicant, and it's been pretty great. what > > does NetworkManager offer that makes it superior to > > systemd-networkd on the desktop (which i'm interpreting to mean > > "for interactive use")? > > Ubiquitous user interfaces, mostly. Our default for laptops and other > portable computers needs to be something that lets a non-technical user > of GNOME/Plasma/etc. join a wireless network, without learning how to > write configuration files and operate sudo, and in practice that means > the various desktop environments' UIs for NM (or something analogous > like connman or wicd, but NM seems to be by far the best-supported choice > out of those). > > I don't know enough about implementation details of NM and > systemd-networkd to know whether the API design of NM is more suitable > for that purpose, or whether the various UIs for NM and the absence of > UIs for systemd-networkd is just inertia; but in practice the network > configuration service that has first-class support in most of our desktop > environments (in particular GNOME and Plasma) is NM. > > I was using "desktop" in the sense of task-gnome-desktop and friends, more > than as a class of hardware. Laptops and other portable computers are the > main thing that really needs easily user-configurable networking. > I think it makes sense for desktop/workstation hardware to be treated like > an oddly-shaped laptop by default, which means it gets the benefit of the > wider testing that goes into NM and its various user interfaces, rather > than having laptops and desktops behave differently for reasons that are > unlikely to be obvious to a new user. > > Some users of desktop/workstation hardware strongly prefer to use a more > "static" network configuration service like systemd-networkd or ifupdown > so that they can rely on having the network setup not change under > them, particularly if they're using services like NFS filesystems or > LDAP authentication. That's an entirely reasonable thing to want to do, > but IMO this is an example of the design principle that the choice that > is better for non-technical users can make a better default, because > technically adept users who know they have particular requirements can > easily switch to what we might characterize as "server" infrastructure, > but non-technical users can't easily switch in the opposite direction > (or even know that they might want to). > > A secondary benefit of NM is that it works on non-systemd-booted systems, > whereas systemd-networkd isn't designed for that use. I'm personally > happy with systemd as pid 1, but some people consider requiring systemd > as pid 1 to be a deal-breaker, and if NM is a good candidate for being > our default *anyway* then we might as well get that secondary benefit too. Yes a fully working and well-integrated GUI is the most important thing for the default (as in, desktop tasklet default), power users can always switch to something else. NetworkManager is clearly ahead of the alternatives in that regard. Kind regards, Luca Boccassi
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Tue, 20 Jun 2023 at 05:03:19 -0400, nick black wrote: > Simon McVittie left as an exercise for the reader: > > At the moment I believe the status quo for d-i is that networking is > > managed by NetworkManager if a desktop task happens to have pulled it in, > > or ifupdown otherwise? And that seems reasonable (although I personally > > prefer to set up systemd-networkd on servers). > > i don't wish to start an argument, but just to ask: everyone has > recommended NetworkManager for workstations. i've been running > systemd-networkd on everything (servers, laptops, and > workstations) for several years now, usually in conjunction with > dnsmasq and wpa_supplicant, and it's been pretty great. what > does NetworkManager offer that makes it superior to > systemd-networkd on the desktop (which i'm interpreting to mean > "for interactive use")? Ubiquitous user interfaces, mostly. Our default for laptops and other portable computers needs to be something that lets a non-technical user of GNOME/Plasma/etc. join a wireless network, without learning how to write configuration files and operate sudo, and in practice that means the various desktop environments' UIs for NM (or something analogous like connman or wicd, but NM seems to be by far the best-supported choice out of those). I don't know enough about implementation details of NM and systemd-networkd to know whether the API design of NM is more suitable for that purpose, or whether the various UIs for NM and the absence of UIs for systemd-networkd is just inertia; but in practice the network configuration service that has first-class support in most of our desktop environments (in particular GNOME and Plasma) is NM. I was using "desktop" in the sense of task-gnome-desktop and friends, more than as a class of hardware. Laptops and other portable computers are the main thing that really needs easily user-configurable networking. I think it makes sense for desktop/workstation hardware to be treated like an oddly-shaped laptop by default, which means it gets the benefit of the wider testing that goes into NM and its various user interfaces, rather than having laptops and desktops behave differently for reasons that are unlikely to be obvious to a new user. Some users of desktop/workstation hardware strongly prefer to use a more "static" network configuration service like systemd-networkd or ifupdown so that they can rely on having the network setup not change under them, particularly if they're using services like NFS filesystems or LDAP authentication. That's an entirely reasonable thing to want to do, but IMO this is an example of the design principle that the choice that is better for non-technical users can make a better default, because technically adept users who know they have particular requirements can easily switch to what we might characterize as "server" infrastructure, but non-technical users can't easily switch in the opposite direction (or even know that they might want to). A secondary benefit of NM is that it works on non-systemd-booted systems, whereas systemd-networkd isn't designed for that use. I'm personally happy with systemd as pid 1, but some people consider requiring systemd as pid 1 to be a deal-breaker, and if NM is a good candidate for being our default *anyway* then we might as well get that secondary benefit too. smcv
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Tue, 2023-06-20 at 05:03 -0400, nick black wrote: > Simon McVittie left as an exercise for the reader: > > At the moment I believe the status quo for d-i is that networking is > > managed by NetworkManager if a desktop task happens to have pulled it in, > > or ifupdown otherwise? And that seems reasonable (although I personally > > prefer to set up systemd-networkd on servers). > > i don't wish to start an argument, but just to ask: everyone has > recommended NetworkManager for workstations. i've been running > systemd-networkd on everything (servers, laptops, and > workstations) for several years now, usually in conjunction with > dnsmasq and wpa_supplicant, and it's been pretty great. what > does NetworkManager offer that makes it superior to > systemd-networkd on the desktop (which i'm interpreting to mean > "for interactive use")? Managing VPN connections or 802.1X authentication for ethernet connections is nicer with NetworkManager for desktop computers too. For computers with static networking (where static might still mean DHCP) systemd-networkd might be sufficient as well. This might also include a subset of desktop computers, but I think the better default is still NM and it is up to the administrator to configure an alternative. Ansgar
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Ansgar writes: > I think this should be NetworkManager for desktop environments and I > personally like systemd-networkd for other environments. In both cases > these replace both ifupdown and isc-dhcp-client. We might be using slightly different terms, but for desktops I still tend to use ifupdown (since the network config is easily configured thus, and essentially never changes); laptops I have ifupdown & network-manager (since the latter makes joining wireless networks on my travels easier). Regards, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
nick black writes: > what > does NetworkManager offer that makes it superior to > systemd-networkd on the desktop I don't know what systemd-networkd has to offer in this regard, but for laptop usage I'm personally fond of the ModemManager integration along with multihoming policies (eth0 preferred over wlan0 preferred over wwan0 by default). For the same reason I believe conman should not be default on any hardware with a built-in modem, regardless of desktop choice. For servers I agree with others here - I'm slowly migrating to systemd-networkd. Makes stuff like DHCPv6-PD much easier to manage for example. I've been a happy ifupdown user for ages, but now I believe it's time to move on... A standalone dhcp client is still important to me for one specific use case: testing and debugging of DHCP services. Been using the ISC client a lot for this, both for IPv4 and for different DHCPv6 modes. I guess the busybox client is a good enough replacement for v4. Not sure about DHCPv6. The advantages of the ISC client for this use case has been the terminal debug output and the scripting abilities, where you also could use "/usr/bin/env" as "script" to dump all the vars. Bjørn
Default network configuration system (was Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie)
Am 19.06.23 um 20:01 schrieb Simon McVittie:
On Mon, 19 Jun 2023 at 14:13:11 +0200, Ansgar wrote:
On Mon, 2023-06-19 at 13:35 +0200, Michael Biebl wrote:
Why does isc-dhcp-client have priority:important to begin with?
I don't think users care so much about a dhcp client but rather a
network configuration system
The priority question isn't the important one. The real question is:
What network configuration system should users end up with (by
default)?
Indeed, this is the correct question to ask!
Yes, whatever DHCP client ifupdown would prefer to use, that seems
like an implementation detail of ifupdown: it should pull it in via
an appropriate level of dependency, and that's orthogonal to whether a
particular class of installation has its networking managed by ifupdown,
NetworkManager, systemd-networkd or something else by default.
ACK.
At the moment I believe the status quo for d-i is that networking is
managed by NetworkManager if a desktop task happens to have pulled it in,
or ifupdown otherwise? And that seems reasonable (although I personally
prefer to set up systemd-networkd on servers).
Of our desktop tasks, all except possibly LXDE and LXQT pull in
NetworkManager via Recommends or stronger, which seems right. LXDE
and LXQT might pull in connman as a higher preference than NM, via an
alternative dependency that includes connman-gtk or cmst: it's not
immediately obvious to me what actually happens, and I don't have a
recent installation of either one to look at right now.
As the maintainer of Netplan, I have a strong interest in this topic. I agree with
bluca, going with systemd-networkd on servers and NetworkManager on desktops, the
pooling & sharing of resources between Debian and Ubuntu will be a win-win
situation! I'd propose to use Netplan.io on top of that, to seed the configuration
for either network configuration tool in a common way, which should make life
easier for the d-i team.
Netplan allows to configure both of those tools and is already being used
across Ubuntu and in Debian cloud-images for this purpose. All while keeping
full flexibility to use the underlying tool's native config files, should
Netplan's simple YAML settings not be enough for a given complex usecase. E.g.
/etc/netplan/*.yaml will generate configuration in /run/systemd/network/...
and/or /run/NetworkManager/system-connections/... while
/etc/systemd/network/... and /etc/NetworkManager/system-connections/... are
still there for native (or override) configurations!
I think we shaped up the Netplan package in Debian [2] pretty nicely in the
recent 1-2 years, e.g. having extensive autopkgtest coverage. Last but not
least, at the Netplan project we're happy to help out with any rough edges that
Debian might run into, as we might have already seen those in Ubuntu and of
course we're also open for contributions!
The other possible reason to have a DHCP client is for recovery, but
most bootable Debian systems will have busybox (via Recommends from
initramfs-tools-core), and that has a small DHCP client included anyway.
I also think that installing both ifupdown and NetworkManager on
desktop environments is worse than only NM.
ifupdown should be fairly harmless when not configured to manage any
non-loopback interfaces (which is what d-i does when NM is installed),
but I agree that it seems better not to have it if it's not needed.
ifupdown is mostly in "life support" mode, as stated by andrewsh at Debian
Reunion Hamburg [2].
ifupdown2 is implemented in Python and has some backing by CumulusNetworks.
ifupdown-ng has only ever seen a single upload in Debian, but was deemed to be
the best ifupdown implementation currently.
IMHO ifupdown{2,-ng} is the "old world" and when doing such change we should rather go the systemd-networkd
(server) + NetworkManager (desktop) path, potentially in combination with Netplan, in order to switch to a more modern
and future proof network configuration tool, that also supports advanced features such as WiFi regulatory domain
settings or SR-IOV network virtualization, to cover today's usecases. We'd also get nice CLI tools to control this
stack for free, such as "networkctl", "nmcli" or "netplan status".
Cheers,
Lukas
[1] https://tracker.debian.org/pkg/netplan.io
[2]
https://hamburg-2023.mini.debconf.org/talks/5-network-configuration-on-debian-systems/
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Simon McVittie left as an exercise for the reader: > At the moment I believe the status quo for d-i is that networking is > managed by NetworkManager if a desktop task happens to have pulled it in, > or ifupdown otherwise? And that seems reasonable (although I personally > prefer to set up systemd-networkd on servers). i don't wish to start an argument, but just to ask: everyone has recommended NetworkManager for workstations. i've been running systemd-networkd on everything (servers, laptops, and workstations) for several years now, usually in conjunction with dnsmasq and wpa_supplicant, and it's been pretty great. what does NetworkManager offer that makes it superior to systemd-networkd on the desktop (which i'm interpreting to mean "for interactive use")? i'm not doubting its advantages, just ignorant of them. =] it seems to me that unifying the network stack has some value all its own. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Am 19.06.23 um 21:05 schrieb Luca Boccassi: On Mon, 19 Jun 2023 at 18:21, Philipp Kern wrote: On 2023-06-19 14:37, Luca Boccassi wrote: The advantage of doing that is that it's what Ubuntu does IIRC, so there will be extra pooling of resources to maintain those setups, and the road should already be paved for it. I am not sure if I have seen this play out in practice[1]. Ubuntu^WCanonical has been doing its own development in this space as well with netplan. Ubuntu will continue to do its own fixes to glue things together. Kind regards Philipp Kern [1] With notable exceptions like doko maintaining the toolchain - and I'm sure I'm not crediting everyone. But that's also explicit package maintainership. I've been working for a long time with many Canonical engineers, happily and fruitfully, to the benefit of both Debian and Ubuntu, so my experience is quite different. This includes the developers working on src:systemd. As the maintainer of Netplan and (soon to be [1]) DD, I have a strong interest in this topic. I agree, going with systemd-networkd on servers and NetworkManager on desktops, the pooling & sharing of resources between Debian and Ubuntu will be a win-win situation! Netplan allows seeding and configuration for both of those tools and is already being used in Debian cloud-images for this purpose. All while keeping full flexibility to use the underlying tool's native config files in addition to Netplan's YAML. E.g. /etc/netplan/*.yaml will generate configuration in /run/systemd/network/... and/or /run/NetworkManager/system-connections/... while /etc/systemd/network/... and /etc/NetworkManager/system-connections/... are still there for native or override configurations. I think we shaped up the Netplan package in Debian [2] pretty nicely in the recent 1-2 years, e.g. having extensive autopkgtest coverage. Last but not least, at the Netplan project we're happy to help out with any rough edges that Debian might run into, as we might have already seen those in Ubuntu and of course we're also open for contributions! Cheers, Lukas [1] https://nm.debian.org/process/1180/ [2] https://tracker.debian.org/pkg/netplan.io
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Martin-Éric Racine writes: > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón > wrote: >> El 19/06/23 a las 13:54, Martin-Éric Racine escribió: >> > Greetings, >> > >> > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a >> > good time to re-visit Debian's choice of standard DHCP client shipping >> > with priority:important. >> > >> > I hereby propose bin:dhcpcd-base: >> > >> > 1) already supported by ifupdown. >> > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege >> > separation. >> > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf >> > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail >> > 5) a mere inet line in /etc/network/interfaces is sufficient to >> > configure both stacks. >> ... >> >> I agree that dhcpcd seems the best alternative to isc-dhcp-client for >> the moment, and I'll make the relevant changes in ifupdown as soon as I >> can. Josué, any thoughts? > > 1) As someone pointed out in the thread, the reason why > isc-dhcp-client had priority:important probably was to ensure that > debootstrap would pull it, since debootstrap ignores Recommends and > packages with a priority lower than standard. > > 2) However, as long as ifupdown explictly depends on a package, it can > also pull dependencies with a lower priority. Right now ifupdown > Recommends "isc-dhcp-client | dhcp-client" which debootstrap would > ignore. It would have to Depends "dhcpcd-base | dhcp-client" instead. > > 3) At that point, swapping the priority of isc-dhcp-client and > dhcpcd-base merely becomes "nice to have". Heck, the priority of both > could, in principle, be optional, just as long as ifupdown explicitly > Depends on a DHCP client, and the first alternative is a real package. That would make the order of operations for a smooth migration as follows: 1. ifupdown switches from Recommends "isc-dhcp-client | dhcp-client" to Depends "isc-dhcp-client | dhcp-client". 2. isc-dhcp-client drops from Priority: important to Priority: optional 3. ifupdown switches from isc-dhcp-client to dhcpcd-base. -- Arto Jantunen
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón wrote: > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > Greetings, > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a > > good time to re-visit Debian's choice of standard DHCP client shipping > > with priority:important. > > > > I hereby propose bin:dhcpcd-base: > > > > 1) already supported by ifupdown. > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > separation. > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > configure both stacks. > ... > > I agree that dhcpcd seems the best alternative to isc-dhcp-client for > the moment, and I'll make the relevant changes in ifupdown as soon as I > can. Josué, any thoughts? 1) As someone pointed out in the thread, the reason why isc-dhcp-client had priority:important probably was to ensure that debootstrap would pull it, since debootstrap ignores Recommends and packages with a priority lower than standard. 2) However, as long as ifupdown explictly depends on a package, it can also pull dependencies with a lower priority. Right now ifupdown Recommends "isc-dhcp-client | dhcp-client" which debootstrap would ignore. It would have to Depends "dhcpcd-base | dhcp-client" instead. 3) At that point, swapping the priority of isc-dhcp-client and dhcpcd-base merely becomes "nice to have". Heck, the priority of both could, in principle, be optional, just as long as ifupdown explicitly Depends on a DHCP client, and the first alternative is a real package. Martin-Éric
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On 2023-06-19 21:37 +0100, Simon McVittie wrote: > On Mon, 19 Jun 2023 at 21:42:08 +0300, Martin-Éric Racine wrote: >> I've never had to do this before, so I wonder if moving packages to >> severity: standard or higher (in this case, important) requires any >> decision from the CTTE or a similar authority, before we proceed? > > Regarding *whether* to make that change: as Luca said, I don't think a > DHCP client really needs to be at an elevated Priority at all. I think > it would be better to lower the priority of isc-dhcp-client to optional, > but *not* raise the priority of dhcpcd-base, and instead have ifupdown > pull in the DHCP client of its choice (currently isc-dhcp-client, but > you'd prefer this to be dhcpcd-base) as a Recommends or Depends. > My understanding is that because ifupdown is (currently) > Priority: important, that dependency would still pull your chosen DHCP > client into a default debootstrap. Unfortunately that assumption is not correct, because ifupdown only "Recommends: isc-dhcp-client | dhcp-client", and debootstrap ignores Recommends. So as long as ifupdown is installed by debootstrap, either it would have to change that recommendation to "Depends: dhcpcd-base | dhcp-client", or the priority of dhcpcd-base needs to be bumped so that debootstrap picks it up due to its priority. > Years ago we had a rule in Policy that if package A depends on package B, > then the priority of B must be >= the priority of A; but we dropped that > rule, because it wasn't particularly helpful, and sometimes led to wrong > situations where packages get installed for no good reason. So there's no > need to follow that rule any more. As far as debootstrap is concerned, it only handles Depends, ignores everything but the first alternative and cannot deal with virtual packages. For dependencies on libraries computed by dpkg-shlibdeps this usually works, but manually inserted relationships do not always fulfill these constraints. > If you agree with the way forward that I'm suggesting, then I think the > way to do it would be: > > 1. open an override bug asking for isc-dhcp-client to be lowered from >important to optional > 2. wait for the ftp team to do that > 3. ask the ifupdown maintainer to switch the Recommends to point to >dhcpcd-base instead of isc-dhcp-client If my above statements about debootstrap are correct, this will result in no dhcp-client being installed at all by debootstrap unless the override bug also requests bumping dhcpcd-base's priority from optional to important. Cheers, Sven
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Am 19.06.23 um 22:37 schrieb Simon McVittie: If you agree with the way forward that I'm suggesting, then I think the way to do it would be: 1. open an override bug asking for isc-dhcp-client to be lowered from important to optional 2. wait for the ftp team to do that 3. ask the ifupdown maintainer to switch the Recommends to point to dhcpcd-base instead of isc-dhcp-client +1 OpenPGP_signature Description: OpenPGP digital signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, 19 Jun 2023 at 21:42:08 +0300, Martin-Éric Racine wrote: > I've never had to do this before, so I wonder if moving packages to > severity: standard or higher (in this case, important) requires any > decision from the CTTE or a similar authority, before we proceed? Regarding *whether* to make that change: as Luca said, I don't think a DHCP client really needs to be at an elevated Priority at all. I think it would be better to lower the priority of isc-dhcp-client to optional, but *not* raise the priority of dhcpcd-base, and instead have ifupdown pull in the DHCP client of its choice (currently isc-dhcp-client, but you'd prefer this to be dhcpcd-base) as a Recommends or Depends. My understanding is that because ifupdown is (currently) Priority: important, that dependency would still pull your chosen DHCP client into a default debootstrap. Years ago we had a rule in Policy that if package A depends on package B, then the priority of B must be >= the priority of A; but we dropped that rule, because it wasn't particularly helpful, and sometimes led to wrong situations where packages get installed for no good reason. So there's no need to follow that rule any more. Separately, regarding *how* to make that change: as an ordinary package maintainer you cannot change the Priority of an existing package either upward or downward yourself, you have to ask the ftp team to do it, via an 'override' bug. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018690 is an example. It's up to the ftp team how they manage priorities, but how I imagine they do it is to make obvious/uncontroversial changes immediately, or check for distribution consensus (for example in a thread like this one) if the change is non-obvious or controversial. The technical committee doesn't generally get involved in this sort of thing unless there's a dispute that needs resolving, or some maintainer asks for advice. If you agree with the way forward that I'm suggesting, then I think the way to do it would be: 1. open an override bug asking for isc-dhcp-client to be lowered from important to optional 2. wait for the ftp team to do that 3. ask the ifupdown maintainer to switch the Recommends to point to dhcpcd-base instead of isc-dhcp-client (The reason I'm suggesting that sequence is that it avoids installing two DHCP clients in a default debootstrap, which would definitely be unnecessary.) smcv (without technical committee hat on in this case)
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, 19 Jun 2023 at 18:21, Philipp Kern wrote: > > On 2023-06-19 14:37, Luca Boccassi wrote: > > The advantage of doing that is that it's what Ubuntu does IIRC, so > > there will be extra pooling of resources to maintain those > > setups, and the road should already be paved for it. > > I am not sure if I have seen this play out in practice[1]. > Ubuntu^WCanonical has been doing its own development in this space as > well with netplan. Ubuntu will continue to do its own fixes to glue > things together. > > Kind regards > Philipp Kern > > [1] With notable exceptions like doko maintaining the toolchain - and > I'm sure I'm not crediting everyone. But that's also explicit package > maintainership. I've been working for a long time with many Canonical engineers, happily and fruitfully, to the benefit of both Debian and Ubuntu, so my experience is quite different. This includes the developers working on src:systemd. Kind regards, Luca Boccassi
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, 19 Jun 2023 at 20:00, Martin-Éric Racine wrote: > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón > wrote: > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a > > > good time to re-visit Debian's choice of standard DHCP client shipping > > > with priority:important. > > > > > > I hereby propose bin:dhcpcd-base: > > > > > > 1) already supported by ifupdown. > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > > separation. > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > > configure both stacks. > > > > I agree that dhcpcd seems the best alternative to isc-dhcp-client for > > the moment, and I'll make the relevant changes in ifupdown as soon as I > > can. Josué, any thoughts? > > I've never had to do this before, so I wonder if moving packages to > severity: standard or higher (in this case, important) requires any > decision from the CTTE or a similar authority, before we proceed? As mentioned elsewhere in the thread, there shouldn't be any need to change the priority, adjusting ifupdown's dependencies should be all that's needed. Kind regards, Luca Boccassi
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón wrote: > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a > > good time to re-visit Debian's choice of standard DHCP client shipping > > with priority:important. > > > > I hereby propose bin:dhcpcd-base: > > > > 1) already supported by ifupdown. > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > separation. > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > configure both stacks. > > I agree that dhcpcd seems the best alternative to isc-dhcp-client for > the moment, and I'll make the relevant changes in ifupdown as soon as I > can. Josué, any thoughts? I've never had to do this before, so I wonder if moving packages to severity: standard or higher (in this case, important) requires any decision from the CTTE or a similar authority, before we proceed? Martin-Éric
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Hi, El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > Greetings, > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a > good time to re-visit Debian's choice of standard DHCP client shipping > with priority:important. > > I hereby propose bin:dhcpcd-base: > > 1) already supported by ifupdown. > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege separation. > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > 5) a mere inet line in /etc/network/interfaces is sufficient to > configure both stacks. ... I agree that dhcpcd seems the best alternative to isc-dhcp-client for the moment, and I'll make the relevant changes in ifupdown as soon as I can. Josué, any thoughts? Cheers, -- S signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, 19 Jun 2023 at 14:13:11 +0200, Ansgar wrote: > On Mon, 2023-06-19 at 13:35 +0200, Michael Biebl wrote: > > Why does isc-dhcp-client have priority:important to begin with? > > I don't think users care so much about a dhcp client but rather a > > network configuration system > > The priority question isn't the important one. The real question is: > > What network configuration system should users end up with (by > default)? Yes, whatever DHCP client ifupdown would prefer to use, that seems like an implementation detail of ifupdown: it should pull it in via an appropriate level of dependency, and that's orthogonal to whether a particular class of installation has its networking managed by ifupdown, NetworkManager, systemd-networkd or something else by default. At the moment I believe the status quo for d-i is that networking is managed by NetworkManager if a desktop task happens to have pulled it in, or ifupdown otherwise? And that seems reasonable (although I personally prefer to set up systemd-networkd on servers). Of our desktop tasks, all except possibly LXDE and LXQT pull in NetworkManager via Recommends or stronger, which seems right. LXDE and LXQT might pull in connman as a higher preference than NM, via an alternative dependency that includes connman-gtk or cmst: it's not immediately obvious to me what actually happens, and I don't have a recent installation of either one to look at right now. The other possible reason to have a DHCP client is for recovery, but most bootable Debian systems will have busybox (via Recommends from initramfs-tools-core), and that has a small DHCP client included anyway. > I also think that installing both ifupdown and NetworkManager on > desktop environments is worse than only NM. ifupdown should be fairly harmless when not configured to manage any non-loopback interfaces (which is what d-i does when NM is installed), but I agree that it seems better not to have it if it's not needed. smcv
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On 2023-06-19 14:37, Luca Boccassi wrote: The advantage of doing that is that it's what Ubuntu does IIRC, so there will be extra pooling of resources to maintain those setups, and the road should already be paved for it. I am not sure if I have seen this play out in practice[1]. Ubuntu^WCanonical has been doing its own development in this space as well with netplan. Ubuntu will continue to do its own fixes to glue things together. Kind regards Philipp Kern [1] With notable exceptions like doko maintaining the toolchain - and I'm sure I'm not crediting everyone. But that's also explicit package maintainership.
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, 19 Jun 2023 at 13:13, Ansgar wrote: > > On Mon, 2023-06-19 at 13:35 +0200, Michael Biebl wrote: > > Why does isc-dhcp-client have priority:important to begin with? > > I don't think users care so much about a dhcp client but rather a > > network configuration system and each network configuration system > > has its own preferred dhcp implementation e.g NetworkManager no > > longer uses isc-dhcp-client by default and systemd-networkd doesn't > > use isc-dhcp-client either. > > > > So maybe simply demoting the priority of isc-dhcp-client to normal is > > a better route. > > ifupdown already recommends isc-dhcp-client and if ifupdown want's to > > use dhcpcd in the future it could change this recommends. > > The priority question isn't the important one. The real question is: > > What network configuration system should users end up with (by > default)? > > I think this should be NetworkManager for desktop environments and I > personally like systemd-networkd for other environments. In both cases > these replace both ifupdown and isc-dhcp-client. > > I also think that installing both ifupdown and NetworkManager on > desktop environments is worse than only NM. The advantage of doing that is that it's what Ubuntu does IIRC, so there will be extra pooling of resources to maintain those setups, and the road should already be paved for it. Kind regards, Luca Boccassi
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, 2023-06-19 at 13:35 +0200, Michael Biebl wrote: > Why does isc-dhcp-client have priority:important to begin with? > I don't think users care so much about a dhcp client but rather a > network configuration system and each network configuration system > has its own preferred dhcp implementation e.g NetworkManager no > longer uses isc-dhcp-client by default and systemd-networkd doesn't > use isc-dhcp-client either. > > So maybe simply demoting the priority of isc-dhcp-client to normal is > a better route. > ifupdown already recommends isc-dhcp-client and if ifupdown want's to > use dhcpcd in the future it could change this recommends. The priority question isn't the important one. The real question is: What network configuration system should users end up with (by default)? I think this should be NetworkManager for desktop environments and I personally like systemd-networkd for other environments. In both cases these replace both ifupdown and isc-dhcp-client. I also think that installing both ifupdown and NetworkManager on desktop environments is worse than only NM. Ansgar
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, 19 Jun 2023 at 12:36, Michael Biebl wrote: > > Am 19.06.23 um 12:54 schrieb Martin-Éric Racine: > > Greetings, > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a > > good time to re-visit Debian's choice of standard DHCP client shipping > > with priority:important. > > > > I hereby propose bin:dhcpcd-base: > > > > 1) already supported by ifupdown. > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > separation. > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > configure both stacks. > > > > While dhcpcd development became somewhat erratic last year due to > > upstream's health issues, things are seemingly back to normal. > > Additionally, a new developer has joined and is willing to take over > > the development should upstream's health deteriorate again. > > > > Why does isc-dhcp-client have priority:important to begin with? > I don't think users care so much about a dhcp client but rather a > network configuration system and each network configuration system has > its own preferred dhcp implementation e.g NetworkManager no longer uses > isc-dhcp-client by default and systemd-networkd doesn't use > isc-dhcp-client either. > > So maybe simply demoting the priority of isc-dhcp-client to normal is a > better route. > ifupdown already recommends isc-dhcp-client and if ifupdown want's to > use dhcpcd in the future it could change this recommends. Yes, this sounds like a better approach to me as well. Kind regards, Luca Boccassi
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Am 19.06.23 um 12:54 schrieb Martin-Éric Racine: Greetings, Seeing how the ISC DHCP suite has reached EOL upstream, now might be a good time to re-visit Debian's choice of standard DHCP client shipping with priority:important. I hereby propose bin:dhcpcd-base: 1) already supported by ifupdown. 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege separation. 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail 5) a mere inet line in /etc/network/interfaces is sufficient to configure both stacks. While dhcpcd development became somewhat erratic last year due to upstream's health issues, things are seemingly back to normal. Additionally, a new developer has joined and is willing to take over the development should upstream's health deteriorate again. Why does isc-dhcp-client have priority:important to begin with? I don't think users care so much about a dhcp client but rather a network configuration system and each network configuration system has its own preferred dhcp implementation e.g NetworkManager no longer uses isc-dhcp-client by default and systemd-networkd doesn't use isc-dhcp-client either. So maybe simply demoting the priority of isc-dhcp-client to normal is a better route. ifupdown already recommends isc-dhcp-client and if ifupdown want's to use dhcpcd in the future it could change this recommends. Regards, Michael OpenPGP_signature Description: OpenPGP digital signature
proposal: dhcpcd-base as standard DHCP client starting with Trixie
Greetings, Seeing how the ISC DHCP suite has reached EOL upstream, now might be a good time to re-visit Debian's choice of standard DHCP client shipping with priority:important. I hereby propose bin:dhcpcd-base: 1) already supported by ifupdown. 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege separation. 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail 5) a mere inet line in /etc/network/interfaces is sufficient to configure both stacks. While dhcpcd development became somewhat erratic last year due to upstream's health issues, things are seemingly back to normal. Additionally, a new developer has joined and is willing to take over the development should upstream's health deteriorate again. Martin-Éric
