We should try to avoid access to global variables. For libreadline
callbacks we still need a global variable.
Introduce a global variable nm_cli_global_readline, specially for this
use. It makes the places clear where we use it, and discourages
the use at other places, where we better avoid global variables.
g_clear_pointer() would always cast the destroy notify function
pointer to GDestroyNotify. That means, it lost some type safety, like
GPtrArray *ptr_arr = ...
g_clear_pointer (&ptr_arr, g_array_unref);
Since glib 2.58 ([1]), g_clear_pointer() is also more type safe. But
this is not used by NetworkManager, because we don't set
GLIB_VERSION_MIN_REQUIRED to 2.58.
[1] f9a9902aac
We have nm_clear_pointer() to avoid this issue for a long time (pre
1.12.0). Possibly we should redefine in our source tree g_clear_pointer()
as nm_clear_pointer(). However, I don't like to patch glib functions
with our own variant. Arguably, we do patch g_clear_error() in
such a manner. But there the point is to make the function inlinable.
Also, nm_clear_pointer() returns a boolean that indicates whether
anything was cleared. That is sometimes useful. I think we should
just consistently use nm_clear_pointer() instead, which does always
the preferable thing.
Replace:
sed 's/\<g_clear_pointer *(\([^;]*\), *\([a-z_A-Z0-9]\+\) *)/nm_clear_pointer (\1, \2)/g' $(git grep -l g_clear_pointer) -i
nmcli should not perform checks on the interface name length,
this kind of operations should only be performed by the NetworkManager
daemon and not be duplicated inside cli applications.
Several macros are used to define function. They had a "_STATIC" variant,
to define the function as static.
I think those macros should not try to abstract entirely what they do.
They should not accept the function scope as argument (or have two
variants per scope). This also because it might make sense to add
additional __attribute__(()) to the function. That only works, if
the macro does not pretend to *not* define a plain function.
Instead, embrace what the function does and let the users place the
function scope as they see fit.
This also follows what is already done with
static NM_CACHED_QUARK_FCN ("autoconnect-root", autoconnect_root_quark)
In all the cases, we don't want to perform locale dependent comparison.
$ sed -i 's/\<strcasecmp\>/g_ascii_\0/g' $(git grep -w -l strcasecmp -- ':(exclude)shared/systemd/' )
The abbreviations "ns" and "ms" seem not very clear to me. Spell them
out to nsec/msec. Also, in parts we already used the longer abbreviations,
so it wasn't consistent.
It is a waste of resources instantiating a NMClient, filling the
object cache and then throwing everything away without using it. This
can take seconds on slow systems with many objects. Since the
ReloadConnections doesn't need anything from the cache, just execute
the D-Bus method call directly.
Various cleanups:
- after detecting the modifier, remove it from the string right away.
It's redundant and confusing to do it later.
- rename variables and move to inner scope.
- don't use g_str_split() to split the property name at the
first dot. strchr() is sufficient.
Also, now that we strip the modifier from option early, they start also
working for aliases. There is no need to not support (or behave
differently) w.r.t. whether aliases support modifiers or not.
This fixes:
$ nmcli connection modify r +ip4 192.168.5.2/24
Error: invalid <setting>.<property> 'ip4'.
The enum values are unique throughout the source code so they
can easier be searched (e.g. with grep), compared to '\0'. It
is often interesting where a certain modifier is used, so searching
the source code is important to give relevant results.
Also, the modifier is really an enum and we shouldn't misuse char type.
If that would be a good idea in general, we wouldn't need any enums
at all. But we use them for good reasons.
Instead of straight-out rejecting extra parameters for various nmcli
sub-commands (such as "nmcli dev status", "nmcli dev wifi rescan" or
"nmcli dev wifi connect", etc.), we just print a warning and go ahead.
This is unhelpful. In case the user makes a typo, we'll do the wrong
thing and possibly even drown the warning in the output.
While at that, let's make the error message consistent. One less string
to translate.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/217
Make use of the new API. Note that AddConnection2() covers all
functionality of AddConnection() and AddConnectionUnsaved(). Let's
only use one API for all.
There is a minor downside to this patch: now nmcli requires
libnm 1.20 API. Note that libnm's nm_client_add_connection2()
makes an effort to avoid AddConnection2() under the hood to
still work against older server versions. So, you can use nmcli
with libnm 1.20 to talk to older versions of NetworkManager.
But with this change nmcli strictly requires libnm 1.20. I think that is
sensible because commonly nmcli requires a libnm version that is as new
as itself.
Also, the value of allowing nmcli to talk to older NetworkManager
versions is during package upgrade (where the daemon might not be
restarted). This is much less concern w.r.t. to updating the nmcli/libnm
combo, which is commonly packaged together.
The 'bt-type' property alias accepts values provided by
gen_func_bt_type(); instead the 'bluetooth.type' property can only be
set to [dun, panu, nap] and therefore it doesn't need special
handling.
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.
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
It's fundamentally wrong to have separate "remove_fcn" and "set_fcn"
implementations. Set, reset, add, and remove are all similar, and should
be implemented in a similar manner.
Merge the implementations all in set-property, which now can:
- reset the value (value == NULL && modifier == '\0')
- set a value (value != NULL && modifier == '\0')
- add a value (value != NULL && modifier == '+')
- remove a value (value != NULL && modifier == '-')
The real problem is that remove_fcn() behaves fundamentally different
from set_fcn(). You can do "+setting.property value1,value2" but you
cannot remove them the same way. That is because most remove_fcn()
implementations don't expect a list of values. But it's also because of
the unnatural split between set_fcn() and remove_fcn().
The next commit will merge set_fcn(), remove_fcn() and reset property.
This commit just merges them all in nmc_setting_set_property().
"reset" is just a special case of "set". We can keep nmc_setting_reset_property() as a convenience
function, but it must be implemented based on nmc_setting_set_property().
Also, reset only used nmc_property_set_default_value(), which only works
with GObject based properties. It's wrong to assume that all properties
are GObject based. By implementing it based via nmc_setting_set_property()
we can fix this (later).
Not all implementations support having the value being an index.
For example, the implementations that are done via DEFINE_REMOVER_OPTION() macro.
The meaning of the "value" string must not be determined by
nmc_setting_remove_property_option(). It's up to the implementation
to decide whether to allow an index and how to interpret it.
Support importing ".conf" files as `wg-quick up` supports it.
`wg-quick` parses several options under "[Interface]" and
passes the remainder to `wg setconf`.
The PreUp/PreDown/PostUp/PostDown options are of course not supported.
"Table" for the moment behaves different.
(cherry picked from commit a3a8583c31)
If we already specified "type" or "file", don't offer it for
completion again.
$ nmcli connection import type openvpn <TAB>
file type
(cherry picked from commit fea0f4a5ea)
For now only add the core settings, no peers' data.
To support peers and the allowed-ips of the peers is more complicated
and will be done later. It's more complicated because these are nested
lists (allowed-ips) inside a list (peers). That is quite unusual and to
conveniently support that in D-Bus API, in keyfile format, in libnm,
and nmcli, is a effort.
Also, it's further complicated by the fact that each peer has a secret (the
preshared-key). Thus we probably need secret flags for each peer, which
is a novelty as well (until now we require a fixed set of secrets per
profile that is well known).
Just calling nm_connection_verify() is not correct. We need
nm_connection_normalize() because otherwise we miss out on places
where we have common normalization steps implemented to fix a
connection. This is also what server-side is done.
Revert the patch, as it breaks CI tests.
I wonder also whether this is the right place. There are already
several places in "clients/cli/connections.c" that call verify()
and normalize(). These places should be unified so that there is
one place where we complete the connection. And it probably should be
done as a separate step before the add_new_connection()/update_connection()
calls.
This reverts commit ca58bcca0c.
Most of the times we actually need a NMSecretAgentSimple typed pointer.
This way, need need to cast less.
But even if we would need to cast more, it's better to have pointers
point to the actual type, not merely to avoid shortcomings of C.
