Add support for creating dummy devices. This commit adds a D-Bus
interface 'org.freedesktop.NetworkManager.Device.Dummy' which is used
primarily for determining the device type but does not carry any
properties.
The new NMSettingMacsec contains information necessary to establish a
MACsec connection. At the moment we support two different MACsec
modes, both using wpa_supplicant: PSK and EAP.
PSK mode is based on a static CAK key for the MACsec key agreement
protocol, while EAP mode derives keys from a 802.1x authentication and
thus requires the presence of a NMSetting8021x in the connection.
This file is only used by plugins and copied between them.
It's purpose is to contain general utility functions that are
only relevant for implementing NetworkManager's VPN plugins.
In principle the utility functions could be part of libnm, however,
there are a few problems with that:
- if they are part of libnm, adding and using a new utility function
requires the plugin to bump the required libnm version. Since you
usally can work around/reimplement utility functions, this results
in not using the API from libnm, not adding the API to libnm,
and reimplementing it over and over in the plugin.
- plugins compile both against libnm and libnm-glib. Thus, either
the utility function would also be needed in libnm-glib, or again,
it is not usable by the plugin.
We must avoid that the utility functions diverge and no local
modifications to these files should be made in the plugin.
Instead, one special location of the utility functions shall be
extended and re-imported (copied) to the plugin as needed.
Add the files to NetworkManager's repository. Although they are not
needed for NetworkManager itself, they are a different API provided
by NetworkManager. An API that is reused and shared by copying the files
around.
The "shared" directory contains files that are possibly used by all components
of NetworkManager repository.
Some of these files are even copied as-is to other projects (VPN plugins, nm-applet)
and used there without modification. Move those files to a separate directory.
By moving them to a common directory, it is clearer that they belong
together. Also, you can easier compare the copied versions to their
original via
$ diff -r ./shared/nm-utils/ /path/to/nm-vpn-plugin/shared/nm-utils/
Let VPN plugins return a virtual function table to extend
the API while bypassing libnm. This allows to add and use
new functionality to VPN plugins without updating libnm.
The actual definitions are in a header-only file
"nm-vpn-editor-plugin-call.h", which can be copied to the
caller/plugin.
Add new Reload D-Bus command to reload NetworkManager configuration.
For now, this is like sending SIGHUP to the process. There are several
advantages here:
- it is guarded via PolicyKit authentication while signals
can only be sent by root.
- the user can wait for the reload to be complete instead of sending
an asynchronous signal. For now, we operation completes after
nm_config_reload() returns, but later we could delay the response
further until specific parts are fully reloaded.
- SIGHUP reloads everything including re-reading configuration from
disk while SIGUSR1 reloads just certain parts such as writing out DNS
configuration anew.
Now, the Reload command has a flags argument which is more granular
in selecting parts which are to be reloaded. For example, via
signals the user can:
1) send SIGUSR1: this writes out the DNS configuration to
resolv.conf and possibly reloads other parts without
re-reading configuration and without restarting the DNS plugin.
2) send SIGHUP: this reloads configuration from disk,
writes out resolv.conf and restarts the DNS plugin.
There is no way, to only restart the DNS plugin without also reloading
everything else.
When performing NM package upgrade the new version of nmcli will be immediately
available while NM daemon will not, as it would not restart in order to avoid
to disrupt connectivity. This could create issues with tools leveraging
on nmcli output (till reboot). As apart from this case it is very unlikely
that a user can have this nmcli / NM daemon version mismatch situation,
the check could cause more harm than benefit in real user case
scenarios.
https://bugzilla.redhat.com/show_bug.cgi?id=1291785
