fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2026-01-07 18:20:22 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

core: ignore unmanaged devices for explicit activation request depending on multi-connect

Browse source 
When a device is unmanaged, an explicit activation request can
still activate it. In particular, that is the case for

  $ nmcli connection up "$PROFILE" ifname "$DEVICE"

It is also the case, for plain

  $ nmcli connection up "$PROFILE"

where NetworkManager searches for a suitable device -- depending on
multi-connect setting of the profile.

The idea is, that a profile with "multi-connect=single" is expected
to sufficently and uniquely match a device, based on matching properties
like "connection.interface-name". In that case, an explicit activation
request from the user shows the intent to manage the device.
Note that it's hard to understand whether the profile really uniquely
selects a particular device. For example, if the profile doesn't specify
"connection.interface-name", it might still uniquely identify
an ethernet device, if you only have one such device.

On the other hand, with "connection.multi-connect" other than "single",
it is very much expected that the profile does not strictly match
one device.

Change the behavior here for multi-connect profiles. This allows the
user to block individual devices from activation via

  $ nmcli device set "$DEVICE" managed not

A subsequent

  $ nmcli connection up "$MULTI_PROFILE"

will not consider "$DEVICE" as suitable candidate for activation.

Likewise, in the future we may want to add a

  $ nmcli connection up --all "$MULTI_PROFILE"

command, to activate the profile on all suitable device.
In that case again, unmanaged devices probably also should be skipped
for multi-connect profiles.

https://bugzilla.redhat.com/show_bug.cgi?id=1639254
This commit is contained in:
Thomas Haller 2018-10-17 11:33:02 +02:00
parent 920346a5b9
commit 0cb8bed23c
1 changed files with 35 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

37
src/nm-manager.c
View file

@ -3404,10 +3404,43 @@ nm_manager_get_best_device_for_connection (NMManager *self,
if (!connection)
connection = nm_settings_connection_get_connection (sett_conn);
flags = for_user_request ? NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST : NM_DEVICE_CHECK_CON_AVAILABLE_NONE;
multi_connect = _nm_connection_get_multi_connect (connection);
if (!for_user_request)
flags = NM_DEVICE_CHECK_CON_AVAILABLE_NONE;
else {
/* if the profile is multi-connect=single, we also consider devices which
* are marked as unmanaged. And explicit user-request shows sufficent user
* intent to make the device managed.
* That is also, because we expect that such profile is suitably tied
* to the intended device. So when an unmanaged device matches, the user's
* intent is clear.
*
* For multi-connect != single devices that is different. The profile
* is not restricted to a particular device.
* For that reason, plain `nmcli connection up "$MULIT_PROFILE"` seems
* less suitable for multi-connect profiles, because the target device is
* left unspecified. Anyway, if a user issues
*
* $ nmcli device set "$DEVICE" managed no
* $ nmcli connection up "$MULIT_PROFILE"
*
* then it is reasonable for multi-connect profiles to not consider
* the device a suitable candidate.
*
* This may be seen inconsistent, but I think that it makes a lot of
* sense. Also note that "connection.multi-connect" work quite differently
* in aspects like activation. E.g. `nmcli connection up` of multi-connect
* "single" profile, will deactivate the profile if it is active already.
* That is different from multi-connect profiles, where it will aim to
* activate the profile one more time on an hitherto disconnected device.
*/
if (multi_connect == NM_CONNECTION_MULTI_CONNECT_SINGLE)
flags = NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST;
else
flags = NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST & ~_NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST_OVERRULE_UNMANAGED;
}
if ( multi_connect == NM_CONNECTION_MULTI_CONNECT_SINGLE
&& (ac = active_connection_find_by_connection (self, sett_conn, connection, NM_ACTIVE_CONNECTION_STATE_DEACTIVATING, &all_ac_arr))) {
/* if we have a profile which may activate on only one device (multi-connect single), then