Could we consider instead going all-NetworkManager instead? NetworkManager is fully capable of handling all the various networking cases we care about, and recently cloud-init got support for generating native NetworkManager keyfiles too.
This would also align us with other distributions (RH/Fedora, [open]SUSE) and let us benefit from the shared development going on in NetworkManager for all these use-cases.
Worked fine here. My setup:
All got correctly reflected both ways, only spewed warnings all over, but that’s probably by design.
netplan: NM-…: handling NetworkManager passthrough device, settings are not fully supported.
One thing that was unexpected, though — in your “Common case 1”, when I removed the Ethernet connection and sudo netplan apply'd, NM reconnected to the wired network immediately, but netplan was unawares. Only after dis- and reconnecting the cord did things show up.
Actually there’s one issue I found. I had a custom route added to an OpenVPN connection:
[ipv4]
method=auto
never-default=true
route1=1.2.3.4/24,
I can’t get that back with the new setup. Even adding the below to the yaml doesn’t help. It may well be a NM bug, as I was only able to get this behaviour (a gateway-less route configuration) in NM through manual editing of the connection files.
passthrough:
ipv4.route1: "1.2.3.4/24,"
Some issues using the network-manager-openvpn plugin have been reported by @alfonsosanchezbeato in LP#1998207
While writing an autopkgtest for this integration I believe I’ve found another issue. After creating a connection, the file is created in /etc/netplan, but then I try to change it hoping that Network Manager would apply the changes to the existing file. But it ends up deleting both the Netplan and the keyfile files while the connection will still exist.
I’ve created a script that can be used to reproduce the issue.
https://gist.github.com/daniloegea/d3bb95dbac2bf37e2f1a7ad046a9f0e8
I just tried this on Lubuntu Lunar.
Some things I noticed:
1: After installing the Netplan-integrated NetworkManager, my WiFi and loopback connections appeared to drop, then both reconnected. WiFi dropping out seems normal, however I don’t think the loopback connection should ever drop. Not sure if that’s something to be taken into account.
2: When installation was finished, sudo netplan get and ls /etc/netplan both showed almost no Netplan-related data. All I got from sudo netplan get was:
** (process:4088): WARNING **: 12:41:41.394; Permissions for /etc/netplan/01-network-manager-all.yaml are too open. Netplan configuration should NOT be accessible by others.
network:
version: 2
renderer: NetworkManager
I had to disconnect from WiFi, entirely delete my WiFi connection with nmtui, then reconnect to WiFi in order to get anything to register in Netplan. After doing that, things seem to look normal.
3: Netplan is storing my WiFi password in cleartext. I don’t think this is a problem since the .yaml file that actually holds my WiFi info isn’t publicly accessible like the 01-network-manager-all.yaml file is. However, I believe that Kubuntu (at least sometimes) holds the WiFi password in KWallet, and retrieves it from KWallet to connect to WiFi. I’m wondering how that will interact with Netplan - will the two conflict? Will one get ignored?
4: Last but not least since this ended up not being a bug, it looks like Netplan is failing to get the IP address from NetworkManager. My sudo netplan get output looks like this after getting things to show up there:
network:
version: 2
renderer: NetworkManager
wifis:
NM-90ea9018-baa8-8c59-f4044a9c8b31:
renderer: NetworkManager
match:
name: "wlp1s0"
dhcp4: true
dhcp6: true
access-points:
"My WiFi Hotspot Name":
auth:
key-management: "psk"
password: hunter2
networkmanager:
uuid: "90ea9018-baa8-41d5-8c59-f4044a9c8b31"
name: "My WiFi Hotspot Name"
passthrough:
wifi-security.auth-alg: "open"
ipv6.addr-gen-mode: "default"
ipv6.ip6-privacy: "-1"
proxy._: ""
networkmanager:
uuid: "90ea9018-baa8-41d5-8c59-f4044a9c8b31"
name: "My WiFi Hotspot Name"
The “Common case 2: Wifi Connection” above shows that there are IPv4 addresses in the Netplan output, and I know my hotspot provides me an IPv4 address.
My WiFi appears to be working just fine, though - I can still browse websites and whatnot without problems so far.
My testcase is a fairly standard WiFi connection on a laptop. I’m using a cellular WiFi hotspot. Also, in case it wasn’t obvious, “My WiFi Hotspot Name” is not the actual name of my WiFi hotspot, and “hunter2” is not my actual WiFi password.
I filed a new bug about the missing IPv4 information here: https://bugs.launchpad.net/netplan/+bug/2009764 (edit - not a bug, I misunderstood how this was supposed to work.)
I noticed the same behaviour. In my case, I tested with an eduroam connection.
Having the password show in plain-text in the netplan yaml is definitely not ideal, especially for connections like eduroam or corporate WiFi where it’s possible the users domain username/password is used for eduroam authentication.
Worse still because all netplan yaml files are world-readable.
Although, this might also be the case with NetworkManager system-connection files??
Some more notes from my eduroam connection testing.
Adding the eduroam connection with nmcli command seems to always fail with the following error:
Error: Failed to add 'eduroam' connection: failure adding connection: settings plugin does not support adding connections
Adding with the GNOME control center GUI appears to work, and I get a corresponding file in /etc/netplan/90-NM*****.
However, the new netplan isn’t automatically applied for me, and even after a netplan apply, the new eduroam connection doesn’t show for me.
This should actually not be the case. The NetworkManager-Netplan integration is supposed to create files accessible to root only, using “0o600” permissions (-rw-------). Can you please double-check your system for the file permissions:
$ ls -la /etc/netplan/
$ sudo ls -la /run/NetworkManager/system-connections/
Thanks a lot for reporting this issue! Can you please elaborate on this issue: which nmcli command are you using exactly? How to reproduce it? Could you maybe create a bug report about this at OpenID transaction in progress giving all the details?
Thank you very much for your tests and bug reports @arraybolt3! This is very helpful.
A new version is now deployed to the PPA (for Lunar), which should migrate all of the existing connection profiles in /etc/NetworkManager/system-connections to /etc/netplan on upgrade/install. Could you give this another try?
Sorry for the delay. Only just got a chance to revisit this.
Here’s the output of those commands:
root@example.org:~# ls -l /etc/netplan/
total 8
-rw-r--r-- 1 root root 813 Apr 17 12:32 90-NM-d7129202-78f4-4651-a606-f91cda2a75b7.yaml
-rw-r--r-- 1 root root 1272 Apr 5 15:59 99-ebi-netplan.yaml
root@example.org:~# ls -la /run/NetworkManager/system-connections/
total 16
drwx------ 2 root root 120 Apr 17 12:32 .
drwx------ 5 root root 140 Apr 17 12:07 ..
-rw------- 1 root root 477 Apr 17 12:32 netplan-EBI-WIFI-EBI.nmconnection
-rw------- 1 root root 432 Apr 17 12:32 netplan-EBI-WIRED.nmconnection
-rw------- 1 root root 287 Apr 17 12:32 netplan-NM-d7129202-78f4-4651-a606-f91cda2a75b7-eduroam.nmconnection
-rw------- 1 root root 143 Apr 17 12:32 netplan-Standard.nmconnection
90-NM-d7129202-78f4-4651-a606-f91cda2a75b7.yaml is the yaml file automatically created when attempting to add eduroam via nmcli.
The other netplan yaml file is one we deploy ourselves.
I’ve submitted a bug for this with the relevant details: https://bugs.launchpad.net/netplan/+bug/2016625
Hello,
Thank you for your great work on Netplan, it keeps getting more useful every day.
Being a user of the Ubuntu development release (Mantic), my system got migrated as a part of the updated network-manager package. Most of my connections appear to have migrated smoothly, but one of them resulted in a failure:
Setting up network-manager (1.42.4-1ubuntu3) ...
Migrating Bridge connection 1 (505dd778-c585-4632-bad2-70ac6964fcfc) to /etc/netplan
...
Error: Failed to modify connection 'bridge0 port 1': Message recipient disconnected from message bus without replying
FAILED. Restoring backup ...
Looking at the pieces the migrated bridge looks like this:
sudo cat /etc/netplan/90-NM-505dd778-c585-4632-bad2-70ac6964fcfc.yaml
network:
version: 2
bridges:
bridge0:
renderer: NetworkManager
dhcp4: true
dhcp6: true
ipv6-address-generation: "stable-privacy"
networkmanager:
uuid: "505dd778-c585-4632-bad2-70ac6964fcfc"
name: "Bridge connection 1"
passthrough:
connection.timestamp: "1684472567"
ethernet._: ""
bridge._: ""
ipv6.ip6-privacy: "-1"
proxy._: ""
And the port in that bridge that it complained about appears to still be in NM-format:
$ sudo cat /etc/NetworkManager/system-connections/bridge0\ port\ 1.nmconnection
[connection]
id=bridge0 port 1
uuid=4984a833-9c64-41dc-aa9e-79941990e776
type=ethernet
interface-name=enp71s0
master=bridge0
slave-type=bridge
timestamp=1665642212
[ethernet]
cloned-mac-address=preserve
mac-address=XX:XX:XX:XX:XX:XX
[bridge-port]
Should I report a LP bug for this?
Thanks a lot for providing feedback here, Frode!
Yes, please open a bug report at OpenID transaction in progress providing the original keyfile, the generated (corrupt?) YAML, tagging it netplan-everywhere.
TIA!
See latest updates in [Blog] Netplan developer diaries
This intergration is now enabled in Ubuntu Mantic.
Is there a way to go without the netplan integration in Ubuntu 23.10 ??
I really dont like it - so I banned netplan package with a empty dummy package.
But I cant create new network connections:
Nov 13 22:46:10 ub-tc NetworkManager[1007]: <info> [1699911970.3108] audit: op="connection-add-activate" pid=2062 uid=1000 result="fail" reason="failure adding connection: settings plugin does not support adding connections"
I hope you guys also come up with a simple disable plugin or whatever config line for NetworkManager to let ppl choose not to migrate to netplan backend!
By force was newer a good choice 
I read debian/patches/netplan/0002-netplan-make-use-of-libnetplan-for-YAML-backend.patch and it dont looks like it is possible to disable. Looks like the only option is to recompile the whole NM package. Why you have not gone a clean way with a seperate plugin which we can select to install.
plugin: keyfile or keyfile-netplan or something like it.
I really see no more comfort in netplan and so don’t like to be forced to it. For me netplan was always just an option - but now things changing which makes me not happy.
From your webpage:
Netplan has established itself as the proven network stack across all variants of Ubuntu – Desktop, Server, Cloud, or Embedded. It has been the default stack across many Ubuntu LTS releases, serving millions of users over the years.
But you must also see, that not everybody used netplan - I am a Ubuntu fan for long time and also installed over 500 server and desktop systems with it. I was every time free to use what I want and newer went to netplan. I used systemd on servers and NM on desktop systems.
For sure I am not the only one who liked to have a choice.
As you mentioned, the only option is to disable the functionality at compile-time inside the NetworkManager package, using the --disable-netplan flag.
We have a bug report tracking this behavior here: Bug #2041491 “Provide an option to avoid the yaml NM backend” : Bugs : network-manager package : Ubuntu