[Freeipa-users] Needs help understand this timeout issue

[Sullivan, Daniel [CRI]]

The  ldap_enumeration_search_timeout is for enumeration, this is for looking up all users, try using the ldap_opt_timeout and or ldap_opt_timeout for a single user lookup.  If a lookup is timing out you will definitely see it in your domain logs, it’s hard to miss.

I would take the time to familiarize yourself at a minimum with the following two articles:

https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/

https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/

Also, this is very good document to familiarize yourself with, it has a lot of very detailed and use information.

https://fedorahosted.org/sssd/wiki/InternalsDocs

My personal opinion based on experience is that if you are going to be leveraging sssd in a trusted AD setup, you should be prepared to take on performance tuning considerations and become intimately familiar with the internals of sssd, specifically how a lookup works, and how to tune sssd as well as 389ds.  You should know the difference between the mapped memory cache, the sysdb, how to use ldbsearch to inspect the cache, etc.  The learning curve is a little steep but once you get over it it’s not that bad. 

Dan

> On Feb 1, 2017, at 2:53 AM, Troels Hansen <th at casalogic.dk> wrote:
> 
> Hmm, suspect its happening on the server...... thous I haven't been able to pinpoint a log entry that confirms my suspecting.
> 
> I have pinpointed the timeout to happen after 58 seconds after completely removing the SSSD cache and restaring SSSD, which leads me to think my issue is related to ldap_enumaration_search_timeout which defaults to 60.
> 
> rm -fr /var/lib/sss/{mc,db}/* && systemctl restart sssd && time id shja
> 
> However, I'm unable to crank it up on the server as it seems to be adjusted Down to 60 Again?
> 
> Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_get_options] (0x0400): Option ldap_enumeration_search_timeout has value 120
> (Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): Option ldap_enumeration_search_timeout has value 60
> (Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): Option ldap_enumeration_search_timeout has value 60
> 
> LDAP seems speedy enough, not timeouts while querying it manually while a client is doing a user lookup.
> 
> ----- On Jan 30, 2017, at 6:06 PM, Sullivan, Daniel [CRI] dsullivan2 at bsd.uchicago.edu wrote:
> 
>> 
>> If the timeout is occurring on the server, I would start by increasing one or
>> both of these values:
>> 
>> ldap_opt_timeout
>> ldap_search_timeout
>> 
>> If that doesn’t work I’d take look to see if the 389 server is under high load
>> when you are performing this operation.  The easiest way I have found to do
>> this is to just execute an LDAP query directly against the IPA server when you
>> are performing an id lookup, for example:
>> 
>> ldapsearch -D "cn=Directory Manager" -w <pw> -s base -b "cn=config"
>> "(objectclass=*)”
>> 
>> If the LDAP server is not responsive you probably need to increase the number of
>> worker threads for 389ds.  Also, you might want to disable referrals, check out
>> the man pages for this;
>> 
>> ldap_referrals = false
>> 
>> Also, FWIW, if you crank up debug logging on the sssd client, you should be able
>> to see the amount of seconds of timeout assigned to the operation, and witness
>> the fact that the operation is actually timing out by inspecting the logs
>> themselves.  The logs can get a little verbose but the data is there.
>>