On Thu, 2014-05-15 at 11:06 +1000, Trent W. Buck wrote: > In the last couple of weeks, I switched from unencrypted ldap://ldap > to encrypted ldaps://ldap, and now I'm seeing it on around 10% to 20% > of boots (with a sample set of about ten boots).
If you can reasonably reliably reproduce this, can you add the following to /etc/init.d/nslcd (around line 120, right before # start nslcd). (date ; gdb -return-child-result -ex run -ex "thread apply all bt full" -ex "quit" --args ldapsearch -x -H ldaps://ldap/ -b YOURBASEDN' uid=YOURUID mail ) < /dev/null >> /var/log/nslcd.ldapsearch.boot.log 2>&1 & (replace YOURBASEDN and YOURUID with appropriate values) I'm wondering if this can help pinpoint the issue. If ldapsearch also bums out it shouldn't be a threading issue (and at least prove that it isn't something that nslcd is doing wrong). I've recently added this myself but haven't caught a crash yet. > FTR, workarounds I'm considering are: > > - stunnel4 on the clients, then plaintext ldap over that. > (I'm already doing this for > > http://wiki.squid-cache.org/Features/HTTPS#Encrypted_browser-Squid_connection > due to problems with chromium.) > > - build openldap against openssl instead of gnutls. > I used to do this to get sudo-ldap to work with PADL libpam-ldap, > where gnutls+ldaps+setuid was broken. > > Obviously neither are appropriate fixes for Debian. Thanks for the ideas and thanks for updating the bug report. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong --
signature.asc
Description: This is a digitally signed message part
