NetworkManager 1.16 Approaches With WireGuard VPN Tunnels, WiFi Direct Connections

[phoronix]

Phoronix: NetworkManager 1.16 Approaches With WireGuard VPN Tunnels, WiFi Direct Connections

The release of NetworkManager 1.16 is right around the corner with this morning's first release candidate...

http://www.phoronix.com/scan.php?page=news_item&px=NetworkManager-1.16-RC1

[orschiro]

Looking forward to synchronising my saved networks across machines. 😍🤗

[Britoid]

Nice.

The network manager Wireguard plugin has been broken for a while (won't compile with newer Networkmanager versions), so nice it has it built in.

[dwagner]

Given how unhelpful NetworkManager has been to me, especially in situations where the network configuration is less than trivial, I will continue to de-install and ignore it. It is just one additional abstraction layer that introduces its own bugs while hiding what is going on the lower abstraction layers.

[bitman]

Nice.

The network manager Wireguard plugin has been broken for a while (won't compile with newer Networkmanager versions), so nice it has it built in.

It doesnt even compile? Version that worked was still broken with any custom pre/post commands. Hopefully this official support will be better.

[q2dg]

"- NetworkManager is no longer installed as a D-Bus activatable service"

This means, for instance, Cockpit won't be able to manage network settings, doesn't it? (https://cockpit-project.org/guide/13...rkmanager.html)
It's a really big disruption!!!

[oiaohm]

"- NetworkManager is no longer installed as a D-Bus activatable service"

This means, for instance, Cockpit won't be able to manage network settings, doesn't it? (https://cockpit-project.org/guide/13...rkmanager.html)
It's a really big disruption!!!

No it does not mean this. NetworkManager Dbus API will still be there for Cockpit to use as long as NetworkManager is running.

To be truthful this D-Bus activated service feature in some cases is the path to hell.

Start of hell is 1 of 2 events
1) you attempt stop/restart network manager.
2) network manger crashes for some reasons.
Now what happens after this is fairly identical path to hell.
Multi programs are attempt to use the D-Bus API resulting in D-bus activatable service in fact starting the service multi times as it d-bus services function a lot like inetd services. inetd style activation is good for some services but not good for services like network manager.

When you end up with like 5 running copies of network manager trying to control the network stack you end up in one hell of a cat fight.

It will mean minor changes like cockpit detects network manager dbus interfaces are not running call out to service manager this could be systemd to start network manager. Systemd case will not do this multi copies running. Also it will mean it will be simpler to disable networkmanager when you want it stopped.

[DrYak]

"- NetworkManager is no longer installed as a D-Bus activatable service"

This means, for instance, Cockpit won't be able to manage network settings, doesn't it?

No. What it means is that now, the only way to start NetworkManager is by typing something like :

systemctl start NetworkManager.service

(equivalent OpenRC, Upstart, etc. commands are left as an exercice for the reader).

Until now, NetworkManager could *also* start completely on its own, just because some app tried to call NetworkManager API.
(e.g.: if you try to configure something with Cockpit, and that one calls NM API over D-Bus and suddenly you have an unwanted NM daemon running in the background and trying to grab your network device and auto-configure them).
This would be a big problem, because you have problems such as :

Given how unhelpful NetworkManager has been to me, especially in situations where the network configuration is less than trivial, I will continue to de-install and ignore it. It is just one additional abstraction layer that introduces its own bugs while hiding what is going on the lower abstraction layers.

For (my own rough estimation) 90~99% of people, Network Manager does a sufficent jobs, specially at everyday tasks that should be simple for everyone :
e.g.: Connecting your laptop (= a mobile device) to a password-protected WPA network.
NM makes it simple point'n'click, whereas the old classical method (Devuan-friendly ?) would have required to manually edit some obscure files in '/etc/sysconfig/network' and '/etc/wpa_supplicant/wpa_supplicant.conf'.

But then there are situation with weird specific network configuration.
(e.g.: a sperate virtual network for LXC container that should be on its private IPv4 subnet, but should be accessible publicly with their IPv6 address (sharing a common subprefix as the rest of the network) and advertised as such. Because of complex adminitrative reasons.)

Not having NetworkManager suddenly popping-in and grabbing the network just because some random application called some API over the D-Bus is a big nerve saver.

[q2dg]

Thanks a lot oiaohm and DrYak !!

[StefanBruens]

Multi programs are attempt to use the D-Bus API resulting in D-bus activatable service in fact starting the service multi times as it d-bus services function a lot like inetd services. inetd style activation is good for some services but not good for services like network manager.

Completely wrong. DBus-Activation locks against concurrent duplicate activation of a service, if mutiple clients request a service concurrently, (at most) one instance will be started, and all clients get the same response.