libnm-core.a should only be linked once in libnm.so. Previously,
it was linked twice, once as part of libnm-utils.a and once
directly in libnm.so.
Fixes: 8df944c7e4
(cherry picked from commit 5a67130e15)
Previously, internal parts of libnm were not testable.
Instead, add "libnm/nm-libnm-utils.c" and "libnm/libnm-utils.la"
to contain code that can be statically linked with a new
test "libnm/tests/test-general".
(cherry picked from commit 8df944c7e4)
The user data values are encoded in shell variables named
prefix "NM_USER_". The variable name is an encoded form of the
data key, consisting only of upper-case letters, digits, and underscore.
The alternative would be something like
NM_USER_1_KEY=my.keys.1
NM_USER_1_VAL='some value'
NM_USER_2_KEY=my.other.KEY.42
NM_USER_2_VAL='other value'
contary to
NM_USER_MY__KEYS__1='some value'
NM_USER_MY__OTHER___K_E_Y__42='other value'
The advantage of the former, numbered scheme is that it may be easier to
find the key of a user-data entry. With the current implementation, the
shell script would have to decode the key, like the ifcfg-rh plugin
does.
However, user data keys are opaque identifers for values. Usually, you
are not concerned with a certain name of the key, you already know it.
Hence, you don't need to write a shell script to decode the key name,
instead, you can use it directly:
if [ -z ${NM_USER_MY__OTHER___K_E_Y__42+x} ]; then
do_something_with_key "$NM_USER_MY__OTHER___K_E_Y__42"
fi
Otherwise, you'd first have to search write a shell script to search
for the interesting key -- in this example "$NM_USER_2_KEY", before being
able to access the value "$NM_USER_2_VAL".
(cherry picked from commit 79be44d990)
We have unit tests for writing and re-reading ifcfg file. Those
tests compare whether a file can be successfully read and is
semantically identical.
However, there were no tests that a certain output is written in
a stable format. We aim not to change the output of what we write.
For that, add tests to not only check the semantic of the written
ifcfg file, but their bits and bytes.
Some future changes may well intentionally change the current
output. That will require to update the expected result files
and can be done via
NMTST_IFCFG_RH_UPDATE_EXPECTED=yes src/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh
Note that alias, route, and key files are not checked.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1445414
(cherry picked from commit f04bf45e84)
NMPlatform, NMRouteManager and NMDefaultRouteManager are singletons
instances. Users of those are for example NMDevice, which registers
to GObject signals of both NMPlatform and NMRouteManager.
Hence, as NMDevice:dispose() disconnects the signal handlers, it must
ensure that those singleton instances live longer then the NMDevice
instance. That is usually accomplished by having users of singleton
instances own a reference to those instances.
For NMDevice that effectively means that it shall own a reference to
several singletons.
NMPlatform, NMRouteManager, and NMDefaultRouteManager are all
per-namespace. In general it doesn't make sense to have more then
one instances of these per name space. Nnote that currently we don't
support multiple namespaces yet. If we will ever support multiple
namespaces, then a NMDevice would have a reference to all of these
manager instances. Hence, introduce a new class NMNetns which bundles
them together.
(cherry picked from commit 0af2f5c28b)
This moves tracking of connectivity to NMDevice and makes the NMManager
negotiate the best of known connectivity states of devices. The NMConnectivity
singleton handles its own configuration and scheduling of the permission
checks, but otherwise greatly simplifies it.
This will be useful to determine correct metrics for multiple default routes
depending on actual internet connectivity.
The per-device connection checks is not yet exposed on the D-Bus, since they
probably should be per-address-family as well.
Works by dumb luck for in-tree build, because the .deps files that are
meant for the distribution happen to be the builddir. The out-of-tree
builds would generate an empty file.
We also dist libnm/nm-property-docs.xml, so depending on
whether we build from git or source tarball, the file
is in $(srcdir) or $(builddir).
Fixes: d7ad13591b
There are very few places where we actually use floating point
or #include <math.h>.
Drop that library, although we very likely still get it as indirect
dependency (e.g. on my system it is still dragged in by libsystemd.so,
libudev.so and libnl-3.so).
One day, I wish we would have more setting metadata in shared via
"shared/nm-setting-metadata.h", ready for nmcli and nmtui to use
(by statically linking against the internal API).
Anyway, it is still unused, so drop the files from the SOURCES of
nmcli.
"$(srcdir)/clients/cli/settings.c" includes "$(builddir)/clients/cli/settings-docs.c",
hence, we need "-I$(builddir)/clients/cli".
This basically reverts commit bbce089840,
but adds dependencies so that the build directory exists.
The sources should reach files in the $builddir using #include "".
Besides, it is not guarranteed to be around:
CC shared/clients_cli_nmcli-nm-setting-metadata.o
cc1: error: ./clients/cli: No such file or directory [-Werror=missing-include-dirs]
cc1: all warnings being treated as errors
Makefile:12971: recipe for target 'shared/clients_cli_nmcli-nm-setting-metadata.o' failed
It's not sufficient to make nm-core-enum-types.[ch] depend on the
dirstamp, because they also depend on their own stamps that are to be
placed in libnm-core.
$ make libnm-core/nm-core-enum-types.h.stamp
GEN libnm-core/nm-core-enum-types.h
/bin/sh: libnm-core/nm-core-enum-types.h.tmp: No such file or directory
../../Makefile.glib:107: recipe for target 'libnm-core/nm-core-enum-types.h.stamp' failed
make: *** [libnm-core/nm-core-enum-types.h.stamp] Error 1
We use output redirection in numerous places; leaving the half-built
artifacts in place would cause the subsequent builds to succeed when it
should not.
The only reliable way of setting a MAC address for the team is through
the "hwaddr" property in the configuration passed to teamd. In order
to rewrite the configuration we need Jansson support; since it is
already a requirement for teamd, let the team plugin depend on it.
If configure is called without --enable-json-validation or
--disable-json-validation, let's automatically choose a value
depending on the availability of the library.
Add support for creating dummy devices. This commit adds a D-Bus
interface 'org.freedesktop.NetworkManager.Device.Dummy' which is used
primarily for determining the device type but does not carry any
properties.
Since we generate "libnm-core/nm-core-enum-types.h" via GLIB_GENERAED,
there is no obvious place to $(MKDIR_P). Add a dependency to the
.dirstamp of the directory to instruct automake to create the directory.
"shared/nm-setting-metadata.h" will contain data structures
to handle NM setting properties in a generic way.
For now, this is internal API, but shared between libnm-core (which
extends to libnm, NetworkManager, device-plugins, settings-plugins),
and nmcli.
Related: https://bugzilla.gnome.org/show_bug.cgi?id=732292
