NMManager and NMSettings both may have multiple authorization requests
ongoing. They need to keep track of them, at the very least to be able
to cancel them on shutdown.
Since NMAuthChain is not ref-countable, it always has only one clear
user/owner. It makes little sense otherwise. Since most callers already
want to track their NMAuthChain instances, let NMAuthChain help with that.
Embed a "parent" CList field inside NMAuthChain. This avoids requiring
an additional GSList allocation to track the element. Also, it allows to
link and append an element without iterating the list.
This ties the caller and the NMAuthChain a bit tighter together (making them
less indepdendent). Generally that is not desirable. But here it seems the
logic (of tracking the NMAuthChain) is still trivial and well separated.
It's just that NMAuthChain instances now can be linked in a CList.
VPN settings (for openconnect) can only be handled by the keyfile settings
plugin.
In any case, such special casing belongs to the settings plugin and not
"nm-settings.c". The reason is that the settings plugin already has an
intimate understanding of the content of connections, it knows which fields
exist, their meaning, etc. It makes sense special handling of
openconnect is done there.
See also commit 304d0b869b ('core: openconnect migration hack').
Unfortunately it's not clear to me why/whether this is still the
right thing to do.
nm_device_check_connection_compatible() is potentially expensive.
Check first whether the connection candidate is of a relevant type,
hoping that this check is cheaper and thus shortcuts other checks
early.
NMSettings is complicated enough. We should try to move independent code out
of it, so that there is only logic that is essential there.
While at it, rework how we copy the GSList items. I don't like GSList as
a data structure, but there really is no need to allocate a new list.
Just unlink the list element and prepend it in the other list.
As nm_settings_plugin_initialize() could not fail (it returned no value indicating
failure), there is no reason to explicitly call this. Instead just
initialize the plugin when needed.
Also, we don't need the plugin to initialize early before nm_settings_plugin_get_connections().
Instead of
<info> [1558284380.2045] settings: Loaded settings plugin: SettingsPluginIfcfg ("/usr/lib64/NetworkManager/1.19.2/libnm-settings-plugin-ifcfg-rh.so")
log
<info> [1558284380.2045] settings: Loaded settings plugin: ifcfg-rh ("/usr/lib64/NetworkManager/1.19.2/libnm-settings-plugin-ifcfg-rh.so")
Note how `man NetworkManager.conf` documents "main.plugins" configuration
option where settings plugins have names like "keyfile" and "ifcfg-rh".
It's not helpful to log the GObject type name, which is an implementation
detail.
It was only kept to compare whether we loaded the same
plugin multiple times.
Note that load_plugins() already checks for duplicate plugin names,
so it actually could not happen that we tried to load the same file
more than once.
For a "is" check, it's inconvenient to assert against the parameter
being %NULL. We should accept %NULL and just say that it's not a valid
uuid.
This relaxes previous API.
Also drop the paragraph about "autoconf mechanism". The general
guideline is self evident, while it didn't mention meson builds.
Also, a first time contributor likely won't likely be concerned about
this, as this is already advanced.
If the mode is one of '802.3ad', 'tlb' or 'alb' and the connection has
both 'arp_interval' and 'arp_ip_target' options, during normalization
we remove 'arp_interval' because unsupported in the current mode. The
connection then becomes invalid because 'arp_ip_target' requires
'arp_interval'.
Since 'arp_interval' and 'arp_ip_target' are mutually dependent, the
latter should also be unsupported for those bonding modes.
https://bugzilla.redhat.com/show_bug.cgi?id=1718173
The values cached in the device may be stale when we start a new
activation because in a disconnected state we might have called
ip_config_merge_and_apply() which cached the main table value.
Also, plan right away to backport this symbol all the way back to
1.14.8. As such, we only need to add it once, with the right linker
version "libnm_1_14_8".
But still, the symbols first appears on a major release 1.20.0.
The default value is "1", not "0". Also, because "0" is not actually a
valid value as far as teamd is concerned. This fixes:
$ nmcli connection add type team autoconnect no con-name t team.runner lacp team.runner-min-ports default
Error: Failed to add 't' connection: team.runner-min-ports: value out or range
See "teamd.conf" manual:
runner.min_ports (int)
Specifies the minimum number of ports that must be active before asserting
carrier in the master interface, value can be 1 – 255.
Default: 1
This mistake probably happend because the teamd manual is wrong in older versions [1].
[1] f36c191da3https://bugzilla.redhat.com/show_bug.cgi?id=1716987
It's rather limiting if we have no API to ask NMSettingEthtool which
options are set.
Note that currently NMSettingEthtool only supports offload features.
In the future, it should also support other options like coalesce
or ring options. Hence, this returns all option names, not only
features.
If a caller needs to know whether the name is an option name, he/she
should call nm_ethtool_optname_is_feature().
We no longer add these. If you use Emacs, configure it yourself.
Also, due to our "smart-tab" usage the editor anyway does a subpar
job handling our tabs. However, on the upside every user can choose
whatever tab-width he/she prefers. If "smart-tabs" are used properly
(like we do), every tab-width will work.
No manual changes, just ran commands:
F=($(git grep -l -e '-\*-'))
sed '1 { /\/\* *-\*- *[mM]ode.*\*\/$/d }' -i "${F[@]}"
sed '1,4 { /^\(#\|--\|dnl\) *-\*- [mM]ode/d }' -i "${F[@]}"
Check remaining lines with:
git grep -e '-\*-'
The ultimate purpose of this is to cleanup our files and eventually use
SPDX license identifiers. For that, first get rid of the boilerplate lines.
While at it, rename the "addr" field to "l_address". The term "addr" is
used over and over. Instead we should use distinct names that make it
easier to navigate the code.
nmtst_get_rand_int() was originally named that way, because it
calls g_rand_int(). But I think if a function returns an uint32, it
should also be named that way.
Rename.
Maybe DHCP plugins should be configurable per address family and be
re-loadable via SIGHUP. But that just adds complexity.
Nowadays we always have the "internal" DHCP plugin, which is known to
support both IPv4 and IPv6. One day, we should get rid of all plugins
and only use one implementation (that works well). The "internal" plugin
is supposed to be(come) that.
That also means, that we are not going to add more (external) DHCP
plugins and we are not going to invest work in the existing plugins
(except the "internal" plugin).
Some DHCP plugins are known to not support IPv6. If the user selects
"dhcpcd" we should just fallback to the "internal" plugin. What's the
point of letting the activation fail? Probably users shouldn't use
"dhcpcd" plugin anyway, but that's a different story. Doing such fallback
could be a problem with forward compatibility if we ever would add IPv6
support to "dhcpcd". But we won't.
Also, we are going to add "n-dhcp4" as replacement for the systemd based
code. For a time, there will be an experimental plugin "nettools" that
eventually will become the new "internal" plugin. Until that happens,
we want for IPv6 automatically fallback to systemd based "internal"
plugin. This patch will make that simple.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/173
When we set the same JSON config twice in a row, the second time has
indeed no effect and we can just return right away (indicating that
no attributes changed).
However, that is not true, if we are in strict validating mode and
the JSON string just happens to be the same. In this case, we still
want to switch from strict validating mode to relaxed mode. Hence,
we should not return early but continue setting the property.
NM_MODEM_OPERATOR_CODE property is construct-only. Add our common
code comment to the property setter.
Construct-only setters are pretty simple. They run before the object is
constructed, hence their scope is clearer. As such, there is no need to
emit property changed notifications (also because that is already taken
care by the GObject property setter). Don't call _nm_modem_set_operator_code(),
just directly set the property.
Usually we aim to have only one place where we set state (_nm_modem_set_operator_code()).
But a construct-only property setter is trivial enough that we can affort having two
places to modify the property. In particular, because the property setter does not "modify"
the property, it merely initializes it before the object is fully
constructed.
