Previously we created a new NMIP[46]Config object to replace the
previous one every time the plugin reported a new IP configuration
through the Ip[46]Config signal, but the old configuration was not
removed from the DNS manager and would become stale.
The interaction with DNS manager is handled by NMPolicy, which only
reacts to changes in connection status, so it's not easy to have the
configuration removed from DNS while keeping the connection state
ACTIVATED.
A cleaner solutions is to avoid creating a new IP configuration object
and reuse the existing one if possible. The side effect is that the
D-Bus path of the object will not change, which seems also positive.
https://bugzilla.redhat.com/show_bug.cgi?id=1348901
If the plugin sends a new configuration when the connection is already
activated the state should not go back to PRE_UP since this causes
dispatcher scripts to run again.
This would fix for example:
nmcli e <TAB>
(e interpreted as --escape, would allow autocompletion to work... but
when the command is executed an error is reported)
Moreover, we will now have:
nmcli c <TAB>
autocompletion work correctly, i.e., c is correctly interpreted as
"connection" instead of "--colors"
Software devices must report the NM_DEVICE_CAP_IS_SOFTWARE capability
in order to be properly activated. Add the flag to NMDeviceTun and
NMDeviceVxlan.
https://bugzilla.gnome.org/show_bug.cgi?id=767846
When NM looks for vpn plugins, it would expect the full service name
otherwise it will not be able to retrieve the correct plugin.
Fixes VPN configurations generated with "nmcli connection add".
It's possible for wpa_supplicant to transition to INACTIVE
state with an outstanding requested_scan pending. This can
lead to a stall condition where scanning no longer occurs.
[thaller@redhat.com: added break statement to avoid fall-through]
https://mail.gnome.org/archives/networkmanager-list/2016-June/msg00116.html
nl_recv() in libnl3 before version 3.2.15 would return dangling pointers
if nl_recv() fails or has nothing to read [1].
Workaround that by explicitly clearing @buf and @creds.
https://bugzilla.gnome.org/show_bug.cgi?id=767986
[1] 69468517d0
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
This improves the HTML rendering.
But it also causes a lot of non-resolvable linkends warning when rendering a
separate manual pages into roff/mman. The messages are harmless, but still
a bit ugly.
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
* no need to check HELP_ONLY_AS_FIRST var as when --help option is passed
_nmcli_compl_OPTIONS will return 0, falling in the general case that
will trigger end of autocompletion
* clanup local var declaration in _nmcli func:
- remove dupliated OPTIONS_MANDATORY declaration
- init HELP_ONLY_AS_FIRST on declaration
- order vars for common prefix
nm_vpn_get_secret_names() has only one caller, which passes
nm_setting_vpn_get_service_type() as @vpn_type argument. That
argument is not a short-name or abbreviation, it must be the
full service-type.
For our well-known, hard-coded list of service-types, all must
start with the same prefix.
We use statement expressions all over the place without explicitly
marking them. If that would be a problem, we'd have to change a
*lot* of code. We simply require that as a mandatory feature from
our compiler.
The logging domain VPN_PLUGIN controlls logging of the VPN plugins.
Especially at verbose levels <debug> and <trace>, the plugins might
reveal sensitive information in the logging.
Thus, this level should not be enabled by a
$ nmcli logging general level DEBUG domains ALL
It should only be enabled when requested explicitly.
$ nmcli logging general level DEBUG domains ALL,VPN_PLUGIN:DEBUG
Previously, the special level VPN_PLUGIN was entirely excluded from
ALL and DEFAULT domains and it was entirely disabled by default. That
is however to strict, as it completely silences the VPN plugins by
defult. Now, enable them by default up to level INFO.
VPN plugins should take care that they don't reveal sensitive
information at levels <info> (LOG_NOTICE) and higher (less verbose).
For more verbose levels they may print passwords, but that should
still be avoided as far as possible.
