When writing a file (for example with `sed -i`) a temporary file
might be created and removed quickly. This causes spurious events
in dir_changed().
(cherry picked from commit 8ba8a55cfa)
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().
(cherry picked from commit db5c4ce64f)
Log lines with a "keyfile:" prefix and show more information about
the loaded connection. Especially printing the UUID is interesting.
(cherry picked from commit 5c2fa92099)
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.
(cherry picked from commit 8a4e64c6aa)
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().
(cherry picked from commit c2fcb680f8)
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.
(cherry picked from commit e14ea6818a)
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.)
(cherry picked from commits 24a464a7da
and c9002c041d)
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.
Just code cleanup: This is much less error-prone than manual nesting,
and will mesh very well with future changes to use the libgsystem
cleanup macros.
GObject creation cannot normally fail, except for types that implement
GInitable and take a GError in their _new() method. Some NM types
override constructor() and return NULL in some cases, but these
generally only happen in the case of programmer error (eg, failing to
set a mandatory property), and so crashing is reasonable (and most
likely inevitable anyway).
So, remove all NULL checks after calls to g_object_new() and its
myriad wrappers.
https://bugzilla.gnome.org/show_bug.cgi?id=693678
When updating connections, it is less confusing to reuse the existing file
instead of renaming files according to connection's ID. That reduces surprises
of moving connection files when a connection is edited.
When a connection changes on-disk, the in-memory copy of it may contain
transient secrets (agent-owned or not saved) that dont' get written out
to disk. When comparing the on-disk copy to the in-memory copy make sure
transient secrets are ignored so that we don't re-read the on-disk copy
needlessly.
