GitLab

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

https://bugzilla.gnome.org/show_bug.cgi?id=766427

And make it incredibly slow at the same time.

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.

Abuse the 'name' property for this, for now, so we don't have to grab
a free slot from NMDeviceClass.

https://bugzilla.gnome.org/show_bug.cgi?id=592819

https://bugzilla.gnome.org/show_bug.cgi?id=724860
https://bugzilla.redhat.com/show_bug.cgi?id=1301226

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.

Will be useful to pass around the complete flag.

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=724860
https://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

The call can fail; in such case assume that an existing teamd died and
our instance will be able to continue.

https://bugzilla.redhat.com/show_bug.cgi?id=1347015

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.

Fixes: 2822f924

Otherwise, deprecation warnings are not properly suppressed for

  g_return_if_fail (g_strv_contains (strv, str));

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.

This makes NetworkManager use runtime detection to manage the
ModemManager lifecycle when not run by systemd. Under systemd, we expect
the ModemManager service to be started by systemd, under non-systemd, we
use the dbus activation feature to start ModemManager.

[thaller@redhat.com: original patch heavily modified to check for available
 libsystemd library]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770871
https://mail.gnome.org/archives/networkmanager-list/2016-June/msg00086.html

https://mail.gnome.org/archives/networkmanager-list/2016-June/msg00087.html

Some newer WWAN netdev types are "rawip" which don't bother with
ethernet framing.

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.

It has the very similar purpose as "nm-utils/nm-vpn-plugin-utils.[ch]", except
that is is header-only.

"nm-test-utils.h" may also be used by the VPN plugins, there
we have no NM_ASSERT_NO_MSG define.

https://bugzilla.gnome.org/show_bug.cgi?id=767697

For testing, add a build target to build those files too.

"nm-glib.h" is our most basic header. "nm-macros-internal.h" extends
on that. Thus, let "nm-macros-internal.h" include "nm-glib.h".

"nm-glib.h" is the most basic header, the one we cannot do without.
("nm-default.h", is already more generic, the one which every common
source file in NetworkManager repository should include).

Let "gsystem-local-alloc.h" be included by "nm-glib.h" and nowhere
else.

This file is only used by plugins and copied between them.

It's purpose is to contain general utility functions that are
only relevant for implementing NetworkManager's VPN plugins.

In principle the utility functions could be part of libnm, however,
there are a few problems with that:
  - if they are part of libnm, adding and using a new utility function
    requires the plugin to bump the required libnm version. Since you
    usally can work around/reimplement utility functions, this results
    in not using the API from libnm, not adding the API to libnm,
    and reimplementing it over and over in the plugin.
  - plugins compile both against libnm and libnm-glib. Thus, either
    the utility function would also be needed in libnm-glib, or again,
    it is not usable by the plugin.

We must avoid that the utility functions diverge and no local
modifications to these files should be made in the plugin.
Instead, one special location of the utility functions shall be
extended and re-imported (copied) to the plugin as needed.

Add the files to NetworkManager's repository. Although they are not
needed for NetworkManager itself, they are a different API provided
by NetworkManager. An API that is reused and shared by copying the files
around.

The "shared" directory contains files that are possibly used by all components
of NetworkManager repository.

Some of these files are even copied as-is to other projects (VPN plugins, nm-applet)
and used there without modification. Move those files to a separate directory.
By moving them to a common directory, it is clearer that they belong
together. Also, you can easier compare the copied versions to their
original via

  $ diff -r ./shared/nm-utils/ /path/to/nm-vpn-plugin/shared/nm-utils/

https://bugzilla.gnome.org/show_bug.cgi?id=767197

Let VPN plugins return a virtual function table to extend
the API while bypassing libnm. This allows to add and use
new functionality to VPN plugins without updating libnm.

The actual definitions are in a header-only file
"nm-vpn-editor-plugin-call.h", which can be copied to the
caller/plugin.

The NMVpnPluginInfo is essentially the .name file, that is, a
configuration file about the plugin itself. Via NMVpnPluginInfo
instance, the NMVpnEditorPlugin can be created.

Usually, one would create a NMVpnPluginInfo (that is, reading the
.name file) and then create a NMVpnEditorPlugin instance from there.
In this case, usually the editor-plugin is owned by the plugin-info
instance (although the API allows for creating the editor-plugin
independently).

Now, pass the  NMVpnPluginInfo to the editor-plugin too.
This is useful, because then the editor-plugin can look at the .name
file.

The .name file is not user configuration. Instead it is configuration
about the plugin itself. Although the .name file is part of the plugin
build artefacts, it is useful to allow the plugin to access the .name
file. The reason is, that this can allow the user to easily change a
configuration knob of the plugin without requiring to patch or the
plugin.