From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 Description of problem: First, one quick annoyance... ldapsearch doesn't seem to read ldap.conf, it seems to be looking at /etc/openldap/ldap.conf. Should this be a symlink? Onto the issue: I configured ldap.conf so that ldapsearch'es work fine. However, whenever I add "ldap" to nsswitch.conf, things start breaking. Here are the relevant entries in my nsswitch.conf file, which by the way, along with the rest of our ldap setup, have been working great on all our RH9 boxen for half a year now. passwd: files ldap shadow: files group: files ldap Version-Release number of selected component (if applicable): nss_ldap-207-2 How reproducible: Always Steps to Reproduce: 1. add "ldap" to passwd or group (possibly others) in nsswitch.conf 2. "getent passwd" or "getent group" Actual Results: [root@a-lnx006 etc]# getent passwd root:x:0:0:root:/root:/bin/bash ... ... wnn:x:49:49:Wnn System Account:/home/wnn:/sbin/nologin pvm:x:24:24::/usr/share/pvm3:/bin/bash Segmentation fault [root@a-lnx006 etc]# Expected Results: a whole bunch more passwd entries, and not segfault Additional info: This is the default RH WS 3 for Itanium load. I haven't done any updates (yet).
The /etc/ldap.conf and /etc/openldap/ldap.conf configuration files are read by different libraries, and support different configuration directives. The coincidence in their naming is unfortunate and confusing. Can you append the output of ldapsearch -x -b '' -s base supportedSASLmechanisms to this report? (If you get any values, then this is likely a dup of #106801.)
Here you go... This does look like a duplicate of the other bug. Any idea what's going on? [root@a-lnx006 root]# ldapsearch -x -b '' -s base supportedSASLmechanisms version: 2 # # filter: (objectclass=*) # requesting: supportedSASLmechanisms # # dn: supportedSASLMechanisms: GSSAPI # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@a-lnx006 root]#
Hmm, yes, the package was built wrong (links with libsasl2 instead of libsasl). That's being fixed for RHBA-2003:339.
We've downloaded RHBA-2003-339 and recompiled it on a fresh RHEL3 AMD x86_64. While using it, we get a dlopen error and unresolved symbols: PAM unable to dlopen(/lib/security/$ISA/pam_ldap.so) PAM [dlerror: /lib/security/../../lib64/security/pam_ldap.so: undefined symbol: _pam_ldap_readconfigfromdns] PAM adding faulty module: /lib/security/$ISA/pam_ldap.so Failed password for illegal user ##user## from ##ip## port 33347 ssh2 Illegal user ##user## from ##ip## After disabling the included dnsconfig-patch, everything works as expected. Is it possible there's a missing define _LDAP_PAM_LDAP_DNSCONFIG_H when compiling the default package for x86_64.
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
The RHEL3 U1 update fixes the pam_ldap problem on x86_64 with a clean RHEL3 installation. Thanks.