NetworkManager and netplan

NetworkManager and netplan

The default netplan configuration files in Ubuntu Core leave management of networking devices to networkd. But, when network-manager is installed, it creates new netplan configuration files, setting itself as the default network renderer and taking control of all devices.

It is possible to control this behavior with the defaultrenderer snap option. It is set by default to true , but if we set it to false , network-manager reverts the netplan configuration and networkd takes control of the devices again. Note however that networkd will take control only of devices explicitly configured by netplan configuration files, which is usually only ethernet or wifi devices. To do that:

snap set network-manager defaultrenderer=false

In the core16 snap (legacy), the behavior was different: networkd was left as default renderer and the default netplan configuration was unchanged when network-manager was installed. There was instead a setting called ethernet.enable that was false by default. When set to true , NetworkManager was set as the default network renderer similarly as described above.

YAML backend

As of core20 the network-manager snap was modified to use a YAML backend by default, based upon libnetplan functionality. This YAML backend replaces NetworkManager’s native keyfile format and stores any configuration in /etc/netplan/*.yaml, to stay compatible with the rest of the system.

On boot the netplan.io generator processes all of the YAML files and renders them into the corresponding NetworkManager configuration in /run/NetworkManager/system-connections. The usual netplan generate/try/apply can be used to re-generate this configuration after the YAML was modified.

If a connection profile is modified or created from within NetworkManager, e.g. to update a WiFi password via nmcli, NetworkManager will create an ephemeral keyfile that will be converted to netplan YAML right away and stored in /etc/netplan. After that NetworkManager will automatically call netplan generate to re-process the current YAML configuration and render it into NM connection profiles in /run/NetworkManager/system-connections.

The system wide network configuration can be read, using the netplan get command and modified via netplan set or snapd. Configuration options that are not supported by the NetworkManager YAML backend are stored in a networkmanager.passthrough YAML mapping, so that they won’t be lost during the netplan conversion.

2 Likes

Does the netplan generator re-process yaml files even their system-connections counterpart already exists? Or do the system-connections not exist (every boot) until the netplan generator processes them?

Perhaps worth mentioning that while this is true, the user should not have to do anything here. It’s all behind the scenes automatically.

When does the ephemeral keyfile get removed?