The main reason to introduce the "no-wait.d" dispatcher directory was
"10-ifcfg-rh-routes.sh", which (as a pre-up script) delays activation.
We even extracted the script to a separate package on RHEL to avoid
delays by default.
Invoke the script via no-wait.d.
NetworkManager-devel package contained development headers that
are useful without libnm-glib and without glib. But it is also
based on the legacy libnm-glib library as it has headers like
"/usr/include/NetworkManager/NetworkManager.h".
A glib-free devel package based on the new libnm library would
be needed to provide "/usr/include/libnm/nm-dbus-interface.h".
But that would amount to 4 devel packages. Instead, just move
the content of NetworkManager-devel into NetworkManager-glib-devel
package.
Note that NetworkManager-devel already contained several truely
libnm-glib dependent files, like the vala bindings (which require
libnm-glib). So that was another bug in the packaging and is fixed
by moving it all to NetworkManager-glib-devel.
https://bugzilla.gnome.org/show_bug.cgi?id=755938
For libnm library, "nm-dbus-interface.h" contains defines like the D-Bus
paths of NetworkManager. It is desirable to have this header usable without
having a dependency on "glib.h", for example for a QT application. For that,
commit c0852964a8 removed that dependancy.
For libnm-glib library, the analog to "nm-dbus-interface.h" is
"NetworkManager.h", and the same applies there. Commit
159e827a72 removed that include.
However, that broke build on PackageKit [1] which expected to get the
version macros by including "NetworkManager.h". So at least for libnm-glib,
we need to preserve old behavior so that a user including
"NetworkManager.h" gets the version macros, but not "glib.h".
Extract the version macros to a new header file "nm-version-macros.h".
This header doesn't include "glib.h" and can be included from
"NetworkManager.h". This gives as previous behavior and a glib-free
include.
For libnm we still don't include "nm-version-macros.h" to "nm-dbus-interface.h".
Very few users will actually need the version macros, but not using
libnm.
Users that use libnm, should just include (libnm's) "NetworkManager.h" to
get all headers.
As a special case, a user who doesn't want to use glib/libnm, but still
needs both "nm-dbus-interface.h" and "nm-version-macros.h", can include
them both separately.
[1] https://github.com/hughsie/PackageKit/issues/85
Fixes: 4545a7fe96
Without that DATADIRNAME was not present in po/Makefile.in.in
and it resulted in /usr/\@DATADIRNAME\@/locale/cs/LC_MESSAGES/ path instead of
/usr/share/locale/cs/LC_MESSAGES/.
https://bugzilla.redhat.com/show_bug.cgi?id=1265117
When a script is a symbolic link to the 'no-wait.d' subdirectory, the
dispatcher now schedules it immediately and in parallel with other
no-wait scripts.
https://bugzilla.gnome.org/show_bug.cgi?id=746703
The default SELinux policy on current RHEL and Fedora distributions
does not allow for NetworkManager to use audit. Hence, unless the user
changes the SELinux policy it will not work.
Disable auditing by default, but have it compiled so that the user can
enable it via "NetworkManager.conf".
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.
NMVpnPluginInfo is little more then a wrapper around
the GKeyFile that describes the VPN plugin settings,
i.e. the name files under "/etc/NetworkManager/VPN/".
Add this class to make the VPN API more explicit. Clients
now can use NMVpnPluginInfo instead of concerning themselves
with loading the keyfile and the meaning of its properties.
Also add support for a new VPN plugins directory
"/usr/lib/NetworkManager/VPN", which should replace
"/etc/NetworkManager/VPN" in the future. But we have to
consider both locations for backward compatibility.
The content of the VPN directory is not user configuration,
hence it should not be under "/etc". See related bug 738853.
We don't really know which version it's going to be -- and thus if we're going
to actually need it (version 5), or not (version 4). It's going to be decided
at configure time.
Also, drop the bogus Fedora 19 conditionals; Fedora < 20 has ModemManager that's
too old for the WWAN code anyway.
NetworkManager uses wpa_supplicant, which in turn calls OpenSSL for verifying
certificates. wpa_supplicant calls
SSL_CTX_load_verify_locations(ctx, CAfile, CApath)
using its ca_cert and ca_path options as CAfile and CApath parameters.
We have a configure time option with_system_ca_path to override ca_path.
However, it doesn't work when a system (like Fedora) only uses bundled PEM
certificates instead of a directory with hashed certificates ([1], [2]).
So this commit allows setting --with_system_ca_path to a file name (the
trusted certificate bundle). Then the name is used to populate wpa_supplicant's
ca_cert instead of ca_path.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1053882
[2] https://www.happyassassin.net/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/https://bugzilla.redhat.com/show_bug.cgi?id=1236548
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.
Don't move "10-ibft-plugin.conf", because we need it to be
read *after* "NetworkManager.conf". Many users might have
an old "NetworkManager.conf" file that contains "plugin=ifcfg-rh".
This allows packages to install their configuration snippets to
"/usr/", which is a better place for system-provided configuration
files then "/etc".
"/usr/lib/NetworkManager/conf.d/" is read first, so that the values
in /etc have higher priority.
In general, we want to move system-provided configuration away from
/etc, so that a user can do a "factory-reset" by purging /etc.
https://bugzilla.gnome.org/show_bug.cgi?id=738853
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
If a connection has an associated "rule-NAME" or "rule6-NAME" file,
don't try to read in the routes, since NetworkManager won't be able to
parse them correctly. Instead, log a warning that they will need to be
applied via a dispatcher script, and provide a script that would do
that in examples/dispatcher/.
Team was split out between NM 0.9.10 and NM 1.0 after the other
sub-packages, so the existing obsoletes won't work for it (they
would cause all upgrades to install all sub-packages, instead
of replacing existing sub-packages without adding uninstalled
ones). We only want to unconditionally add the team sub-package.
s390 does not enable several device plugins, but ADSL and Wi-Fi
plugins are still build. They must be excluded in the spec file,
otherwise rpmbuild fails.
This partly reverts commit 1f631cd08d.
Checking for unpackaged file(s): /usr/lib/rpm/check-files /builddir/build/BUILDROOT/NetworkManager-1.1.0-11242.9709d009d5.el7.s390x
RPM build errors:
error: Installed (but unpackaged) file(s) found:
/usr/lib64/NetworkManager/libnm-device-plugin-adsl.so
/usr/lib64/NetworkManager/libnm-device-plugin-wifi.so
Installed (but unpackaged) file(s) found:
/usr/lib64/NetworkManager/libnm-device-plugin-adsl.so
/usr/lib64/NetworkManager/libnm-device-plugin-wifi.so
Child returncode was: 1
On s390/s390x we would disable hardware plugins, especially %{with_bluetooth} and
%{with_wwan}. Depending on that we would set 'BuildRequires: ModemManager-glib-devel'.
This was not corresponding to the '--with-modem-manager-1' configure
option, hence we did not have ModemManager-glib-devel, but
'--with-modem-manager-1=yes'
When quitting, the Manager asks each device to spawn the interface helper,
which persists and manages dynamic address on the interface after NetworkManager
is gone. If the dynamic address cannot be maintaned, the helper quits and
the interface's address may be removed when their lifetime runs out.
To keep the helper as simple as possible, NetworkManager passes most of the
configuration on the command-line, including some properties of the device's
current state, which are necessary for the helper to maintain DHCP leases
or IPv6 SLAAC addresses.
This adds service discovery via SDP and RFCOMM tty management to
NetworkManager, as it was dropped from Bluez.
Based on work by Dan Williams <dcbw@redhat.com>.
The SDP discovery is based on code from Bluez project.
This makes NetworkManager independent of <polkit/polkit.h>
development headers and libpolkit-gobject-1.so library.
Instead communicate directly with polkit using its DBUS
interface.
PolicyKit support is now always compiled in. You can control
polkit authorization with the configuration option
[main]
auth-polkit=yes|no
If the configure option is omitted, a build time default
value is used. This default value can be set with the
configure option --enable-polkit.
This commit adds a new class NMAuthManager that reimplements the
relevant DBUS client parts. It takes source code from the polkit
library.
https://bugzilla.gnome.org/show_bug.cgi?id=734146
Signed-off-by: Thomas Haller <thaller@redhat.com>
The module is used for building man pages by generate-plugin-docs.pl script.
1c2174a libnm-util: generate-plugin-docs.pl script for extracting plugin docs
Add libnm to NetworkManager.spec, and try to update the descriptions
of NetworkManager-devel, NetworkManager-glib, and
NetworkManager-glib-devel to make sense in the libnm world...
Create a new clients/ subdirectory at the top level, and move cli/ and
tui/ into it, as well as nm-online.c (which was previously in test/,
which made no sense).
cli/ was split into two subdirectories, src/ and completion/. While
this does simplify things (given that the completion file and the
binary both need to be named "nmcli"), it bloats the source tree, and
we can work around it by just renaming the completion file at install
time. Then we can combine the two directories into one and just have
it all under clients/cli/.
There are three fixes:
1) the config packages shouldn't require the main NetworkManager
package. We explicitly make NetworkManager-glib not
depend on NM itself to ensure that clients can link to it (and thus
have an RPM dependency on -glib) without pulling in NetworkManager
itself. The same should hold true for the config packages, since
consumers of NetworkManager may want to pull them in, but not
necessarily pull NetworkManager in.
For example, GNOME Shell wants to make use of NetworkManager's
connectivity detection *if NM is available*, and this requires
pulling in NM-config-connectivity-fedora, but that shouldn't
pull in NetworkManager itself.
Similarly, we had a problem with RHEL7 making sure that
NM-config-server was installed by default on Server variants but
not on other variants; removing the dependency from the -config
subpackage was the cleanest way to fix that.
Furthermore, nothing in the config sub-packages actually
requires NetworkManager anyway since they are simply config files.
2) nmtui doesn't care what architecture the running NM is since
it communicates solely over D-Bus. So skip the %{?_isa}, just
like we do for other clients (nm-applet, GNOME Shell, etc)
3) Requiring NetworkManager.%{?_isa} from the -devel package
has problems with multilib (see rh #1112367). This is an issue
if you install a 32-bit development environment and try to build
something that uses NetworkManager. Since the -devel package
requires the main package, you can end up either having *both*
NetworkManager.i686 and NetworkManager.x86_64 installed, or you
end up having NetworkManager.i686 replace NetworkManager.x86_64.
Neither one is good. So remove the %{?_isa} bit.
