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 _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list