On Tue, Jul 11, 2023 at 03:06:57PM -0600, Sam Hartman wrote:
> >>>>> "Lukas" == Lukas Märdian <luk@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
Attachment:
signature.asc
Description: PGP signature