We inconsistently use gulong,guint,int types to store signal handler
id, but the type returned by g_signal_connect() is a gulong.
This has no practical consequences because a int/guint is enough to
store the value, however it is better to use a consistent type, also
because nm_clear_g_signal_handler() accepts a pointer to the signal id
and thus it must be always called with the same pointer type.
A GObject interface, like a class, has two different C types
associated with it; the type of the "class" struct (eg, GObjectClass,
GFileIface), and the type of instances of that class/interface (eg,
GObject, GFile).
NetworkManager was doing this wrong though, and using the same C type
to point to both the interface's class struct and to instances of the
interface. This ends up not actually breaking anything, since for
interface types, the instance type is a non-dereferenceable dummy type
anyway. But it's wrong, since if, eg, NMDeviceFactory is a struct type
containing members "start", "device_added", etc, then you should not
be using an NMDeviceFactory* to point to an object that does not
contain those members.
Fix this by splitting NMDeviceFactory into NMDeviceFactoryInterface
and NMDeviceFactory; by splitting NMConnectionProvider into
NMConnectionProviderInterface and NMConnectionProvider; and by
splitting NMSettingsPlugin into NMSettingsPluginInterface and
NMSettingsPlugin; and then use the right types in the right places.
As a bonus, this also lets us now use G_DEFINE_INTERFACE.
Since there have not been separate system and user settings services
since 0.8, the "system" in NMSystemConfigInterface is kind of
meaningless. Rename it to NMSettingsPlugin, which describes what it
does better.
This is just:
git mv src/settings/nm-system-config-interface.h src/settings/nm-settings-plugin.h
git mv src/settings/nm-system-config-interface.c src/settings/nm-settings-plugin.c
perl -pi -e 's/SystemConfigInterface/SettingsPlugin/g;' \
-e 's/system_config_interface/settings_plugin/g;' \
-e 's/system-config-interface/settings-plugin/g;' \
-e 's/SYSTEM_CONFIG_INTERFACE/SETTINGS_PLUGIN/g;' \
-e 's/sc_plugin/settings_plugin/g;' \
-e 's/SC_PLUGIN/SETTINGS_PLUGIN/g;' \
-e 's/SC_IS_PLUGIN/SETTINGS_IS_PLUGIN/g;' \
-e 's/SC_TYPE_PLUGIN/SETTINGS_TYPE_PLUGIN/g;' \
-e 's/SCPlugin/SettingsPlugin/g;' \
-e 's/nm_system_config_factory/nm_settings_plugin_factory/g;' \
$(find src/settings -type f)
(followed by some whitespace fixups in nm-settings-plugin.c, and a
Makefile.am fix for the rename)
There is no need to have a static @singleton variable.
The only caller of nm_settings_keyfile_plugin_new() is
NMSettings which owns the singleton instance.
A *_new() function should just create a new instance and
that's it. It's unexpected to reuse the same instance.
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, if you change the ID of a connection,
the existing keyfile will not be renamed. That means
after renaming a connection, it's keyfile name will
mismatch.
Now, when th user modifies a connection via D-Bus and changes
the connection it, rename the file.
https://bugzilla.gnome.org/show_bug.cgi?id=740738
In some cases we want the returned value to be stripped. In some cases,
we want to read the raw value instead of the string parsed by GKeyFile.
Add an flags argument to nm_config_data_get_value(). It is up to the caller
to determine the exact meaning (and whether to strip).
By adding the flags argument, the caller can get the desired behavior easier
without having to workaround it afterwards. But more importantly, it becomes
apparent that there are different ways to retrieve the value and the caller
should decide on the details.
Some plugins had their local defines for the name of the sections and
keys in NMConfig. Move those defines to "nm-config.h".
Usually plugins make use of code in core, but not the other
way round. Defining the names inside "nm-config.h" is no violation of
that because the config section names are anyway not local to the
plugin, but global in the shared name-space with other settings.
For example, another plugins shouldn't reuse the section "ifnet".
For that reason, it is correct and consistent to move these defines
to "nm-config.h".
We don't use those names in core, we merely signal their existance.
Instead of parsing "/etc/NM/NetworkManager.conf" in keyfile plugin itself,
use NMConfig. Parsing it outside of NMConfig API has the significant disadvantage
of not considering files under "conf.d/".
This also has a behavioral change: keyfile no longer monitors
"NetworkManager.conf" file for changes, but instead only reacts
on explict "config-changed" signals from NMConfig.
This previous behavior of picking up file changes without
user-interaction is anyway not what we want. NM should not react
on mere file changes, but only on explicit reload commands. And
even if we want to support it, file watching should be implemented
properly inside NMConfig, watching *all* relevant files.
This was the last out-of-api access to the configuration after
refactoring NMConfig. Now that keyfile plugin no longer writes
the hostname, we can get rid of this.
There are three configuration options that contain device specs:
'main.ignore-carrier', 'main.no-auto-default', and
'keyfile.unmanaged-devices'.
Unify the parsing of them by splitting the device spec with
nm_match_spec_split(). This changes behavior for parsing of these
properties.
Also get rid of logging warnings when parsing 'keyfile.unmanaged-devices'.
When adding a connection to NMSettings we did not check for
duplicate connection UUIDs (which could for example happen
if two different plugins report a conflicting UUID).
Also, we would not check that an already added connection
changes it's UUID.
Both could lead to have duplicate connections (by UUID).
Avoid that two ways:
- when adding a connection to NMSettings, ensure that we don't add
a conflicting UUID. Otherwise just bail out and do nothing.
- when modifying a connection that is already added to NMSettings,
enforce that the UUID cannot change. Otherwise fail with error.
For ifcfg-rh plugin this situation still can happen during reload.
In this case error out and refuse to update the connection. After
all, the user configured invalid UUIDs.
https://bugzilla.redhat.com/show_bug.cgi?id=1171751
Also during add_connection() we must take special care of not "adding" a
connection with a conflicting UUID. In that case we want to fallback to
"update".
update_connection() already does all the checks, so call
update_connection() from add_connection().
If there are keyfiles with duplicate UUIDs, read_connections()
would iterate over the files, loading them as they appear and
overwriting duplicate connections that were just loaded.
For example, have keyfiles 'A' and 'B' with the same UUID.
On start, NM might first load 'A', then 'B'. 'B' would replace the
content of 'A' which was just loaded.
On reload, NM would first overwrite 'B' with 'A', and then again
overwriting 'A' with 'B'.
Fix that by accept the first found connection and don't overwrite
it during the same read_connections() run.
Also sort the files by file modification timestamp so that we
get a reproducible and sensible behavior.
new_connection() and update_connection() are very similar as both
must anticipate collisions of UUIDs.
When reloading a connection (update_connection(), previously), the loaded
connection for a certain path might actually replace another existing
connection. In this case, the old connection must be removed, and
the existing one updated instead.
If reloading a connection changes the UUID to a new value, the old
connection must be removed likewise and a new connection added.
Merge both functions into update_connection().
Only log connection diffs when we update a connection that we actually
care about.
Note that most plugin specific connections use
nm_settings_connection_replace_settings() in their constructor
to initialize themselves. These occurrences are not interesting
and spam the logfile.
Add a "filename" property to NMSettingsConnection, and set it from
keyfile and ifcfg-rh (replacing the existing priv->path variables in
those connection types). (The other plugins either don't use files, or
don't use per-connection files.)
config.h should be included from every .c file, and it should be
included before any other include. Fix that.
(As a side effect of how I did this, this also changes us to
consistently use "config.h" rather than <config.h>. To the extent that
it matters [which is not much], quotes are more correct anyway, since
we're talking about a file in our own build tree, not a system
include.)
Include <linux/if_ether.h> and <linux/if_infiniband.h> from
nm-utils.h, to get ETH_ALEN and INFINIBAND_ALEN, and remove those
includes (as well as <net/ethernet.h> and <netinet/ether.h>, and
various headers that had been included to get the ARPHRD_* constants)
from other files where they're not needed now.
Drop the arptype-based nm_utils_hwaddr funcs, and rename the
length-based ones to no longer have _len in their names. This also
switches nm_utils_hwaddr_atoba() to using a length rather than an
arptype, and adds a length argument to nm_utils_hwaddr_valid() (making
nm_utils_hwaddr_valid() now a replacement for nm_utils_hwaddr_aton()
in some places, where we were only using aton() to do validity
checking).
Prevents:
Connection failed to verify: (unknown)
invalid or missing connection property 'blah blah/foo bar'
Simply removing the warning in reader.c is fine, because callers that
care already log the warning themselves. Also make the warning in
update_connection() the same as the warning in new_connection().
If a valid connection was updated and still valid, and then was
updated and become invalid, the connection would not be properly
removed from the keyfile plugin's priv->connections hash, and thus
would never be disposed.
This was due to using the direct pointer to the connection's UUID
as the key for the hash table. When a connection is updated and
its settings are replaced, the old UUID is freed and replaced with
a new pointer. But the keyfile plugin hash table still uses the
old (now freed) UUID pointer as the key. Thus when the connection
is updated and becomes invalid, looking up the UUID in the hash
table fails to find the connection, and the connection is not
removed from the hash.
This bug could cause a crash in some cases, if two keys of the
GHashTable hashed to the same value, in which case GLib would
call g_str_equal() on the freed pointer.
Since code other than in the keyfile plugin replaces settings,
we cannot be guaranteed that the pointer won't change. Avoid all
that and just strdup() the UUID when using it as a key.
(also collapses _internal_new_connection() into its only caller)
Remove the PLUGIN_PRINT() and PLUGIN_WARN() macros and use the
standard NM logging functions instead.
Also changed PLUGIN_PRINT("error: ...") to nm_log_warn("...") in
places.
If the connection has never been saved to disk, it won't have a path yet,
but that doesn't mean we should crash. Next, when reloading connections,
only try to do connection matching on connections that have paths, otherwise
all in-memory-only connections would be removed at the end of
read_connections().
Plugins that could save connections to disk previously depended on inotify
events from the kernel to know when to signal connection removal; that is
in response to a 'delete' request they would unlink the backing filesystem
resources, get the inotify signal, and cause NM_SETTINGS_CONNECTION_REMOVED
to be emitted.
Unsaved connections don't have any backing resources, so they would never
get the signal emitted, and NMSettings would never forget about them.
Also, when monitor-connection-files=false in the configuration, obviously
the inotify signals will never come in because they aren't set up.
Given that we can no longer rely on inotify, it's best to just explicitly
send out the NM_SETTINGS_CONNECTION_REMOVED signal whenever a connection
is deleted via the D-Bus interface or internally.
Add a "monitor-connection-files" config option, which can be set to
"false" to disable automatic reloading of connections on file change.
To go with this, add a new ReloadConnections method on
o.fd.NM.Settings that can be used to manually reload connections, and
add an nm-cli command to call it.
ifcfg-rh didn't let you unmanage an InfiniBand device by hardware
address because it was recording the hardware address with uppercase
letters, while nm_match_spec_hwaddr() required lowercase. Fix this by
making nm_match_spec_hwaddr() match case-insensitively (and remove the
manual lowercasing that several other places were doing to work around
this.)
keyfile didn't let you unmanage an InfiniBand device by hardware
address because it only accepted ARPHRD_ETHER hardware addresses. Fix
that by using nm_utils_hwaddr_valid() instead.
We don't always want to immediately write new connections to disk, to
facilitate "runtime" or "temporary" connections where an interface's
runtime config isn't backed by on-disk config. Also, just because
an interface's configuration is changed doesn't necessarily mean
that new configuration should be written to disk either.
Add D-Bus methods for adding new connections and for updating existing
connections that don't immediately save the connection to disk.
Also add infrastructure to indicate to plugins that the new connection
shouldn't be immediately saved if the connection was added with the
new method.
