The documentation around NM's 10-globally-managed-devices.conf is inadequate

Bug #1962214 reported by Ratchanan Srirattanamet
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Netplan
New
Undecided
Unassigned
network-manager (Ubuntu)
New
Undecided
Unassigned

Bug Description

So, we're UBports, porting Ubuntu Touch stack to Ubuntu 20.04. While debugging why NM won't manage the phone's USB network interface, I stumbled upon /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf. This file prevents NM from managing ethernet connection, which confuses me since this file also exists on my laptop, yet NM happily manages its ethernet port.

This file exists at part of NetworkManager package in Ubuntu without any documentation. And the reason given in the commit that add it [1] does not mention any specific reason why it's added. Only when looking in the log on my laptop do I see that something places the file with the same name in /run/NetworkManager/conf.d/, and requires greping in /usr/lib to find out that the thing is Netplan's generator binary.

Now, that file in /run is empty, which requires another round of searching to find out that Netplan places this file when it's configured to use NM as a renderer. With that in mind, I discovered that /etc/netplan/01-network-manager-all.yaml exists on my laptop but not the phone. Now, because 'dpkg -S' returns empty result, I need to search again what places this file, with no avail. Luckily, I happen to have a clone of livecd-rootfs on my laptop, which leads me to this commit [2] which finally reveals the reason why this is done: to prevent systems which installs NM after-the-fact to have NM conflicts with e.g. systemd-networkd.

All of these knowledge should not require this much searching plus grepping through _binary_ file. If either my laptop was not running Ubuntu or I didn't have livecd-rootfs cloned, it would be much harder to figure this out. They should be more properly documented, probably both in the /usr/lib/ and /run/ files. Thus, this issue is filled against both Netplan and NetworkManager packages.

[1] https://git.launchpad.net/network-manager/commit?id=1ab4db73c1f0db30f3af1845a9c41e3c3952dea1
[2] https://git.launchpad.net/livecd-rootfs/commit/?id=d9ce44d73a0a6d91156bb94e03063d541b0f7579

P.S. Arguably, this behavior might be even wrong. According to https://netplan.io:

> Obviously, without configuration, netplan will not do anything.

This is not really the expected "not do anything". IMO the NM's behavior should be left at the default, unless e.g. the networkd renderer is used, in which case Netplan will disable NetworkManager to not manage interfaces configured by Netplan. However the reason above of preventing conflict with networkd is a valid one, and my proposal doesn't help with that particular case.

Revision history for this message
Ratchanan Srirattanamet (peat-new) wrote :

While the bug #1951653 is solved, it does not change the design of this process. With a quick inspection of repos, NM and livecd-rootfs still ship the file with no explanation, and netplan still place an empty file. So, the heart of this bug (which is documentation, please read the title again) is still not solved. Please de-duplicate this bug.

Revision history for this message
Lukas Märdian (slyon) wrote :

I agree, done!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.