Re: Make NetworkManager connection profiles without changing the current network configuration

[Thomas Haller <thaller redhat com>]

On Tue, 2021-08-03 at 13:26 +0000, Matthew Starr via networkmanager-
list wrote:
> I am looking for a way to generate connection profile config files
> without applying the settings to the currently enabled network
> interfaces that are already configured.  I am using NetworkManager on
> an embedded device and I want to fully generate all profile config
> files before having any of them be applied.  This is to ensure the full
> update of the embedded device was successful before applying the
> changes.  So basically, I am looking for a way to use nmcli to generate
> config files for connection profiles and have them written somewhere,
> but not have them take effect with the current running instance of
> NetworkManager.  I don't want the network interfaces current state
> interrupted since an update application is talking to a remote update
> server telling it the update status.
>  
> Here is the background of what I am currently doing.  I am currently
> doing this by running NetworkManager in a chroot which uses the new
> /etc path vs the running system and the config files are written
> there.  Once the install is successful, the chroot /etc path is setup
> as the new official path on reboot.  The issue is that running
> NetworkManager in the chroot requires stopping the NetworkManager for
> the running system and then using nmcli the new profiles are created. 
> This results in those changes taking effect immediately and stay until
> I stop NetworkManager in the chroot environment and restart
> NetworkManager in the normal runtime environment.  When those changes
> take effect, I lose connection to my remote update server that is
> tracking the update status.
>  
> Does this write config but don't apply functionality exist?  If not are
> there any other suggestions other than writing my own NetworkManager
> profile config file generator?  I want to avoid writing a config file
> generator as I know over time sometimes newer versions of
> NetworkManager change the connection profile config file format
> slightly.


Hi,


NetworkManager reads profiles from disk only during startup and during
`nmcli connection reload` and `nmcli connection load "${PATHS[@]}"`.
Unless any of these 3 things happen, you can modify the profiles on
disk at will.


Also, if you modify profiles via D-Bus API (which is what nmcli does),
then the configuration only take effect when activating the profile the
next time. I mean, the profile changes immediately, but the current
network configuration does not. That means, even if a profile is
currently activated, you might be able to modify it, without changing
the runtime configuration of the interface yet. However, it's still
tricky because:

- if you delete a profile, then a device currently activate with the
profile must go down.
- if you modify a profile, then it might start to autoactivate right
away. You can avoid that by setting the profile to not autoconnect
(`connection.autoconnect=no`), or using Update2 D-Bus API ([1]) with
"block-autoconnect" flag. You could also set the device to temporarily
block autoconnect.
- if you modify a profile that is currently active, then the properties
"connection.metered" and "connection.zone" take effect immediately,
unless you specify "no-reapply" flag for Update2 ([1]).

[1] 
https://networkmanager.dev/docs/api/latest/gdbus-org.freedesktop.NetworkManager.Settings.Connection.html#gdbus-method-org-freedesktop-NetworkManager-Settings-Connection.Update2


Profiles are in keyfile format, the API for handling them is exposed in
libnm. See the example ([2]). That is relatively convenient, provided
that you also use libnm's NMConnection and NMSetting types to construct
the profile in the first place. After all, parsing a keyfile begs the
question: to what? And the answer is "NMConnection" and it's only
useful if your tool operates in terms of NMConnection.

[2] 
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/7a39f1f7e7ee6d3d409523957e889bd8a940d414/examples/python/gi/nm-keyfile.py

You can also generate the files yourself.It should not be too hard. You
can also use glib's GKeyFile API ([3]) which is the lower layer here.
In general, I wouldn't be too concerned that the file you write today
won't be accepted by NetworkManager tomorrow. This is NetworkManager's
native file format, so it MUST be stable. It would be a bug, if
behavior changes. Of course, if you do something unusual and behavior
changes, then we might only notice the regression after it already
happened. Avoid that, by not doing something other than nmcli does.
That is, I would anyway suggest to use nmcli to modify the profile and
check what it does, and the mimik the result. Also check `man nm-
settings` and `man nm-settings-keyfile`.

[3] https://developer-old.gnome.org/glib/stable/glib-Key-value-file-parser.html


It would be a nice feature if nmcli could directly write keyfiles to disk or stdout
([4]). Patch welcome.

[4] https://bugzilla.redhat.com/show_bug.cgi?id=1361145


best,
Thomas