4:19 a.m.
On Fri, Jan 04, 2019 at 09:20:20AM +0000, R Davies wrote:
(re-sending as I initially sent to ssd-users-owners in error)
For an AD environment using service discovery.
Periodically sssd will invalidate its cache at unexpected times. Digging
around debug logs and sources leads me to understand the following:
Every 15 minutes (or as defined by ldap_connection_expire_timeout) sssd
re-establishes the connection to LDAP, closing the exiting collection.
When sssd is configured to auto discover (via DNS _srv_ records, where the
priority is the same for each server); auto-discovery might return a
different LDAP server, at which point sssd's stored uSNChanged values are
invalid (as these are unique to each server), the cached values are
cleared, and enumeration is run - essentially afresh - against the new LDAP
server.
Thank you very much for digging into the issue.
Is this outcome expected by design?
Honestly, I'm not sure and I would like some other developers to chime
in with their opinion.
Historically, we've said that SSSD should stick to a 'working' server as
long as it can, so on one hand I see the point in the sticky behaviour.
On the other hand, I've also seen admins relying on the TTL validity of
the SRV records, expecting that, if they change the SRV records, the
client chooses a new server after the TTL expires.
This behaviour is rather unfortunate as sssd_be will become CPU hog as it
rebuilds the cache again.
It is possible to work around the behaviour e.g.:
1) by not using service discovery, i.e.
Yes, in this case, the same server will always be selected from the
list, working around the problem.
ad_server = server1
ad_backup = server2
which is fairly tiresome to maintain across an estate - separate
configurations for different sites etc, faking load balancing by swapping
configurations.
2) having different priorities for each AD server in a given site, losing
load balancing - unless DNS gave out different priorities depending on the
source of the request, but this seems messy.
A better approach might be to patch sssd's auto discovery to "stick" to
the
previously bound LDAP server, currently the first server in the list of
primary servers returned by ad_sort_servers_by_dns(). I have a proof of
concept patch that is straight forward, and fairly well contained, the
behaviour is controlled by an ad_sticky option in sssd.conf.
Is there a better solution to this problem? Would a patch - as vaguely
outlined above - likely gain acceptance?
If the behaviour is controllable by an option, my opinion is that it
would be a good approach.
Would the stickiness also persist across SRV priority levels? What I
mean is that if server1 had originally the highest priority (the lowest
priority value in the SRV record), but then the SRV record is expired
and the server is suddendly in a lower priority tier, IMO then the server
should be 'forgotten' and a new one chosen..