Since commit ac888de151 ("cli/connections: fail the activation when
the active connection disappears") we rely only on the disappearing of
the active-connection to determine the failure of an activation.
libnm can collapse a 'added' and a 'removed' signal if they are
received closer enough and thus we may miss the removal of the active
connection. Restore the detection of failure based on
active-connection state.
The error returned to users when a load_connection(s)/set_logging call
fails due to D-Bus policy denial is a bit obscure:
$ nmcli general logging level debug
Error: failed to set logging: Rejected send message, 4 matched rules;
type="method_call", sender=":1.233" (uid=1001 pid=27225 comm="nmcli
general logging level debug ")
interface="org.freedesktop.NetworkManager" member="SetLogging" error
name="(unset)" requested_reply="0" destination=":1.207" (uid=0
pid=25793 comm="/usr/sbin/NetworkManager --no-daemon ")
Convert it to a more comprehensible:
$ nmcli general logging level debug
Error: failed to set logging: access denied
https://bugzilla.redhat.com/show_bug.cgi?id=1362542
(cherry picked from commit 805925f9ef)
It can go away before the activation finishes:
(process:378): GLib-GObject-WARNING **: instance with invalid (NULL) class pointer
Thread 1 "lt-nmcli" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff4fa919b in g_logv () from /lib64/libglib-2.0.so.0
(gdb) bt
#0 0x00007ffff4fa919b in g_logv () at /lib64/libglib-2.0.so.0
#1 0x00007ffff4fa930f in g_log () at /lib64/libglib-2.0.so.0
#2 0x00007ffff529b3ea in g_type_check_instance () at /lib64/libgobject-2.0.so.0
#3 0x00007ffff528fa94 in g_signal_handlers_disconnect_matched () at /lib64/libgobject-2.0.so.0
#4 0x000000000041ae4e in activate_connection_info_finish (info=0x7b5490) at connections.c:2197
#5 0x00007ffff5279470 in g_cclosure_marshal_VOID__OBJECTv () at /lib64/libgobject-2.0.so.0
#6 0x00007ffff5276617 in _g_closure_invoke_va () at /lib64/libgobject-2.0.so.0
#7 0x00007ffff5290ea9 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#8 0x00007ffff52914ff in g_signal_emit () at /lib64/libgobject-2.0.so.0
#9 0x00007ffff52763e8 in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#10 0x00007ffff52884a2 in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0
#11 0x00007ffff529112d in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#12 0x00007ffff52919ab in g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0
#13 0x00007ffff78fc9b1 in deferred_notify_cb (data=<optimized out>) at nm-object.c:243
#14 0x00007ffff4fa2703 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#15 0x00007ffff4fa2ab0 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#16 0x00007ffff4fa2dd2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#17 0x00000000004146e3 in main (argc=<optimized out>, argv=<optimized out>) at nmcli.c:618
(gdb) print info->device
Re-enable the check on ambiguos properties but this time manage perfect
matches (i.e., the full property name has been typed) that are prefix
of other properties.
Test case:
nmcli --complete-args connection add type wifi wifi.
Here "wifi" is a property alias that is also prefix of the property
alias "wifi-sec".
When parsing arguments of "connection add" we first read the available
property-value pairs and then check if the --ask option was passed in
order to aid in the fill process of a new connection.
Anyway, if there are no property-value tuples at all, we don't even
check the --ask option, returning with error.
Fix this just checking if any arg is there (argc) before invoking
read_connection_properties().
If we found that setting name prefix is in fact unambiguous and return
the completion string for that setting we were freeing the string upon
the return. That looks like a typo.
Fixes "nmcli --complete-args add type wifi wifi."
^^^^ not ambiguous
It allows us to clean up the nmcli "c add" section considerably.
We list the old-fashioned aliases in a separate section that applies to both
"nmcli c add" and "nmcli c modify".
The section is now nicely cross-linked with nm-settings in HTML
rendering.
This is a huge refactoring in attempt to 1.) reduce the horrible redundancy in
the connection addition path and 2.) reduce confusion between various sources
of property value (command line, properties, interactive mode).
* The conversions from the strings was done all over the place:
settings.c already does for all sensible properties.
The rest is removed.
* The validations are done randomly and redundantly:
server does some validation, and per-property client validations
useful for interactive mode are done in settings.c
The rest is removed.
* The information about defaults and required options was redundantly
scattered in per-type completion functions and interactive mode
questionnaries. This is now driven by the option_info[] table.
In general, we do our best to just map the command line options to
properties and allow mixing them. For the rest there's the
check_and_set() callbacks (basically to keep compatibility with previous
nmcli versions). This this is now all possible:
$ nmcli c add type ethernet ifname '*'
This always worked
$ nmcli c add type bond-slave save no -- connection.autoconnect no
The "save" and "--" still work
$ nmcli c add connection.type ethernet ifname eth0
Properties can now be used
$ nmcli c add type ethernet ip4 1.2.3.4 mac 80:86:66:77:88:99 con-name whatever
There's no implementation mandated order of the properties (the type
still must be known to determine which properties make sense)
$ nmcli --ask c add type ethernet ip4 1.2.3.4 mac 80:86:66:77:88:99 con-name whatever
The interactive mode asks only for properties that weren't specified
on command line
Complete the property as we parse the list of properties. This makes it
possible to actually complete an unfinished property. E.g:
$ nmcli --complete c modify enp0s25 +ipv6.addr
+ipv6.addresses +ipv6.addr-gen-mode
Make property autocompletion take a prefix and modifier flags.
This will make it easier to complete an unfinished property name
(possibly accompanied by a modifier) without shell trickery.
nmcli bash autocompletion leveraged on "nmcli connection edit", "print"
to retrieve the specific properties of a connection. Anyway, the
interactive editor is smart and just prints the used components, so in a
connection where 802.1x is not enabled we had no autocompletion.
Solved adding an "hidden" command "nmcli --complete connection modify"
as suggested in bgo #724860 in order to retrieve ALL the available
properties for use in autocompletion.
Here patch from L.Rintel has been merged to make che --complete option
global to nmcli (first version was local to "connection modify").
https://bugzilla.gnome.org/show_bug.cgi?id=724860https://bugzilla.redhat.com/show_bug.cgi?id=1301226
At various places, nmcli requires to specify a VPN type by name, for example
$ nmcli connection add type vpn ifname '*' vpn-type $VPN_TYPE
This $VPN_TYPE used to be a hard-coded list of known VPN plugin names.
But actually, it should be a VPN service-type. A service-type used to be
the D-Bus name of the VPN plugin. Now, with multiple VPN support that
is no longer the case, but it still has the form of a D-Bus bus name.
Alternativley, it could be an alias, which is just a way for plugins
to support multiple service-types.
Fix that, to support fully qualified service-types in the form
of D-Bus bus names. Also, support lookup by name, in which case
the present plugin-info instances are searched.
Finally, support a list of hard-code short-names.
All the logic how to translate a short-name to a fully qualified
service-type is now inside libnm, so that various user agree on
those names and don't have to hard-code them each.
As explained in the function comment, a NULL value for @val is
acceptable. Otherwise:
$ nmcli connection edit
(process:2276): nmcli-CRITICAL **: check_valid_name: assertion 'val' failed
Fixes: fb8fe1d8cb
Instead of using (only) a hard-coded list of VPN types,
prefer lookup the VPN settings from the .name files.
Still, fallback to a hard-coded list if the plugin cannot
be found, because for connection-add we currently don't
actually need the plugin installed.