On Mon, 2012-02-27 at 16:11 +0200, Marko Myllynen wrote: > > Also, having the information about ldap connection state (i.e. sssd > > running in connected or disconnected mode) is extremely useful to me as > > one the biggest pain with winbind is its cache - you never know which > > information came from the authoritative source and which was just cached > > & winbind can not bind to any server due to whatever reason. > > I filed an RFE to implement querying of online/offline status two years > ago but it's been silent on that front for long time, not sure what's > the status with the InfoPipe effort it was planned to be combined with: > > https://fedorahosted.org/sssd/ticket/385
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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
