PyGObject 3.52 switched from gobject-introspection’s libgirepository 1.0
to glib’s libgirepository 2.0. As a result, the Python script would
no longer be able to find the `GIRepository` 2.0 typelib:
(process:1944): GLib-GIRepository-DEBUG: 15:25:14.521: Ignoring GIRepository-2.0.typelib because this libgirepository corresponds to GIRepository-3.0.typelib
We could update the script to support both versions of the typelib
but it is not really necessary. It was only used to add extra directories
from `$LD_LIBRARY_PATH` and the CLI argument to repository’s library path
but libgirepository already supports using `LD_LIBRARY_PATH` directly:
https://docs.gtk.org/girepository/method.Repository.prepend_library_path.html
Add some missing "(nullable)" annotations to parameters of the
callback functions in NMSecretAgentOld. Otherwise, PyGObject complains
that those parameters cannot be NULL when implementing a secret agent.
Fixes: d595f7843e ('libnm: add libnm/libnm-core (part 1)')
If an alias like `nmcli=nmcli --some-arguments` is used, bash completion
doesn't work. Fix it by using `command nmcli` from the nmcli-completion
script, so we ensure that the --complete-args is passed directly to
nmcli binary, not through an alias.
Contributed-by: Jonas Belouadi (@potamides)
Fixes https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1734
DBus errors were not properly handled after DBus calls and
that caused SIGSEGV. Now they are checked.
Fixes#1738
Fixes: b8714e86e4 ('dns: introduce configuration_serial support to the dnsconfd plugin')
Prevents NetworkManager from trying to determine the
transient hostname via DHCP or other means if "localhost"
is already configured as a static hostname, as the transient
hostname will be ignored by hostnamed if a static hostname
has already been set.
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.
This reverts commit 87d7ccc580.
This will be useful for updating configuration of Vlans and MacVlans,
some of having same MAC addresses as devices of other type.
This reverts commit cee0515f13.
This is done so that AddAndActivate() will return sensible errors in a
future patch that makes it support creating virtual devices.
In effect, all errors are logged in one place, therefore the log levels
are different. I don't think we're losing anything of value by being
a little less verbose here.
Domains are exported via D-Bus and so they must be valid UTF-8.
RFC 1035 specifies that domain labels can contain any 8 bit values,
but also recommends that they follow the "preferred syntax" which only
allows letters, digits and hypens.
Don't introduce a strict validation of the preferred syntax, but at
least discard non UTF-8 search domains, as they will cause assertion
failures later when they are sent over D-Bus.
Skip the configuration of the MPTCP endpoint when the address is in
the l3cd but is not yet configured in the platform. This typically
happens when IPv4 DAD is enabled and the address is being probed.
If we configure the endpoint without the address set, the kernel will
try to use the endpoint immediately but it will fail. Then, the
endpoint will not be used ever again after the address is added.
The name suggests that the function always removes all the watchers
with the given tag; instead it removes only "dirty" ones when the
"all" parameter is FALSE. Split the function in two variants.
When Dnsconfd service is enabled but not started, NetworkManager
should attempt to start it through DBus at least once.
Fixes: c6e1925dec ('dns: Add dnsconfd DNS plugin')
Preventing the activation of unavailable devices for all device types is
too aggresive and leads to race conditions, e.g when a non-virtual bond
port gets a carrier, preventing the device to be a good candidate for
the connection.
Instead, enforce this check only on OVS interfaces as NetworkManager
just makes sure that ovsdb->ready is set to TRUE.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2139
Fixes: 774badb151 ('core: prevent the activation of unavailable devices')
Stop passing "connection-*" entries in the update method to
dnsconfd. The plugin tries to determine the connection from the
ifindex, but it's not possible to do it right at the moment because
the same ifindex can be used at the same time e.g. by a policy-based
VPN like ipsec and a normal device. Instead, it should be NM that
explicitly passes the information about the connection to the DNS
plugin. Anyway, these variables are not used at the moment by
dnsconfd.
Fixes: c6e1925dec ('dns: Add dnsconfd DNS plugin')
After every state change of the plugin there should be an invocation
of _nm_dns_plugin_update_pending_maybe_changed() to re-evaluate
whether we are waiting for an update. send_dnsconfd_update() doesn't
change the state and so there is need to check again afterwards.
When calling activate_port_or_children_connections() we are unblocking
the ports and children but we are not resetting the number of retries if
it is an internal activation.
This is wrong as even if it's an internal activation the number of
retries should be reset. It won't interferfe with other blocking reasons
like USER_REQUESTED or MISSING_SECRETS.
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
