On Tue, 09 Jul 2024 at 16:21:16 +0200, Ansgar đ wrote:
On Tue, 2024-07-09 at 22:44 +0900, Simon Richter wrote:
I believe NM does not have a fixed configuration format, but only a dbus >> > API.
It's perfectly fine to edit configuration files for NM manually, see
man:nm-settings-keyfile(5).
... and debian-installer already knows how to write out these files,
and has done so for more than a decade if I'm reading correctly. This is
not a recent innovation, and anyone who has installed our default desktop environment in the last few years - especially if they used wifi during installation - has been relying on this code path.
<https://salsa.debian.org/installer-team/netcfg/> is responsible
for converting the network configuration that was used temporarily in
the d-i environment into a NM configuration file if NM is installed,
or an ifupdown configuration otherwise. Writing the equivalents into /etc/systemd/network for systemd-networkd would presumably not be rocket science, it's a simple .ini-like syntax similar to the one NM uses.
I've only seen netplan mentioned in passing in this thread so far.Because I believe that Netplan is the answer to a question that nobody
Simon McVittie <smcv@debian.org> writes:
On Tue, 09 Jul 2024 at 16:21:16 +0200, Ansgar đ wrote:
On Tue, 2024-07-09 at 22:44 +0900, Simon Richter wrote:
I believe NM does not have a fixed configuration format, but only a dbus >>>> API.
It's perfectly fine to edit configuration files for NM manually, see
man:nm-settings-keyfile(5).
... and debian-installer already knows how to write out these files,
and has done so for more than a decade if I'm reading correctly. This is
not a recent innovation, and anyone who has installed our default desktop
environment in the last few years - especially if they used wifi during
installation - has been relying on this code path.
<https://salsa.debian.org/installer-team/netcfg/> is responsible
for converting the network configuration that was used temporarily in
the d-i environment into a NM configuration file if NM is installed,
or an ifupdown configuration otherwise. Writing the equivalents into
/etc/systemd/network for systemd-networkd would presumably not be rocket
science, it's a simple .ini-like syntax similar to the one NM uses.
We're just in the process of adding support for netplan as well:
https://salsa.debian.org/installer-team/netcfg/-/merge_requests/9
I've only seen netplan mentioned in passing in this thread so far.
It seems like it is exactly what we need as a replacemtent for ifupdown (given that is what it's designed for AFAICT -- I've not yet tried it
out myself though) and it already supports configuring systemd-networkd,
so seems like a more sensible route than duplicating that effort in D-I.
See: https://netplan.readthedocs.io/
On Jul 11, Philip Hands <phil@hands.com> wrote:
I've only seen netplan mentioned in passing in this thread so far.Because I believe that Netplan is the answer to a question that nobody
asked here.
It has all the disadvantages of switching to a new configuration format,
but then it limits you to the features that it actually implements from
each backend and you have an indirection layer that must be used when interacting with the backend daemon.
On 11.07.24 11:13, Marco d'Itri wrote:
On Jul 11, Philip Hands <phil@hands.com> wrote:
I've only seen netplan mentioned in passing in this thread so far.Because I believe that Netplan is the answer to a question that nobody asked here.
It has all the disadvantages of switching to a new configuration format, but then it limits you to the features that it actually implements from each backend and you have an indirection layer that must be used when interacting with the backend daemon.
Yes, it brings a new configuration format. So do systemd-networkd and NetworkManager.
Netplan's feature set is pretty comprehensive and certainly enough for a default installation,
see its reference: https://netplan.readthedocs.io/en/stable/netplan-yaml/
But it's not an indirection layer that MUST be used. Should the features of Netplan not be enough
for an advanced usecase, everybody is free to write configuration for the underlying backend directly.
Netplan will not interfere with that and go out of the way. Just don't write Netplan configuration
for a specific interface (or all of them) that you want to handle differently.
On Thu, 11 Jul 2024 at 12:12, Lukas MĂ€rdian <slyon@debian.org> wrote:
On 11.07.24 11:13, Marco d'Itri wrote:
On Jul 11, Philip Hands <phil@hands.com> wrote:
I've only seen netplan mentioned in passing in this thread so far.Because I believe that Netplan is the answer to a question that nobody
asked here.
It has all the disadvantages of switching to a new configuration format, >>> but then it limits you to the features that it actually implements from
each backend and you have an indirection layer that must be used when
interacting with the backend daemon.
Yes, it brings a new configuration format. So do systemd-networkd and NetworkManager.
Netplan's feature set is pretty comprehensive and certainly enough for a default installation,
see its reference: https://netplan.readthedocs.io/en/stable/netplan-yaml/
But it's not an indirection layer that MUST be used. Should the features of Netplan not be enough
for an advanced usecase, everybody is free to write configuration for the underlying backend directly.
Netplan will not interfere with that and go out of the way. Just don't write Netplan configuration
for a specific interface (or all of them) that you want to handle differently.
I appreciate the work you've done on Netplan and I am quite sure your
D-I MR should be merged, it looks ready to me. It's good to have this
support in the installer.
However, I do not think it should be the default. First of all, only
Ubuntu uses it, nobody else - as Simon says, we don't want the
defaults to be super-special things that nobody else uses. And then
again, not your fault in the slightest, but Canonical is known for
shifting its priorities every now and then - perfectly normal for a for-profit company, but a bit worrying when one wants to pull all eggs
in that basket. And also for the minimal case, an additional layer of indirection and set of dependencies, when there's an alternative that requires none of that, is not the ideal solution.
So I am quite sure that yes netplan should be supported in the
installer and your MR should be merged, but the new default for the
default, simple, wired case should be networkd, and for the
GUi/desktop case the default should continue to be NetworkManager.
However, I do not think it should be the default. First of all, only
Ubuntu uses it, nobody else - as Simon says, we don't want the
defaults to be super-special things that nobody else uses. And then
Actually, I think this is an agrument FOR Netplan, not against it. Netplan is being used
by millions of users for 7+ years. Plenty of usecases have been tried and documented. It's
clearly not a "super-special thing that nodbody uses".
Whereas I'm not aware of a major Linux distro using systemd-networkd directly, Debian would be
singeling out itself. I see some of networkd's strengths with advanced users who want to dig deep
and have full control at minimal resource usage (e.g. Arch Linux). Also with lightweight container
usecases, where network config only needs minimal manipulation after deployment (if at all).
The RedHat ecosystem is all-in on NetworkManager. Debian and Ubuntu have (natually) been very close
to each other (e.g. package management) and together with its derivatives create the Debian ecosystem.
On Sat, Jul 13, 2024 at 09:44:03PM +0200, Lukas MĂ€rdian wrote:
However, I do not think it should be the default. First of all, only Ubuntu uses it, nobody else - as Simon says, we don't want the
defaults to be super-special things that nobody else uses. And then
Actually, I think this is an agrument FOR Netplan, not against it. Netplan is being used
by millions of users for 7+ years. Plenty of usecases have been tried and documented. It's
clearly not a "super-special thing that nodbody uses".
Whereas I'm not aware of a major Linux distro using systemd-networkd directly, Debian would be
singeling out itself. I see some of networkd's strengths with advanced users who want to dig deep
and have full control at minimal resource usage (e.g. Arch Linux). Also with lightweight container
usecases, where network config only needs minimal manipulation after deployment (if at all).
The RedHat ecosystem is all-in on NetworkManager. Debian and Ubuntu have (natually) been very close
to each other (e.g. package management) and together with its derivatives create the Debian ecosystem.
Then it looks like a chance for netplan to go the way of upstart?
Networking is not static, it constantly changes in the kernel,
sometimes in dramatic and incompatible ways.
A widely used, well maintained stack with large amounts of
contributors is fundamental for the default choice, because we have
to keep up, as the rest of the world will not sit and wait for us.
Here's some stats from 'git shortlog --after="2021-12-31" -sn --all'.
In the last ~2.5 years, in netplan.io's github repo, there are only 2 >contributors with more than 100 commits, and 2 with more than 10, and
2 of them are Canonical employees:
569 Lukas MĂ€rdian
310 Danilo Egea Gondolfo
39 Simon Chopin
38 Danilo EgĂȘa Gondolfo
11 Robert KrĂĄtkĂœ
Same stat, for the same period, for systemd:
6650 Yu Watanabe
5415 Lennart Poettering
2884 Luca Boccassi
2772 Zbigniew JÄdrzejewski-Szmek
3 companies and one independent in the 4 digits, and too many to be
bothered to check between 10 and 999 commits.
Here's some stats from 'git shortlog --after="2021-12-31" -sn --all'.
In the last ~2.5 years, in netplan.io's github repo, there are only 2 contributors with more than 100 commits, and 2 with more than 10, and
2 of them are Canonical employees:
569 Lukas MĂ€rdian
310 Danilo Egea Gondolfo
39 Simon Chopin
38 Danilo EgĂȘa Gondolfo
11 Robert KrĂĄtkĂœ
Same stat, for the same period, for systemd:
Luca Boccassi wrote:
Networking is not static, it constantly changes in the kernel,
sometimes in dramatic and incompatible ways.
Sorry, but no. Networking clearly is *not* changing that fast, in
software terms. Many old tools still continue to work just fine after
a decade or more.
I understand what you're trying to say, but that's a disingenuous
comparison. systemd is a massive (some would say *too* massive)
project with fingers in many pies. How many of those people have
touched *networking* bits?
On Sun, 14 Jul 2024 at 17:09:48 +0100, Steve McIntyre wrote:
Luca Boccassi wrote:
Networking is not static, it constantly changes in the kernel,
sometimes in dramatic and incompatible ways.
Sorry, but no. Networking clearly is *not* changing that fast, in
software terms. Many old tools still continue to work just fine after
a decade or more.
Yes, I think I agree with Luca's conclusion, but not so much with this argument: the parts of networking that are relevant for a default choice
that lets users get started (approximately the subset supported by d-i)
don't move that fast.
Luca Boccassi <bluca@debian.org> writes:
Here's some stats from 'git shortlog --after="2021-12-31" -sn --all'.
In the last ~2.5 years, in netplan.io's github repo, there are only 2 contributors with more than 100 commits, and 2 with more than 10, and
2 of them are Canonical employees:
569 Lukas MĂ€rdian
310 Danilo Egea Gondolfo
39 Simon Chopin
38 Danilo EgĂȘa Gondolfo
11 Robert KrĂĄtkĂœ
Same stat, for the same period, for systemd:
If you're going to make such a comparison, wouldn't it make sense to
limit it to the bits that might have some sort of relation to networkd?
I suspect this is a bit nearer to a fair comparison:
git shortlog --after="2021-12-31" -sn --all src/network/ network/
771 Yu Watanabe
107 Luca Boccassi
86 Zbigniew JÄdrzejewski-Szmek
42 Lennart Poettering
32 Mike Yuan
24 Susant Sahani
18 Frantisek Sumsal
16 Daan De Meyer
13 Ronan Pigott
10 Jan Janssen
10 Michael Biebl
which looks like its in the same ballpark, and presumably still includes quite a lot of stuff that would fall outside netplan's scope, so one
could perhaps argue should be whittled down further.
Additional benefits of Netplan:
* Already used on Debian Bookworm [cloud] images by default
On Sun, 14 Jul 2024 at 17:09:48 +0100, Steve McIntyre wrote:
Sorry, but no. Networking clearly is *not* changing that fast, in
software terms. Many old tools still continue to work just fine
after a decade or more.
Yes, I think I agree with Luca's conclusion, but not so much with this argument: the parts of networking that are relevant for a default
choice that lets users get started (approximately the subset supported
by d-i) don't move that fast.
Dependency size and maintenance
-------------------------------
I also notice that the netplan.io package would bring GLib, Python, python3-dbus and python3-yaml into the dependencies of the base system,
among others. As an upstream and downstream maintainer of GLib, and in practice the only upstream and downstream unmaintainer[1] of python3-dbus, I'm not comfortable with that, both for size reasons (GLib and Python
are not small) and for quality and maintainedness reasons (python3-dbus).
GLib and Python are relatively large in both on-disk size and attack
surface, but they're essential to our desktop installations anyway, reinventing them in parallel would be worse than reusing them, and
their maintainers have already accepted the responsibility of them
being an important system component. So those two are actually not my
main concern here, and if we had no good alternative, I'd be saying:
yes they're relatively bulky for a container/embedded use-case, but on
a typical server installation they're fine.
On Sun, 14 Jul 2024 at 17:09:48 +0100, Steve McIntyre wrote:[...]
Luca Boccassi wrote:
I understand what you're trying to say, but that's a disingenuous
comparison. systemd is a massive (some would say *too* massive)
project with fingers in many pies. How many of those people have
touched *networking* bits?
This is also a valid point, although there are really two contributor sets that matter: the contributors who have actually touched networkd, and the more general systemd contributors/maintainers who don't routinely touch networkd but would step up if necessary to handle serious issues in it, having taken responsibility for it as part of the wider systemd project.
I assume that second set is considerably smaller than systemd's whole contributor list, but still significant in size.
I think perhaps more convincing arguments to be made in favour of
preferring to use networkd directly as a default, rather than netplan, are:
Number of components we rely on
-------------------------------
If we use networkd directly, then our default server/embedded installation can be broken by a bug in either d-i or networkd. If we use networkd via Netplan, then our default server/embedded installation can still be broken
by a bug in d-i or networkd, but it can also be broken by a bug in netplan. That's more "accident surface" (like attack surface, but with no actual attacker, since all of this is trusted system-configuration stuff that hopefully only the sysadmin can manipulate).
This is not a criticism of the quality of Netplan, so much as a criticism
of adding an abstraction layer over something that we could equally well
use directly: a design with an abstraction layer over a backend is
still vulnerable to the backend's bugs, so the abstraction layer can only reduce overall robustness (in the best case, where the abstraction layer
is literally perfect, all it can do is match the level of robustness of
the backend).
To illustrate that point, suppose that abstraction layer A (which
works 99% of the time) uses backend B (which works 90% of the time).
If we combine the two, we can only expect the result to be
(.9*.99) ~= 89% reliable - that's worse than either A or B.
Obviously I hope that both Netplan and networkd are much better than those arbitrary numbers that I made up just now, but neither one is perfect.
Replace server/embedded with laptop/desktop and networkd with NM, and the same idea applies. (Indeed, the same would still be true when comparing
our current direct use of ifupdown with Netplan + ifupdown.)
Dependency size and maintenance
-------------------------------
I also notice that the netplan.io package would bring GLib, Python, python3-dbus and python3-yaml into the dependencies of the base system,
among others. As an upstream and downstream maintainer of GLib, and in practice the only upstream and downstream unmaintainer[1] of python3-dbus, I'm not comfortable with that, both for size reasons (GLib and Python
are not small) and for quality and maintainedness reasons (python3-dbus).
GLib and Python are relatively large in both on-disk size and attack
surface, but they're essential to our desktop installations anyway, reinventing them in parallel would be worse than reusing them, and
their maintainers have already accepted the responsibility of them
being an important system component. So those two are actually not my
main concern here, and if we had no good alternative, I'd be saying:
yes they're relatively bulky for a container/embedded use-case, but on
a typical server installation they're fine.
python3-dbus is a concern to me, though.
I am not involved in libyaml, python3-yaml and other dependencies enough
to comment on whether they raise similar concerns.
Benefits vs. costs
------------------
I can see that Netplan aims to have some benefits over configuring the backend directly: its configuration format might be nicer than networkd's
or NM's (this is a matter of opinion, I personally think networkd syntax
is fine in at least the simple cases that are relevant for a default),
and it lets a sysadmin switch between backends without explicitly
translating configuration (I'm not convinced this actually happens
frequently enough to justify the complexity, but opinions can vary).
The question for the project is whether those benefits, in total, exceed
the costs of adding this layer over the top of what we could just be
using directly (networkd or NM, or for that matter, ifupdown).
I don't want people to think too much in terms of "sd-networkd VS Netplan", but rather in terms of "sd-networkd PLUS Netplan".
* Lukas MĂ€rdian <slyon@debian.org> [240715 09:36]:
I don't want people to think too much in terms of "sd-networkd VS Netplan", >> but rather in terms of "sd-networkd PLUS Netplan".
I'm a little confused. Much earlier in this thread it was stated that ifupdown2 was out of the running simply because it brings in python,
even though some consider it a better alternative than ifupdown-ng.
However, netplan.io also brings in python. Do I misunderstand which
package would be used to implement Netplan as being discussed here?
If we _are_ talking about netplan.io, then shouldn't we also bring
ifupdown2 back into consideration?
On Sun, 14 Jul 2024 at 19:21, Simon McVittie <smcv@debian.org> wrote:
Dependency size and maintenance
-------------------------------
I also notice that the netplan.io package would bring GLib, Python,
python3-dbus and python3-yaml into the dependencies of the base system,
among others. As an upstream and downstream maintainer of GLib, and in
practice the only upstream and downstream unmaintainer[1] of python3-dbus, >> I'm not comfortable with that, both for size reasons (GLib and Python
are not small) and for quality and maintainedness reasons (python3-dbus).
GLib and Python are relatively large in both on-disk size and attack
surface, but they're essential to our desktop installations anyway,
reinventing them in parallel would be worse than reusing them, and
their maintainers have already accepted the responsibility of them
being an important system component. So those two are actually not my
main concern here, and if we had no good alternative, I'd be saying:
yes they're relatively bulky for a container/embedded use-case, but on
a typical server installation they're fine.
Let's put some hard numbers on the table given this is an important
detail. The following is all starting from a default debootstrapped
unstable.
With networkd only we can drop ifupdown, net changes:
REMOVING:
ifupdown
Summary:
Upgrading: 0, Installing: 0, Removing: 1, Not Upgrading: 0
Freed space: 207 kB
Using network-manager in headless mode (no GUI) brings in:[...]
Installing:
network-manager
Summary:
Upgrading: 0, Installing: 69, Removing: 0, Not Upgrading: 0
Download size: 28.2 MB
Space needed: 110 MB / 8295 MB available
Installing netplan.io instead brings in:
Installing:
netplan.io
[...]
Summary:
Upgrading: 0, Installing: 42, Removing: 0, Not Upgrading: 0
Download size: 25.2 MB
Space needed: 101 MB / 8340 MB available
So we have a net gain of ~200K when using networkd, a net loss of
~110M when using network-manager, and a net loss of ~101M when using
netplan.
Furthermore, netplan pulls in a lot of python dependencies that are
not exactly recommended, as Simon said. And I think one of the reasons ifupdown2 never gained traction was because it pulled in python3,
which was considered a deal breaker for the default minimal install.
It seems to me if something other than networkd is desired,
network-manager would be the better choice.
# apt install netplan-generator
Installing:
netplan-generator
Installing dependencies:
libglib2.0-0t64 libglib2.0-data libicu72 libnetplan1 libxml2 libyaml-0-2 shared-mime-info xdg-user-dirs
Suggested packages:
low-memory-monitor network-manager | wpasupplicant openvswitch-switch iw
Summary:
Upgrading: 0, Installing: 9, Removing: 0, Not Upgrading: 0
Download size: 13.9 MB
Space needed: 59.9 MB / 22.5 GB available
# apt install --no-install-recommends netplan-generator
Installing:
netplan-generator
Installing dependencies:
libglib2.0-0t64 libnetplan1 libyaml-0-2
Suggested packages:
low-memory-monitor network-manager | wpasupplicant openvswitch-switch iw
Recommended packages:
libglib2.0-data shared-mime-info xdg-user-dirs
Summary:
Upgrading: 0, Installing: 4, Removing: 0, Not Upgrading: 0
Download size: 1,728 kB
Space needed: 5,265 kB / 22.5 GB available
= "How to do networking on Debian?" =
If we have to tell our users and sysadmins to do "X" on Debian server systems (using ifupdown or potentially sd-networkd), while doing "Y" on Debian desktop
systems (using NetworkManager), while doing "Z" on Debian cloud systems (using
Netplan), while doing something totally different on RaspberryPi (or alike) boards
that run a Debian server setup, but using WiFi as their primary network interface,
that's just a really bad user experience.
Using Debian should NOT feel like using different distros. And we really need a
common way to do network configuration. With Netplan we can tell people to just use
use the "dhcp4: true" setting (for example), which will work on all Debian systems
and is automatically translated to the corresponding backend for server/desktop/cloud/embedded usecases.
All while giving sysadmins the flexibilty to fully utilize the underlying network
daemon directly, if they feel like writing native configuration for it (or don't
like Netplan).
Assuming that's really needed, and it's far from clear that different
use cases should really use the exact same things, using
network-manager everywhere would achieve the exact same result,
without pulling in additional dependencies, and without being tied to
the internal decisions made in Canonical that we cannot do anything to influence. Again, not your fault, but existing examples don't exactly
inspire a lot of confidence in that regard: mir, upstart, unity,
lxd...
On Mon, Jul 15, 2024 at 03:47:16PM +0100, Luca Boccassi wrote:
Assuming that's really needed, and it's far from clear that different
use cases should really use the exact same things, using
network-manager everywhere would achieve the exact same result,
without pulling in additional dependencies, and without being tied to
the internal decisions made in Canonical that we cannot do anything to influence. Again, not your fault, but existing examples don't exactly inspire a lot of confidence in that regard: mir, upstart, unity,
lxd...
You could compile a similar list of software projects that were abandoned when Red Hat stopped funding them. Or of entirely community-backed free software projects that are moribund. I think it's prejudicial to argue that a piece of free software should not be adopted because its development is funded by a company which, over the course of 20 years, has made strategic decisions to discontinue investments in other, unrelated projects.
Either netplan is technically sound, providing a sensible configuration language that meets the needs of Debian users and has a high-quality code base, in which case it should not actually be a problem for Debian to maintain it in the event that Canonical discontinues work on it; or it
isn't, and we can stop the discussion there.
I don't want people to think too much in terms of "sd-networkd VS Netplan", >but rather in terms of "sd-networkd PLUS Netplan". Contributors to Netplan >naturally build up knowledge in sd-networkd (and NetworkManager), so we would >actually have more minds knowledgeable about our network stack.
Also, Netplan is just a configuration layer. That's a way simpler than NM or sd-networkd.
On Mon, 15 Jul 2024 15:35:32 +0200, Lukas MĂ€rdian <slyon@debian.org>
wrote:
I don't want people to think too much in terms of "sd-networkd VS Netplan", >> but rather in terms of "sd-networkd PLUS Netplan". Contributors to Netplan >> naturally build up knowledge in sd-networkd (and NetworkManager), so we would
actually have more minds knowledgeable about our network stack.
Other than being fully RFC 1925 6a compliant, why do we need that
layer then? And why do we need it in the installer, which is only
geared to supposed the most easy network configurations?
* Netplan PLUS NetworkManager(desktop/laptop)
* Netplan PLUS wpa_supplicant (server/embedded, using sd-networkd on WiFi)
Using Debian should NOT feel like using different distros. We want
[snip]
But it's not just this.
Netplan's beauty starts to shine when we're talking about the full
picture:
* Netplan PLUS sd-networkd (server/cloud/container)
* Netplan PLUS NetworkManager(desktop/laptop)
* Netplan PLUS wpa_supplicant (server/embedded, using sd-networkd on
WiFi)
* Netplan PLUS Open vSwitch (cloud/HPC)
So instead of having multiple different ways of configuring networking
on Debian
systems, we should be telling one coherent story. In the end we want
to have a
compelling answer to this question:
Am Di, Jul 16, 2024 at 10:54:47 +0200 schrieb Lukas MĂ€rdian:
Using Debian should NOT feel like using different distros. We want
Sorry, I call this bullshit. Iâm using Debian exactly because it feels different like other distros. There wouldnât be a need for Debian if not.
On 16/7/24 10:54, Lukas MĂ€rdian wrote:
[snip]
But it's not just this.
Netplan's beauty starts to shine when we're talking about the full picture: >>
* Netplan PLUS sd-networkd (server/cloud/container)
* Netplan PLUS NetworkManager(desktop/laptop)
* Netplan PLUS wpa_supplicant (server/embedded, using sd-networkd on WiFi) >> * Netplan PLUS Open vSwitch (cloud/HPC)
So instead of having multiple different ways of configuring networking on Debian
systems, we should be telling one coherent story. In the end we want to have a
compelling answer to this question:
[snip]
Out of curiosity+ignorance: how does Netplan detect the environment? How reliably?
I personally disfavour Netplan and other related tools (but open to be convinced on technical merits)Netplan isn't very common in the Debian world, yet, at least that was my impression from
On Jul 16, 2024 4:55 PM, Lukas MĂ€rdian <slyon@debian.org> wrote:
Netplan is integrated with [cloud-init] "v2" network configuration and the "cloud-config"
is adopted by many major public cloud providers (AWS, GCE, Azure, ...) as a deployment
method, which makes it a well-known format. Similarly default configuration for
[debian-cloud] is provided via Netplan. It is already supported in [Calamares] for our
live-images and as of recently landed in [debian-installer] as well.
It'd be very nice if it could also support a bgp-to-the-host setup natively as well. Maybe I can catch you in Busan to explain that use case?
Am Di, Jul 16, 2024 at 10:54:47 +0200 schrieb Lukas MĂ€rdian:
* Netplan PLUS NetworkManager(desktop/laptop)
All my desktops have only LAN and are working very well with ifupdown since the beginning.
My Laptops are mostly in a LAN either. So NM is onlay needed for the rare cases Iâm in a WLAN.
* Netplan PLUS wpa_supplicant (server/embedded, using sd-networkd on WiFi)
None of my servers are using WLAN. They all work very well with ifupdown including bonding/vlans.
The only times I didnât get a working network with ifupdown are a) missing firmware and b) the installer doesnât support VLAN/Bonding.
And I donât think Netplan will help here.
Using Debian should NOT feel like using different distros. We want
Sorry, I call this bullshit. Iâm using Debian exactly because it feels different like other distros. There wouldnât be a need for Debian if not.
ifupdown *is* one of the reasons Iâm using Debian. Iâm not interested in editing yaml files to configure the network.
Am Di, Jul 16, 2024 at 10:54:47 +0200 schrieb Lukas MĂ€rdian:...
Using Debian should NOT feel like using different distros. We want
Sorry, I call this bullshit. Iâm using Debian exactly because it feels different like other distros. There wouldnât be a need for Debian if not.
On 16.07.24 11:24, Stephan Seitz wrote:
None of my servers are using WLAN. They all work very well withThis might not be your usecase, but I regularly see setups of "embedded >boards", like Raspberry Pi, that use a server image but have the WiFi
ifupdown including bonding/vlans.
adapter as their primary network interface.
Sorry, I call this bullshit. Iâm using Debian exactly because it feels >>different like other distros. There wouldnât be a need for Debian ifAs Colin stated, what I said is that Debian should have a congruent >networking story in itself, independent of the context you're using it
not.
in (desktop, server, cloud, etc.).
I suspect having something that's agnostic about the underlying implementation as our default would be rather better for the non-systemd options that people care about, âŠ
Also, networkd doesn't support non-Linux and non-systemd systems AFAIK,
On Tue, 16 Jul 2024 13:13:16 +0200, Philip Hands wrote:
I suspect having something that's agnostic about the underlying
implementation as our default would be rather better for the non-systemd
options that people care about, âŠ
Also, networkd doesn't support non-Linux and non-systemd systems AFAIK,
AFAICS, the netplan packages (netplan.io, netplan-generator) currently
have a hard dependency on systemd.
On Tue, 16 Jul 2024 13:13:16 +0200, Philip Hands wrote:
I suspect having something that's agnostic about the underlying
implementation as our default would be rather better for the non-systemd
options that people care about, âŠ
Also, networkd doesn't support non-Linux and non-systemd systems AFAIK,
AFAICS, the netplan packages (netplan.io, netplan-generator) currently
have a hard dependency on systemd.
No. We're talking about the "netplan-generator" package, which comes without any
Python dependencies. It's a part of the netplan.io source package and everything
that would be required in the default installation.
On 16.07.24 15:05, gregor herrmann wrote:
On Tue, 16 Jul 2024 13:13:16 +0200, Philip Hands wrote:
I suspect having something that's agnostic about the underlying implementation as our default would be rather better for the non-systemd options that people care about, âŠ
Also, networkd doesn't support non-Linux and non-systemd systems AFAIK,
AFAICS, the netplan packages (netplan.io, netplan-generator) currently
have a hard dependency on systemd.
That's true.
Netplan functions as a [systemd-generator] at its core, so it will have the same limitations as sd-networkd. So ifupdown[-ng] would still be needed as a fallback for the non-systemd ports.
Lukas MĂ€rdian <slyon@debian.org> (2024-07-11):
Additional benefits of Netplan:
* Already used on Debian Bookworm [cloud] images by default
Having started to toy with cloud images these last few days, and
learning about the various components in there, I'm not exactly sure
where /etc/netplan/90-default.yaml is coming from but it's 644 in at
least Debian 12 and Debian sid ânocloudâ amd64 images (QCOW format), leading netplan to complain about these too-wide permissions.
I'm not sure where this file is coming from, but it'd be great to have
those permissions fixed/those warnings go away.
I'd be glad if someone could take it up from here, I've burned up all
the time I had to spend on Netplan on the short term. Thanks already!
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 167:02:14 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,529 |