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.
ifnet has two extra instances @p12_type/@phase2_p12_type, that only
differed from @pk_type/@phase2_pk_type by their suffix.
But as the suffix field as unused, we can drop that entirely.
If one property has multiple ways to be handled, we should not create
two ObjectType instances, instead let the ObjectType have enough
information to act accordingly.
The PKCS#11 URIs start with the "pkcs11:" scheme. There's a slight
possiblity of a clash with file names relative to the ifcfg file, but
that's probably is unlikely enough the leave us not worried.
The alteratives are probably more horrible (using a different key, or
using a separate key for the scheme alone) and it's already simple
enough to avoid a clash by using an absolute file name.
When the main ifcfg file contains no IP addresses, the method
will be "disabled". Later, when reading IP addresses for the
aliases, we must ensure that the method is manual.
Otherwise, validation fails with
ip.addresses: this property is not allowed for method=disabled
With commit 4f6c91d696, we aimed to
enable mac-address-randomization by default for Wi-Fi. That however
is not possible by default because it breaks various scenarios.
Also, later wifi.mac-address-randomization was deprecated in favor
of wifi.cloned-mac-address setting.
Both wifi.mac-address-randomization and wifi.cloned-mac-address support
global default values, so it is wrong to read a missing
MAC_ADDRESS_RANDOMIZATION setting as "NEVER" -- which due to
normalization also results in cloned-mac-address=permanent.
See also commit 46d53e1101 which does
something similar for keyfile.
This bug also prevents a user from clearing the cloned-mac-address:
$ nmcli connection show "$CONN"
...
802-11-wireless.cloned-mac-address: permanent
802-11-wireless.mac-address-randomization: never
...
$ nmcli connection modify "$CONN: wifi.cloned-mac-address ''
# ^ takes no effect
As workaround, you also need to clear mac-address-randomization:
$ nmcli connection modify "$CONN: wifi.cloned-mac-address '' \
wifi.mac-address-randomization default
https://mail.gnome.org/archives/networkmanager-list/2017-January/msg00060.html
When a ifcfg-rh connection becomes unamanaged it is removed from the
connection list in NMSettings and marked as removed; it is however
kept alive in the plugin and can become managed again later. To avoid
failed assertions, the @removed flag of the NMSettingsConnection must
be cleared if the connection is not being disposed.
All implementations of link_changed() chain up to NMDevice's
base implementation. Thus, everybody wants to set the carrier.
Refactor the code to set the carrier outside of link_changed().
Use nm_utils_fd_get_contents() which has precisely all the steps implemented
to read data from a file descriptor.
There is a downside to this: previously you could compile shvar.c without
nm-core-utils.c. Now, the ifcfg implementation gained a dependency
on NM core utils. That would matter if we one day would like to build
shvar.c without core NetworkManager utils (but that is not planned).
Pre-process each line and parse the key and value.
Thus, keep the key already prepared.
The point is to do the parsing early and keep the
data in a more suitable format in shvarLine.
