Add the only important example that this file should have
All other examples are nice. But when you install a console-only
machine and read the NM man pages, you are none the wiser, because
something as simple like this isn't covered in the man pages.
I've seen other users complain about it, and I've torn my hair out
over this several times.
[thaller@redhat.com: changed subject line of patch]
Otherwise, we only prune unused files when the service terminates.
Usually, NetworkManager service doesn't get restarted before shutdown
of the system (nor should it be). That means, if you create (and
destroy) a large number of software devices, the state files pile
up.
From time to time, go through the files on disk and delete those that
are no longer relevant.
In this case, "from time to time" means after we write/update state
files 100 times.
nm_manager_write_device_state() writes the device state to a file. The ifindex
is here important, because that is the identifier for the device and is also
used as file name. Return the ifindex that was used, instead of letting the
caller reimplement the knowledge which ifindex was used.
It was not very clear whether update_dns() would always set the error
output variable if (and only if) it would return false.
Rework the code to make it clearer.
Not using cleanup attribute is error prone.
In theory, a function should only return a GError if (and only if) it
signals a failure. However, for example in commit 324f67956a ('dns:
ensure to log a warning when writing /etc/resolv.conf fails') due to
a bug we was violated. In that case, it resulted in a leak.
Avoid explicit frees and use the gs_free_error cleanup attribute
instead. That would also work correctly in face of such a bug and in
general it seems preferable to explicitly assign ownership to auto
variables on the stack.
When setting "main.rc-manager=symlink" (the default) and /etc/resolv.conf
is a file, NetworkManager tries to write the file directly. When that fails,
we need to make sure to propagate the error so that we log a warning about that.
With this change:
<debug> [1583320004.3122] dns-mgr: update-dns: updating plugin systemd-resolved
<trace> [1583320004.3123] dns-sd-resolved[f9e3febb7424575d]: send-updates: start 8 requests
<trace> [1583320004.3129] dns-mgr: update-resolv-no-stub: '/var/run/NetworkManager/no-stub-resolv.conf' successfully written
<trace> [1583320004.3130] dns-mgr: update-resolv-conf: write to /etc/resolv.conf failed (rc-manager=symlink, $ERROR_REASON)
<trace> [1583320004.3132] dns-mgr: update-resolv-conf: write internal file /var/run/NetworkManager/resolv.conf succeeded
<trace> [1583320004.3133] dns-mgr: current configuration: [{ [...] }]
<warn> [1583320004.3133] dns-mgr: could not commit DNS changes: $ERROR_REASON
<info> [1583320004.3134] device (eth0): Activation: successful, device activated.
https://bugzilla.redhat.com/show_bug.cgi?id=1809181
The GSource must also be unrefed. Also, first clear the field
before invoking callbacks to the upper layers.
Fixes: 843d696e46 ('dhcp: clean source on dispatch failure')
Fix the following warning:
NetworkManager[1524461]: Source ID 3844 was not found when attempting to remove it
g_logv (log_domain=0x7f2816fa676e "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7ffe697374d0) at gmessages.c:1391
g_log (log_domain=log_domain@entry=0x7f2816fa676e "GLib", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7f2816fae240 "Source ID %u was not found when attempting to remove it") at gmessages.c:1432
g_source_remove (tag=519) at gmain.c:2352
nm_clear_g_source (id=<optimized out>) at ./shared/nm-glib-aux/nm-macros-internal.h:1198
dispose (object=0x55f7289b1ca0) at src/dhcp/nm-dhcp-nettools.c:1433
g_object_unref (_object=<optimized out>) at gobject.c:3303
g_object_unref (_object=0x55f7289b1ca0) at gobject.c:3232
dhcp4_cleanup (self=self@entry=0x55f728af3b20, cleanup_type=cleanup_type@entry=CLEANUP_TYPE_DECONFIGURE, release=release@entry=0) at src/devices/nm-device.c:7565
...
Fixes: 45521b1b38 ('dhcp: nettools: move to failed state if event dispatch fails')
The 'Before' dependency between NM-dispatcher and NM causes a deadlock
when stopping the NM service. When terminating, NM wants to D-Bus
activate NM-dispatcher to synchronously handle pre-down events; but
NM-dispatcher start is ordered after NM shutdown due to the following
behavior described in systemd.unit(5) man page:
Given two units with any ordering dependency between them, if one
unit is shut down and the other is started up, the shutdown is
ordered before the start-up. It doesn't matter if the ordering
dependency is After= or Before=, in this case. It also doesn't
matter which of the two is shut down, as long as one is shut down
and the other is started up; the shutdown is ordered before the
start-up in all cases.
So, NM is waiting NM-dispatcher to start and NM-dispatcher is queued
by systemd, waiting that NM is stopped. The result is a 90 seconds
delay, after which systemd kills NM and continues.
The dependency was added so that during shutdown NM-dispatcher would
be stopped after NM. I don't think it worked as expected because
NM-dispatcher is not supposed to be active most of the times, and so
it doesn't need a dependency that delays its stop after NM.
This reverts commit acc335aad4.
Move the assertion for valid LIST first. It only checks static data,
and regardless of the entry_cmd, it should be done first.
Fixes: f4d12f7b59 ('shared: add NM_UTILS_STRING_TABLE_LOOKUP_STRUCT_DEFINE() macro for lookup of structs')
Just looking at the hashtable entry of 'updelay' and 'downdelay' options
is wrong, we have to inspect their values to check if they're
actually enabled or not.
Otherwise bond connections with valid settings will fail
when created:
$ nmcli c add type bond ifname bond99 bond.options miimon=0,updelay=0,mode=0
Error: Failed to add 'bond-bond99' connection: bond.options: 'updelay' option requires 'miimon' option to be set
Also add unit tests.
https://bugzilla.redhat.com/show_bug.cgi?id=1805184
Fixes: d595f7843e ('libnm: add libnm/libnm-core (part 1)')
Don't spread the validation for the interface name between multiple
places. There should be one place only, so when you search for how
this property gets verified, you can find the single place.
That requires to move the special handling for OVS interfaces to
NMSettingConnection.
Since we already have _nm_setting_ovs_interface_verify_interface_type(),
that is easy.
Depending on the type, OVS interfaces also have a corresponding netdev
in kernel (e.g. type "internal" does, type "patch" does not).
Such a case is neither NMU_IFACE_OVS nor NMU_IFACE_KERNEL (alone). There should
be a special type to represent those cases.
Add NMU_IFACE_OVS_OR_KERNEL for that.
nm_utils_ifname_valid() is to validate "connection.interface-name"
property. But the exact validation depends on the connection type.
Add "NMU_IFACE_ANY" to validate the name to check whether it would be
valid for any connection type.
This is for completeness and for places where the caller might not know
the connection type.
We should return the chosen type whenever we can verify the setting.
Previously, the normalized-type output argument was only set when
normalization was actually necessary.
On most cases, the caller cares whether the setting verifies and which
interface type is chosen. It's much less likely that a caller cares
only about the normalized-type if normalization is actually necessary.
Whenever we return TRUE (indicating that the setting is valid), also
return the chosen interface-type.
_nm_setting_ovs_interface_verify_interface_type() does verify and
normalize both. Especially for verify, it's useful to run the operation
without having a NMSettingOvsInterface instance, because we might
want to know how normalization would react, if we had a
NMSettingOvsInterface instance.
Allow for that.
Maybe the reader should not try to add its own validation. It
could just read the value, set it in the profile, and let
nm_connection_verify() handle it.
However:
- in this form the code only logs a warning about invalid setting.
If we let it come to nm_connection_verify(), the connection profile
will be entirely rejected. I think this makes sense, because ifcfg
files may be edited by the user and we don't know what is out there.
- it's nicer to show a warning that specifically mentions the DEVICE=
variable. There error message we get from nm_connection_verify()
is no longer aware of ifcfg peculiarities.
Instead: use the appropriate validation function.
The interface-name property has several deprecated aliases, like
"bridge.interface-name". For backward compatibility, we keep handling
them.
In particular, the "missing_from_dbus_fcn" handler is set. This handles
the case where GVariant only contains the deprecated form, but not
"connection.interface-name".
Previously, from_dbus_fcn() would check whether the deprecated form was
present, and -- only if that form was invalid -- prefer it. The idea was
to fail validation if the deprecated property was invalid.
I think that is not necessary. Just completely ignore the deprecated property,
if the new property is present.
What might make sense is to check whether the deprecated and the new
form are both present, that they are identical. However, I don't think
that is worth the effort.
We use the filename of the imported .conf file for "connection.interface-name".
That follows what `wg-quick` does.
However, we also validate that the interface name is valid UTF-8
(otherwise -- as it currently is -- the setting couldn't be send via
D-Bus). As such, we have stricter requirements.
We want to fail early and tell the user when the filename is unsuitable.
Failing later gives a worse user experience, because the failure message
about invalid "connection.interface-name" wouldn't make it clear that
the filename is wrong.
Use the appropriate function to validate "connection.interface-name".
Before:
$ touch $'./a\344b.conf'
$ nmcli connection import type wireguard file $'./a\344b.conf'
Error: failed to import './a?b.conf': Failed to create WireGuard connection: connection.interface-name: 'a?b': interface name must be UTF-8 encoded.
Now:
$ nmcli connection import type wireguard file $'./a\344b.conf'
Error: failed to import './a?b.conf': The name of the WireGuard config must be a valid interface name followed by ".conf".
There should not be multiple places to validate the interface-name.
The check in "nm-setting-infiniband.c" is unnecessary and wrong.
It's unnecessary, because _nm_connection_verify() takes care to
first verify the NMSettingConnection instance.
It's wrong, because it does not check the property the same way as
NMSettingConnection does (e.g. it does not check for valid UTF-8).
Fully sort the settings in _nm_connection_verify(). Previously, only the
NMSettingConnection instance was sorted first (as required). The remaining
settings were in undefined order. That means, we would validate settings
in undefined order, and if multiple settings have an issue, the reported
error would be undefined.
Instead, use nm_connection_get_settings() which fully sorts the settings
(and of course, sorts NMSettingConnection first as we require it).
Also, this way we no longer need to allocate multiple GSList instances
but only malloc() one array large enough to contain all settings.
"all" and "default" never works.
"bonding_masters" works if you unload the bonding module. Well,
that should not really be called working...
Reject these names.
Generally, it's dangerous to reject values that were accepted
previously. This will lead to NetworkManager being unable to load
a profile from disk, which was loadable previously.
On the other hand, kernel would not have treated this setting as
it was intended. So, I would argue that the such a setting was not
working (as intended) anyway.
We can only hope that users don't configure arbitrary interface names.
It generally isn't a good idea to do, so "breaking" such things is less
of a concern.
It's very unlikely that we have actual blobs for a Wi-Fi network.
That is because the settings plugins (keyfile, ifcfg-rh) convert
blobs to files on disk when writing the profile. So, you can only
have them by editing the files directly to contain blobs.
At that point, don't always create the GHashTable for blobs.
Fail the enslavement of the ovs port if the bridge device is not
found, instead of generating assertions and potentially crash later.
https://bugzilla.redhat.com/show_bug.cgi?id=1797696
Fixes: 101e65d2bb ('ovs: allow changing mac address of bridges and interfaces')
The previous code tried to get the bridge active connection and it
used the port active connection instead in case of failure. This
doesn't seem right, as in nm-ovsdb.c the bridge AC is used to get the
bridge settings (including the uuid, interface name, and cloned mac).
In case of failure getting the bridge AC we should just fail.
Fixes: 830a5a14cb ('device: add support for OpenVSwitch devices')
Currently if an error is encountered during a send() of a message, the
client fails and there is no possibility of recover, since no timers
are armed after a failed event dispatch. An easy way to reproduce a
failure is to add a firewall rule like:
iptables -A OUTPUT -p udp --dport 67 -j REJECT
which makes the send() fail with EPERM during the renew. In such case,
the client should continue (failing) until it reaches the rebind phase
at T2, when it will be able to renew the lease using the packet
socket.
In general, a failure to send a packet should not cause the failure of
the client.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/419https://bugzilla.redhat.com/show_bug.cgi?id=1806516
