till now when no explicit value was set on a property, the default value
for that property was returned, also if the property was not applicable
to the selected runner.
Fix this, showing default values for properties only when relevant and
showing instead -1 or null when the property is not relevant for the
selected runner.
Moreover, reset all the properties but the link-watchers when the team.runner
is changed: this is required to clean up the properties unrelated to the
new runner and start with the runner-specific defaults.
(cherry picked from commit a5642fd93a)
the teamd 'runner.tx_balancer.balancing_interval' property was wrongly
set and searched as 'runner.tx_balancer.interval'. Fixed.
Fixes: fc3b7d61e2
(cherry picked from commit ed2a1a153b)
Move code from _nm_utils_team_config_get to the brand new
_json_team_add_defaults function without any change.
Then remove the duplicated code from _nm_utils_team_config_equal and
leverage the new function. Here the only functional change is that
the defaults for "notify_peers" and "mcast_rejoin" for the
"activebackup" runner are added (the only case in which their default
values are different than 0).
(cherry picked from commit fdd41852ee)
Team allows to specify multiple link watchers for each link.
Define a link watcher object in order to allow to specify multiple ones
for each Team configuration.
(cherry picked from commit 72f6d08714)
When jansson lib version is < 2.8 the order of the keys of json objects
is not preserved automatically. In particular, when loading the json
string, parsing it and dumping it back to a string the key order will be
lost if the now deprecated JSON_PRESERVE_ORDER flag is not set.
Add the flag: will do nothing on recent jansson versions but will fix
behavior for legacy ones.
(cherry picked from commit 5e6f7de4be)
Add functions and structure to simplify json config and team property
enforcement. These will be used in both NMSettingTeam and
NMSettingTeamPort.
(cherry picked from commit b4c9bcd49f)
DNS searches from the ipv4 and ipv6 settings were joined and written
to the same ifcfg-rh "DOMAIN" variable and so the connection read back
from disk was different from the one written.
Instead, introduce a separate variable for ipv6 searches; to preserve
backwards compatibility, still read the "DOMAIN" variable for ipv6
when ipv4 is disabled so that we don't lose DNS searches on upgrade.
https://bugzilla.redhat.com/show_bug.cgi?id=1517794
(cherry picked from commit a9b5079324)
Extend the Update2 flags to allow marking a connection as volatile.
Making a connection as volatile means that the connection stays alive
as long as an active connection references it.
It is correct that Update2() returns before the connection is actually
deleted. It might take an arbitrary long time until the volatile
mechanism cleans up the connection.
Also add two more IN_MEMORY flags: "detached" and "only".
The existing NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY would not detach nor
delete the possible file on disk. That is, the mode only changes what NM
thinks is the current content of the connection profile. It would not delete
the file on disk nor would it detach the profile in-memory from the file.
As such, later persisting the connection again to disk would overwrite
the file, and deleting the profile, would delete the file.
Now add two new IN_MEMORY modes.
NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACH is like making the connection
in-memory only, but forgetting that there might be any profile on disk.
That means, a later Delete() would not delete the file. Similarly, a
later Update2() that persists the connection again, would not overwrite
the existing file on disk, instead it would choose a new file name.
On the other hand, NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_ONLY would delete
a potential file from disk right away.
It's clear that "volatile" only makes sense with either "in-memory-detached"
or "in-memory-only". That is, the file on disk should be deleted right away
(before the in-memory part is garbage collected) or the file on disk should
be forgotten.
(cherry picked from commit 35dc6421de)
We already have Update(), UpdateUnsaved() and Save(), which serve
similar purposes. We will need a form of update with another argument.
Most notably, to block autoconnect while doing the update.
Other use cases could be to prevent reapplying connection.zone and
connection.metered, to to reapply all changes.
Instead of adding a specific update function that only serves that
new use-case, add a extensible Update2() function. It can be extended
to cope with future variants of update.
(cherry picked from commit 98ee18d888)
The wireless-security setting has a 'wep-key-type' property that is
used to specify the WEP key type and is needed because some keys could
be interpreted both as a passphrase or a hex/ascii key.
The ifcfg-rh plugin currently stores the key type implicitly: if
wep-key-type is 'passphrase' it uses the KEY_PASSPHRASE%d variable, if
it's 'key' the KEY%d variable and when it's 'unknown' it uses either
variables depending on the detected type (preferring 'key' in case
both are compatible).
This means that some connections will be read differently from how
they were written, because once the KEY (or KEY_PASSPHRASE) is read
there is no way to know whether the 'wep-key-type' property was 'key'
(or 'passphrase') or 'unknown'.
Fix this by persisting the key type explicitly in the file. The new
variable is redundant in most cases because the variables used for
keys also determine the key type.
https://bugzilla.redhat.com/show_bug.cgi?id=1518177
(cherry picked from commit c6eb18ee05)
Until now the ifcfg-rh plugin merged the values of 'ipv4.dns-options'
and 'ipv6.dns-options' and wrote the result to the RES_OPTIONS
variable. This is wrong because writing a connection and reading it
back gives a different connection compared to the original.
This behavior existed since when DNS options were introduced, but it
became more evident now that we reread the connection after write,
because after doing a:
$ nmcli connection modify ethie ipv4.dns-options ndots:2
the connection has both ipv4.dns-options and ipv6.dns-options set. In
order to delete the option, an user has to delete it from both
settings:
$ nmcli connection modify ethie ipv4.dns-options "" ipv6.dns-options ""
To improve this let's use different variables for IPv4 and IPv6. To
keep backwards compatibility IPv4 still uses RES_OPTIONS, while IPv6
uses a new IPV6_RES_OPTIONS variable.
https://bugzilla.redhat.com/show_bug.cgi?id=1517794
(cherry picked from commit 8379785560)
We should use the same str2bool parser everywhere: _nm_utils_ascii_str_to_bool().
Incidentally, this function allows more forms of expressing a boolean
value.
$ nmcli connection modify "$CON" ipv4.routes '1.2.3.4/32 1.2.3.1 onlink=1'
Error: failed to modify ipv4.routes: invalid option 'onlink=1': invalid boolean value '1' for attribute 'onlink'.
(cherry picked from commit 26e7abc65e)
Currently both bridge.mac-address and ethernet.cloned-mac-address get
written to the same MACADDR ifcfg-rh variable; the ethernet property
wins if both are present.
When one property is set and the connection is saved (and thus reread)
both properties are populated with the same value. This is wrong
because, even if the properties have the same meaning, the setting
plugin should not read something different from what was written. Also
consider that after the following steps:
$ nmcli con mod c ethernet.cloned-mac-address 00:11:22:33:44:55
$ nmcli con mod c ethernet.cloned-mac-address ""
the connection will still have the new mac address set in the
bridge.mac-address property, which is certainly unexpected.
In general, mapping multiple properties to the same variable is
harmful and must be avoided. Therefore, let's use a different variable
for bridge.mac-address. This changes behavior, but not so much:
- connections that have MACADDR set will behave as before; the only
difference will be that the MAC will be present in the wired
setting instead of the bridge one;
- initscripts compatibility is not relevant because MACADDR for
bridges was a NM extension;
- if someone creates a new connection and sets bridge.mac-address NM
will set the BRIDGE_MACADDR property instead of MACADDR. But this
shouldn't be a big concern as bridge.mac-address is documented as
deprecated and should not be used for new connections.
https://bugzilla.redhat.com/show_bug.cgi?id=1516659
(cherry picked from commit fb191fc282)
Since the order was arbitrary before, we can also sort it.
Also rework it, to avoid the creating a temporary GList of keys.
(cherry picked from commit d5b3c6ee53)
Matters when backslash escaping ascii charaters <= 0xF, to
produce "\\XX" instead of "\\ X". For example tabulator is "\\09".
This also can trigger an nm_assert() failure, when building with
--with-more-asserts=5 (or higher).
(cherry picked from commit 89c89143b5)
Kernel doesn't support it for IPv6.
This is especially useful, if you combine static routes
with DHCP. In that case, you might want to get the device-route
to the gateway automatically, but add a static-route for it.
(cherry picked from commit 0ed49717ab)
The number of authentication retires is useful also for passwords aside
802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has
a retry counter and uses a hard-coded value of 3.
Move the setting, so that it can be used in general. Although it is still
not implemented for other settings.
This is an API and ABI break.
