Cache the scope as part of the NMPlatformIP4Route and
no longer read it from libnl object when needed. Later
there will be no more libnl objects around, and we need
to scope when deleting an IPv4 route.
- move all hostname-related functions from plugins to the core
- allow to specify the method used to load and store the hostname at
build time
- add hostnamed support
- remove unused setting plugins
https://bugzilla.gnome.org/show_bug.cgi?id=740409
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.
warning: function declaration isn’t a prototype [-Wstrict-prototypes]
In C function() and function(void) are two different prototypes (as opposed to
C++).
function() accepts an arbitrary number of arguments
function(void) accepts zero arguments
The metered property of a NMDevice that reaches the activated state is
copied from the active connection and if its value is 'unknown' some
heuristics are used to guess the actual value.
When the connection is torn down the metered property is reset to
'unknown'.
Some versions of Android's DHCP server send option 43 (Vendor specific
information) with value "ANDROID_METERED" in Wi-Fi hotspot mode.
Mark the NMIP4Config as metered when such option is received.
This adds support for DHCP option 43 (Vendor Specific Information) to
the internal DHCP client. The option carries an opaque object of n
octets, interpreted by vendor-specific code on the clients and
servers.
Some DHCP servers send specific options to give a hint that clients
should avoid unneeded data usage.
Add a metered flag to NMIP4Config to keep track of this information.
Add a 'metered' enum property to NMSettingConnection with possible
values: unknown,yes,no. The value indicates the presence of limitations
in the amount of traffic flowing through the connection.
- add new file 'nm-platform-utils.c' and moves some independent utility
functions there (ethtool, udev).
- some refactoring of platform code, including initialization of
NMPlatform instance.
- run platform tests in a separate user namespace, which allow
us to run root-tests as non-root.
https://bugzilla.gnome.org/show_bug.cgi?id=747981
