This makes package updates more robust, avoiding in-place replaces of
the plugins.
Previously, if an upgrade transaction was terminated, NetworkManager
library could end up being of a different version than the plugins.
If the user was unfortunate enough to connect using a connection that
required a plugin (say, Wi-Fi), he would be left without a network
connection making it somewhat inconvenient to recover from the botched
upgrade.
This makes the whole situation a little bit less sad.
The VPN plugins are kept where they always have been -- the path is not
qualified with a version number.
With autotools, we use libtool so that the right libraries are
automatically found. Still, we won't find the right GI typelib.
Add a mechanism so that when make/meson invokes the run-nm-test.sh
runner, it passes the build-root directory.
Also, try to autodetect when invoked manually.
This makes package updates more robust, avoiding in-place replaces of
the plugins.
Previously, if an upgrade transaction was terminated, NetworkManager
library could end up being of a different version than the plugins.
If the user was unfortunate enough to connect using a connection that
required a plugin (say, Wi-Fi), he would be left without a network
connection making it somewhat inconvenient to recover from the botched
upgrade.
This makes the whole situation a little bit less sad.
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.
We already do conditional build with "#if WITH_CONCHECK".
Get rid of the conditional in the makefile and instead do
conditional compilating inside the source file "nm-connectivity.c".
The advantage is, now if you want to know which parts are build,
you only need to grep for the WITH_CONCHECK preprocessor define
instead of also caring about the conditional in Makefile.am and
meson.build.
It doesn't change the fact of conditional compilation. But it
consistently uses one mechanism to achieve it.
From libnl3, we only used the helper function to parse/generate netlink
messages and the socket functions to send/receive messages. We don't
need an external dependency to do that, it is simple enough.
Drop the libnl3 dependency, and replace all missing code by directly
copying it from libnl3 sources. At this point, I mostly tried to
import the required bits to make it working with few modifications.
Note that this increases the binary size of NetworkManager by 4736 bytes
for contrib/rpm build on x86_64. In the future, we can simplify the code
further.
A few modifications from libnl3 are:
- netlink errors NLE_* are now in the domain or regular errno.
The distinction of having to bother with two kinds of error
number domains was annoying.
- parts of the callback handling is copied partially and unused parts
are dropped. Especially, the verbose/debug handlers are not used.
In following commits, the callback handling will be significantly
simplified.
- the complex handling of seleting ports was simplified. We now always
let kernel choose the right port automatically.
clang 5.0.1 complains:
src/systemd/src/libsystemd-network/dhcp6-option.c:40:28: error:
field 'option' with variable sized type 'struct DHCP6Option' not at
the end of a struct or class is a GNU extension
[-Werror,-Wgnu-variable-sized-type-not-at-end]
struct DHCP6Option option;
^
systemd disables this warning too.
Make it possible to add compiler options to a different variable than
CFLAGS. This is useful to conditionally disable a compiler warning for a
subpart of a tree.
The address sanitizer is not compatible [1] with libraries dynamically
opened using RTLD_DEEPBIND: disable the flag when building with asan.
[1] https://github.com/google/sanitizers/issues/611
Shared libraries built with sanitizers are a bit inconvenient to use
because they require that any application linking to them is run with
libasan preloaded using LD_PRELOAD. This limitation makes the
sanitizer support less useful because applications will refuse to
start unless there is a special environment variable set.
Let's turn the --enable-address-sanitizer configure flag into
--with-address-sanitizer=yes|no|exec so that is possible to enable
asan only for executables.
autotools' AC_LANG_PROGRAM() generates a main() function which triggers
a compiler warning (for which we fail with -WError).
conftest.c:92:1: error: function declaration isn't a prototype [-Werror=strict-prototypes]
main ()
^~~~
cc1: all warnings being treated as errors
Fixes: 557d83bf2d
XXX was used to either raise attention (NOTE) or to indicate
that this is ugly code that should be fixed (FIXME). The usage
was inconsistent.
Let's avoid XXX and use either NOTE or FIXME.
The check doesn't seem useful, because it does not result in a fallback
or a different build.
Just assume <linux/wireless.h> is valid. In case it is not, we will get a
build failure later. That is just as good.
The check doesn't seem useful, because it does not result in a fallback
or a different build.
Just assume <linux/nl80211.h> is valid. In case it is not, we will get a
build failure later. That is just as good.
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.
Many of the configured directories default to being defined using existing
directory configuration. As a result you usually don't see the actual
directories that will be used. With the added directories you can at least
assemble the information and thus see which directories will be used.
We don't have a complete list of distributions that use ifcfg for network
configuration but we can easily check for `/etc/sysconfig/network-scripts`
and then distributions can explicitly disable the plugin of that is what
they want.
[thaller@redhat.com: cherry-picked and adjusted for rebase from
https://github.com/NetworkManager/NetworkManager/pull/49]
In future we should probably either switch to `/etc/os-release` or just
check for `/etc/sysconfig` or something like that.
[thaller@redhat.com: cherry-picked and adjusted for rebase from
https://github.com/NetworkManager/NetworkManager/pull/49]
Even Gentoo disables this plugin since before 0.9.8 release
of NetworkManager. Time to say goodbye.
If somebody happens to show up to maintain it, we may resurrect it
later.
If "$distro_plugins=ifnet" was set, configure.ac would use that
to autodetect --with-hostname-persist=gentoo. Replace that autodetect
part by checking for /etc/gentoo-release file.
The option is deprecated together with the ifcfg-suse settings plugin.
Selecting the plugin has no effect at runtime, beside logging a warning.
Drop the configure option.
Note, that if $distro_plugins was set to "ifcfg-suse", it was also used to
autodetect --with-hostname-persist=suse. Now, autodetect the hostname
persist mode based on presence of /etc/SuSE-release file.
This is very similar to NMDeviceWifi but simplified to remove the things
currently unsupported and with calls to nm_platform_wifi_* and
nm_supplicant_* replaced with IWD DBus API calls. Only unsecured
infrastructure-mode networks are supported here.
[bgalvani@redhat.com: fix compilation error after rebase for
NMActRequestGetSecretsCallId]
[thaller@redhat.com: don't use _() macro strings server side.
Translating strings only makes sense for clients that set environment
variables accordingly.]
Also, don't add the CFLAGS for libjansson to dflt_cppflags_libnm_core.
dflt_cppflags_libnm_core is used also by core and libnm. But those
components do not (directly) link against libjansson. The cannot use
these flags.
I don't think we should do this.
- renamining/dropping configure options is still an annoyance,
because it requires to different ./configure options depending
on the version. The rename from --enable-teamctl to --enable-team
might be theoretically nice, but more annoying then helpful.
- There is no strict dependency between --enable-team and
--enable-json-validation. At most, one could argue that
when enabling the team plugin (--enable-teamctl), then
libnm must also be build with --enable-json-validation.
But in fact, the team plugin will happily work with a
libnm that doesn't link against libjansson.
That is --enable-teamctl --disable-json-validation will work
in practice just fine.
On the other hand, libnm is a client library to create connection
profiles, fully supporting team profiles also makes sense if the
actual plugin is not installed (or build). Thus, --disable-teamctl
--enable-json-validation certainly makes sense.
At this point, one might ask whether libnm is even still complete without
libjansson. Maybe libnm should *require* --enable-json-validation.
But that is not what the patch was doing, and it would also need
some careful consideration before doing so.
This reverts commit 9d5cd7eae8.
Rename the team functionality enablement from 'teamdctl' to 'team'.
Force jansson lib requirement for team functionality: NetworkManager
requires the teamd daemon to manage team. As teamd depends upon jansson
lib, adding jansson requirement for teaming support in NetworkManager
seems reasonable.
Remove the jansson_validation flag, as the only generic json function in
nmcli (not related to team) was the one to check if a string was in json
format. Anyway, that function is used for team checks only. So, move
also json validation functions under the WITH_TEAM flag.
Currently there are multiple features that require Jansson support,
but WITH_JANSSON=1 is set only when configuring with
--enable-json-validation. Therefore a build with
"--disable-json-validation --enable-ovs" fails.
The availability of Jansson (WITH_JANSSON) should only be used:
- to check if dependent features can be enabled
- to determine compiler and linker flags in the Makefile
- in nm-jansson.h to define compatibility functions if needed
Everything else must be controlled by a configure switch.
https://bugzilla.gnome.org/show_bug.cgi?id=790233
After 1.10.0 is released, merge it back into master so that
1.10.0 is part of the history of master. That means,
$ git log --first-parent master
will also traverse 1.10.0 and 1.10-rc*.
Also bump the micro version to 1.11.1-dev to indicate that this is
after 1.10.0 is out.
There is still a fallback detection in "shared/nm-utils/nm-macros-internal.h",
so that VPN-plugins and applet don't need to bother about adding these
configure checks.
Register empty "NMClient" and "NetworkManager" GIR modules as soon as libnm is
loaded witch gnome-introspection. This prevents the real modules from being
loaded because they would in turn load libnm-glib and abort() and crash.
In particular this prevents the GNOME shell from crashing with
libnm-glib abort and allows gracefully disabling the extensions which
use the obsolete library.
Test:
$ cat test.js
const NM = imports.gi.NM;
print (NM.SecretAgentGetSecretsFlags.ALLOW_INTERACTION);
const NMClient = imports.gi.NMClient;
print (NMClient.SecretAgentGetSecretsFlags.ALLOW_INTERACTION);
Before:
$ gjs test.js
1
(gjs:16253): libnm-util-ERROR **: libnm symbols detected; Mixing libnm with libnm-util/libnm-glib is not supported
Trace/breakpoint trap (core dumped)
$
After:
$ gjs test.js
1
Gjs-Message: JS WARNING: [test.js 5]: reference to undefined property "SecretAgentGetSecretsFlags"
(gjs:16228): Gjs-WARNING **: JS ERROR: TypeError: NMClient.SecretAgentGetSecretsFlags is undefined
@test.js:5:1
JS_EvaluateScript() failed
When building with -flto, we need to use linker plugins.
In case of binutils' nm, it means to prefer gcc-nm if
available.
Like for ranlib and ar, prefer gcc-nm.
- replace AC_PATH_TOOL() by AC_CHECK_TOOLS(). That is consistent
with what we do for ar,ranlib and suggested on bgo#783311.
- instead of using the variable $BINUTILS_NM, replace it by
$NM, which is more common according to bgo#783311.
- Keep recognizing $BINUTILS_NM environment, which was introduced
by commit 8bc88bcc7c. This is purely to keep previous build
scripts working. Originally I named it "$BINUTILS_NM" because
using $NM in NetworkManager seemed confusing. But well...
https://bugs.gentoo.org/show_bug.cgi?id=620052https://bugzilla.gnome.org/show_bug.cgi?id=782525https://bugzilla.gnome.org/show_bug.cgi?id=783311
