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
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.
It attempts to modify attributes clearly belong to TestNmcli such as
_skip_test_for_l10n_diff or call methods that are in unittest.TestCase:
======================================================================
ERROR: test_002 (__main__.TestNmcli.test_002)
----------------------------------------------------------------------
Traceback (most recent call last):
File ".../src/tests/client/test-client.py", line 1508, in f
self.ctx.run_post()
~~~~~~~~~~~~~~~~~^^
File ".../src/tests/client/test-client.py", line 1185, in run_post
self.fail(
^^^^^^^^^
AttributeError: 'NMTestContext' object has no attribute 'fail'
It has presumably been moved out of TestNmcli at some point, but that
seems to have been in error, as it's also pretty specific to the nmcli
test cases. Not useful for cloud-init tests that also utilize
NMTestContext. Move it back.
Right now, on any baremetal only max. 2 physical NICs are available.
This might change in the future, so better to directly accept larger
nicIndex if we receive it. No behaviour change with this, just remove
an artificial limit.
There is no need to avoid including the full header, they are small
headers with some GLib type system stuff and no more. Just include them
where they are needed.
If the connection didn't exist in advance, there's no unrealized device,
and find_device_by_iface() is not going to get us one.
Call system_create_virtual_device() afrer nm_utils_complete_generic()
completes the connection for virtual devices. Make sure we do proper
cleanup if we happen to fail the activation later, so that de device
doesn't end up hanging there.
Make validate_activation_request() only do the validation -- split the
determination of the device into find_device_for_activation().
The point of this is to be able complete the connection and actually
create a virtual device after the validation.
I believe this is also somewhat easier to follow now that the procedure
does what its name says.
The point is to get rid of device/connection type specific arguments, to
eventually be able to complete the connection on AddAndActivate before knowing
which factory is going to take care of creating the device.
Aside from that, the whole thing is pretty awful -- with complicated
macros and variadic argument (ugh). Let's get rid of that.
All of these are wrong asserting that a connection has a particular
setting. On AddAndActivate, the connection can be pretty much empty:
impl_manager_add_and_activate_connection ()
validate_activation_request ()
nm_manager_get_best_device_for_connection ()
iface = nm_manager_get_connection_iface ()
find_parent_device_for_connection ()
nm_device_factory_get_connection_parent () <====== *shriek*
nm_device_factory_get_connection_iface ()
find_device_by_iface (iface)
nm_device_complete_connection ()
Remove those assertions.
Some of them are wrong: they assert a connection has a particular
setting even though this can be called on AddAndActivate against a
connection that is not complete or normalized:
impl_manager_add_and_activate_connection ()
validate_activation_request ()
nm_manager_get_best_device_for_connection ()
iface = nm_manager_get_connection_iface ()
find_parent_device_for_connection ()
nm_device_factory_get_connection_parent ()
nm_device_factory_get_connection_iface () <====== here
find_device_by_iface (iface)
nm_device_complete_connection ()
Fix those by removing the assertions.
Some of them are also fall back to just calling
nm_connection_get_interface_name() which is a pretty useless thing to do
because nm_device_factory_get_connection_iface() only calls the
device-specific routine if nm_device_factory_get_connection_iface()
doesn't return anything, to give the factory a chance to make up a name
(like <parent>.<vlan-id> for Vlan) on its own. Drop those.
The current approach is flawed. During a commit of the L3
configuration we do a RTM_GETROUTE to find the next-hop to the DNS
server on the current interface, in order to create the DNS route to
inject into the l3cd. However, we haven't added routes to kernel yet
and so the result of the RTM_GETROUTE is going to be wrong.
In some cases, for example when IPv4 DAD is enabled, the bug can't be
easily noticed because we perform multiple commits for the interface,
and the regular routes are already set in kernel from the 2nd commit
on.
To fix the problem, do the following: during a commit we first add
addresses and routes to platform. Then, we create a list of DNS routes
to configure, we collect the old DNS routes, and do a comparison. If
they changed, we need to add the DNS routes to platform in a 2nd step.
Note that in the previous approach we tracked the routes in the
committed-l3cd object of the l3cfg, and so they were applied to kernel
automatically. Because of the 2-step requirement, that no longer works
and we must apply the DNS routes manually.
Fixes: 5449b18a94 ('core: support automatically adding DNS routes')
Don't try to add the routing rule that points to the table containing
DNS routes at every commit.
Instead, look into the platform cache to see if the rule already
exists and add it only when needed.
Using `n_dhcp4_c_connection_start_request()` will cause staying in
`connection->request`, as a result, it will cause the resending of
DHCPRELEASE and DHCPDECLINE message, thus, use
`n_dhcp4_c_connection_send_request()` directly instead to avoid
unnecessary retransmission timeout, as suggested by
f030927a54 (r1531834009).
We should not send the DHCP release message when udp socket is still in
the PACKET state, this state is typically used during the discovery and
offer phases, where the client broadcasts DHCP packets like DHCPDISCOVER
and receives responses like DHCPOFFER. At this point, the client has no
lease because it has not yet completed the DHCP handshake.
In the scenario for sending the release message, we need to guarantee
that NM only sends the release message when the client received a lease
from the server. However, there is some distinction between the
`l3cd_curr` and `l3cd_next` when ACD is pending, because `l3cd_curr` is
NULL but `l3cd_next` is not NULL when ACD is pending. Regardless of
whether ACD is pending or completed, these are all considered the client
have received the release from the server. Therefore, adapt the function
`nm_dhcp_client_get_lease()` to control whether to get next or current
lease.
In the "Action()" D-Bus method, the "nameservers" key used to contain
an array of binary addresses. If we change the key to contain
something else, there can be problems when the NM and the
NM-dispatcher versions mismatch (right after an upgrade or a
downgrade).
To avoid such problem, still send the old key in the old format, and
introduce a new key for the new format. The new format carries the
name servers as a string list, and can encode encrypted DNS servers.
Introduce a new kernel command line option named "rd.net.dns" that can
be used to specify a global name server. It accepts name server in a
URI-like form, as for example:
rd.net.dns=dns+tls://[fd01::1]:5353#mydomain.com
