These helper function will be needed in the next commit to be earlier.
Helper functions like these, that operate solely on trival types (in
this case, converting an enum to a string), make generally sense to have
at the beginning of the source file. Because they themself have few/no
dependencies and are rather trivial and self contained.
Functions like nmc_find_connection() and nmc_find_active_connection()
can easily find multiple matching results. For example, the
"connection.id" in NetworkManager is not enforced to be unique,
so if the user adds multiple connections with the same name,
they should be all selected.
The previous API had a @pos argument, that allowed to iterate over
the results. Change that, to return all matches in a GPtrArray.
Also, extend connection-show and other places, to anticipate that
a connection might be active multiple times in any moment.
The present version of the specification is somewhat unclear at times,
Unclear points were discussed with the maintainers [1] and probably
some new version will address those.
https://www.spinics.net/lists/util-linux-ng/msg15222.html
Until then here's how the implementation copes with ambiguities
(after the discussion with util-linux maintainers):
1.) It is unclear whether multiple .schem files should override each
other or be merged. We use the overriding behavior -- take the
highest priority one and ignore the rest.
2.) We assume "name.schem" is more specific than "@term.schem".
3.) We assume the "Color name" are to be used as aliases for the color
sequences and translate them to ANSI escape sequences.
4.) The "Escape sequences" are of no use since the specification
pretty much assumes an ANSI terminal and none of the sequences make
any sense in ANSI color codes. We don't support them.
accept that.
5.) We don't implement TERMINAL_COLORS_DEBUG because it's unspecified
what should it do.
This basically replaces the (NMMetaTermColor, NMMetaTermFormat) combo
with NMMetaColor that describes the colored element semantically as
opposed to storing the raw attributes.
A (currently static) paletted is used to translate the semantic color
code to the actual ANSI controle sequence. This matches what
terminal-colors.d(5) schemes use, making it convenient to implement
customizable palettes.
This actually makes very little difference at the moment, but will make
things more confortable later on, when the logic of enabling/disabling
coloring will involve terminal-colors.d(5).
Instead of deciding whether to use colors lazily with use_colors(), it's
done very early on nmcli initialization and a boolean use_colors field
is stored in the NmcConfig instance instead of the raw tristate option
of NmcColorOption type (which is now confined to nmcli.c).
Wherever the NmcColorOption was used previously, the whole NmcConfig
instance is passed around. That might seem pointless (since only the
use_colors boolean is actually used at the moment), but will be utilized
to pass around the actual color palette in future.
It's undocumented, useless, somewhat expensive in volume of code and
probably just downright stupid. We'll get a more general way to set
colors.
Hacking in some code to keep this working wouldn't be too difficult, but
it seems entirely pointless.
Coccinelle:
@@
expression a, b;
@@
-a ? a : b
+a ?: b
Applied with:
spatch --sp-file ternary.cocci --in-place --smpl-spacing --dir .
With some manual adjustments on spots that Cocci didn't catch for
reasons unknown.
Thanks to the marvelous effort of the GNU compiler developer we can now
spare a couple of bits that could be used for more important things,
like this commit message. Standards commitees yet have to catch up.
It is meant to be rather similar in nature to isblank() or
g_ascii_isspace().
Sadly, isblank() is locale dependent while g_ascii_isspace() also considers
vertical whitespace as a space. That's no good for configuration files that
are strucutured into lines, which happens to be a pretty common case.
Let the matching continue when we are autocompleting arguments and we
have already found 'id', 'uuid' or 'path'.
Before:
# nmcli connection modify path<TAB>
path
After:
# nmcli connection modify path<TAB>
path
pathfinder-wifi
With --ask it might call back to nmcli's agent, causing a deadlock
while the client is waiting for the response. Let's give the client
a chance to service the agent requests while waiting:
$ nmcli --ask --show-secrets c show 'Oracle HQ'
<hang>
This is probably still rather suboptimal and inefficient, since we
still serialize the calls and block on response. However, if we submit
multiple calls to GetSecrets, the daemon would start authorizing the
first one and fail the other ones immediately before the authorization
succeeds.
This could perhaps be addressed in the daemon, but let's settle for a
fix that's compatible with the current daemon for now.
We commonly only allow tabs at the beginning of a line, not
afterwards. The reason for this style is so that the code
looks formated right with tabstop=4 and tabstop=8.
In most cases, it copies the entire strv needlessly.
We can do better.
Also, the max_tokens argument is handled wrongly (albeit
not used anywhere anymore).
nmc_strsplit_set() handles max_token wrong. It cannot call
g_strsplit_set() with max_token first, and then split empty
words. You cannot use g_strsplit_set() to achieve what
nmc_strsplit_set() wants to do, unless you first split all
tokens, then them construct them together again -- thereby
loosing the delimiters.
Anyway, there are just a few caller that do essentially the same.
Refactor the code to not use nmc_strsplit_set().
$ nmcli connection down p
path
Connection 'p' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/2)
Don't do completion when not requested.
We also do this for libnm, where it causes visible changes
in behavior. But if somebody would rely on the hashing implementation
for hash tables, it would be seriously flawed.
Next we will use siphash24() instead of the glib version g_direct_hash() or
g_str_hash(). Hence, the "nm-utils/nm-hash-utils.h" header becomes very
fundamental and will be needed basically everywhere.
Instead of requiring the users to include them, let it be included via
"nm-default.h" header.
Change the activation procedure for connections that require secrets
in the following way:
- nmcli creates a secret-agent and leaves it disabled so that
incoming requests are queued
- nmcli calls ActivateConnection()
- when the method returns success, the secret-agent gets enabled and
all queued requests are processed
When the user activates a connection which is already auto-activating,
NM will deactivate the current active-connection and will call
CancelGetSecrets() for it before the new ActivateConnection()
returns. In this way, when the secret-agent is enabled by nmcli, we
have the guarantee that there aren't any queued requests for
the deactivating connections.
https://bugzilla.redhat.com/show_bug.cgi?id=1438476
nmc_read_connection_properties() iterates over the input arguments, and
completes the connection.
Initially, the type is not yet known, in that case, we should not wrongly
assume that this is a generic connection. Later, when the type is specified,
con_settings() will return the correct settings.
Previously, this would wrongly add a [generic] section:
$ nmcli connection add type ethernet ifname eth1 con-name ethie autoconnect no ipv4.method auto ethernet.cloned-mac-address random
With the fix, it still works to specify the type later:
$ nmcli connection add ifname eth1 con-name ethie autoconnect no ipv4.method auto type ethernet
but it doesn't work, to specify the type after type-specific options:
$ nmcli connection add ifname eth1 con-name ethie autoconnect no ipv4.method auto ethernet.cloned-mac-address random type ethernet
Error: invalid or not allowed setting 'ethernet': 'ethernet' not among [connection, ipv4, ipv6, proxy].
The patch doesn't change the latter limitation.
Fixes: c5324ed285
Replace the usage of g_str_hash() with our own nm_str_hash().
GLib's g_str_hash() uses djb2 hashing function, just like we
do at the moment. The only difference is, that we use a diffrent
seed value.
Note, that we initialize the hash seed with random data (by calling
getrandom() or reading /dev/urandom). That is a change compared to
before.
This change of the hashing function and accessing the random pool
might be undesired for libnm/libnm-core. Hence, the change is not
done there as it possibly changes behavior for public API. Maybe
we should do that later though.
At this point, there isn't much of a change. This patch becomes
interesting, if we decide to use a different hashing algorithm.
In a later commit we'll add a new generic client function used by
nmcli and nmtui. nm-client-utils.c seems the right place for it, so
move the file to the base library that is used by both clients.
While at it, also put in that file some functions that will be needed
by nmtui.
As far as NetworkManager is concerned, the "connection.id" (also called
"con-name" in nmcli) is a pretty name and does not need to be unique.
UI components usually show the "connection.id" instead of the
"connection.uuid" identifier. It is hence likely, that the user
would not intentionally re-use the same name for multiple connection
profiles.
Print a warning to stderr when the user adds such a connection.
This only affects `nmcli connection add` and `nmcli connection import`,
but not `nmcli connection clone` and not interactive edit mode.
https://bugzilla.redhat.com/show_bug.cgi?id=1460796
Currently nmcli considers the state of the device associated to a
connection to determine the success of an activation; for VPNs the
device is the parent interface on which the VPN is established.
This means that VPNs on bond/bridge/team interfaces are reported as
connected immediately because of the special handling of master
devices state in check_activated().
The parent device state is not meaningful for VPNs, so don't track it.
Since properties are asked only when the connection has the related
setting, ensure that the connection type is set early so that the base
type gets added to the connection before evaluating other settings.
After NMSettingConnection properties, ask properties for the base
setting and then all other settings.
In the previous code it is not clear to me that there won't be
a situation where we don't react on a state change, waiting for a
device-state-change that never comes.
Now, only wait for a better device-state reason if:
- we have a device
- and the ac-reason is unspecific (NM_ACTIVE_CONNECTION_STATE_REASON_DEVICE_DISCONNECTED)
- and the device still references the current active connection
- and the device state is not yet FAILED or DISCONNECTED.
The most important change is that we only wait longer, if the device's
active-connection is still the same as our current active connection.
I don't think this commit is really necessary, but I cannot understand
the previous logic.
See-also: 57a26fd2aa
This basically uses "wifi" in place of "802-11-wireless" and analogously
for other setting types that have aliases unless a --terse option was
specified.
Apart from looking nicer it makes the default output less wide,
hopefully avoiding line breaks on 80 column terminals in basic use
cases.
