On Tue, Jul 11, 2023 at 03:06:57PM -0600, Sam Hartman wrote: > >>>>> "Lukas" == Lukas Märdian <l...@slyon.de> 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 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.
The 90-default.yaml example I've given above, isn't too complex either, and
provides the additional benefit of being able to hand over control to
NetworkManager if needed, by shipping a drop-in config.
On Wed, Jul 12, 2023 at 07:54:15AM +0200, Gioele Barabucci wrote:
> 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.
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.
-- Lukas
signature.asc
Description: PGP signature
