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

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


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 "" take effect immediately,
unless you specify "no-reapply" flag for Update2 ([1]).


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.


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`.


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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]