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
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().