Quote from `man NetworkManager.conf`:
When the default wired connection is deleted or saved to a new
persistent connection by a plugin, the device is added to a list in the
file /run/NetworkManager/no-auto-default.state to prevent creating
the default connection for that device again.
"/run" is obviously wrong. Fix it.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/33
We have a fork of a lot of useful systemd helper code.
However, until now we shyed away from using it aside from
the bits that we really need.
That means, although we have some really nice implementations
in our source-tree, we didn't use them. Either we were missing
them, or we had to re-implement them.
Add "nm-sd-utils.h" header to very carefully make internal
systemd API accessible to the rest of core.
This is not intended as a vehicle to access all of internal
API. Instead, this must be used with care, and only a hand picked
selection of functions must be exposed. Use with caution, but where it
makes sense.
"shared/nm-utils" is a loose collection of utility functions.
There is a certain aim that they can be used independently.
However, they also rely on each other.
Add a test that we can build a minimal shared library with
these tools, independent of libnm-core.
This is independent functionality that only depends on linux API
and glib.
Note how "nm-logging" uses this for getting the timestamps. This
makes "nm-logging.c" itself dependen on "src/nm-core-utils.c",
for little reason.
If the NetworkManager daemon has been stopped manually we don't want it
to be autostarted by a client request.
[lkundrak@v3.sk: The auto-activation is probably more surprising than useful.
Services that need NetworkManager API should depend on NetworkManager service
directly.
I have no idea what purpose does the D-Bus service file serve nowadays,
but it looks rather hacky (really, activating /bin/false) and the comment
in it suggests that the autoactivating behavior was not intended anyway.
Debian has been shipping this for quite some time and no complains have been
heard.]
https://github.com/NetworkManager/NetworkManager/pull/230
NMAcdManager is a rather simple instance.
It does not need (thread-safe) ref-counting, in fact, having
it ref-counted makes it slighly ugly that we connect a signal,
but never bother to disconnect it (while the ref-counted instance
could outlife the signal subscriber).
We also don't need GObject signals. They have more overhead
and are less type-safe than a regular function pointers. Signals
would make sense, if there could be multiple independent listeners,
but that just doesn't make sense.
Implementing it as a plain struct is less lines of code, and less
runtime over head.
Also drop the possiblitiy to reset the NMAcdManager instance.
It wasn't needed and I think it was buggy because it wouldn't
reset the n-acd instance.
https://github.com/NetworkManager/NetworkManager/pull/213
Adapt the meson post-installation script to handle the $DESTDIR
variable supplied by user to specify the installation target
directory. While at it, convert the script to shell because it seems
simpler to me.
nm-initrd-generator scans the command line for options relevant to network
configuration and creates configuration files for an early instance of
NetworkManager run from the initial ramdisk during early boot.
This is loosely based on nms-ibft-reader, but with some significant
changes. Notably, it parses /sys/firmware/ibft directly instead of
iscsiadm output.
iscsiadm is not available on early boot (perhaps it's too large) and
turns out that parsing sysfs directly is easier and more
straightforwared anyways. A win-win situation.
It is not useful alone, it's in a separate commit just for the sake of
easier review.
Add a configure option to disable eBPF support in n-acd.
Note that, even if eBPF is not supported, n-acd requires a kernel >
3.19, which means that the setsockopt(..., SO_ATTACH_BPF) option must
be defined. To allow building on older kernels without modifying the
n-acd code, we inject the SO_ATTACH_BPF value as a preprocessor define
in the compiler the command line.
Some path variable like $(bindir), $(datadir), etc. are special for
autotools and must be handled separately through config-extra.h.
But dhcp path variables are just normal variables defined through
the configure script and should go into config.h.
(cherry picked from commit 087c367d62)
If the library is available, let's at least compile both
crypto backends.
That is helpful when developing on crypto backends, so that
one does not have to configure the build twice.
With autotools, the build is only run during `make check`.
Not for meson, but that is generally the case with our meson
setup, that it also builds tests during the regular build step.
There are two aspects: the public crypto API that is provided by
"nm-crypto.h" header, and the internal header which crypto backends
need to implement. Split them.
We already had nm_free_secret() to clear the secret out
of a NUL terminated string. That works well for secrets
which are strings, it can be used with a cleanup attribute
(nm_auto_free_secret) and as a cleanup function for a
GBytes.
However, it does not work for secrets which are binary.
For those, we must also track the length of the allocated
data and clear it.
Add two new structs NMSecretPtr and NMSecretBuf to help
with that.
Add a new 'match' setting containing properties to match a connection
to devices. At the moment only the interface-name property is present
and, contrary to connection.interface-name, it allows the use of
wildcards.
Note that in NetworkManager API (D-Bus, libnm, and nmcli),
the features are called "feature-xyz". The "feature-" prefix
is used, because NMSettingEthtool possibly will gain support
for options that are not only -K|--offload|--features, for
example -C|--coalesce.
The "xzy" suffix is either how ethtool utility calls the feature
("tso", "rx"). Or, if ethtool utility specifies no alias for that
feature, it's the name from kernel's ETH_SS_FEATURES ("tx-tcp6-segmentation").
If possible, we prefer ethtool utility's naming.
Also note, how the features "feature-sg", "feature-tso", and
"feature-tx" actually refer to multiple underlying kernel features
at once. This too follows what ethtool utility does.
The functionality is not yet implemented server-side.
CC src/devices/ovs/src_devices_ovs_libnm_device_plugin_ovs_la-nm-device-ovs-bridge.lo
In file included from src/devices/ovs/nm-device-ovs-bridge.c:20:
In file included from ./shared/nm-default.h:307:
In file included from ./src/nm-logging.h:25:
./libnm-core/nm-core-types.h:28:10: fatal error: 'nm-core-enum-types.h' file not found
#include "nm-core-enum-types.h"
^~~~~~~~~~~~~~~~~~~~~~
1 error generated.
CC src/settings/plugins/ifupdown/src_settings_plugins_ifupdown_libnms_ifupdown_core_la-nms-ifupdown-interface-parser.lo
In file included from src/settings/plugins/ifupdown/nms-ifupdown-interface-parser.c:23:
In file included from ./shared/nm-default.h:307:
In file included from ./src/nm-logging.h:25:
./libnm-core/nm-core-types.h:28:10: fatal error: 'nm-core-enum-types.h' file not found
#include "nm-core-enum-types.h"
^~~~~~~~~~~~~~~~~~~~~~
1 error generated.
make: *** [Makefile:13904: src/settings/plugins/ifupdown/src_settings_plugins_ifupdown_libnms_ifupdown_core_la-nms-ifupdown-interface-parser.lo] Error 1
Instead of letting each nmcli run write an individual .expected file,
combine the output of multiple runs in one file (per test).
Advantages:
- since there is a very large number of tests, having a file for each
tests is cumbersome. For example, since they are all added to
$(EXTRA_DIST) (and since we use non-recursive make), autoconf can
easily hit a length limit when processing all the file names.
- previously, whenever we added tests, all .expected files shifted
and the diff was large. Now, there is a chance that the diff is
smaller and more accurate.
We only have a certain granularity of how our headers in "shared/nm-utils"
can be used independently.
For example, it's not supported to use "nm-macros-internal.h" without
"gsystem-local-alloc.h". Likewise, you cannot use "nm-glib.h" directly,
you always get it together with "nm-macros-internal.h".
This is, we don't support to use certain headers entirely independently,
because usually you anyway want to use them together.
As such, no longer support "gsystem-local-alloc.h", but merge the
remainder into "nm-macros-internal.h". There is really no reason
to support arbitrary flexibility of including individual bits. You
want cleanup-macros? Include "nm-macros-internal.h".
Merge the headers.
With --enable-more-warnings, we already used -std=gnu99, see
commit ba2b2de3ad.
Compilation may behave differently depending on the selected
C standard that we choose. It seems wrong, with more-warnings,
to build against a C standard, while otherwise leaving it undefind.
Indeed, one might argue, that our build system should not use
such compiler specific options. At least, not without detecting
support for the compiler option during ./configure.
However:
- we already did this for --enable-more-warnings.
- we should not program against a theoretical compiler. In practice,
only gcc and clang works to build NetworkManager. Both these compilers
support this option, so there is no reason to not use it. If we ever
come into the situation to support another compiler, adjusting -std=gnu99
will be the smallest problem. Until that happens (and that's far from
imminent), don't pretend to be portable to non-existing compilers and
use the flag that in practice is available.
See-also: https://gcc.gnu.org/onlinedocs/gcc/Standards.html
1) the command line gets shorter. I frequently run `make V=1` to see
the command line arguments for the compiler, and there is a lot
of noise.
2) define each of these variables at one place. This makes it easy
to verify that for all compilation units, a particular
define has the same value. Previously that was not obvious or
even not the case (see commit e5d1a71396
and commit d63cf1ef2f).
The point is to avoid redundancy.
3) not all compilation units need all defines. In fact, most modules
would only need a few of these defines. We aimed to pass the necessary
minium of defines to each compilation unit, but that was non-obvious
to get right and often we set a define that wasn't used. See for example
"src_settings_plugins_ibft_cppflags" which needlessly had "-DSYSCONFDIR".
This question is now entirely avoided by just defining all variables in
a header. We don't care to find the minimum, because every component
gets anyway all defines from the header.
4) this also avoids the situation, where a module that previously did
not use a particular define gets modified to require it. Previously,
that would have required to identify the missing define, and add
it to the CFLAGS of the complation unit. Since every compilation
now includes "config-extra.h", all defines are available everywhere.
5) the fact that each define is now available in all compilation units
could be perceived as a downside. But it isn't, because these defines
should have a unique name and one specific value. Defining the same
name with different values, or refer to the same value by different
names is a bug, not a desirable feature. Since these defines should
be unique accross the entire tree, there is no problem in providing
them to every compilation unit.
6) the reason why we generate "config-extra.h" this way, instead of using
AC_DEFINE() in configure.ac, is due to the particular handling of
autoconf for directory variables. See [1].
With meson, it would be trivial to put them into "config.h.meson".
While that is not easy with autoconf, the "config-extra.h" workaround
seems still preferable to me.
[1] https://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Installation-Directory-Variables.html
It's for 6LoWPAN devices. "o.fd.NM.Device.6Lowpan" wouldn't be a valid
interface name -- just skip the leading numeral, that's what kernel also
does on similiar occassions.
