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
There is no general purpose file for platform utilities.
We only have nm-platform.h, which contains (mostly) functions
that operate on a NMPlatform instance (and that can be mocked
using NMFakePlatform).
Add a new file for independent utility functions. nm-platform-utils.c
should not call into functions having a NMPlatform instance, to
have them independent from platform caching and the platform
singleton.
nm_platform_query_devices() would raise an 'added' signal
for all its links. That is bad style because it could
confuse other listeners for platform signals which don't
expect such artificial change signals.
The public API of NMPlatform already gives NMManager the ability
to 'pull' all the links and iterate them itself.
Before, nm_platform_query_devices() would also initialize udev
devices, so there was a more compelling reason for this function.
We already populate the netlink cache in constructed(). No need
to wait with udev devices until nm_platform_query_devices(). Just
do it right away.
Add a hack to keep 'lo' default-unmanaged. Now that we load
udev devices earlier, we end up clearing the default-unmanged
flag on 'lo', which has bad consequences.
We don't want error logging for nm_platform_link_add() which
tries to load the bonding module. Later we will run tests as non-root,
where modprobe will fail. Logging an error would break the tests.
Even if asserts are not enabled, still let the compiler see what we would
assert. Otherwise, we get warnings about unused variables or we migth miss
compile errors inside nm_assert().
Since introduction for support of ip6-privacy (use_tempaddr,
RFC4941) with commit d376270bfe,
the sysctl value from /etc was always read first.
This is problematic, because an explicit setting in the
connection should not be ignored over a global configuration.
Drop that old behavior. It was also problematic, because we did
not read any files under /etc/sysctl.d (except for sysctl.conf).
Also, we did not honor per-interface configurations.
Now we also use as last fallback the value from
/proc/sys/net/ipv6/conf/default/use_tempaddr
That has the advantage of falling back to the system default value
so that NM doesn't need to have it's own default policy
(Related: https://bugzilla.redhat.com/show_bug.cgi?id=1187525).
This is a change in behavior.
Support default value for setting 'ipv6.ip6-privacy' in
NetworkManager.conf.
If the global value is unset, preserve old behavior of looking into
/etc/sycctl.conf first. That behavior was introduced with commit
d376270bfe, since we support ip6-privacy
setting.
If the global value is set to "unknown", add a new fallback
that instead reads the runtime value from
"/proc/sys/net/ipv6/conf/default/use_tempaddr"
This seems more sensible behavior because we fallback to sysctl,
but instead of looking at static files in /etc, read /proc.
But to preserve the old behavior, we only do that when a global
value is configured at all.
https://bugzilla.gnome.org/show_bug.cgi?id=721200
The route-metric can be configured per connection via the
ipv4.route-metric and ipv6.route-metric fields. When the
value is left at -1 (the default), we would determine the
route-metric based on the device type (nm_device_get_priority()).
Extend that scheme by making the default value overwritable in
NetworkManager.conf.
