Add a new option that allows to activate a profile multiple times
(at the same time). Previoulsy, all profiles were implicitly
NM_SETTING_CONNECTION_MULTI_CONNECT_SINGLE, meaning, that activating
a profile that is already active will deactivate it first.
This will make more sense, as we also add more match-options how
profiles can be restricted to particular devices. We already have
connection.type, connection.interface-name, and (ethernet|wifi).mac-address
to restrict a profile to particular devices. For example, it is however
not possible to specify a wildcard like "eth*" to match a profile to
a set of devices by interface-name. That is another missing feature,
and once we extend the matching capabilities, it makes more sense to
activate a profile multiple times.
See also https://bugzilla.redhat.com/show_bug.cgi?id=997998, which
previously changed that a connection is restricted to a single activation
at a time. This work relaxes that again.
This only adds the new property, it is not used nor implemented yet.
https://bugzilla.redhat.com/show_bug.cgi?id=1555012
The header-cell is the header for a column with possibly many
rows.
We must not set:
header_cell->skip = nmc_config->overview && is_default;
for a particular cell, because it does not take into accound
the neighbouring rows. It is only correct, if there is only
one row.
Invert the logical meaning and rename "strip" to "to_print".
Each cell then can opt-in, whether it needs to be printed.
Only if no cell opts-in, it will be skipped.
Fixes: 9a19bbcb2f
Instead of re-fetching the UUID each time with a D-Bus call,
cache/memoize it.
On my system, this improves
$ make check-local-clients-tests-test-client
from 20.9 to 20.4 seconds (- 2.6%). That is not stellar, but noticible
enough to warrant this simple change.
These nmcli calls are inside a Util.iter_nmcli_output_modes()
loop, hence, --terse will passed to them already.
Specifying --terse more than once, causes nmcli to fail.
We didn't actually want to test how nmcli rejects such
duplicate arguments. Adjust the test.
Add more tests for various output modes of nmcli.
This most interestingly includes a terse output for
$ nmcli device status
Which was not tested previously (but a later commit will change
behavior here).
This blows up the number of tests even further.
Previously, the test invoked nmcli 850 times (taking ~15 seconds
ony my machine), afterwards, it is 1334 times (taking ~20 seconds).
No doubt, this seems excessive and questionable.
However, I maintain that the computer doesn't mind running a lot of
redundant tests. The important thing is, that we cover as many cases
as possible. Trying at the same time to minimize the number of tests
by avoiding duplicates and redundant tests, is just a lot of manual
labor. Manual labor that must be repeated whenever new tests are added, to
ensure that this test case is not yet covered. So, I am fine
with the large number of tests. Let the computer do the work.
Instead of letting each nmcli run write an individual .expected file,
combine the output of multiple runs in one file (per test).
Advantages:
- since there is a very large number of tests, having a file for each
tests is cumbersome. For example, since they are all added to
$(EXTRA_DIST) (and since we use non-recursive make), autoconf can
easily hit a length limit when processing all the file names.
- previously, whenever we added tests, all .expected files shifted
and the diff was large. Now, there is a chance that the diff is
smaller and more accurate.
It's not libnm's responsibility to hide the banner
depending on the VPN state. libnm should cache and expose
NetworkManager's state, and if the VPN connection has
a banner there, it should be returned.
The previous behavior was since ever in libnm, and in libnm-glib since
the banner was introduced in commit e5b834c1f9.
I think it's wrong if libnm tries too hard putting additional logic
on top of what is on D-Bus.
When a property getter returns an empty/missing strv-array, in multi-line
mode we should not print any lines.
To get that right, we must mark the cell as STRV type, even if there is no value
provided.
Previously, with text_out_flags having NM_META_ACCESSOR_GET_OUT_FLAGS_STRV
and value being NULL, we would not set
cell->text_format = PRINT_DATA_CELL_FORMAT_TYPE_STRV;
and thus, later on the value would be treated as a missing (plain)
string.
The property getter for certain properties tries to return
a strv array.
In this case, the result should be identical, whether an
empty strv array or NULL is returned.
Let _ip_config_get_routes() return %NULL if there are no routes.
This should have no practical difference, but it actually exposes
a bug in "cli/common/utils.c", which was previously hidden by
not commonly returning %NULL. This bug will be fixed in the
next commit.
Currently, nmcli does not sort the list of available connections
for display. Instead, it shows them in the order as NetworkManager
exposes them on D-Bus.
Previously, test-networkmanager-service.py, would generate the list
of available connections by iterating the connections dictionary.
In Python (at least until Python 3.6), the order when iterating over
dictionaries is undefined. This inconsistancy lets tests behave
differently depending on the python version. Possibly with Python
3.4 and 3.5, tests might even behave differently between individual
runs (since Python there uses siphash with a randomized hash seed).
Commands that fail with G_DEBUG=fatal-warnings produce unstable
output like
(process:10743): GLib-CRITICAL **: 16:29:13.635: g_ptr_array_add: assertion 'rarray' failed
To workaround that, add a new option for marking the output as unstable.
An alternative might be to extend the replace_stdout, replace_stderr
arguments to support more powerful matching, like by specifying regular
expression for replacing. However, it's just too complicated. Add a simpler
workaround by passing _UNSTABLE_OUTPUT.
How does `nmcli -f ALL dev show $DEV` look, if it references
a connection that is invisible to the user?
Note in the output:
CONNECTIONS.AVAILABLE-CONNECTIONS[1]: (null) | (null)
At several places, "test-networkmanager-service.py" uses generated numbers
with a defined seed. For example, generated connection's UUID is
generated in a predictable, but randomized way (if you forgive the
inprecise use of the word "random" in context of using a deterministic
seed).
Aside the connection's UUID, this becomes more interesting in the next commit
where the stub server generates a list of IP and DHCP settings in a predictable
randomized way.
For "clients/tests" we spawn the test service multiple times, but also
create similar environments by calling init_001(). This is done for
convenience, where out of lazyness all the tests share one setup. But it's
still a good idea that these tests generate slightly different setups,
wherever applicable. this increases the possible setups which get tested.
For example, the number of static IPv4 addresses (the following commit) is
interested to explicitly test for zero or a non-zero number of
addresses. If all tests happen to use the same seed, the tests are expected
to also generate the same number of addresses, and we miss an opportunity to
hit interesting test cases.
There is still no guarantee that all interesting cases are hit, the chances are just
better. The approach of generating the setup randomly, does not preclude that
the stub-server allows to explicitly configure the setup. However, due to the
sheer number of combinations that might be interesting to test, it's much simpler
to rely on some randomization and have the justifid hope we catch interesting cases.
Also in terms of runtime of the test, the cli unit tests should complete within
few seconds. Testing every combination would result in huge tests and long runtimes.
Also, the patch refactors generating random numbers in
"test-networkmanager-service.py". For example, it introduces
Util.RandomSeed(), which can be used to generate a sequence of different
random numbers. It works by having an internal state and a counter which is
combined to chain the seed and generate different numbers on each call.
Just to give it some variety. Also, note how the message from the
server cannot be translated. Which is the case with real NetworkManager
as well, and is a major usability issue.
The real NetworkManager service has a clear understanding how a valid
connection looks like. This is what nm_connection_verify() returns.
Let also our stub-service verify connections the same way.
Note that this is cumbersome, because the stub service uses python's
dbus module, while libnm only accepts creating NMConnection instances
from GVariant. Thus, we need to a cumbersome conversion first.
It would be better if test-networkmanager-service.py would also expose
normalized connections on D-Bus. But that requires the inverse converion
from GVariant to python dbus.
use nmc_print() for the job.
Also, localize non-terse output.
Also, fix bug with
$ nmcli c s /org/freedesktop/NetworkManager/ActiveConnection/1
if active connection #1 is invisible to the user.
Also, previously, fill_output_active_connection() wrongly tries to
write to a field that doesn't exist:
set_val_strc (arr, 13-idx_start, s_con ? nm_setting_connection_get_slave_type (s_con) : NULL);
The output of `nmcli connection show` contains also information about
whether the profile is currently active, for example the device and
the current (activation) state.
Even when a profile can be activated only once (without supporting
mutiple activations at the same time), there are moments when a
connection is activating and still deactivating on another device.
NetworkManager ensures in the case with single activations that
a profile cannot be in state "activated" multiple times. But that
doesn't mean, that one profile cannot have multiple active connection
which reference it. That was already handled wrongly before, because
`nmcli connection show` would only search the first matching
active-connection. That is, it would arbitrarily pick an active
connection in case there were multiple and only show activation
state about one.
Furthermore, we will soon also add the possibility, that a profile can be
active multiple times (at the same time). Especially then, we need to
extend the output format to show all the devices on which the profile is
currently active.
Rework printing the connection list to use nmc_print(), and fix various
issues.
- as discussed, a profile may have multiple active connections at each time.
There are only two possibilities: if a profile is active multiple
times, show a line for each activation, or otherwise, show the
information about multiple activations combined in one line, e.g. by
printing "DEVICE eth0,eth1". This patch, does the former.
We will now print a line for each active connection, to show
all the devices and activation states in multiple lines.
Yes, this may result in the same profile being printed multiple times.
That is a change in behavior, and inconvenient if you do something
like
for UUID in $(nmcli connection show | awk '{print$2}'); do ...
However, above is anyway wrong because it assumes that there are no
spaces in the connection name. The proper way to do this is like
for UUID in $(nmcli -g UUID connection show); do ...
In the latter case, whenever a user selects a subset of fields
(--fields, --get) which don't print information about active connections,
these multiple lines are combined. So, above still works as expected,
never returning duplicate UUIDs.
- if a user has no permissions to see a connection, we previously
would print "<invisible> $NAME". No longer do this but just print
the ID was it is reported by the active-connection. If the goal
of this was to prevent users from accidentally access the non-existing
connection by $NAME, then this was a bad solution, because a script
would instead try to access "<invisible> $NAME". This is now solved
better by hiding the active connection if the user selects "-g NAME".
- the --order option now sorts according to how the fields are shown.
For example, with --terse mode, it will evaluate type "802-11-wireless"
but with pretty mode it will consider "wifi". This may change the
ordering in which connections are shown. Also, for sorting the name,
we use g_utf8_collate() because it's unicode.
