#456 catch going online to reset offline status of back ends

Created 7 years ago by sgallagh
Modified 4 months ago

As noted in https://bugzilla.redhat.com/show_bug.cgi?id=586825 we handle changes in network status somewhat poorly. On those systems where !NetworkManager is available and in-use, the backends should register with the !NetworkManager D-BUS service to receive signals when the network status changes (connection dropped, added, changed).

When this signal is detected, if it disconnects or changes the interface the backend is relying on, I propose that we mark the backend offline immediately, so that events like screensaver unlock will immediately go to cached credentials.

Fields changed

description: As noted in https://bugzilla.redhat.com/show_bug.cgi?id=586825 we handle changes in network status somewhat poorly. On those systems where NetworkManager is available and in-use, the backends should register with the NetworkManager D-BUS service to receive signals when the network status changes (connection dropped, added, changed).

When this signal is detected, if it disconnects or changes the interface the backend is relying on, I propose that we mark the backend offline immediately, so that events like screensaver unlock will immediately go to cached credentials. => As noted in https://bugzilla.redhat.com/show_bug.cgi?id=586825 we handle changes in network status somewhat poorly. On those systems where !NetworkManager is available and in-use, the backends should register with the !NetworkManager D-BUS service to receive signals when the network status changes (connection dropped, added, changed).

When this signal is detected, if it disconnects or changes the interface the backend is relying on, I propose that we mark the backend offline immediately, so that events like screensaver unlock will immediately go to cached credentials.

Note: this maybe harder then it seem at a first sight.
We can really force offline mode only if all interfaces have been shut down.
If only one of many is stopped we can't just blindly go oflline.
Same sort of consideration for trying to go online apply.

Well, as I mentioned in the original comment, I think we probably want to compare the interface that changed with the one(s) that the provider is currently using. If it matches, then we go offline. After the reconnect delay, if it belongs online it will sort itself out.

What happens if there are multiple servers configured which are reachable via different interfaces?

The only ones that are relevant are the interfaces that are in use at the moment that NetworkManager signals us. Failover will sort itself out when the offline delay times out and we reconnect.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.3

Fields changed

milestone: SSSD 1.4.0 => SSSD 1.3.0

Fields changed

owner: somebody => jhrozek

We decided to use libnl in favor of NM.

status: new => assigned
summary: Register with NetworkManager for notifications => catch going online to reset offline status of back ends

Fixed by 90acbcf20b5f896ca8f631923afe946c90d90de7

fixedin: => 1.3.0
resolution: => fixed
status: assigned => closed

4 months ago

Metadata Update from @sgallagh:
- Issue assigned to jhrozek
- Issue set to the milestone: SSSD 1.3.0

Login to comment on this ticket.

enhancement

Data Provider

1.1.1

0

https://bugzilla.redhat.com/show_bug.cgi?id=586825

cancel