For example, if you want to test whether a value is present and
reset it to a different value (only if it is present), it would
be reasonable to do
if (svGetValue (s, key, &tmp)) {
svSetValue (s, key, "new-value");
g_free (tmp);
}
Without this patch, you could not be sure that key is not
set to some inparsable value, which svWriteFile() would then
write out as empty string.
Have invalid values returned by svGetValue() as empty string.
That is how svWriteFile() treats them.
We have unit tests for writing and re-reading ifcfg file. Those
tests compare whether a file can be successfully read and is
semantically identical.
However, there were no tests that a certain output is written in
a stable format. We aim not to change the output of what we write.
For that, add tests to not only check the semantic of the written
ifcfg file, but their bits and bytes.
Some future changes may well intentionally change the current
output. That will require to update the expected result files
and can be done via
NMTST_IFCFG_RH_UPDATE_EXPECTED=yes src/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh
Note that alias, route, and key files are not checked.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1445414
libnm contains the public function nm_utils_enum_from_str() et al.
The function is not flexible enough for nmcli's usecase. So, I would
need another public function like nm_utils_enum_from_str_full() that
has an extended API.
That was already required previously for ifcfg-rh writer, but in that
case I could just add it as internal API as libnm-core is linked statically
with NetworkManager.
I don't want to commit to a public API for an utility function. So move
the code instead to the shared directory, so that nmcli may link
statically against it and use the internal API.
This part contains static functions and variables to describe
settings. It is distinct from the mechanism to use them, or
access them.
Split it out.
It still uses clients/cli/common.h and clients/cli/utils.h
which shall be fixed next.
In practice, this should only matter when there are multiple
header files with the same name. That is something we try
to avoid already, by giving headers a distinct name.
When building NetworkManager itself, we clearly want to use
double-quotes for including our own headers.
But we also want to do that in our public headers. For example:
./a.c
#include <stdio.h>
#include <nm-1.h>
void main() {
printf ("INCLUDED %s/nm-2.h\n", SYMB);
}
./1/nm-1.h
#include <nm-2.h>
./1/nm-2.h
#define SYMB "1"
./2/nm-2.h
#define SYMB "2"
$ cc -I./2 -I./1 ./a.c
$ ./a.out
INCLUDED 2/nm-2.h
Exceptions to this are
- headers in "shared/nm-utils" that include <NetworkManager.h>. These
headers are copied into projects and hence used like headers owned by
those projects.
- examples/C
For IPv4 we support both the legacy and the new route file format. In
the legacy format, option are appended to the "ip route" command
arguments:
203.0.113.0/24 metric 3 via 198.51.100.1 dev eth2 cwnd 14 mtu lock 1500
This is backwards compatible with initscripts. In the new format, a
OPTIONSx= variable is added to represent the options in the same
format understood by iproute2:
ADDRESS0=203.0.113.0
NETMASK0=255.255.255.0
GATEWAY0=198.51.100.1
METRIC0=3
OPTIONS0="cwnd 14 mtu lock 1500"
initscripts do not support this variable at the moment (but the
changes needed to support it are trivial).
By default the new format is used, unless the route file is already in
the legacy format.
For IPv6 only the legacy format is supported, as before.
The filename of the shvarFile instance should be immutable and stay
unchanged for the entire lifetime of the instance. Similarly, the
modified flag should not be explicitly set.
However, for testing it is still useful to give the unit test a
direct access to those functions.
Rename the setters to make it clear that this is test-only.
Having a bridge-port/team-port setting for a connection that
has a different slave-type makes no sense. Such a configuration
shall be considered invalid, and be fixed by normalization.
Note that there is already a normalization the other way around,
when you omit the "slave-type" but a "master" and one(!) port-type
setting is present, the slave-type is automatically determined
based on the port-type.
The use of this is of course to modify an existing slave connection
to make it a non-slave. Then the invalid port settings should be
automatically removed.
Previously, ifcfg-rh writer would write the "BRIDGING_OPTS" setting
without a "BRIDGE". The reader would then (correctly) ignore the
bridge-port. Avoid that altogehter, by requiring the connection to
strictly verify.
Writing a connection to keyfile and read it back should result
in the identical setting. That is, a full round-trip would not
alter any information.
That is however particularly not true for certificate properties, where
the keyfile writes blobs to file and coerces paths.
Thus, whenver writing a keyfile we must read back what we just
wrote and use that instead.
Add API to re-read the keyfile after writing it.
Usually, we would expect that whenever we serialize
something to disk, it can be read back exactly the same.
That is however not true for certificates, where we mangle
path and blobs while writing to file.
Anyway, extend the write-API to re-read what we just wrote.
The tests got extended to assert that whatever we write can
be read back the same.
Later, we want to reinject the reread connection into the settings
plugin again.
A "vlan" setting can optionally have an ethernet setting.
However, ifcfg-rh reader always adds such a setting, because
well... Anyway, the result is that writing a VLAN setting
without ethernet section will yield a different result
on re-read.
Let's have normalization add the ethernet setting, so that
two we consistently have it present.
Our reader/writer has flaws. We easily write out something that
is re-read differently. That is a problem and should be fixed.
Add API to re-read the connection after writing.
Extend the tests to check that the re-read value is identical
to what we wrote. In some cases, this does not hold. That is
usually a bug which needs fixing. Note that for certificate
blobs and paths we may intentionally mutate the connection
during writing, so there are valid cases where a connection
is re-read differently.
Some keys, such as MASTER may still be different as they may depend on
other connections. svWriteFile() checks if the resulting file is
different already anyway.
Add svGetValue_cp() and svGetValueStr() for completeness.
Currently, we mostly use svGetValueStr_cp(), which I think is wrong
because for most cases we should instead not ignore empty values -- that
is, svGetValue_cp() would be a better choice.
Also, I think that the non *_cp() API should be preferred in many cases
because it avoids cloning the value in many cases. The API is not
necessarily less favorable either:
gs_free char *value = NULL;
value = svGetValue_cp (s, key);
if (value)
...
vs.
gs_free char *value_to_free = NULL;
const char *value;
value = svGetValue (s, key, &value_to_free);
if (value)
...
Add the two missing variants, so that future code can use what fits
best, not following undesired practices because seemingly there is
no alternative.
We have
- svGetValue()
- returns the original string
- avoids copying the string unless necessary
- svGetValueStr_cp() (formerly svGetValueString())
- returns the original string, unless it is empty ""
- always clones the string
I think the behavior svGetValueStr*() of coercing "" to NULL is wrongly
used in most places. We should better handle "" like any other value,
not treat it as unset.
That would require another function svGetValue_cp(), which is like svGetValue()
but always copies the string. Rename svGetValueString() so that there is a place
for names like
- svGetValue_cp()
- svGetValueStr()
Also rename svSetValueString() to svSetValueStr().
Ifcfg reader now properly handles escaping and quoting. We don't
need to stip whitespace, if somebody explicitly configures
prop=" value"
it is a configuration error.
