[SSSD] debbuging, how to turn off cache [SOLVED]

steve steve at steve-ss.com
Fri Apr 19 18:12:39 UTC 2013


On 04/19/2013 07:26 PM, Jakub Hrozek wrote:
> On Fri, Apr 19, 2013 at 07:09:09PM +0200, steve wrote:
>> On 04/19/2013 06:53 PM, Jakub Hrozek wrote:
>>> On Fri, Apr 19, 2013 at 06:33:41PM +0200, steve wrote:
>>>> On 04/19/2013 05:51 PM, Jakub Hrozek wrote:
>>>>> On Fri, Apr 19, 2013 at 04:48:15PM +0200, steve wrote:
>>>>>> Hi
>>>>>> The LDAP_PROTOCOL_ERROR occurs once during user authentication and
>>>>>> again upon logging out. It does not occur with getent or at ny other
>>>>>> time during the session. I'm almost certain that this has something
>>>>>> to do with sssd; users authenticating against nslcd or winbind do
>>>>>> not produce this response from the Samba4 ldap. I'll post over on
>>>>>> samba-technical to see if they can help.
>>>>>> Cheers,
>>>>>> Steve
>>>>> Yes, but can you post the relevent snippet from the logs? They should
>>>>> include the query that is failing.
>>>> Hi
>>>> I put the level 9 logs here:
>>>> https://dl.dropboxusercontent.com/u/45150875/sssd.client.log.tar
>>>>
>>>> I'm not a dev but I'll try: Here is where it fails getting the
>>>> groups for the user (from sssd_default.log) I think that this is
>>>> what produces the LDAP_PROTOCOL_ERROR.
>>> Yes, but that's the same error as before. Let me explain the log
>>> snippet in a more detail.
>>>
>>>> [sssd[be[default]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://dolores.site/CN=Configuration,DC=dolores,DC=site] with fd [22].
>>>> [sssd[be[default]]] [sdap_rebind_proc] (0x1000): Successfully bind to [ldap://dolores.site/CN=Configuration,DC=dolores,DC=site].
>>>                       ^^^^^^^^
>>> An LDAP referral was followed here.
>>>
>>>> [sssd[be[default]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE]
>>>> [sssd[be[default]]] [sdap_process_result] (0x2000): Trace: sh[0x893d088], connected[1], ops[0x895ef58], ldap[0x8933328]
>>>> [sssd[be[default]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE]
>>>> [sssd[be[default]]] [sdap_process_result] (0x2000): Trace: sh[0x893d088], connected[1], ops[0x895ef58], ldap[0x8933328]
>>>> [sssd[be[default]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE]
>>>> [sssd[be[default]]] [sdap_process_result] (0x2000): Trace: sh[0x893d088], connected[1], ops[0x895ef58], ldap[0x8933328]
>>>> [sssd[be[default]]] [sdap_process_result] (0x0040): ldap_result error: [Can't contact LDAP server]
>>>> [sssd[be[default]]] [sdap_handle_release] (0x2000): Trace: sh[0x893d088], connected[1], ops[0x895ef58], ldap[0x8933328], destructor_lock[0], release_memory[0]
>>>> [sssd[be[default]]] [remove_connection_callback] (0x4000): Successfully removed connection callback.
>>>> [sssd[be[default]]] [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb
>>>                        ^^^^^
>>> server_setup is the first function that a new sssd_be instance runs
>>> after it crashed and was respawned.
>>>
>>>> [sssd[be[default]]] [recreate_ares_channel] (0x0100): Initializing new c-ares channel
>>>> [sssd[be[default]]] [resolv_get_family_order] (0x1000): Lookup order: ipv4_first
>>> So I'd like to ask you to try two things:
>>> 1) run the same case with ldap_referrals=False in the sssd.conf config
>>> file to stop SSSD from following referrals
>>> 2) if possible, gather the backtrace or the core file
>>>
>>> Thank you!
>> Hi. Brilliant. With ldap_referrals=False it works instantaneously. I
>> can remove steve3 from staff and it is reflected immediately after
>> logging in by id and getent group staff. Similarly for re-adding him
>> to the group. Upon logging in, he appears immediately. Do we lose
>> anything by using  ldap_referrals=False?
>> Cheers,
>> Steve
> I'm glad it finally works for you!
>
> About needing the referrals - I'm not entirely sure about S4, but if it
> behaves just like AD, then you don't lose any data unless you use
> partial replication.
Hi
S4 is advertised as a 1 to 1 replacement for AD and I know the dev's 
strive hard for that. Our production setup has 2 DC's which replicate in 
the normal way. I've never heard of partial replication. Is it safe to 
assume that as I don't know what partial replication is, then we don't 
use it? A far as I know, the DC's supply identical LDAP attributes no 
matter which is queried.
>
> I'm still quite concerned about the crash you saw. Any chance you could
> get us the backtrace? Even if sssd was not configured optimally, it
> should never ever crash. (Then again, the problem might have been in
> openldap as we use libldap's referral chasing). The backtrace would tell
> us for sure.
Yes, of course except I don't know how to do it. I once used gdb for the 
Samba guys when we had a crash. Is gdb what you mean to produce te 
backtrace? Could you give me a one liner as to what the syntax is to jog 
my memory? I'll dig out my notes and have a go.

Thanks for all your help and for making sssd such a great piece of software.




More information about the sssd-devel mailing list