Previously, when compiling NetworkManager with libaudit support, it
was disabled by default and only used after setting logging.audit=true.
Turn that around. If we compile NetworkManager with audit support, we also
enable it by default. The user can then explicitly disable it by
configuring logging.audit in NetworkManager.conf.
But also, add a configure option 'yes-disabled-by-default' to compile
with audit support, but have it disabled by default. This would be the
previous behavior, but it must be enabled explicitly.
Fixes: be49a59fb6
Introduce some primitives to deliver messages about relevant
configuration changes to the Linux audit subsystem through libaudit
(if enabled at build time) and to the logging system.
The PKG_CHECK_MODULES macro shipped with modern versions (at least
0.24) of pkg-config already calls AC_SUBST to generate ${PKG}_CFLAGS
and ${PKG}_LIBS variables in Makefiles.
Remove the unneeded occurrences of AC_SUBST after PKG_CHECK_MODULES in
configure.ac; this should be safe because we are already assuming that
pkg-config version is recent enough in some other places.
Rather than randomly including one or more of <glib.h>,
<glib-object.h>, and <gio/gio.h> everywhere (and forgetting to include
"nm-glib-compat.h" most of the time), rename nm-glib-compat.h to
nm-glib.h, include <gio/gio.h> from there, and then change all .c
files in NM to include "nm-glib.h" rather than including the glib
headers directly.
(Public headers files still have to include the real glib headers,
since nm-glib.h isn't installed...)
Also, remove glib includes from header files that are already
including a base object header file (which must itself already include
the glib headers).
Originally, ibft settings were handled by "ifcfg-rh" plugin. Later, we added
a separate "ibft" plugin and moved the functionality there.
The problem was that users quite possibly had a configuration like
[main]
plugins=ifcfg-rh
in their "NetworkManager.conf". That meant, after upgrade users would
no longer have ibft support.
We fixed that by installing "/etc/NetworkManager/conf.d/10-ibft-plugin.conf"
which was read after the main file and contained:
[main]
plugins+=ibft
We no longer want to install configuration snippets with our core packages to
/etc. Avoid the regression by changing the meaning of "ifcfg-rh". By enabling
"ifcfg-rh" you now implicitly enable "ibft" plugin as well. This can be
turned off via "no-ibft". And you can continue to enable "ibft" plugin
alone.
The 'example' settings plugin is (obviously) unused, but it is also
badly maintained and no longer best-practice in several ways:
- it directly reads "NetworkManager.conf" instead of using NMConfig.
- it parses device specs itself, instead of using
nm_match_spec_split().
- read_connections() doesn't ensure that loading a file
does not replace a previously loaded one (due to conflicting
UUID). In general the example doesn't show/handle the complexity
of potential UUID conflicts.
Instead of fixing these issues it is better to ensure our main plugin
('keyfile') corresponds to current best practices. Should we ever add a
new pluginww, 'keyfile' should be the example.
After the hostname functionality has been moved from plugins to core,
the ifcfg-suse plugin contains only boilerplate code with no actual
functionality.
Remove the plugin, mark it as deprecated in manual page and print a
warning when it is selected in configuration file.
How to write and read the machine hostname is something that has been
handled until now by plugins; this is questionable since the method
using for storing the hostname should depend only on the distro used
and not on which plugins are enabled.
This commit moves all hostname-related functions from plugins to the
core and allows to specify the method used to load and store the
hostname at build time with the
--with-hostname-persist=default|suse|gentoo
configure option.
'default' method stores the hostname to /etc/hostname and monitors it
to detect runtime changes.
When the selected method is 'suse', the hostname gets read from and
written to /etc/HOSTNAME; the file /etc/sysconfig/network/dhcp is also
read to detect if the hostname is dynamic and thus invalid. Both files
are monitored for changes.
'gentoo' method relies on /etc/conf.d/hostname for storing the
hostname.
This reverts commit 7daf63461de4195b1626ca15f835fc7cbc56e847.
Turns out the removal of the second set of [] in configure.ac causes the command
to be wrong in 'configure' and the test to be incorrect.
We switched to user-mode PPPoE client to work around a bug in kernel
PPPoE code that caused pppd not to be notified when the connection was
terminated with a PADT before the LCP Termination Request.
The kernel bug has now been fixed upstream with commit 287f3a943fef
"pppoe: Use workqueue to die properly when a PADT is received", queued
for v4.1.
Since the issue affected only very particular scenarios and could
somehow be solved with the right configuration (see bugzilla entry),
we can safely revert the patch and restore the use of kernel mode
PPPoE.
This reverts commit 7955806a02.
https://bugzilla.gnome.org/show_bug.cgi?id=742939
Add a new 'rc-manager' configuration parameter that allows to select
the strategy used to write resolv.conf; currently supported values
are: none|resolvconf|netconfig, 'none' meaning that NM directly writes
the file.
The default value of the parameter is 'none'; however if a
RESOLVCONF_PATH (or NETCONFIG_PATH) is specified at build time, the
default value will be 'resolvconf' (or 'netconfig').
Even Fedora is no longer shipping the WiMAX SDK, so it's likely we'll
eventually accidentally break some of the code in src/devices/wimax/
(if we haven't already). Discussion on the list showed a consensus for
dropping support for WiMAX.
So, remove the SDK checks from configure.ac, remove the WiMAX device
plugin and associated manager support, and deprecate all the APIs.
For compatibility reasons, it is still possible to create and save
WiMAX connections, to toggle the software WiMAX rfkill state, and to
change the "WIMAX" log level, although none of these have any effect,
since no NMDeviceWimax will ever be created.
nmcli was only compiling in support for most WiMAX operations when NM
as a whole was built with WiMAX support, so that code has been removed
now as well. (It is still possible to use nmcli to create and edit
WiMAX connections, but those connections will never be activatable.)
NM core uses nm-logging which is entirely configurable at runtime.
Other components use glib-logging, which can also be partly configured
via G_MESSAGES_DEBUG.
It makes sense to have a compile time option to enable some
logging statements that are only useful for heavy debugging.
For glib-logging, this is a way to enable/disable extra logging.
For nm-logging, we could alternatively configure a least log-level
that is enabled at compile time (that way, we could configure to prune all
LOGL_TRACE logging). While that might be useful (too), this gives
an alternative way to disable/enable logging.
Add a configure option --enable-more-logging and a NM_MORE_LOGGING define
for that.
If we don't find this useful after a while, we can simply remove it,
because our logging statements are not part of a "stable" behavior.
NM already has two kinds of assertions:
- g_assert*(), conditionally compiled via #ifndef G_DISABLE_ASSERT
- g_return*(), conditionally compiled via #ifndef G_DISABLE_CHECKS
In theory, one should be able to disable both asserts and NM should
still work correctly (and possibly more efficient). In practice,
hardly anybody is testing such a configuration and it might be broken.
Especially, we don't disable asserts for production builds, both because
of less test coverage and because it might reduce our ability to debug.
Add a new configure option --enable-more-asserts, which defines
NM_MORE_ASSERTS and nm_assert(). This is for expensive asserts,
that -- contrary to the asserts above -- are disabled by default.
This is useful for extended debugging.
The previous change turned out to be wrong despite it was nothing more
than a reversion of the respective lines.
Acked-By: Thomas Haller <thaller@redhat.com>
First, configure.ac's grep was wrong and wasn't setting DHCPCD_SUPPORTS_IPV6,
which caused dhcpcd to acquire a DHCPv6 address when NM didn't think that
was going to happen, and thus DHCP options couldn't be parsed.
Second, even if that does happen, don't just assert and quit, but set the
DHCP state to failed.
https://bugzilla.gnome.org/show_bug.cgi?id=743700
Before, the Wi-Fi plugin was always build. Users who didn't want
to use it would simply drop "libnm-device-plugin-wifi.so".
Add a compile time option to disable needlessly building the plugin.
https://bugzilla.gnome.org/show_bug.cgi?id=743388
When specifying '--enable-lto=anything' or '--disable-lto',
the configure script would always set enable_lto=yes.
The only way to disable lto, was *not* specifying the
configure option.
https://bugzilla.gnome.org/show_bug.cgi?id=742575
The main motivation for this change is to be able to build configure
command lines that will work for both old and new versions of
NetworkManager.
Acked-By: Thomas Haller <thaller@redhat.com>
Merged all session tracking modules into one source file and simplified
it substantially. Now systemd-logind and ConsoleKit support can be built
in at the same time and both are detected at runtime. This is useful on
source based as well as binary distributions.
Original patch written by Fabio Erculiani <lxnay@sabayon.org>, modified
by Pavel Šimerda <psimerda@redhat.com> and Thomas Haller <thaller@redhat.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=686997
Acked-By: Thomas Haller <thaller@redhat.com>
In the 'configure.ac' script we already detect the git commit id
for the current source version. When creating a tarball, it is also
included inside the generated 'configure' script.
Add the commit id as a static string to nm-utils.c. That way, having
a build of libnm.so or NetworkManager, you can quickly find the
corresponding git commit:
strings src/NetworkManager | grep NM_GIT_SHA
Note that this only works after a new `autogen.sh` run. Only rebuilding
is not enough. Hence, you must rebuild all to ensure that the correct
commit id is embedded.
https://bugzilla.gnome.org/show_bug.cgi?id=741651
Takes about 3x as long to build with gcc 4.8, but gcc 4.9
is supposed to speed that up considerably.
Name Before After Saved
-------------------------------------
NetworkManager 1734744 1689728 3%
libnm 1263536 808816 36%
nm-iface-helper 931136 906496 3%
libnm-util 441264 437168 1%
libnm-glib 297064 292960 2%
https://bugzilla.gnome.org/show_bug.cgi?id=741140
docs/api/settings-spec.xml was accidentally not getting disted,
because gtk-doc.make explicitly removes all DISTCLEANFILES from
distdir. However, it doesn't actually make sense for the settings docs
files to be in DISTCLEANFILES anyway; they were put there rather than
CLEANFILES (IIRC) so that "make clean" in a tarball build wouldn't
delete them and break things. But the right fix is to just make them
only be in CLEANFILES when BUILD_SETTING_DOCS is true, and not ever
get deleted otherwise.
Also adjust the build rules to ensure that the generated docs don't
get rebuilt in tarball builds, since that can cause problems when
building from a read-only source tree, etc.
Meanwhile, in an unrelated but also fatal bug, configure.ac's check
for if the generated docs were already present never got updated for
the cli/src -> clients/cli move, and so even if we had been disting
settings-spec.xml, configure would still think that the tarball didn't
have all of the generated docs in it, so SETTING_DOCS_AVAILABLE would
be set false and none of the generated docs would get used.
https://bugzilla.gnome.org/show_bug.cgi?id=740035
make[5]: Entering directory `./NetworkManager/_build/src/devices/bluetooth'
CC nm-bluez-device.lo
../../../../src/devices/bluetooth/nm-bluez-device.c: In function 'nm_bluez_device_disconnect':
../../../../src/devices/bluetooth/nm-bluez-device.c:430:5: error: "WITH_BLUEZ5_DUN" is not defined [-Werror=undef]
#if WITH_BLUEZ5_DUN
Fixes: f1c9595311
Fixes: 751b52e50b
Signed-off-by: Thomas Haller <thaller@redhat.com>
