#456 catch going online to reset offline status of back ends
Closed: Fixed None Opened 13 years ago by sgallagh.

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 90acbcf

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

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

7 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1498

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata