Currently it is possible to specify a list of default settings plugins
to be used when configuration doesn't contain the main.plugins key.
We want to add a mechanism that allows to automatically load any
plugin found in the plugins directory without needing
configuration. This mechanism is useful when plugins are shipped in a
different, optional subpackage, to automatically use them.
With such mechanism, the actual list of plugins will be determined
(in order of evaluation):
1. via explicit user configuration in /etc, if any
2. via distro configuration in /usr, if any
3. using the build-time default, if any
4. looking for known plugins in /usr/lib
This paragraph that "it's likely that" some changes will be backported
to 1.34 branch seems unnecessary. Whenever we backport things to 1.34
we will add them to the NEWS file for nm-1-34, and then also mention
them in nm-1-36 and newer. But we don't need to announce that.
It seems that the nftables backend works well. Let's change the default.
This will also be backported to nm-1-32 branch, for 1.32.0 release.
This reverts commit 0609f1f31c.
D-Bus 1.3.1 (2010) introduced the standard "PropertiesChanged" signal
on "org.freedesktop.DBus.Properties". NetworkManager is old, and predates
this API. From that time, it still had it's own PropertiesChanged signal
that are emitted together with the standard ones. NetworkManager
supports the standard PropertiesChanged signal since it switched to
gdbus library in version 1.2.0 (2016).
These own signals are deprecated for a long time already ([1], 2016), and
are hopefully not used by anybody anymore. libnm-glib was using them and
relied on them, but that library is gone. libnm does not use them and neither
does plasma-nm.
Hopefully no users are left that are affected by this API break.
[1] 6fb917178a
For NetworkManager profiles, "connection.uuid" is the identifier of the
profile. It is supposed to be a UUID, however:
- the UUID was not ensured to be all-lower case. We should make sure
that our UUIDs are in a consistent manner, so that users can rely
on the format of the string.
- the UUID was never actually interpreted as a UUID. It only was some
opaque string, that we use as identifier. We had nm_utils_is_uuid()
which checks that the format is valid, however that did not fully
validate the format, like it would accept "----7daf444dd78741a59e1ef1b3c8b1c0e8"
and "549fac10a25f4bcc912d1ae688c2b4987daf444d" (40 hex characters).
Both invalid UUIDs and non-normalized UUID should be normalized. We
don't want to break existing profiles that use such UUIDs, thus we don't
outright reject them. Let's instead mangle them during
nm_connection_normalize().
Property aliases should really just be shortcuts for one fully spelled
out property (sometimes, they do more like "master").
Anyway, we must also handle resetting the value, otherwise:
$ nmcli connection add type gsm apn ""
will still result in "gsm.apn=internet", unlike
$ nmcli connection add type gsm gsm.apn ""
Add new configure option to set the path to "polkit-agent-helper-1".
The path cannot be obtained from pkg-config and `pkg-config
--variable=prefix polkit-agent-1` is not good enough.
On Fedora, the path is "/usr/lib/polkit-1/polkit-agent-helper-1".
On Debian Buster, the path is "/usr/lib/policykit-1/polkit-agent-helper-1"
On Debian Sid, the path is "/usr/libexec/polkit-agent-helper-1" (but
currently it is also symlinked from "/usr/lib/policykit-1/polkit-agent-helper-1".
This locks NM into dhcpcd-9.3.3 as that is the first version to support
the --noconfigure option. Older versions are no longer supported by NM
because they do modify the host which is undesirable.
Due to the way dhcpcd-9 uses privilege separation and that it re-parents
itself to PID 1, the main process cannot be reaped or waited for.
So we rely on dhcpcd correctly cleaning up after itself.
A new function nm_dhcp_client_stop_watch_child() has been added
so that dhcpcd can perform similar cleanup to the equivalent stop call.
As part of this change, the STOP and STOPPED reasons are mapped to
NM_DHCP_STATE_DONE and PREINIT is mapped to a new state NM_DHCP_STATE_NOOP
which means NM should just ignore this state.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/668
