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