[Touch-packages] [Bug 1962214] Re: The documentation around NM's 10-globally-managed-devices.conf is inadequate
I agree, done! ** This bug is no longer a duplicate of bug 1951653 can't use NM for ethernet device on 20.04 LTS because it is 'strictly unmanaged' -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1962214 Title: The documentation around NM's 10-globally-managed-devices.conf is inadequate Status in netplan: New Status in network-manager package in Ubuntu: New 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. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1962214/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962214] Re: The documentation around NM's 10-globally-managed-devices.conf is inadequate
*** This bug is a duplicate of bug 1951653 *** https://bugs.launchpad.net/bugs/1951653 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. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1962214 Title: The documentation around NM's 10-globally-managed-devices.conf is inadequate Status in netplan: New Status in network-manager package in Ubuntu: New 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. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1962214/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962214] Re: The documentation around NM's 10-globally-managed-devices.conf is inadequate
*** This bug is a duplicate of bug 1951653 *** https://bugs.launchpad.net/bugs/1951653 ** This bug has been marked a duplicate of bug 1951653 can't use NM for ethernet device on 20.04 LTS because it is 'strictly unmanaged' -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1962214 Title: The documentation around NM's 10-globally-managed-devices.conf is inadequate Status in netplan: New Status in network-manager package in Ubuntu: New 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. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1962214/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
