We configurably use --enable-gtk-doc/--disable-gtk-doc, but
we always require --enable-introspection (due to --enable-vala).
Add the missing build requirement to the "xsltproc" binary, which is in
libxslt package.
With --enable-introspection we generate various targets that either
require perl or xsltproc. Error out when building with introspection
enabled but the programs are not found.
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.
This adds definition of a set of known route option attributes to
libnm-core and helper functions.
nm_ip_route_attribute_validate() performs the validation of the
attribute type and, in case of a formatted string attribute, of its
content.
nm_ip_route_get_variant_attribute_spec() returns the attribute format
specifier to be passed to nm_utils_parse_variant_attributes(). Since
at the moment NMIPRoute is the only user of NMVariantAttributeSpec and
the type is opaque to users of the library, the struct is extended to
carry some other data useful for validation.
Various libnm objects (addresses, routes) carry an hash table of
attributes represented as GVariants indexed by name. Add common
routines to convert to and from a string representation.
To parse a string, a knowledge of the supported attributes (and their
types) is needed: we represent it as an opaque type
NMVariantAttributeSpec that callers must query to the library for the
specific object type and pass to the parse function.
On rollback, before updating the settings-connection check if it
actually changed. Also, only reactivate the connection if it was
deactivated or if the settings/applied connection changed.
https://bugzilla.redhat.com/show_bug.cgi?id=1427187
Add two new methods can_reapply_change() and reapply_connection() to
the device class. In this way device subclasses can declare that they
support the changes in a given setting and take care of reapplying it.
The kernel doesn't accept an interface to be set as active_slave until
the interface is enslaved to the bond. Delay the initialization of the
property.
Until now any "interface" statement was ignored and any enclosed
statement for which we have a special handling was considered, even if
belonging to a different interface. This can cause wrong options to be
set in the generated dhclient configuration.
Change the code to parse "interface" statements and skip the content
if the interface doesn't match.
https://bugzilla.gnome.org/show_bug.cgi?id=778430
Previously, the test runner would only accept leading options,
an optional "--" separator, followed by "$TEST" and optional arguments
for the test.
Like
./tools/run-nm-test.sh -m src/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh
That is annoying, because to toggle an option you have to seek the
curser in the before the test name.
Now, accept a "--test" option, so that the above can be done with trialing
arguments:
./tools/run-nm-test.sh -t src/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh -m
However, the arguments for the tests still must come last:
./tools/run-nm-test.sh -m [--] src/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh -p /settings/plugins/ifcfg-rh/bridge/write-master
./tools/run-nm-test.sh -t src/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh -m [--] -p /settings/plugins/ifcfg-rh/bridge/write-master
./tools/run-nm-test.sh -m src/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh
makes the test before running it. However, that failed if the
test didn't exist already. Reorder the code so that we always
try to make the test before trying to run it.
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.
