Learn more about these different git repos.
Other Git URLs
It would be useful if SSSD could provide information about its current status (like online/offline, reachable authentication sources, and so on). Administrators might find this helpful especially in scripts running on laptops.
Fields changed
milestone: NEEDS_TRIAGE => SSSD Deferred
An example use case would be that a custom script checks from SSSD whether it's online or offline and this information could be used to determine whether the host is in the intranet or in internet (taking into consideration different SSSD domains, if needed). One could then use this information for example to apply proper set of firewall rules, adjusting some application parameters, possibly even to start/stop services, and in general tightening the system security when offline (i.e., away from the protection that the company firewall and other such measures provide).
Since SSSD is currently the only system level component keeping track of the online/offline state, it would seem that providing this information to other components would be most helpful. All the actions based on this information would be easily scriptable, so while fully customizable to suit different needs nothing but exposing the information which SSSD already has would be needed.
cc: => jhrozek
I think this action may be more appropriate for a NetworkManager script. NetworkManager can run scripts every time an interfacde is activated or deactivated. SSSD may be offline for reasons not dependent from the actual availability of a network interface (remote server goes down for example) so it would not be a good indication for setting or removing firewall rules.
That is a good point and actually there two different methods to detect networking status with NetworkManager: either with dispatcher.d scripts (see NetworkManager(8) for details) or by querying via API, for example see:
http://mail.gnome.org/archives/networkmanager-list/2010-February/msg00078.html
So ideally SSSD would also support both the polling based method (API) and also a event based mechanisms :)
In general, I see these two methods of NM/SSSD more as complementing than overlapping allowing users to select or combine them as needed to suit their particular environment. For example, in some enterprise environments with tens of thousands of users it would be unthinkable that the authentication/LDAP servers would be unreachable so it could be appropriate to use that for detecting whether a system is in the intranet or not (basically if the authentication servers would be unreachable then more or less everything in the intranet would be affected, too).
I was thinking about this a little bit today.
What if we were to expose the SSSD on the D-BUS system bus and allow applications to register with us for notifications when the SSSD goes offline or comes online.
This could be fairly straightforward, and it would allow applications to take a cue from the SSSD that it's time to switch to offline access (e.g. Thunderbird).
What I'm envisioning is basically a D-BUS interface at org.freedesktop.sssd.domains and a method call registerDomains() that would accept a list of domains to monitor (or all of them).
After that, we would simply send an DomainOffline or DomainOnline signal (with an argument of the name of the domain) to any registered clients whenever that activity occurred.
It would be very easy to implement, now that we're supporting callbacks in the identity provider for going online, and we already had the be_mark_offline() call that we can hook into.
I'm resetting this to NEEDS_TRIAGE for discussion.
milestone: SSSD Deferred => NEEDS_TRIAGE
Thanks for considering this.
In general your suggestion sounds good but I do wonder would it be possible to allow a client to query the initial state SSSD is in when the client registers? If SSSD does not have this information available one possibility would be allowing clients to do a registration time probe, i.e., asking SSSD to make a request - then SSSD would know its current state for sure. Otherwise it might take a very long time before a client gets any information from SSSD if its state does not change.
milestone: NEEDS_TRIAGE => SSSD 1.3
It looks like this effort will be combined with the infopipe effort.
milestone: SSSD 1.5.0 => SSSD 2.0
rhbz: => 0
See https://fedorahosted.org/pipermail/sssd-devel/2012-February/008822.html for additional comments.
blockedby: => blocking: => coverity: => feature_milestone: => patch: => 0 upgrade: => 0
For easier viewing, https://fedorahosted.org/pipermail/sssd-devel/2012-February/008822.html contains:
We haven't done this because we haven't ever been able to determine a way to present this information without sometimes lying. There are two reasons why what you two are asking for is difficult if not impossible to provide:
1) For identity lookups, we always prefer the local cache unless the cache is expired. This is to improve performance and lower the load on the LDAP server. We don't care if we're online or offline if the cache is up-to-date.
2) SSSD is designed to be reactive; we rarely know our definitive online/offline status until a request comes in. Once a request arrives that is a cache-miss (either expired or the first attempt to request this data) we try to ask the server. It's only at this time that we ever know with any degree of certainty whether the system is online or offline. If it's offline, we'll attempt to use the (expired) cached value if it's available, so the client continues to function.
We do some tricks to enable us to detect online availability quickly (such as monitoring the /etc/resolv.conf file so that if it changes, we try to immediately reconnect, guessing that you may have joined a new network or connected to a VPN). But most of the time, the system is idle and querying us will at best give you what our state was the LAST time the providers were asked for LDAP data. This could be very old information and no longer valid.
What I had originally proposed as an answer to Marko's enhancement request was actually a service to which a client could register to be notified of whether a provider had switched from online to offline operation. This is an action we CAN describe definitively. The original intent was to include that in a D-BUS responder that we were scoping, but have now repeatedly shelved in favor of more urgent functionality.
Another thing we COULD do (I'm not sure yet how useful it would be) is include a syslog message at INFO or DEBUG level for each request that's answered by the NSS responder. It could log a message saying that "User userA in [%s]" where %s could be "unexpired cache", "expired offline cache", "refreshed cache" or "not found" for the four cases it's possible for us to detect.
I will note that there are two problems with this approach: 1) syslog will be VERY noisy, as many requests for user information come in every minute. 2) We're planning in 1.9 to supplement the responder cache with an in-memory cache that will basically always return results for the "unexpired cache" without ever contacting the NSS responder, so the responder wouldn't be able to log this case any longer.
Would something asynchronous be possible to implement? I.e. we have a list of ldap servers + credentials for bind. If someone asks for connection status, we might go trough the server list (using the existing code) and attempt just to bind them (no actual search performed as we do not have anything to look for).
The reason why this functionality would be so much welcome is that there are too many things to break - either sssd related (invalid keytab, invalid dns settings, poor network connection - all of them are good enough to make sssd go offline) or system related (invalid username, account locked, other possible problems).
For network admin it is quite tedious to go though all the possible logs and guess what is wrong. If we knew the connection status, it would help us to diagnose the problem much more quickly (like "sssd online, fine, move on, must be something different"). On production system (imagine Linux terminal server with multiple users logged in) it is crucial to diagnose & fix network errors fast.
I understand the requested functionality could be somewhat harder to implement, but it would be very very beneficial.
proposed_priority: => Blocker
May be the status check would report last time when the online authentication and or online data lookup was conducted. This way the administrator would be able to trigger an authentication for a test user and then see whether SSSD went online. For that to happen more reliably the user should not be served from cache so may be we should have a special user that is never cached for exactly these purposes? Or may be there should be a separate mode when responder would not try to use cache and would go directly to the data provider for test purposes. There can be a utility - a small responder "sss_online_test" that would talk to providers directly simulating an authentication and request for user data. If the provider is offline the utility would return that provider is offline. The cache would be out of the way in this case so the problem of "lying" would be addressed.
proposed_priority: Blocker => Important
rhbz: 0 => todo
Moving all the features planned for 1.10 release into 1.10 beta.
milestone: SSSD 2.0 => SSSD 1.10 beta
priority: minor => major
selected: => Not need
Moving tickets that are not a priority for SSSD 1.10 into the next release.
milestone: SSSD 1.10 beta => SSSD 1.11 beta
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=961264 (Fedora)
rhbz: todo => [https://bugzilla.redhat.com/show_bug.cgi?id=961264 961264]
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=985732 (Red Hat Enterprise Linux 7)
rhbz: [https://bugzilla.redhat.com/show_bug.cgi?id=961264 961264] => [https://bugzilla.redhat.com/show_bug.cgi?id=961264 961264], [https://bugzilla.redhat.com/show_bug.cgi?id=985732 985732]
changelog: => design: => design_review: => 0 fedora_test_page: => keywords: => Status review: => 0
mark: => 1
owner: somebody => preichl
cc: jhrozek => jhrozek, tobias.pal@gmail.com
Downstream no longer requires this RFE. Moving to backlog.
milestone: SSSD 1.13 beta => SSSD 1.13 backlog
priority: major => critical sensitive: => 0
The tool could also measure the time an operation took to be useful in performance tuning.
Moving to the next upstream release.
Either of Pavels will work on this feature. Please split the tickets between you as appropriate.
cc: jhrozek, tobias.pal@gmail.com => jhrozek, tobias.pal@gmail.com, pbrezina, preichl milestone: SSSD 1.13 backlog => SSSD 1.14 alpha
In 1.14 Alpha, we will implement ticke #2957 as a first step towards this RFE. The rest will be implemented in the Beta release.
milestone: SSSD 1.14 alpha => SSSD 1.14 beta
owner: preichl => pbrezina patch: 0 => 1
Fixed as part of the sssctl patchset:
More failover improvements are coming in the next release, though, this patchset only displays the online/offline status of the domains. I will ask Pavel to open tickets to track the additional improvements.
resolution: => fixed status: new => closed
Metadata Update from @myllynen: - Issue assigned to pbrezina - Issue set to the milestone: SSSD 1.14 beta
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/1427
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Log in to comment on this ticket.