Before, when having a test with nmtst_init_assert_logging(),
the caller was expected to setup logging separately according
to the log level that the test asserts against.
Since 5e74891b58, the logging
level can be reset via NMTST_DEBUG also for tests that
assert logging. In this case, it would be useful, if the test
would not overwrite the logging level that is set externally
via NMTST_DEBUG.
Instead, let the test pass the logging configuration to
nmtst_init_assert_logging(), and nmtst will setup logging
-- either according to NMTST_DEBUG or as passed in.
This way, setting the log level works also for no-expect-message
tests:
NMTST_DEBUG="debug,no-expect-message,log-level=TRACE" $TEST
keyfile should become our main import/export format. It is desirable,
that a keyfile can contain every aspect of a connection.
For blob certificates, the writer in core daemon would always write
them to a file and convert the scheme to path.
This behavior is not great for a (hyptetical) `nmcli connection export`
command because it would have to export them somehow outside of keyfile,
e.g. by writing them to temporary files.
Instead, if the write handler does not handle a certificate, use a
default implementation in nm_keyfile_write() which adds the blob inside
the keyfile.
Interestingly, keyfile reader already supported reading certificate
blobs. But this legacy format accepts the blob as arbitrary
binary without marking the format and without scheme prefix.
Instead of writing the binary data directly, write it with a new
uri scheme "data:;base64," and encode it in base64.
Also go through some lengths to make sure that whatever path
keyfile plugin writes, can be read back again. That is, because
keyfile writer preferably writes relative paths without prefix.
Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate
the detection of pathnames without file:// prefix and use it to
check whether the path name must be fully qualified.
nm_keyfile_plugin_kf_get_integer_list() should always set
@length to zero when returning no integer list. So, this
is probably correct. Still, just to be explicit, anticipate
and handle a missing @tmp_list.
There are three configuration options that contain device specs:
'main.ignore-carrier', 'main.no-auto-default', and
'keyfile.unmanaged-devices'.
Unify the parsing of them by splitting the device spec with
nm_match_spec_split(). This changes behavior for parsing of these
properties.
Also get rid of logging warnings when parsing 'keyfile.unmanaged-devices'.
We have nm_keyfile_plugin_utils_should_ignore_file() to ignore certain
files based on patterns. We also need a matching escape function to
avoid saving connections with a name we would ignore later.
https://bugzilla.gnome.org/show_bug.cgi?id=735824
After refactoring libnm-core to use GBytes instead of
GByteArray/DBUS_TYPE_G_UCHAR_ARRAY, it was forgotten to update
keyfile writer.
This causes keyfile writer to skip the NMSetting8021x:password-raw setting
and raise a g_critical() warning.
Fixes: c43f88907b
When adding a connection to NMSettings we did not check for
duplicate connection UUIDs (which could for example happen
if two different plugins report a conflicting UUID).
Also, we would not check that an already added connection
changes it's UUID.
Both could lead to have duplicate connections (by UUID).
Avoid that two ways:
- when adding a connection to NMSettings, ensure that we don't add
a conflicting UUID. Otherwise just bail out and do nothing.
- when modifying a connection that is already added to NMSettings,
enforce that the UUID cannot change. Otherwise fail with error.
For ifcfg-rh plugin this situation still can happen during reload.
In this case error out and refuse to update the connection. After
all, the user configured invalid UUIDs.
https://bugzilla.redhat.com/show_bug.cgi?id=1171751
Also during add_connection() we must take special care of not "adding" a
connection with a conflicting UUID. In that case we want to fallback to
"update".
update_connection() already does all the checks, so call
update_connection() from add_connection().
If there are keyfiles with duplicate UUIDs, read_connections()
would iterate over the files, loading them as they appear and
overwriting duplicate connections that were just loaded.
For example, have keyfiles 'A' and 'B' with the same UUID.
On start, NM might first load 'A', then 'B'. 'B' would replace the
content of 'A' which was just loaded.
On reload, NM would first overwrite 'B' with 'A', and then again
overwriting 'A' with 'B'.
Fix that by accept the first found connection and don't overwrite
it during the same read_connections() run.
Also sort the files by file modification timestamp so that we
get a reproducible and sensible behavior.
new_connection() and update_connection() are very similar as both
must anticipate collisions of UUIDs.
When reloading a connection (update_connection(), previously), the loaded
connection for a certain path might actually replace another existing
connection. In this case, the old connection must be removed, and
the existing one updated instead.
If reloading a connection changes the UUID to a new value, the old
connection must be removed likewise and a new connection added.
Merge both functions into update_connection().
Only log connection diffs when we update a connection that we actually
care about.
Note that most plugin specific connections use
nm_settings_connection_replace_settings() in their constructor
to initialize themselves. These occurrences are not interesting
and spam the logfile.
Add a "filename" property to NMSettingsConnection, and set it from
keyfile and ifcfg-rh (replacing the existing priv->path variables in
those connection types). (The other plugins either don't use files, or
don't use per-connection files.)
In several cases, connection uuids are generated based on
some strings. Change the algorithm, to prefix the hashed
identifier differently for each setting type. This makes
collisions very unlikely.
Also, change the algorithm, to create proper Variant3 UUIDs.
This is a behavioral change, but it only affects code places
that were added since nm-0-9-10 and were not yet part of
a stable release.
There are different types (variants) of UUIDs defined.
Especially variants 3 and 5 are name based variants (rfc4122).
The way we create our UUIDs in nm_utils_uuid_generate_from_string()
however does not create them according to RFC and does not set
the flags to indicate the variant.
Modify the signature of nm_utils_uuid_generate_from_string() to accept
a "uuid_type" argument, so that we later can add other algorithms without
breaking API.
NMIPRoute is used by NMSettingIPConfig, but also
NMIPConfig. In the former case, default routes are (still)
disallowed. But in the NMIPConfig use-case, it can make sense
to expose default routes as NMIPRoute instances.
Relax the restriction on the NMIPRoute API to allow this
future change.
No code actually supports having NMIPRoute instances with
prefix length zero (default routes). Up to now, all such uses
would be a bug.
https://bugzilla.gnome.org/show_bug.cgi?id=739969
Signed-off-by: Thomas Haller <thaller@redhat.com>
config.h should be included from every .c file, and it should be
included before any other include. Fix that.
(As a side effect of how I did this, this also changes us to
consistently use "config.h" rather than <config.h>. To the extent that
it matters [which is not much], quotes are more correct anyway, since
we're talking about a file in our own build tree, not a system
include.)
