(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.
Is this outcome expected by design?
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.
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?