From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; de-de) AppleWebKit/85.7 (KHTML, like Gecko) Safari/85.5 Description of problem: when using ldapi:// (e.g. ldapi://%2fvar%2frun%2fldapi/ ) socket communication witch nss_ldap everything using pam or nss segfaults (e.g. id, sshd) ldapsearch -x <same URI> works, so does samba. Version-Release number of selected component (if applicable): nss_ldap-207-2 How reproducible: Always Steps to Reproduce: 0. configure ldap authentication 1. put ' SLAPD_OPTIONS='"-h ldap:/// ldapi:///"' ' in /etc/openldap/slapd.conf 2. put ' uri ldapi://%2fvar%2frun%2fldapi/' in /etc/ldap.conf ' 3. restart openldap 4. run ' id ' or whatever Actual Results: SEGFAULT Expected Results: no SEGFAULT Additional info: must be fixed before
*** Bug 112046 has been marked as a duplicate of this bug. ***
Just to add my comments: This problem seems to have gone away in the final release of rhel 3 on ia32 (I am using it without problem.) However, on my new AMD opteron using the x86-64 it does not work. Please would you fix this as quickly as possible - it is preventing me from letting users login to this box. If I can provide more info please let me know. Regards, Paul
Created attachment 96536 [details] strace of segfault on RHEL 3 At least in SMP mode (Test setup: 4x Pentium II Xeon 400 MHz) this bug has not gone away in RHEL 3 final. See attached strace output.
I have LDAP auth working fine on the x86 version for the smp kernel on a P4 hyperthread - ie not with two actual CPUs. The box I suffer the problems on is a dual opteron using the SMP kernel. Regards, Paul
LDAP auth is not the problem, that works fine. nsswitch lookups via ldapi:// (socket in /var/run/ldapi ), not ldap:// or ldaps:// are the problem.
OK - but it still means that you can't use ldap for logins, right? Or am I missing something? Cheers, Paul
version in beta update 1 works for me. great. Paul
I'm glad to hear that you solved your problem. Well, but it doesn't solve the bug. Again, LDAP authentication and nsswitch lookups via ldap://localhost:389/ work FINE, just PERFECTLY! But via ldapi:// %2fvar%2frun%2fldapi/ (unix domain socket in /var/run/ldapi ) it produces segfaults.
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2003-339.html
Actually, I'm having the same issue here. One difference is that our LDAPS server is Active Directory. If LDAPS is enabled (I've not tried just LDAP) to ports 3268 (with TLS) and 3269 (with SSL) I run into the same issues. Here is something else. Under Fedora Core (1.90), the nss_ldap package works flawlessly (there is another issue with kcheckpass but I'll save that for later). As an experiment I compiled the nss_ldap from Fedora 1.90 (nss_ldap-207-6) but that didn't help at all, I still get segmentation violations and behavior described by Jan Koop above. This might be a cyrus-sasl issue but I have not looked into that yet.
One other note. This is Red Hat Enterprise 3 (Update 1) and not the public beta.