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
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.
Move D-Bus export/unexport handling into NMExportedObject and remove
type-specific export/get_path methods (export paths are now specified
at the class level, and NMExportedObject handles the counters for all
exported types automatically).
Since all exportable objects now use the same get_path() method, we
can also add some helper methods to simplify get_property()
implementations for object-path and object-path-array properties.
Add NMExportedObject, make it the base class of all D-Bus-exported
types, and move the nm-properties-changed-signal logic into it. (Also,
make NMSettings use the same properties-changed code as everything
else, which it was not previously doing, presumably for historical
reasons).
(This is mostly just shuffling code around at this point, but
NMExportedObject will be more important in the gdbus port, since
gdbus-codegen doesn't do a very good job of supporting objects that
export multiple interfaces [as each NMDevice subclass does, for
example], so we will need more glue/helper code in NMExportedObject
then.)
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).
Add a file containing the defines like DBUS_INTERFACE_DBUS from
dbus-shared.h, and use it from the gdbus-using files.
Also, convert a bunch of other places that were previously hardcoding
the string values to use the defines instead, and fix the ifcfg-rh
plugin to properly namespace its own D-Bus-related defines.
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
A GError should contain a nice, human readable error message. The
file:line prefix looks ugly. Also, the error messages are already
systemwide unique. So a user can easily grep for them and locate
the origin.
Now that we set hostname with systemd, call dispatcher in nm-settings.c.
gethostname() in nm-policy.c already sees the new hostname.
Fixes: 6dc35e66d4
Fixes: 6c3d71c431
Fixes:Beaker:NetworkManager_Test44_dispatcher_hostname
Originally, ibft settings were handled by "ifcfg-rh" plugin. Later, we added
a separate "ibft" plugin and moved the functionality there.
The problem was that users quite possibly had a configuration like
[main]
plugins=ifcfg-rh
in their "NetworkManager.conf". That meant, after upgrade users would
no longer have ibft support.
We fixed that by installing "/etc/NetworkManager/conf.d/10-ibft-plugin.conf"
which was read after the main file and contained:
[main]
plugins+=ibft
We no longer want to install configuration snippets with our core packages to
/etc. Avoid the regression by changing the meaning of "ifcfg-rh". By enabling
"ifcfg-rh" you now implicitly enable "ibft" plugin as well. This can be
turned off via "no-ibft". And you can continue to enable "ibft" plugin
alone.
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.
We ought to set an error if we're returning NULL from
connection_from_file_full(). Also, printing out a warning ourselves makes no
sense -- the caller communicates this if we signal an error by returning NULL.
AUTOCONNECT_SLAVES is an NetworkManager extension. initscripts always activate
slaves with the master connection for bond and team, and doesn't activate
automatically slaves for bridge.
NetworkManager behaviour is controlled by this variable. If the variable is
missing the default value from configuration file is used.
The 'example' settings plugin is (obviously) unused, but it is also
badly maintained and no longer best-practice in several ways:
- it directly reads "NetworkManager.conf" instead of using NMConfig.
- it parses device specs itself, instead of using
nm_match_spec_split().
- read_connections() doesn't ensure that loading a file
does not replace a previously loaded one (due to conflicting
UUID). In general the example doesn't show/handle the complexity
of potential UUID conflicts.
Instead of fixing these issues it is better to ensure our main plugin
('keyfile') corresponds to current best practices. Should we ever add a
new pluginww, 'keyfile' should be the example.
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.
After the hostname functionality has been moved from plugins to core,
the ifcfg-suse plugin contains only boilerplate code with no actual
functionality.
Remove the plugin, mark it as deprecated in manual page and print a
warning when it is selected in configuration file.
When the systemd-hostnamed daemon is available, use it to read and
change the hostname.
Based on 'danw/wip/hostnamed' branch by Dan Winship <danw@redhat.com>
How to write and read the machine hostname is something that has been
handled until now by plugins; this is questionable since the method
using for storing the hostname should depend only on the distro used
and not on which plugins are enabled.
This commit moves all hostname-related functions from plugins to the
core and allows to specify the method used to load and store the
hostname at build time with the
--with-hostname-persist=default|suse|gentoo
configure option.
'default' method stores the hostname to /etc/hostname and monitors it
to detect runtime changes.
When the selected method is 'suse', the hostname gets read from and
written to /etc/HOSTNAME; the file /etc/sysconfig/network/dhcp is also
read to detect if the hostname is dynamic and thus invalid. Both files
are monitored for changes.
'gentoo' method relies on /etc/conf.d/hostname for storing the
hostname.
