rh #1025007 reports a crash on g_assert_no_error() in
connection_new_or_changed() of src/settings/plugins/ifcfg-rh/plugin.c.
From the back trace I am not 100% sure, what the problem was, but I
think that nm_settings_connection_replace_settings failed because of
nm_connection_update_secrets. Apparently such a situation can
happen and it should simply be accepted as valid.
What might have happened, is that the connection used to have
secrets (maybe it had 802.1x configured?) and then it got changed,
so update_secrets() fails because the connection no longer has a
setting to which the secrets would apply.
https://bugzilla.redhat.com/show_bug.cgi?id=1025007
Signed-off-by: Thomas Haller <thaller@redhat.com>
In Fedora, OVS ports are now identified in ifcfg files as
"TYPE=OVSPort", which NM doesn't recognize, and so it would ignore
those ifcfg files. Unfortunately, this meant that if auto-default
wasn't disabled, and there was no other configuration defined for the
device, then NM would create an NMDefaultWiredConnection for it and
screw things up.
So, add an "unrecognized-specs" settings plugin property, which allows
a plugin to indicate to NetworkManager that it knows of some
non-NetworkManager-supported connection defined for a device. This
will suppress default-wired connection creation for that device,
similar to the "no-auto-default" config file option, but determined by
the plugin instead of by manual configuration. Devices listed in
unrecognized-specs may still be managed by NetworkManager, unless they
are also listed in unmanaged-specs.
https://bugzilla.redhat.com/show_bug.cgi?id=1022256
Rather than having each connection-parsing function do its own
unmanaged-spec handling, just do it all directly from
connection_from_file(), and don't bother trying to fully parse the
file if it is unmanaged, since it won't ever be seen outside of the
plugin in that case anyway.
This also makes it possible to have an ifcfg file of an unrecognized
type be unmanaged.
We were accidentally removing the connection from priv->connections
(and thus from unmanaged-specs) when NM_CONTROLLED changed to no when
rereading a changed connection file.
If an ifcfg file changed from one non-NULL unmanaged-spec to another
(eg, if it previously had an interface-name: unmanaged-spec, and then
you add a HWADDR line, switching it to a mac: unmanaged-spec), we were
not updating the connection's unmanaged property, or emitting
unmanaged-specs-changed.
Also, remove the notify::unmanaged handler, since only plugin.c ever
changes an existing NMIfcfgConnection's unmanaged property, and it
always emits the signal itself afterward (and it needs to manually
emit the signal in other cases anyway, like when a connection is
removed).
When settings are NULL or empty in impl_manager_add_and_activate_connection(),
the connection is created and completed by nm_utils_complete_generic() or
nm_device_complete_connection().
Also, do not assert in nm_connection_is_type(). Returning FALSE there is
sufficient.
Related commit a878cd8145
If a connection is given but no device, the correct device will be
automatically determined.
If a device is given but not a connection, a connection will be
automatically chose from among that device's available connections.
Adds the cli command "nmcli dev connect <ifname>".
When called with a connection path, activates that connection.
When called without a connection path, picks the best available
connection to activate for that device.
Doesn't work with VPN connections because they don't have devices.
This branch decouples NMActiveConnection creation from device activation
so that the NMActiveConnection object tracks the entire activation request
(either internally-requested by the Policy or externally via D-Bus) from
start to finish, instead of the previous situation where the PendingActivation
handled D-Bus requests separately. This also will allow implementation of
the DEACTIVATING state in the future. The NMActiveConnection object tracking
the activation is not actually exported to D-Bus until the device or VPN
activation is completely authorized and actually begins.
It also encapsulates all the details needed to authorize a request into
a new NMAuthSubject class, replacing various "dbus_sender" and "user_requested"
arguments throughout the code.
Besides killing PendingActivation, this patch decouples ActiveConnection
creation from actually activating that connection. This allows the
ActiveConnection to complete authorization asynchronously. This will
also be used in the future for handling the DEACTIVATING state of devices
(for "pre-down" functionality).
ActiveConnections will (soon) not have a D-Bus path on creation, but
only when they are exported after authorization is complete. That
means we can't rely on their dbus path in the secondaries code.
Instead, track them directly since the path may be NULL.
The device may not be created yet (in the case of software devices)
when the ActiveConnection is created; in that case we still want to
proceed with authorization for the connection, but we'll create the
device when authorization is complete.
Both NMActRequest and NMVPNConnection need to track their device's state,
so instead of both subclasses having to do so, consolidate that code into
the superclass.
When ActiveConnections take over authentication, it may mean that the
master active connection is still handling authentication when the
slave starts to activate. Thus the master device may still be in
DISCONNECTED state and not ready to enslave the slave.
Add a 'master-ready' property to NMActiveConnection that NMDevice can
watch for to indicate that the master connection/device is ready to accept
slaves. Since the slave device's ActiveConnection is already tracking
its master connection, and since ActiveConnections don't enter the
ACTIVATING state until their device is ready for slaves, it's pretty
trivial to implement this property.
We need to track the master active connection, since it may require authentication
or other operations to complete before the device actually starts activating.
We want to create the object earlier now, and figuring out the master is
a lot of code that we don't want to run before creating the object. The
master still must be set before exporting the object over D-Bus though,
as before.
Eventually the manager will create both NMActRequest and
NMVPNConnection subclasses directly, instead of leaving
NMVPNConnection creation to the VPN manager.
This also ensures that VPN connections get their user_requested
attribute set correctly, which wasn't happening before in the
case of secondary VPN connections.
When we eventually do authorization in the ActiveConnection itself,
we want to make sure the AC doesn't get exported until everything
is authorized. Thus let the manager handle exporting the objects
since it knows when the AC will be authorized or not.
NM uses "/" to mean a NULL object path, since you can't pass
NULL object paths through D-Bus. The AC code didn't handle that
and we'll soon be passing object paths from D-Bus into it.
Do less authentication in the PA and make the DBusGMethodInvocation
opaque to the PA. This pushes the responsibility for replying to
the D-Bus method call closer to the D-Bus method handler instead
of stuffing it all into the PA. This does mean we need to get
the D-Bus sender name and the sender UID and pass that into the
pending_activation_new(), but we'll clean that up in a bit.
