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.