In the future we might want to specify filters when requesting netlink
dumps; this requires that strict check is enabled on the socket.
When enabling strict check, we need to pass a full struct in the
netlink message, otherwise kernel ignores it.
This commit doesn't change behavior.
Adds an option in the connectivity section to change the timeout before
the interface is deemed "limited". Previously, it was hardcoded to
20 seconds, but for our usecase (failing over to cell modem if
hardwired ethernet drops), it's nice to be able to failover to another
interface more quickly.
The OVS interface can be matched via MAC address; in that case, the
"connection.interface-name" property of the connection is empty.
When populating the ovsdb, we need to pass the actual interface name
from the device, not the one from the connection.
Fixes: 830a5a14cb ('device: add support for OpenVSwitch devices')
https://issues.redhat.com/browse/RHEL-34617
Currently, the Dockerfile expects /etc/systemd/journald.conf to exist on the base container,
but sometimes this may not be the case, for example on Fedora 40, which causes
the build process to fail if the host machine is also running Fedora 40.
Update the dockerfile to create a conf.d file instead, which has higher precedence.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1972
The comment makes it sounds as if we could do without CAP_DAC_OVERRIDE
if we don't use OpenVSwitch, which is not true. At the very least it's
needed by the VPN plugins we spawn to access cert/key material from
users' homes.
For [connection*] and [device*] sections, any suffix is allowed in
the group.
However (at least for configuration snippets we ship upstream), we
want to give a suffix that matches the name of the configuration
snippet.
It seems more common to use [connection-*] instead of [connection.].
See also "examples/nm-conf.d/*.conf" and "15-carrier-timeout.conf" file
which contains a [device-15-carrier-timeout] section.
Note that this file (in Fedora) is not configuration (installed in
/usr/lib). It is thus not problematic to modify.
Fixes: ea8dbd7a6d ('contrib/rpm: add "22-wifi-mac-addr.conf" to F40+')
The group interface is only used during activation; there is no need
to add a pending action for it, because when the device is in
activating state it already delays "startup-complete" via other
pending actions.
The daemon is now capable of understanding and removing these prefix
tags by itself. It is better than this is not a responsibility of the
secret agent because it requires changes in all secret agents to work
properly (see https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1536).
If the secret agent knows what these prefix tags are, it can remove them
only in the text that is displayed in the UI, but maintaining the
original string as the secret name that is returned to the daemon.
Secret agents that doesn't know what these prefix tags are won't do
anything with them, and they will also return the same string as secret
name, as expected. The only drawback is that they might display the full
string to the user, which is not a nice UX but it will at least work.
Also, allow to translate the secret name for the UI in libnmc.
Commit 345bd1b187 ('libnmc: fix secrets request on 2nd stage of 2FA
authentication') and commit 27c701ebfb ('libnmc: allow user input in
ECHO mode for 2FA challenges') introduced 2 new tags that hints for the
secret agents can have as prefix.
These tags were processed (and removed) in the secret agents, not in the
daemon. This is wrong because a system with an updated VPN plugin but a
not yet updated secret agent (like nm-plasma) will fail: it won't remove
the prefix and the daemon will save the secret with the prefix, i.e.
"x-dynamic-challenge:challenge-response" instead of just
"challenge-response". Then, VPN plugins doesn't recognize it, failing the
profile's activation. This is, in fact, an API break.
Also, if the VPN connection already existed before updating NM and the
VPN plugin, the secret flags are not added to the profile (they are only
added when the profile is created or modified). This causes the user's
first time response is saved to the profile, so the activation fails the
second and next times.
See:
- https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1536
- https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/issues/142
Anyway, in a good design the daemon should contain almost all the logic
and the clients should keep as simple as possible. Fix above's problems
by letting the daemon to receive the secret names with the prefix
already included. The daemon will strip it and will know what it means.
Note that this is done only in the functions that saves the secrets from
the data received via D-Bus. For example, nm_setting_vpn_add_secret
doesn't need to do it because this value shouldn't come from VPN
plugin's hints.
Add explanation of how to indicate the new issues workflow to
MAINTAINERS.md: triage -> investigation -> devel. The different
stages are indicated using Gitlab's scoped labels (mutually exclusive).
These stages try to hightlight that the issue cannot be fixed and it's
not moving forward because more info is needed, already. Also, add a
section to CONTRIBUTING.md highlighting the importance of helping in
the triage and investigation stages: developers often cannot fix bugs
because lack of time to investigate, but even users that doesn't know
how to fix it due to lack of knowledge of the code base can help thanks
to their knowledge on networking.
Finally, make the 'triage:issues' CI job to work again, adding some
new policies with new automations. The automation will add or remove the
labels: stale, help-needed::{triage, investigation, devel} and
unassigned.
The labels help-needed::* and unassigned will be automatically added to
all issues without an assignee. This reflects better the reality of not
having enough time to work on most of the issues unless there is some
external help.
Translatable strings were added to nm-setting-generic.c. Add this file to
POTFILES.in.
Fixes: 9322c3e9db ('libnm: add generic.device-handler property')
(cherry picked from commit f84282a880)
Note: here I refer to the numbers in a version as MAJOR.MINOR.MICRO.
Having stable and development releases do make sense for the MINOR
version, because we maintain separate branches for them and they
evolve separately. We have 1.47.z where we put all the changes so
anyone can pick the latest development release and test it. At the
same time, we have 1.46.z with the latest stable released version.
However, it does not make sense to have 1.46.2 and 1.46.3-dev because
the latter is not a development version. It is identical to 1.46.2,
only the version number has been bumped, there are no changes to test.
When we add commits, we will be actually testing 1.46.3-dev + some
commits, which is exactly the same as testing 1.46.2 + some commits.
So, basically, someone can use the releases of a development BRANCH,
like 1.47.4, to test the development version of NM. But using a
development MICRO version is exactly the same as using a
non-development one.
From now on, we will just increment the MICRO version each time we do a
release on a stable branch and won't create the '-dev' tag. Update
release.sh to do it this way.
(cherry picked from commit 8eb00c0991)
With the deprecation of autotools, use meson by default. For the moment,
it's still possible to build with autotools passing -a/--autotools.
Additionally, as we allow to specify different build directories other
than './build', let's not asume that the user wants to overwrite it
by default. Instead, the script will asume ./build if the user doesn't
specify the build directory, but only if it doesn't exist. If it does,
the user will have to force overwritting it with `--meson ./build`.
Instead of forcing to use ./build directory, let's make the the user
specify what directory he wants to use. This will allow to have multiple
build directories with different configurations as meson is designed to
allow, without having to overwrite the existing build one.
