When autoconnecting ports of a controller, we look for all candidate
(device,connection) tuples through the following call trace:
-> autoconnect_ports()
-> find_ports()
-> nm_manager_get_best_device_for_connection()
-> nm_device_check_connection_available()
-> _nm_device_check_connection_available()
The last function checks that a specific device is available to be
activated with the given connection. For virtual devices, it only
checks that the device is compatible with the connection based on the
device type and characteristics, without considering any live network
information.
For OVS interfaces, this doesn't work as expected. During startup, NM
performs a cleanup of the ovsdb to remove entries that were previously
added by NM. When the cleanup is terminated, NMOvsdb sets the "ready"
flag and is ready to start the activation of new OVS interfaces. With
the current mechanism, it is possible that a OVS-interface connection
gets activated via the autoconnect-ports mechanism without checking
the "ready" flag.
Fix that by also checking that the device is available for activation.
Rename "unavailable_devices" to "exclude_devices", as the
"unavailable" term has a specific, different meaning in NetworkManager
(i.e. the device is in the UNAVAILABLE state). Also, use
nm_g_hash_table_contains() when needed.
The current mess of code seems like a hodgepodge of complex ideas,
partially copied from systemd, but then subtly different, and it's a
mess. Let's simplify this drastically.
First, assume that getrandom() is always available. If the kernel is too
old, we have an unoptimized slowpath for still supporting ancient
kernels, a path that should be removed at some point. If getrandom()
isn't available and the fallback path doesn't work, the system has much
larger problems, so just crash. This should basically never happen.
getrandom() and having randomness available in general is a critical
system API that should be expected to be available on any functioning
system.
Second, assume that the rng is initialized, so that asking for random
numbers should never block. This is virtually always true on modern
kernels. On ancient kernels, it usually becomes true. But, more
importantly, this is not the responsibility of various daemons, even
ones that run at boot. Instead, this is something for the kernel and/or
init to ensure.
Putting these together, we adopt new behavior:
- First, try getrandom(..., ..., 0). The 0 flags field means that this
call will only return good random bytes, not insecure ones.
- If this fails for some reason that isn't ENOSYS, crash.
- If this fails due to ENOSYS, poll on /dev/random until 1 byte is
available, suggesting that subsequent reads from the rng will almost
have good random bytes. If this fails, crash. Then, read from
/dev/urandom. If this fails, crash.
We don't bother caching when getrandom() returns ENOSYS. We don't apply
any other fancy optimizations to the slow fallback path. We keep that as
barebones and minimal as we can. It works. It's for ancient kernels. It
should be removed soon. It's not worth spending cycles over. Instead,
the goal is to eventually reduce all of this down to a simple boring
call to getrandom(..., ..., 0).
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2127
Add support for two new command line arguments:
- `rd.net.dns-backend` used to control the "dns" option in
NetworkManager configuration;
- `rd.net.dns-resolve-mode` used to control the "resolve-mode" in the
global DNS configuration.
The use case for them is the installation of a new system where the
administrator wants to configure aspects of the DNS resolution
starting from the early boot, for example to enable DNS over TLS and
avoid that any query goes out unencrypted.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2123
Move nm_keyfile_add_group() to libnm-glib-aux so that it can be used
by other components such as nm-initrd-generator. Rename it to
nm_key_file_add_group() to be consistent with the GLib API names
(g_key_file_*()).
Add the DNS routing rules explicitly instead of tracking them via the
NMGlobalTracker mechanism. Since we do not plan to ever remove them,
there is no reason to track the rules. Also, the current
implementation is buggy because in some situations the rules are
wrongly removed when they should not.
Fixes: bf3ecd9031 ('l3cfg: fix DNS routes')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2125
"configuration_serial" dbus property ensures that the plugin
can mark update 'not pending' when the update is trully finished.
This mechanism exists because of underlying problem of having
to restart, or perform similarly time consuming operation, to change
certain configuration parameters of resolver. If Dnsconfd would
block the update call until the update is finished, we could not
respond to any other requests until the call is finished.
Resolve-mode allows user to specify way how the global-dns domains
and DNS connection information should be merged and used.
Certification-authority allows user to specify certification
authority that should be used to verify certificates of encrypted
DNS servers.
Fix the following error with GCC 15:
../src/libnm-glib-aux/nm-shared-utils.c:35:42: error: initializer-string for array of 'char' is too long [-Werror=unterminated-string-initialization]
35 | const char _nm_hexchar_table_lower[16] = "0123456789abcdef";
| ^~~~~~~~~~~~~~~~~~
../src/libnm-glib-aux/nm-shared-utils.c:36:42: error: initializer-string for array of 'char' is too long [-Werror=unterminated-string-initialization]
36 | const char _nm_hexchar_table_upper[16] = "0123456789ABCDEF";
| ^~~~~~~~~~~~~~~~~~
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2116
This resulted in what looked like more significant bits of GType pointer
sometimes falling off the cliff, presumably because of a cast to
NMDeviceType enum (that probably ends up actually being a char).
This was silent enough to not emit compiler warnings and only occurring
with some very rare situations (needs GCC with LTO and some of the
optimization flags used by Fedora 41).
Fixes: cf6af54ffa ('cloud-setup: allow VETH along with ETHERNET too')
Fixes: 6ff4b9e57c ('cloud-setup: create VLANs for multiple VNICs on OCI')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2119
Always explicitly tear down pexpect instances and collect their
results. Assert on the results after orderly teardowns.
Track the current pexpect instance in test context so that it could be
still collected if the test blows up. That could provide more clue into
what went wrong in the test if it's due to a crash the testee.
Before:
[1573928.02238] <debug> config device C0:00:00:00:00:10: creating vlan connection for VLAN 700 on C0:00:00:00:00:10...
[1573928.02330] <debug> config device C0:00:00:00:00:10: connection "vlan2" (ac3c08f5-3e5c-38a3-a366-c16253de6db2) created
======================================================================
ERROR: test_oci_vlans (__main__.TestNmCloudSetup.test_oci_vlans)
----------------------------------------------------------------------
Traceback (most recent call last):
...
pexp.expect("some changes were applied for provider oci")
~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
pexpect.exceptions.EOF: End Of File (EOF). Exception style platform.
After:
[1573928.02238] <debug> config device C0:00:00:00:00:10: creating vlan connection for VLAN 700 on C0:00:00:00:00:10...
[1573928.02330] <debug> config device C0:00:00:00:00:10: connection "vlan2" (ac3c08f5-3e5c-38a3-a366-c16253de6db2) created
*** pexpect'd process killed by SIGABRT ***
======================================================================
ERROR: test_oci_vlans (__main__.TestNmCloudSetup.test_oci_vlans)
----------------------------------------------------------------------
Traceback (most recent call last):
...
pexp.expect("some changes were applied for provider oci")
~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
pexpect.exceptions.EOF: End Of File (EOF). Exception style platform.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2119
Allow running the following locally (for quick loval nm-c-s valgrind check),
without requiring $NM_TEST_CLIENT_NMCLI_PATH to be set.
$ NM_TEST_CLIENT_CLOUD_SETUP_PATH=build/src/nm-cloud-setup/nm-cloud-setup \
NMTST_USE_VALGRIND=1 python src/tests/client/test-client.py TestNmCloudSetup
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2119
The list describing the order of DHCP clients is confusing because it
doesn't take into account what clients are disabled at build
time. Instead, just show the available clients in the preferred order.
Describe in the NetworkManager.conf man page what DHCP clients the
user can set in this build, instead of showing a generic list and
letting the user try each one.
Pairs of veth devides are used for CI testing in place of real
ethernets. Use GLib types instead of NM numbers, since it's possible to
match them in hierarchical manner, with NMDeviceVeth being a subclass of
NMDeviceEthernet.
Fixes: 6ff4b9e57c ('cloud-setup: create VLANs for multiple VNICs on OCI')
The idea is to create a pair of VLAN and MACVLAN with AddAndActivate if
they are not present, and otherwise follow the ordinary (GetApplied &
Reapply) procedure if the devices are already present.
