Seriously, current versions are barely usable, and I don’t think I’m doing anything particularly hard. Want to verify your config before committing to it? Nope. Want to delete a vlan? Not happening without bypassing netplan. Want to bring up a vlan on an interface with a long name (which is the default on a fresh Ubuntu install with a NIC in a PCIe slot)? Netplan will accept the configuration, but it won’t work, and you’ll have to do quite a bit of digging to find out why your vlan doesn’t exist as far as the kernel is concerned.
The latter one is nasty if you upgrade Ubuntu on a system where the management interface is on a vlan.
You can verify your config with netplan-try. This works fairly well for me with the timeout feature. Additionally you could write a bash script that basically replaces the netplan config to the old state when the machine is no longer able to ping (or similar).
There is a -state parameter for netplan apply which allows deleting VLANs, which has worked for me every time so far. What's the exact issue?
I never ran into your last issue, so I can't comment on that.
But I think this whole model is wrong. For as long as I'm aware, every serious network config system (at least Cisco IOS and everything that came after) has it right: there is a live configuration and a saved configuration. You can edit the live configuration, and you can commit to the saved configuration.
So with netplan try, you edit the configuration, hope you don't crash or otherwise reboot, run netplan try, and hope it succeeds in rolling back on failure. That's a lot of hoping. With old IOS, you would just not do 'write memory' until you get the configuration right.
Similarly, netplan apply -state relies on the user to do some horrible manual shuffling of configuration. An IOS-like solution would make this automatic.
In the context of netplan, this could be quite straightforward. Instead of just /etc/netplan, there would be:
/etc/netplan: The configuration to be loaded at boot.
/var/run/netplan-live: The configuration that was most recently applied. NOTHING EXCEPT THE NETPLAN TOOLING EDITS THIS.
/tmp/whatever (or any other path): configuration that the administrator wants to test.
To use it, the admin could stage their configuration anywhere they want and netplan apply it. Then netplan commit would commit the running configuration to /etc/netplan. -state is automatic: it's in /var/run/netplan-live.
re: the last issue, one of my servers has a NIC with a name like eno12345np1. On that physical link is a vlan with tag 1234. This gives a name like "eno12345np1.1234". That plus the trailing NULL is 17 bytes, which is too long. Now this isn't strictly netplan's fault (although eno12345np1 really is excessive IMO), but the fact that netplan can't intelligently handle this or at least notice when I do netplan apply is fairly sad.
Netplan has oversimplified things to cater only to the simplest of topologies. The schema seems unable to capture the richness and modularity of actual networking technologies.
If by "only the simplest of topologies" you mean: 4 physical interfaces, bonded with active/backup failover and mii-monitoring, and 20 VLANs, turning off IPv6 on my public interface...
Honestly, I really like netplan, been using it for all my systems for ~5 years now.
I was able to set up fiber link aggregation with triple NICs and a custom VLAN and MTU with no issues. It supports bridges and child interfaces just fine.
I've achieved more reliable and reproducible complex setups with netplan than any hodgepodge of ifupdown scripts has ever done for me. Which topologies does it not work for?
Linux allows you to bind a subnet of addresses to an interface so that an application can listen on them. The netplan syntax is poorly thought out and overloads the CIDR notation to specify both the IP and netmask, so it is impossible to specify more than a single address.
I use this functionality in production for high availability configurations and effectively have to have a cron job to use 'ip' directly to fix things up.
I was hoping that Canonical has higher standards when it comes to server software, as opposed to something like Snapcraft, but reading this makes me think that maybe they both were developed by the same team.
On the server side, this is one of the reasons my company is quickly moving all Ubuntu servers to Debian. It is so much easier to just edit /etc/network/interfaces.
I prefer plain Systeme-networkd. Basically you just create a network unit file and configure the interface with it. Basically like network/interfaces, just a little bit more cleaned up
So that if you like to randomly switch your underlying network management tools, you can have something take what you have and generate semi-working configurations with hard to track down bugs.
The thing I can't understand is that netplan is just a bunch of janky C that is almost entirely parsing logic and the thinnest wrapper humanly possible over systemd-networkd/networkmanager that does all the real work. And the abstraction leaks for anything but the simplest cases so your files are targeting a specific backend anyway.
systemd-networkd already gives you simple declarative INI networking files and a dbus interface. I can't find any value-add over just using its backends directly.
I like the chaos of the Fedora networking tools because they let me charge more billable hours as I untangle what the client set up for themselves.
In all seriousness, once you learn Netplan, you get accustomed to 1 config file for all networking needs. I also prefer UFW to iptables. Simple and handles most day-to-day use cases.
Linux networking has been a solved problem since just about forever, and all this instability will do is cause people to abandon Ubuntu in favor of something less fickle.
It would be more useful for the various major distros to pitch in for easy, simple, congruent CLI, UI, declarative, and API configuration management for common advanced configuration.
Creating artificial lock-in that doesn't work is a double-barrel footgun blast.
The Ubuntu people are like the SystemD people: they just want to reinvent things from scratch and shove it down everyone's throats without any consideration.
This, I really don't understand that they want to create a diverging solution for something that already works really well. We don't need 15 different solutions to configure networking.
Imagine looking for a Java solution and the only response you find is in Kotlin... fucking annoying as I have to learn Kotlin to convert it to Java...
The same thing with network configuration, you're looking for something that works on Debian and you only find a Ubuntu solution....
What they have done is taken the chaos of networking scattered across 1/2 dozen (or more) configuration files and commands and centralizes so the chaos is in one place. They've succeeded in simplifying some parts and I have faith they will make network configuration much simpler in the future.
You only think ifupdown-ng, nmcli/nmtui work well because you don't remember how hard it was to learn and developed scar tissue from using them. To my scar tissue, Debian/Ubuntu is well organized and tools like netplan clicked very fast and make network configuration much easier.
Guessing, but I think it probably has more to do with the various tools and frontends (GUI, cloud-init, etc.) designed to manage the configurations than it has to do with the capabilities of what the configuration system will support. I have been bitten by some of this too, but the various script hooks are still there, and I've been able to support everything else via those mechanisms.
Can someone explain to me why netplan even exists? I don't see any utility in it, I don't change out my network connection manager on a daily basis so what use is a sub par abstraction when I can configure my manager of choice directly? For me it's just one of the many many reasons I don't touch Ubuntu, but sometimes I have to deal with it and I always end up shaking my head at the half baked crap they keep adding.
Seriously, current versions are barely usable, and I don’t think I’m doing anything particularly hard. Want to verify your config before committing to it? Nope. Want to delete a vlan? Not happening without bypassing netplan. Want to bring up a vlan on an interface with a long name (which is the default on a fresh Ubuntu install with a NIC in a PCIe slot)? Netplan will accept the configuration, but it won’t work, and you’ll have to do quite a bit of digging to find out why your vlan doesn’t exist as far as the kernel is concerned.
The latter one is nasty if you upgrade Ubuntu on a system where the management interface is on a vlan.