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.
