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.
"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/
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.
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.
Refactor code to add function _list_find_by_service(), which will be used in the
next commit.
A notable change is that we now search also through the aliases
together with the service-name.
That makes a difference, if one plugin privdes an "alias" which another
plugin provides as "service". Due to that change, we would also find the
aliased plugin first.
In practice it shouldn't matter, because different plugins are
not supposed to provide identical services.
g_qsort_with_data() passes the pointers to the compared items to the
compare function, that is not the "const char *" pointers itself.
Fixes: 41976e3069
Commit bdd0e7fec0 which added symbol
nm_setting_ip_config_get_dns_priority to libnm_1_4_0 was backported
to nm-1-2 in commit ad1cdcf6571da23e3197b09f1b4b14d23b8899d1.
Add the backported symbol to master to allow seemless upgrading
from 1.2.4 to 1.4.0.
Assertions like g_assert*() and g_return_*() contain the stringified
test expression. This string ends up in the binary and increases its
size.
We usually don't have failing assertions. These string are a waste,
instead the file and line number shall suffice.
It reduces the striped size of the NetworkManager binary from 2500k
to 2392k, that is -108k, -4.3%.
This changes
- "g_assert (1 == 2);"
from: NetworkManager:ERROR:source.c:347:some_function: assertion failed: (1 == 2)
to: NetworkManager:ERROR:source.c:347:<unknown-fcn>: assertion failed: (<dropped>)
- "g_return_if_fail (1 == 2);"
from: (process:21024): NetworkManager-CRITICAL **: some_function: assertion '1 == 2' failed
to: (process:21024): NetworkManager-CRITICAL **: ((source.c:347)): assertion '<dropped>' failed
When doing a non-debug build, those string are now removed. Debug-builds
can be enabled by setting --with-more-assert=$LEVEL to larger then zero.
https://bugzilla.gnome.org/show_bug.cgi?id=767296
A failure to g_return*() by default prints a g_critical() with stringifing the
condition. Add a macro NMTST_G_RETURN_MSG() that reproduces that line to more
accurately match the failure message.
When a reverse DNS entry must be added to dnsmasq, instead of
considering IP addresses as classful use the prefix to compute one or
more "in-addr.arpa" according to CIDR rules.
https://bugzilla.gnome.org/show_bug.cgi?id=767174
