nmcli calls nm_setting_802_1x_set_private_key() with a password pointer that
it just got from the setting connection itself. Make this less fragile, by
not freeing the current password before assigning it.
The idea is
tfilter.<parent>=[handle <handle>] <tfilter> [<options>] [action [<action options>...]]
What works now:
[tc]
qdisc.root=handle 1234: fq_codel
qdisc.ffff:fff1=ingress
tfilter.1234:=matchall action drop
tfilter.ffff:=matchall action simple sdata Hello
Printing a g_warning() from the library is not helpful.
Client-side, libnm should support newer server versions and changing
formats. To support forward-compatibility, it should parse the received
GVariant best-effort like, without complaining.
Server-side, libnm-core should return errors when receiving invalid
configuration. It must not maintain forward-compatibility, only
backward-compatibility -- which is implemented by handling old
and newer formats. But never should server allow a configuration
that is invalid.
Currently, the libnm API cannot yet fail at this point. Hence,
it cannot return an error. It would need a strict and relaxed
parsing mode. Until that exists, just comment out the warnings.
The format for qdiscs is
qdisc.<parent>=[handle <handle>] <qdisc> [<options>...]
E.g.:
[tc]
qdisc.root=fq_codel handle de4d:
qdisc.ffff:fff1=ingress
That is pretty much what is supported at this point.
"no_value" indicates that the the attribute is a single word, not a
key=value pair. If the type is BOOLEAN then the attribute is considered
true, if it's a STRING then the key is used instead of a value.
"consumes_rest" indicates that the particular key takes the unparseable
tail of the string for a value.
This allows parsing tc-style strings. Consider this filter:
,------ regular key/value pair
,-----'----.
root handle 1234: matchall action simple foo bar baz
| | `-----------.-----------'
| | `- "", STRING, consumes_rest
| `------------------- "kind", STRING, no_value
`-------------------------------------- "root', BOOLEAN, no_value
Make use of NMUtilsNamedValue in nm_utils_format_variant_attributes().
This avoids creating a GList and sorting it.
Also, reuse nm_utils_named_values_from_str_dict() in
nm_setting_bond_get_option().
I don't think we should do this.
- renamining/dropping configure options is still an annoyance,
because it requires to different ./configure options depending
on the version. The rename from --enable-teamctl to --enable-team
might be theoretically nice, but more annoying then helpful.
- There is no strict dependency between --enable-team and
--enable-json-validation. At most, one could argue that
when enabling the team plugin (--enable-teamctl), then
libnm must also be build with --enable-json-validation.
But in fact, the team plugin will happily work with a
libnm that doesn't link against libjansson.
That is --enable-teamctl --disable-json-validation will work
in practice just fine.
On the other hand, libnm is a client library to create connection
profiles, fully supporting team profiles also makes sense if the
actual plugin is not installed (or build). Thus, --disable-teamctl
--enable-json-validation certainly makes sense.
At this point, one might ask whether libnm is even still complete without
libjansson. Maybe libnm should *require* --enable-json-validation.
But that is not what the patch was doing, and it would also need
some careful consideration before doing so.
This reverts commit 9d5cd7eae8.
Rename the team functionality enablement from 'teamdctl' to 'team'.
Force jansson lib requirement for team functionality: NetworkManager
requires the teamd daemon to manage team. As teamd depends upon jansson
lib, adding jansson requirement for teaming support in NetworkManager
seems reasonable.
Remove the jansson_validation flag, as the only generic json function in
nmcli (not related to team) was the one to check if a string was in json
format. Anyway, that function is used for team checks only. So, move
also json validation functions under the WITH_TEAM flag.
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.
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).
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.
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.
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
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.
