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.
Use the new NMConnection 'changed' signal to mark connections
as dirty/unsaved, and reset that when they get flushed to disk.
Previously, the 'Updated' signal was emitted only when the
connection was changed and flushed to disk, but now we have
more granular needs, and the signal is emitted whenever the
connection actually *is* changed, regardless of whether its
flushed to disk or not.
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
Use autoconf/automake variables for NetworkManager paths. Use
NetworkManager subdirectory where appropriate.
Files in /var/run (or /run on some distros) are moved into a separate
directory as is usual with other daemons. It makes the filesystem
more readable and file prefixing unnecessary.
/var/run/NetworkManager.pid -> /var/run/NetworkManager/NetworkManager.pid
/var/run/nm-dns-dnsmasq.pid -> /var/run/NetworkManager/dnsmasq.pid
/var/run/nm-dns-dnsmasq.conf -> /var/run/NetworkManager/dnsmasq.conf
The /var/run/NetworkManager directory is created at runtime, if it doesn't
exist.
Note: Path-based security policies like SELinux and AppArmor may need to
be adapted.
We had separate checks for glib-2.0, gobject-2.0, gmodule-2.0, and
gio-unix-2.0. It doesn't make sense to link a binary against all 4
because gio-unix-2.0 depends on glib-2.0 and gobject-2.0. Doing this
actually breaks things in unusual circumstances.
Generally, few bits of NM actually just use glib, and not gio. We
might as well coalesce those requirements together, even if it means
in some cases we "overlink". Additionally, I chose for now to fold
gmodule-2.0 in as well, even though many fewer programs need it. The
cost of overlinking is quite small.
The benefit of this is less repeated junk in Makefile.am, as well as
more centralized control over GLib. A followup patch will allow us to
set -DGLIB_VERSION_MIN_REQUIRED in just one place, rather than having
to replicate it 4 times.
The NM configure is still suboptimal - for example, libpolkit-1
depends on gio-2.0, so really we should determine the compiler flags
all in one pass. But it doesn't matter too much for now.
This functionality is (mostly) obsoleted by the newer
GLIB_VERSION_MIN_REQUIRED and GLIB_VERSION_MAX_ALLOWED defines. With
this, your build doesn't all of a sudden blow up if we deprecate
something in GLib - you have to explicitly opt-in to the newer
version.
G_DISABLE_DEPRECATED does still apply for macros and things that can't
take __attribute__((deprecated)), but it's not really worth the pain
and cargo culting around just for that.
