8:46 a.m.
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.