We must trust l3cfg when generating dependent onlink routes for all kind
of routes not default routes only. This was done by
"nm_platform_ip_route_sync()" so there is not change in behaviour at
all.
"nm_platform_ip_route_sync()" could be needed for other situation where
l3cfg cannot add the dependent onlink routes, so we are not removing
that logic.
This reverts commit 6b4123db1c.
Currently, the use of [global-dns] section for setting DNS options is
conditioned on presence of a nameserver in a [global-dns-domain-*] section.
Attempt to use the section for options alone results in an error:
[global-dns]
options=timeout:1
Or via D-Bus API:
# busctl set-property org.freedesktop.NetworkManager \
/org/freedesktop/NetworkManager org.freedesktop.NetworkManager \
GlobalDnsConfiguration 'a{sv}' 2 \
"options" as 1 "timeout:1" \
"domains" a{sv} 0
...
Nov 24 13:15:21 zmok.local NetworkManager[501184]: <debug> [1669292121.3904]
manager: set global DNS failed with error: Global
DNS configuration is missing the default domain
The insistence on existence of [global-dns-domain-*] would make sense if
other [global-dns-domain-...] sections were present.
However, the user might only want to set the options in resolv.conf and
still use connection-provide nameservers for the actual resolving.
Lift the limitation by allowing the [global-dns] to be used alone, while
still insist on [global-dns-domain-*] being there in presence of other
domain-specific options.
https://bugzilla.redhat.com/show_bug.cgi?id=2019306
(cherry picked from commit 1f0d1d78d2)
This effectively makes [*global-dns-domain-*] sections in configuration be
ignored unless [*global-dns] is also present. This happens because
nm_config_keyfile_has_global_dns_config() mixes the group names up and
attempts to loop up [.intern.global-dns-domain-*] in user configuration and
[global-dns-domain-*] in the internal one.
Fixes: da0ded4927 ('config: drop global-dns.enable option in favor of .config.enable')
(cherry picked from commit de1c06daab)
We silently tolerate NetworkManager not responding at all (easily
reproduced with e.g. pkill -STOP NetworkManager):
$ LIBNM_CLIENT_DEBUG=trace nmcli c show dummy666
libnm-dbus[23540]: <debug> [3316.81989] nmclient[ddafb84b8deebe4a]: new NMClient instance
libnm-dbus[23540]: <debug> [3316.81998] nmclient[ddafb84b8deebe4a]: starting async initialization...
libnm-dbus[23540]: <debug> [3316.82461] nmclient[ddafb84b8deebe4a]: name owner changed: (null) -> ":1.2"
libnm-dbus[23540]: <debug> [3316.82464] nmclient[ddafb84b8deebe4a]: fetch all
libnm-dbus[23540]: <debug> [3341.85715] nmclient[ddafb84b8deebe4a]: GetManagedObjects() call failed: Timeout was reached
libnm-dbus[23540]: <debug> [3341.85740] nmclient[ddafb84b8deebe4a]: async init complete with success
Error: dummy666 - no such connection profile.
libnm-dbus[23540]: <debug> [3341.86723] nmclient[ddafb84b8deebe4a]: release all
libnm-dbus[23540]: <debug> [3341.86798] nmclient[ddafb84b8deebe4a]: disposed
$
As a comment in _dbus_get_managed_objects_cb() explains, this is sort of
intentional. NetworkManager might just be shutting down and the libnm
users will eventually see the objects once a new daemon starts up.
This may make some sense for long-running clients ("nmcli monitor",
various desktop environments), but not for one-shot invocations that
require the daemon running, such as those of "nmcli c ...".
Let's not consider the client running unless we actually got the manager
object. That way the error message will make more sense:
$ LIBNM_CLIENT_DEBUG=trace nmcli c show dummy666
libnm-dbus[24730]: <debug> [5360.95480] nmclient[8cb898d3c891e210]: new NMClient instance
libnm-dbus[24730]: <debug> [5360.95487] nmclient[8cb898d3c891e210]: starting async initialization...
libnm-dbus[24730]: <debug> [5360.95901] nmclient[8cb898d3c891e210]: name owner changed: (null) -> ":1.2"
libnm-dbus[24730]: <debug> [5360.95904] nmclient[8cb898d3c891e210]: fetch all
libnm-dbus[24730]: <debug> [5385.98487] nmclient[8cb898d3c891e210]: GetManagedObjects() call failed: Timeout was reached
libnm-dbus[24730]: <debug> [5385.98497] nmclient[8cb898d3c891e210]: async init complete with success
Error: NetworkManager is not running.
libnm-dbus[24730]: <debug> [5385.98571] nmclient[8cb898d3c891e210]: release all
libnm-dbus[24730]: <debug> [5385.98698] nmclient[8cb898d3c891e210]: disposed
$
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1502
Currently, the use of [global-dns] section for setting DNS options is
conditioned on presence of a nameserver in a [global-dns-domain-*] section.
Attempt to use the section for options alone results in an error:
[global-dns]
options=timeout:1
Or via D-Bus API:
# busctl set-property org.freedesktop.NetworkManager \
/org/freedesktop/NetworkManager org.freedesktop.NetworkManager \
GlobalDnsConfiguration 'a{sv}' 2 \
"options" as 1 "timeout:1" \
"domains" a{sv} 0
...
Nov 24 13:15:21 zmok.local NetworkManager[501184]: <debug> [1669292121.3904]
manager: set global DNS failed with error: Global
DNS configuration is missing the default domain
The insistence on existence of [global-dns-domain-*] would make sense if
other [global-dns-domain-...] sections were present.
However, the user might only want to set the options in resolv.conf and
still use connection-provide nameservers for the actual resolving.
Lift the limitation by allowing the [global-dns] to be used alone, while
still insist on [global-dns-domain-*] being there in presence of other
domain-specific options.
https://bugzilla.redhat.com/show_bug.cgi?id=2019306
This effectively makes [*global-dns-domain-*] sections in configuration be
ignored unless [*global-dns] is also present. This happens because
nm_config_keyfile_has_global_dns_config() mixes the group names up and
attempts to loop up [.intern.global-dns-domain-*] in user configuration and
[global-dns-domain-*] in the internal one.
Fixes: da0ded4927 ('config: drop global-dns.enable option in favor of .config.enable')
Fixes: 096b9955d6 ('contrib/fedora: make "lto" in the spec file configurable')
Fixes: 7a62845424 ('contrib/rpm: fix condition in "NetworkManager.spec"')
Fixes: 096b9955d6 ('contrib/fedora: make "lto" in the spec file configurable')
Fixes: 7a62845424 ('contrib/rpm: fix condition in "NetworkManager.spec"')
When we build a copr image, we run the "nm-copr-build.sh" script.
That script, should honor "LTO=0|1|" to explicitly enable/disable
LTO. Since the copr script only builds a SRPM, which then gets build
we need that the default LTO flag in the SRPM is templated.
Fixes: 0566e9dc63 ('contrib: support disabling "LTO" in "nm-copr-build.sh"')
The "nm-copr-build.sh" script is run by our copr to generate the SRPM of
NetworkManager (via `curl ... | bash`).
Building with LTO takes a long time, for testing it can be nice to disable
that. Add an environment variable for that. It can be used when manually
building an RPM in copr.
With the meson build configuration, there is obviously python3 installed
and in the path. The build script will pick that up as preferred python.
However, we will also need working pygobject to build the documentation.
But we only have that for python2 installed. Fix that, by installing
"python36-gobject".
We have "BuildRequires: ppp-devel". While in Fedora 37 that has a
dependency on "ppp" package, that is not the case on Centos7. I didn't
test others, but the point is it's not always there.
"/usr/sbin/pppd" is provided by "ppp" package, and we might not have it
installed via the build requirements. But we only need it to detect the
path, which is not necessary on RHEL/Fedora. Just set the path
explicitly with the respective configure option.
It is possible that an ra leads to two routes having
the same prefix as well as the same prefix length.
One of them, however, refers to the on-link prefix,
and the other one to a route from the route information field.
(Moreover, they might have different route preferences.)
Hence, if both routes differ in the on-link property,
both are added, and the route from the route information
option receives a metric penalty.
Fixed#1163.
(cherry picked from commit 11832e2ba3)
It is possible that an ra leads to two routes having
the same prefix as well as the same prefix length.
One of them, however, refers to the on-link prefix,
and the other one to a route from the route information field.
(Moreover, they might have different route preferences.)
Hence, if both routes differ in the on-link property,
both are added, and the route from the route information
option receives a metric penalty.
Fixed#1163.
Obviously, it would be nice if our unit tests are fast. However, with
valgrind and a busy machine, some of the tests can take a relatively
long time. In particular those, that are marked as "slow" (if you want
to skip them during development, do so via "NMTST_DEBUG=quick"
environment, or "CFLAGS=-DNMTST_TEST_QUICK=TRUE", see
"nm-test-utils.h").
Anyway. Our tests almost never hit the timeout, and if they do, the most
likely reason is that something was just slower then expected, and the
timeout is a bogus error.
Timeouts only act as last fail safe. It more important to avoid a false
(premature) timeout failure, than to minimize the wait time when the
test really hangs. Because a real hang is a bug anyway, that we will
discover and need to fix.
Increase the default test timeout for meson tests to 3 minutes.
Also, "test-route-linux" is known to take a long time. Increase that
timeout even further.
It's not clear why this happens. But since recently in our gitlab-ci,
all the Fedora machines will fail. It happens in the step
check_run_clean 6 && test $IS_FEDORA = 1 -o $IS_CENTOS = 1 && ./contrib/fedora/rpm/build_clean.sh -g -w crypto_gnutls -w debug -w iwd -w test -W meson
which explains why it only affects Fedora configurations.
It does not always fail, but the probability of failure is high.
The failure is:
...
rm -f et.gmo && /usr/bin/msgmerge --for-msgfmt -o et.1po et.po NetworkManager.pot && /usr/bin/msgfmt -c --statistics --verbose -o et.gmo et.1po && rm -f et.1po
libgomp: Thread creation failed: Resource temporarily unavailable
make[3]: *** [Makefile:383: et.gmo] Error 1
Maybe some new resource restricting in gitlab. Let's add this workaround.
I don't really understand the cause, but this seems to avoid it, which is
good enough for me.
When we run `NM_TEST_SELECT_RUN=x ./.gitlab-ci/run-test.sh` to run one
step only, we should not do the final clean, so that the build artifacts
are preserved.
When we register/unregister a commit-type or when we add/remove a
config-data to NML3Cfg, that act only does the registration/addition.
Only on the next commit, are the changes actually done. The purpose
of that is to add/register multiple configurations and commit them later
when ready.
However, it would be wrong to not do the commit a short time after. The
configuration state is dirty with need to be committed, and that should
happen soon.
Worse, when a interface disappears, NMDevice will clear the ifindex and
the NML3Cfg instance, thereby unregistering all config data and commit
type. If we previously commited something, we need to do another follow-up
commit to cleanup that state.
That is for example important with ECMP routes, which are registered in
NMNetns. When NML3Cfg goes down, it always must unregister to properly
cleanup. Failure to do so, causes an assertion failure and crash. This
change fixes that.
Fix that by automatically schedule and idle commit on
register/unregister/add/remove of commit-type/config-data.
It should *always* be permissible to call a AUTO commit from
an idle handler, because various parties cannot use NML3Cfg
independently, and they cannot know when somebody else does a
commit.
Note that NML3Cfg remembers if it presiouvly did a commit
("commit_type_update_sticky"), so even if the last commit-type gets
unregistered, the next commit will still do a sticky update (one more
time).
The only remaining question is what happens during quitting. When
quitting, NetworkManager we may want to leave some interfaces up and
configured. If we were to properly cleanup the NML3Cfg we might need a
mechanism to handle that. However, currently we just leak everything
during quit, so that is not a concern now. It is something that needs
to be addressed in the future.
https://bugzilla.redhat.com/show_bug.cgi?id=2158394https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1505
Routes can be added with `ip route add|change|replace|append|prepend`.
Add a test that randomly tries to add such routes, and checks that
the cache stays consistent.
https://bugzilla.redhat.com/show_bug.cgi?id=2060684
