Before commit e3ac45c026 the reader set the private key in the
setting using the libnm function, which also set the key as client
certificate if it was in PKCS #12 format.
After the commit, existing connections with a PKCS #12 private key but
without a client certificate became invalid. Restore the old behavior.
Fixes: e3ac45c026 ('ifcfg-rh: don't use 802-1x certifcate setter functions')
When changing the number of VFs the kernel can block for very long
time in the write() to sysfs, especially if autoprobe-drivers is
enabled. Turn the nm_platform_link_set_sriov_params() into an
asynchronous function.
During shutdown, systemd should first stop NetworkManager and then
the dispatcher service. Note that dispatcher service is D-Bus activated,
so the two services don't Want/Require each other. But the ordering
still matters.
Remove the call-id from the requests hash before invoking the callback.
This prevents the user to cancel the request from within the callback.
Supporting such a use case is not necessary so prevent it and tighten
the callers up.
- drops nm_dispatcher_init(), which was called early in the main loop
and created a proxy synchronously. Instead, the GDBusConnection is
always ready.
- reuse the GDBusConnection of NMDBusManager. This means, we won't even
try from in "initrd" configure-and-quit mode.
- as before, there is no "manager" instance. Instead, the data is stored
in a global variable. That's ok. What is not OK is how the entire
shutdown is handled (calling dispatcher blockingly, not waiting for
requests to complete). That is fixable, but a lot of work. It is
independent of whether we use a manager object or not.
A guint value can wrap, so we would need to check that we don't allocate duplicate
IDs (which we currently don't, and it's likely never to actually hit).
Just expose the (opaque) pointer of the call-id.
We still keep a "request_id", but that is only for logging purpose.
This way, we avoid code duplication of how to print the request-id
("(%u) "), but it also will allow up to attach the interface name
and connection name to the call-id, so that we can use it for structured
logging.
We don't need the two callers both unpack the GVariant and pass a GVariantIter.
Let dispatcher_results_process() do the unpacking.
Also, use some cleanup attributes.
We don't need it anymore.
Still, for tests let gdbus-codegen run and generate the sources and
compile them. We want to keep "dispatcher/nm-dispatcher.xml" and ensure
that it is still valid.
Just hook into GDBusConnection directly. No need for this additional
layer that provides nothing. It doesn't even provide extra type-safety,
because you still need to get the arguments of the signal handler right.
That that point, it's as hard as getting the format string for
g_variant_get() right.
It still adds lines of code, because the "Action" method has such a
large argument list.
"nm-dispatcher.c" does something rather simple. It is natural that it
has a bit of global data to keep track of that it's doing ("gl").
But this does not lend itself to pack the job of dispatcher into an
object. In fact, the Handler object was little more about packaging
the GDBus interface skeleton and a bit of state.
Global variables are often problematic because they makes unit testing hard.
But first of all, we have no test for this (we should). But it's not said
that you need an "object" to make testing easier. If we want to make
individual bits easier testable, we can just as well pass all required
parameters explicitly instead of accessing global variables. Since we
package global variables neatly in "gl", this is very simple to
refactor. Also, global variables can make code harder to understand. But
the problem is the amount of state that is accessible. This is not
alleviated by packaging the state in a Handler object.
As there is always only one handler instance, this provides very little
benefit.
I will drop the GDBus interface skeleton soon. So this Handler object
will have even less purpose. Drop it.
It's anyway a singleton that is still referenced by other components.
So unrefing it in the mainloop does not actually release any memory.
However, the GDBusConnection singleton is fundamental for the run of
the program. Keep it accessible in the global variables.
Note that soon I will drop the GDBusInterfaceSkeleton and only operate
on the GDBusConnection. Then it makes more sense to keep it around.
Note that usually we want to keep the amount of global state small.
But this connection is anyway a singleton (that we already implicitly
use). So, it doesn't change the amount of global state nor does it really
have much state (we either have a reference to the singleton or we don't).
Split command line parsing out of the main() function. For one, it's
an self-contained step, so we can make main() simpler.
Also, we don't need the GOptionEntry on the stack of the main() function
for the remainder of the program.
It's ugly to uncoordinated just call exit(). We should quit the mainloop
and clean up everything we had going.
Note that since Handler has no dispose() function, we also need to hack
a g_signal_handlers_disconnect_by_func(). This will change soon.
Silence messages like
find-scripts: Failed to open dispatcher directory '/usr/lib/NetworkManager/dispatcher.d': Error opening directory “/usr/lib/NetworkManager/dispatcher.d”: No such file or directory
find-scripts: Failed to open dispatcher directory '/usr/lib/NetworkManager/dispatcher.d/pre-up.d': Error opening directory “/usr/lib/NetworkManager/dispatcher.d/pre-up.d”: No such file or directory
The messages about loading the scripts are releated to a particular
request. Hence, they should be logged with that context.
Also, we should avoid using g_log() directly. Use our logging macros
instead.
Previously, we would log several messages with level "debug" / g_info().
_LOG_R_D (request, "start running ordered scripts...");
_LOG_R_D (request, "new request (%u scripts)", request->scripts->len);
_LOG_R_D (request, "completed: no scripts");
Note that this effectively logs a message for every event. I think that
is to verbose and not suitable for regular logging.
Only enable these messages if debug logging is enabled. As such, these debug
level messsages now are enabled together with the trace level messages.
What we currently print as "info" level is too verbose for regular
operation. It prints two messages for every dispatcher event. That's
already for debugging.
Next that will be downgraded, so rename "debug" to "trace" and "info" to
"debug".
There is only renaming, no change in behavior.
The sole purpose of this is more type-safe macros.
An alternative solution would be to define a function instead of a
macro. But if the function is unused (currently!) you get a compiler
warning (on some compilers even when marking the function as "static
inline", if it's in the source file). A workaround for that would be
to mark the function as _nm_unused, or to use a macro instead.
_NM_ENSURE_TYPE_CONST() is to aid the macro solution.
Commit d6ec009afd ('team: normalize invalid configuration during
load') let's keyfile reader ignore JSON configs that cannot be parsed.
Keep doing that, but don't parse the JSON twice for that.
Just set the JSON, and if the setting afterwards does not verify, reset
it to NULL. We also get a better error message and in most cases we
don't need to parse twice.
- re-use the existing meta-data. That is, don't duplicate the
dbus-names, the types, or the default value. Instead, parse the
settings according to these flags.
- notice and return if there are any suspicious/wrong keys in the
variant. For strict parsing, we should not silently ignore them.
- previously, the code used g_variant_lookup() to search for the
expected keys. As the number of keys that we look up is fixed, this
still had O(n). But if we want to detect and reject invalid keys,
we cannot use g_variant_lookup() but need to iterate the entire variant
once.
Completely refactor the team/JSON handling in libnm's NMSettingTeam and
NMSettingTeamPort.
- team handling was added as rh#1398925. The goal is to have a more
convenient way to set properties than constructing JSON. This requires
libnm to implement the hard task of parsing JSON (and exposing well-understood
properties) and generating JSON (based on these "artificial" properties).
But not only libnm. In particular nmcli and the D-Bus API must make this
"simpler" API accessible.
- since NMSettingTeam and NMSettingTeamPort are conceptually the same,
add "libnm-core/nm-team-utils.h" and NMTeamSetting that tries to
handle the similar code side-by-sdie.
The setting classes now just delegate for everything to NMTeamSetting.
- Previously, there was a very fuzzy understanding of the provided
JSON config. Tighten that up, when setting a JSON config it
regenerates/parses all other properties and tries to make the
best of it. When modifying any abstraction property, the entire
JSON config gets regenerated. In particular, don't try to merge
existing JSON config with the new fields. If the user uses the
abstraction API, then the entire JSON gets replaced.
For example note that nm_setting_team_add_link_watcher() would not
be reflected in the JSON config (a bug). That only accidentally worked
because client would serializing the changed link watcher to
GVariant/D-Bus, then NetworkManager would set it via g_object_set(),
which would renerate the JSON, and finally persist it to disk. But
as far as libnm is concerned, nm_setting_team_add_link_watcher() would
bring the settings instance in an inconsistent state where JSON and
the link watcher property disagree. Setting any property must
immediately update both the JSON and the abstraction API.
- when constucting a team setting from D-Bus, we would previously parse
both "config" and abstraction properties. That is wrong. Since our
settings plugins only support JSON, all information must be present
in the JSON config anyway. So, when "config" is present, only the JSON
must be parsed. In the best case, the other information is redudant and
contributes nothing. In the worse case, they information differs
(which might happen if the client version differs from the server
version). As the settings plugin only supports JSON, it's wrong to
consider redundant, differing information from D-Bus.
- we now only convert string to JSON or back when needed. Previously,
setting a property resulted in parsing several JSON multiple times
(per property). All operations should now scale well and be reasonably
efficient.
- also the property-changed signals are now handled correctly. Since
NMTeamSetting knows the current state of all attributes, it can emit
the exact property changed signals for what changed.
- we no longer use libjansson to generate the JSON. JSON is supposed
to be a machine readable exchange format, hence a major goal is
to be easily handled by applications. While parsing JSON is not so
trivial, writing a well-known set of values to JSON is.
The advantage is that when you build libnm without libjansson support,
then we still can convert the artificial properties to JSON.
- Requiring libjansson in libnm is a burden, because most of the time
it is not needed (as most users don't create team configurations). With
this change we only require it to parse the team settings (no longer to
write them). It should be reasonably simple to use a more minimalistic
JSON parser that is sufficient for us, so that we can get rid of the
libjansson dependency (for libnm). This also avoids the pain that we have
due to the symbol collision of libjansson and libjson-glib.
https://bugzilla.redhat.com/show_bug.cgi?id=1691619
