On Fri, Apr 19, 2013 at 08:12:39PM +0200, steve wrote:
>>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.
Then you're fine, yes.
>
>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.
You'd need to attach a gdb to the sssd_be process, turn on logging (gdb
would log to a file called gdb.txt by default I think) and resume the
execution of sssd_be:
# gdb program $(pidof sssd_be)
# (gdb) set logging on
# (gdb) continue
Then run the test case that was causing the crash. When the SSSD crashes,
you could also save the core file:
# (gdb) generate-core-file
Thank you for your help debugging this problem!