Previously, the ppp version was only detected (and used) at one place,
in "nm-pppd-compat.c", after including the ppp headers. That was nice
and easy.
However, with that way, we could only detect it after including ppp
headers, and given the ugliness of ppp headers, we only want to include
them in "nm-pppd-compat.c" (and nowhere else).
In particular, 'nm-pppd-compat.c" uses symbols from the ppp daemon, it
thus can only be linked into a ppp plugin, not in NetworkManager core
itself. But at some places we will need to know the ppp version, outside
of the ppp plugin and "nm-pppd-compat.c".
Additionally, detect it at configure time and place it in "config.h".
There is a static assert that we are in agreement with the two ways of
detection.
The "unbound" DNS plugin was very rudimentary and is deprecated since
commit 4a2fe09853 ('man: mark [main].dns=unbound as deprecated') (Jun
2021).
It is part of dnssec-trigger tool, but the dnssec-trigger tool doesn't
actually use it. Instead it installs a dispatcher script
"/usr/lib/NetworkManager/dispatcher.d/01-dnssec-trigger".
Especially, since the plugin requires "/usr/libexec/dnssec-trigger-script",
which is provided by "dnssec-trigger" package on Fedora. At the same
time, the package provides the dispatcher script. So I don't this works
or anybody is using this.
https://mail.gnome.org/archives/networkmanager-list/2022-April/msg00002.html
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
After this change the nmcli program built with meson will have the
possibility to use libedit (BSD license) instead of libreadline
(GPLv3).
Meson configuration line:
meson configure -Dreadline=libedit -C ../nm-build/
or
meson --reconfigure -Dreadline=libedit ../nm-build/
ninja -C ../nm-build/
The new 'readline' option is set to 'auto' by default, so
the current behavior shall be preserved (and the libreadline is
used).
Two new config.h flags (always defined) have been introduced -
HAVE_EDITLINE_READLINE and HAVE_READLINE_HISTORY.
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".
(cherry picked from commit 801c41a11c)
We anyway load libjansson with dlopen(), and already before it could
happen that libjansson is not available. In that case, we would not
crash, but simply proceed without json validation.
Since libnm-core no longer uses libjansson directly, but only via
"nm-glib-aux/nm-json.h", we can just always compile with that, and use
it at runtime. That means, libjansson is not a build dependency for
libnm anymore, so we don't need a compile time check.
Note that if you build without libjansson, then JANSSON_SONAME is
undefined, and loading it will still fail at runtime. So, even if
we now always build with all our code enabled, it only works if you
actually build with libjansson. Still, it's simpler to drop the
conditional build, as the only benefit is a (minimally) smaller
build.
Install a NM-specific firewalld zone to be used for interfaces that
are used for connection sharing. The zone blocks all traffic to the
local machine except some protocols (DHCP, DNS and ICMP) and allows
all forwarded traffic.
The functionality of the ibft settings plugin is now handled by
nm-initrd-generator. There is no need for it anymore, drop it.
Note that ibft called iscsiadm, which requires CAP_SYS_ADMIN to work
([1]). We really want to drop this capability, so the current solution
of a settings plugin (as it is implemented) is wrong. The solution
instead is nm-initrd-generator.
Also, on Fedora the ibft was disabled and probably on most other
distributions as well. This was only used on RHEL.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1371201#c7
This removes libnm-glib, libnm-glib-vpn, and libnm-util for good.
The it has been replaced with libnm since NetworkManager 1.0, disabled
by default since 1.12 and no up-to-date distributions ship it for years
now.
Removing the libraries allows us to:
* Remove the horrible hacks that were in place to deal with accidental use
of both the new and old library in a single process.
* Relief the translators of maintenance burden of similar yet different
strings.
* Get rid of known bad code without chances of ever getting fixed
(libnm-glib/nm-object.c and libnm-glib/nm-object-cache.c)
* Generally lower the footprint of the releases and our workspace
If there are some really really legacy users; they can just build
libnm-glib and friends from the NetworkManager-1.16 distribution. The
D-Bus API is stable and old libnm-glib will keep working forever.
https://github.com/NetworkManager/NetworkManager/pull/308
This removes libnm-glib, libnm-glib-vpn, and libnm-util for good.
The it has been replaced with libnm since NetworkManager 1.0, disabled
by default since 1.12 and no up-to-date distributions ship it for years
now.
Removing the libraries allows us to:
* Remove the horrible hacks that were in place to deal with accidental use
of both the new and old library in a single process.
* Relief the translators of maintenance burden of similar yet different
strings.
* Get rid of known bad code without chances of ever getting fixed
(libnm-glib/nm-object.c and libnm-glib/nm-object-cache.c)
* Generally lower the footprint of the releases and our workspace
If there are some really really legacy users; they can just build
libnm-glib and friends from the NetworkManager-1.16 distribution. The
D-Bus API is stable and old libnm-glib will keep working forever.
https://github.com/NetworkManager/NetworkManager/pull/308
dhcpcd version 6, the first supporting IPv6, was released more than 5
years ago. Remove all checks on version number and IPv6 support.
(cherry picked from commit e0c49d7341)
At other places, we already use __BYTE_ORDER define to detect endianness.
We don't need multiple mechanisms.
Also note that meson did not do the correct thing as AC_C_BIGENDIAN,
so meson + nss + big-endian was possibly broken.
- always define the SESSION_TRACKING_* defines to replace
"#ifdef" with "#if".
- drop defining the consolekit database path CKDB_PATH in
config.h. The path was not customizable via configure/meson.
- fix meson build to enable consolekit support for session tracking
without also enabling logind/elogind session tracking.
logind/elogind is mutually exclusive, but consolekit session tracking
goes together just fine.
Supporting PolicyKit required no additional library, just extra code
to handle the D-Bus calls. For that, there was a compile time option
to even stip out that code. Note, that you could (and still can)
configure the system not to use policy-kit. The point was to reduce
the binary size in case you don't need it.
Remove this. I guess, we we aim for such aggressive optimization of
the binary size, we should instead make all device types disablable
at configuration time. We don't do that either and other low hanging
fruits, because it's better to always enable features, unless they
require external dependencies.
Also, the next commit will make more use of NMAuthManager. So, having
it disabled at compile time, makes even less sense.
netlink's API is stable, and strictly defined by the integer values that make
up commands and attributes. There is little reason do disable a netlink feature
based on compile time detection of the kernel headers.
Either kernel supports it, or it will fail with an appropriate response.
Also, support for NL80211_CMD_CRIT_PROTOCOL_START was merge to kernel
in 2013. Maybe, we should now just always assume support (in the kernel
headers is there). Anyway, don't do that yet, but instead avoid the
defines and use the numeric values directly.
