Please welcome: NetworkManager 1.20

Another three months have passed since NetworkManager’s 1.18, and 1.20 is now available. What follows is a quick overview of what’s new.

We’re dropping some old cruft

Yes, the line diff compared to the previous major release, NetworkManager 1.18, is negative!

The libnm-glib library, deprecated in favor of libnm since NetworkManager 1.0 release almost five years ago, was dropped. At this point it’s almost certain to have no users.

If you’re developing a program that has anything to do with network configuration, libnm is the way to go. You can also use it from other languages than C via GObject instrospection — just check out our examples.

Also gone is the settings plugin for use with iBFT. For those who don’t know: iBFT is the way for the boot firmware to pass the network configuration it has used to the operating system. It really was rather unlike what other settings plugins are — its role was to create a single virtual connection profile that would be there so that NetworkManager won’t tear down the network configuration applied by the early boot firmware. This doesn’t mean that we don’t support network booted installations. Quite the opposite. Since the last release we support configuring the network on early boot with NetworkManager and we preserve configuration done outside NetworkManager without the need of a placeholder connection profile.

Vendor-supplied profiles and scripts

The distributions can now ship connection profiles and dispatcher scripts in the /usr/lib/NetworkManager. This makes things convenient for stateless systems, that ship a read-only system image or are reset to a “factory” state by wiping /etc clean. Note that you the users can still modify and delete the vendor-supplied connection profiles via D-Bus API. In such case, NetworkManager will overlay the read-only files with profiles in /etc or /run.

Refer to file-hierarchy(7) manual page to learn more about the directory layout of a typical Linux installation.

Improved D-Bus API

The Settings.AddConnection2() call was added, as a future-proof version of AddConnection() and AddConnectionUnsaved() calls that turned out to lack extensibility. In addition to the original functionality, it allows suppressing the autoconnect feature on adding a connection. This is like the already existing Settings.Connection.Update2() that supports a similar flag. Settings.Connection.Update2() also got a new “no-reapply” flag to suppress taking changes to “connection.zone” and “connection.metered” immediately.

Using the older API? Worry not, we’re not removing it. We’re committed to maintain a stable API and not ever break things deliberately.

More small things

There have been over seven hundred commits since the last stable release. That’s means this article can not possibly be comprehensive. But here’s are some of the most interesting small bits:

The daemon restart got more robust. In particular, in-memory connections are saved in /run, making it possible for them to survive restarts.

Wi-Fi Mesh networks are supported, if you are lucky enough to have hardware that supports it.

The internal default DHCP client is used by default. It’s smaller and faster than dhclient, which was used previously. NetworkManager supports multiple different DHCP clients and the users and distributors have an option to modify the default.

For those who wish to learn more, there’s always a more exhaustive NEWS file.

Thanks

We’d like to thank everyone who made NetworkManager 1.20 possible. In particular Andy Kling, who contributed the Wi-Fi Mesh support and Tom Gundersen who improved the internal DHCP client. Thomas Haller reviewed and improved the article.