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
"NONE" was wrongly part of @domain_descs and thus advertised
via `NetworkManager --help`. But since its @num was set to
LOGD_NONE (zero), it was already rejected by nm_logging_setup().
The only way to disable logging for a domain entirely is to
omit the domain from the "domains" list. For example:
"level=INFO, domains=PLATFORM,..."
Now add an explicit level "OFF" to facilitate configuration like:
"level=INFO, domains=ALL,WIFI_SCAN:OFF"
It also supports
"level=OFF, domains=PLATFORM:INFO"
but this is for the most part equivalent to
"level=INFO, domains=PLATFORM"
Log all the relevant changes to system configuration and state to the
Linux audit subsystem through libaudit (if enabled at build time) and
to the logging system.
https://bugzilla.gnome.org/show_bug.cgi?id=749364
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.
Future patches will create devices long before they are backed by
kernel resources, so we need to split NMDevice object creation from
actual setup based on the backing resources.
This patch combines the NMDeviceFactory's new_link() and
create_virtual_device_for_connection() class methods into a single
create_device() method that simply creates an unrealized NMDevice
object; this method is not expected to fail unless the device is
supposed to be ignored. This also means that the NMDevice
'platform-device' property is removed, because a platform link
object may not be available at NMDevice object creation time.
After the device is created, it is then "realized" at some later
time from a platform link (for existing/hardware devices via the
realize() method) or from an NMConnection (for newly created software
devices via the create_and_realize() NMDeviceClass methods).
https://bugzilla.gnome.org/show_bug.cgi?id=737458
Let NMSecretAgent emit the 'disconnected' event when dbus_owner is
still valid so that receivers of the signal can query it. This fixes
the following failed assertion:
remove_agent: assertion 'owner != NULL' failed
Fixes: 2a2fd1216b
- add new NMVpnPluginInfo class with new API to load
VPN name files.
- move NMVpnEditorPlugin to libnm-core, including code
to load the client plugin from the shared library.
- deprecate NMVpnPluginOld and add NMVpnServicePlugin.
The latter is identical to NMVpnPluginOld but renamed
and introduced as new API for 1.2.
https://bugzilla.gnome.org/show_bug.cgi?id=749877
In hindsight, the NMVpnPluginOld should never have made public for
nm-1-0 as there are no users and we don't want to support this API.
For now, just deprecate it.
After copying "nm-vpn-plugin-old.*" to "nm-vpn-service-plugin.*",
rename the class and add it to the Makefile.
This will become the new VPN Service API for libnm 1.2. No changes
done yet except renaming of the classes and functions.
Rename the previous classes NMVpnPlugin(Old) to NMVpnServicePlugin
to have a distinct name from NMVpnEditorPlugin. Buth are plugins, but
with a different use.
https://bugzilla.gnome.org/show_bug.cgi?id=749951
Files are yet unchanged, only copy them to get a nicer history.
/bin/cp libnm/nm-vpn-plugin-old.c libnm/nm-vpn-service-plugin.c
/bin/cp libnm/nm-vpn-plugin-old.h libnm/nm-vpn-service-plugin.h
vpn-helper.c is currently not yet used. It was added for future
VPN support for nmtui. Refactor it to make use of the new vpn
helper functions in libnm.
Use NMVpnPluginInfo to load the plugins in NMVpnManager.
This has the advantage of reusing the code from libnm
to use the same approach to read the plugin config files.
Another advantage is that we now check the file permissions
of the config file.
Split the content of libnm/nm-vpn-editor-plugin.h and
move NMVpnEditorPlugin to libnm-core/nm-vpn-editor-plugin.h.
VPN plugins allow us to extend functionality about VPNs.
This can be also useful for NetworkManager core, hence
move that part to libnm-core.
The name NMVpnEditorPlugin is slightly misleading but not completely
wrong. The "editor" part stands no longer for bringing nm-applet
functionality (alone), but enable general VPN functionality in
the client.
Especially because we already have NMVpnPluginOld with a different
meaning (i.e. a base class of the plugin server implementation).
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.
When having a hash-of-hashes where each hash is indexed by a name,
(such as GKeyFile), you can either implement it as a hash-of-hashes
or define your own version of indexes that pack both levels of names
into one key.
This is an implementation of such a key. Use it as:
GHashTable *hash = g_hash_table_new_full (_nm_utils_strstrdictkey_hash,
_nm_utils_strstrdictkey_equal,
g_free, _destroy_value);
and create keys via:
NMUtilsStrStrDictKey *k = _nm_utils_strstrdictkey_create (s1, s2);
For lookup you can use static strings (note that the static string
might increase the size of the binary):
g_hash_table_contains (hash, _nm_utils_strstrdictkey_static ("outer", "inner"))
Add a bunch of compat defines to nm-vpn-plugin-ui-interface.h, to make
it easier to compile the same code against libnm-glib's
NMVpnPluginUiInterface and libnm's NMVpnEditorPlugin.
https://bugzilla.gnome.org/show_bug.cgi?id=752500
Our gdbus generated types use the same names as their corresponding
"real" types, but with "NM" changed to "NMDBus".
Unfortunately, that means that introspection/nmdbus-manager.c (the
generated type for src/nm-manager.c) uses the same type name as the
entirely unrelated src/nm-dbus-manager.c.
Fix this by removing the "d" from src/nm-dbus-manager.c. (We could
rename the generated type instead, but then it becomes inconsistent
with all the other generated types, and we're already using it as
"NMDBusManager" in libnm/nm-manager.c.)
NMSettingConnection's for_each_secret() function works in a
slightly-too-GHashTable-specific way. Reorganize the code now to make
the change to GVariants easier later.
Also, fix a few bugs:
- In the (unlikely) case of a non-secret being stored in
vpn.secrets, we were treating it as though it was a secret
with flags NONE.
- The code was comparing against NONE when it meant !AGENT_OWNED
in a few places. (With the current set of NMSettingSecretFlags
values, this worked, but in the future it might not.)
- In some cases we never called for_each_secret() with the
@remove_non_secrets flag, meaning we might have ended up
passing non-secrets to other code.
Have NMSecretAgent emit "disconnected" when it detects that it has
been disconnected, rather than having both the agent and the agent
manager monitor it separately.
Create a GDBusProxy for the service to be monitored and use that to
tell whether it is running, rather than using NMDBusManager and the
global NameOwnerChanged signal.
