Optimally, all list types properties in nmcli support proper escaping.
For that, we should use nm_utils_escaped_tokens_*() API.
For now, just change that for policy routes. They were just added recently,
so no change in behavior of released API.
nmcli supports list options (optlist and multilist properties).
These commonly are individual items, concatenated by a delimiter.
It should be generally possibly to express every value. That means, we
need some for of escaping mechanism for delimiters.
Currently this is all inconsistent or no escaping is supported. I intend
to fix that (which will be a change in behavior).
For now, just add yet another style of tokenzing/concatenating list
items in nmcli. This is the style to replace all other styles.
Scripts should refer to connections by UUID. That means, whenever a
UUID matches, that is really what the user wants. The specifier "uuid"
must have precedence over "id" (and all others). That means, we must
search all connections.
For example:
$ UUIDS=($(nmcli -g TYPE,UUID connection show | sed -n 's/802-11-wireless://p'))
$ nmcli -f connection.id,connection.uuid connection show "${UUIDS[@]}"
in this case we must preferrably match by UUID, regardless of whether
a "connection.id" exists.
Note that if you have:
$ nmcli connection show | grep fdf7b2d2-2858-3938-9b14-7f1b514a9a00
b fdf7b2d2-2858-3938-9b14-7f1b514a9a00 ethernet --
fdf7b2d2-2858-3938-9b14-7f1b514a9a00 ab9f3891-3420-335e-89da-f14c1b94c540 ethernet --
then certain commands will still select all matching connections:
$ nmcli -f connection.id,connection.uuid --mode multiline connection show fdf7b2d2-2858-3938-9b14-7f1b514a9a00
connection.id: fdf7b2d2-2858-3938-9b14-7f1b514a9a00
connection.uuid: ab9f3891-3420-335e-89da-f14c1b94c540
connection.id: b
connection.uuid: fdf7b2d2-2858-3938-9b14-7f1b514a9a00
This only makes a difference for commands that must pick only one profile:
$ nmcli connection modify fdf7b2d2-2858-3938-9b14-7f1b514a9a00 con-name new-name
Since commit 62b939de4e ('cli: add nmc_complete_strv() which takes a
string array for completion that may contain NULL'), the sentinel is
no longer needed.
Before:
# nmcli c modify eth666 tc.qdiscs root
Error: failed to modify tc.qdiscs: '(null)' is not a valid kind The valid syntax is: '[root | parent <handle>] [handle <handle>] <qdisc>'.
After:
# nmcli c modify eth666 tc.qdiscs root
Error: failed to modify tc.qdiscs: kind is missing. The valid syntax is: '[root | parent <handle>] [handle <handle>] <kind>'.
Leak detection adds unhelpful messages to the stderr of nmcli, making
tests fail. For example:
=================================================================
==17156==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 256 byte(s) in 2 object(s) allocated from:
#0 0x7f08c7e27c88 in realloc (/lib64/libasan.so.5+0xefc88)
#1 0x7f08c7546e7d in g_realloc (/lib64/libglib-2.0.so.0+0x54e7d)
When nmcli needs secrets for a connection it asks them for every known
setting. nmtui is a bit smarter and asks them only for settings that
actually exist in the connection. Make a step further and let clients
ask secrets only for setting that exist *and* have any secret
property. This decreases the number of D-Bus calls when editing or
showing a connection with secrets.
https://bugzilla.redhat.com/show_bug.cgi?id=1506536https://github.com/NetworkManager/NetworkManager/pull/327
Call the correct _finish() function for
nm_client_add_and_activate_connection_async(). add_and_activate_cb()
somewhat confusingly alternates between two different ones depending on
whether info->create is set.
Fixes: 3593237527 ('cli: reuse connections in nmcli dev wifi con')
https://github.com/NetworkManager/NetworkManager/pull/326
I find it questionable, how nmcli likes to coerce the empty input to
NULL to indicate resetting the value. If nmcli would like to set a
default, it should use a different way of signalling that. Anyway, the
assertion was too strict.
$ nmcli connection modify "$PROFILE" +ipv4.addresses ''
Setting one property might affect multiple properties.
For example, setting a team property might also emit property changed
signal for "team.config".
Or, one property might be modified multiple times. For example list
properties may first clear the property, then append multiple elements.
Or a list property might remove multiple elements.
Combine these signals via g_object_freeze_notify() and
g_object_thaw_notify().
There is no reason to validate only in certain cases. Either we
validate, or we don't (always the same).
This is a change in behavior, but the cases should be sensible.
Most GObject properties default to FALSE/NULL/0. In that case, there
is no difference between setting the default or clearing the value.
During
if (_SET_FCN_DO_RESET_DEFAULT (property_info, modifier, value))
return _gobject_property_reset_default (setting, property_info->property_name);
it is correct to reset the default.
However for list-typed properties, we want to clear the list. So,
it should be
if (_SET_FCN_DO_SET_ALL (modifier, value))
_gobject_property_reset (setting, property_info->property_name, FALSE);
The VFs already can be parsed as plain number (to indicate the
ifindex). We should not also support accepting the plain number
as index to be removed.
Fixes: a2f12994b7 ('cli: add support for configuring SR-IOV')
$ nmcli connection modify "$PROFILE" -ipv4.addresses 1,3
Already before, nmcli would support removing items by index. But only
one number was supported.
- indexes are zero based (as before).
- duplicate indexes or indexes out of bounds are silently ignored.
Maybe certain properties should not support removal by index.
Use new ValueStrsplitMode "VALUE_STRSPLIT_MODE_STRIPPED".
Note that this is not exactly what we did before. For example, empty
tokens are now silently removed.
Also, we accept now whitespace as separators.
Have one function that gets all the nonesense right. "nonesense", because
we have inconsistent behaviors, and the function is supposed to help with
that.
set_fcn() and remove_fcn() are strongly related. They should accept
arguments in the same format, hence the parsing of the arguments should
be done at one place.
In fact, previously the parsing was separate, leading to ugly
inconsistencies:
$ nmcli connection modify "$PROFILE" +vpn.data x=y
$ nmcli connection modify "$PROFILE" -vpn.data x=y
Error: failed to remove a value from vpn.data: invalid option 'x=y'.
or
$ nmcli connection modify "$PROFILE" +ipv4.addresses 192.168.1.5/24,192.168.2.5/24
$ nmcli connection modify "$PROFILE" -ipv4.addresses 192.168.1.5/24,192.168.2.5/24
Error: failed to remove a value from ipv4.addresses: invalid prefix '24,192.168.2.5/24'; <1-32> allowed.
Let set_fcn() handle set-default, set-all, add, and subtract.
Previously, set_fcn() could only append values. Now, pass on the modifier
so that it may append, set all, or reset the default.
These operations are strongly related and should be handled by the same
set_fcn() function.
