nm_remote_settings_list_connections() ensures the connections are loaded first.
We check "help" commands before getting connections, because it is time
intensive action.
When removing/replacing a NMSetting in an NMConnection, we have
to disconnect setting_changed_cb() from the "notify" signal.
Backport commit dfba4ce1e1 from
libnm-core.
Signed-off-by: Thomas Haller <thaller@redhat.com>
verify() used to modify interface-name of the base settings. This is
discouraged, because verify() should not touch the connection.
For libnm-core we can change behavior and only modify the connection
in normalize().
Also, be more strict not to verify() sucessfully on invalid
interface-name.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When calling nm_setting_verify() without providing any settings in @all_settings,
we assume that the setting on its own might be valid.
Only when checked together with all settings, we want to consider the setting
in the full context. nm_connection_verify() ensures to pass on a list of settings.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Previously, NMSettingInfiniband:verify() silently modifies the
setting for invalid MTU. verify() should not do that.
For libnm-core we can change behavior and implement normalization
of MTU. This changes behavior for NMSettingInfiniband:verify() so
that MTU gets no longer fixed by verify() alone. Instead verify()
fails with a verification error.
Due the possibility to normalize the MTU, NM still can receive
invalid settings and fix it.
For libnm-core we don't change behavior, merely add a code comment.
Signed-off-by: Thomas Haller <thaller@redhat.com>
We would expect that attempts to normalize a connection
are successful as verify() indicates. This way, a connection
is not modified if it cannot be fixed, and a connection will
be valid and modified after attempts to normalization.
However, there might be subtle, unexpected ways how this can fail.
For example, if NMSettingConnection:verify() detects a missing base type
setting, it returns NORMALIZABLE_ERROR if it finds a valid
NMSettingConnection:type. Normalization then adds an empty, default
setting. However, a new verify() might fail due to other reasons.
This would be a bug in NMSettingConnection:verify() which must not
indicate that it is able to normalize the connection, when it actually
is unable to do so.
Such bugs need fixing, but the code should be more robust to this case
because there might be complex, unanticipated situations.
Especially since NM relies on having a valid connection after normalize(),
so a strict error-out behavior is important.
Signed-off-by: Thomas Haller <thaller@redhat.com>
nm_connection_normalize() can now detect the 'type' property
based on existing base settings.
It can also create a (default) base setting.
Signed-off-by: Thomas Haller <thaller@redhat.com>
nm_connection_normalize() can now add the slave setting as needed. Remove
the duplicate functionality.
This undoes commit 664d64e0c0
but the same functionality is now provided via normalize().
Signed-off-by: Thomas Haller <thaller@redhat.com>
Some NMSettingConnection:slave-type types require a matching slave #NMSetting.
Add normalization of either the 'slave-type' property or the slave-setting.
Also be more strict in NMSettingConnection:verify() to enforce an
existing slave-setting depending on the slave-type.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Partly it was already there. This makes NMSettingConnection:verify() stricter
then before, but validates the same as of NMConnection:_nm_connection_verify().
Signed-off-by: Thomas Haller <thaller@redhat.com>
When removing/replacing a NMSetting in an NMConnection, we have
to disconnect setting_changed_cb() from the "notify" signal.
Signed-off-by: Thomas Haller <thaller@redhat.com>
In general, we don't set errors if passing a completely invalid @self
pointer to a method. We usually also don't set the error argument
when asserting. So, just drop it.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This is an utility function that can be called during verify()
to find an NMSetting from @all_settings.
This is especially useful for looking up the NMSettingConnection
which usually is present. So just get it quickly. In the unexpected
case that it is missing, it sets @error and we can return.
Signed-off-by: Thomas Haller <thaller@redhat.com>
At the end of reading the connection, reader calls nm_connection_normalize()
to normalize the connection. Normalization inplicitly verifies the
connection.
Doing a verify along the way is not needed and even harmful. Soon further
checks will be added that make verify() fail, but normalize()
can fix the connection. So, while reading, we might actually have
an invalid connection, that will be normalized as last step.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The new nm_connection_normalize() function allows to fixup an incomplete connection.
The keyfile reader should call normalize on a connection, so that we can implement
common normalizations there instead of inside the settings plugin.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The recent change c88b832ce9 allows for
missing 'id' and 'uuid' entries. Further make the keyfile reader
more accepting, by creating a missing NMSettingConnection.
Signed-off-by: Thomas Haller <thaller@redhat.com>
As NM_SETTING_SECRET_FLAGS_ALL is used in libnm/nm-vpn-plugin-utils.c,
it is exposed as internal API and should be declared in
nm-core-internal.h.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Add a header file to expose private utility functions from libnm-core
that can be used by NetworkManager (core) and libnm.so. The header
is also used to give privileged access to libnm-core. Since NM links
statically, these functions are not exported and not part of public ABI.
This also removes the NM_UTILS_PRIVATE_CALL() macro and libnm.so no
longer exports nm_utils_get_private().
Before, this functionality was partly declared in nm-utils-private.h.
This was wrong because nm-utils-private.h is for functionality
entirely private to libnm-core.
Signed-off-by: Thomas Haller <thaller@redhat.com>
A few of the settings plugins were calling nm_connection_clear_secrets()
from their finalize() method, but this call can emit signals, and by
the time finalize() runs, the object has a refcount of 0. Signals
cannot be emitted from a finalized object, but instead could be
emitted from dispose() before the object is finalized.
Instead of moving the nm_connection_clear_secrets() to dispose() in each
plugin, make the behavior generic instead. The settings plugins' parent
object is NMSettingsConnection, so clear secrets there. Plus,
NMSettingsConnection caches system & agent secrets with NMSimpleConnection
objects, so clear secrets in NMSimpleConnection's dispose too.
Commit fb6cde50 changed from setBlobs in the old wpa_supplicant D-Bus
interface, which returned an integer status code, to AddBlob in the new
one, which doesn't, but didn't account for that change. That caused
error messages of the form "Couldn't set network certificates: Too few
arguments in reply." on valid connection requests.
Signed-off-by: Geoffrey Thomas <gthomas@mokafive.com>
When connecting a master connection, no slave devices will be activated
automatically. The user is supposed to activate them individually.
Hence nmcli should not wait for the connection to be fully activated
because that is not going to happen (unless the user connects a slave
connection from another terminal).
Instead, for master connections behave differently and signal success
once the master device reaches IP_CONFIG state.
This revises behavior introduced by commit
47710f8211.
https://bugzilla.gnome.org/show_bug.cgi?id=733641
Signed-off-by: Thomas Haller <thaller@redhat.com>
Signed-off-by: Jiří Klimeš <jklimes@redhat.com>
