Buchan, it _IS_ a bug in nss_ldap package in short dbopen is db1 syntax dbX (for X>1) provide a db_185.h wrapper for dbopen nss_ldap looked for dbX/db_185.h (for X <=3) db4 has db4/db_185.h
patch is at: http://www.comedia.it/~bluca/cooker/errata/nss_ldap-207-4.0.92mdk/nss_ldap-207-db4.patch.bz2 fixed rpms at: http://www.comedia.it/~bluca/cooker/errata/nss_ldap-207-4.0.92mdk.i586.rpm http://www.comedia.it/~bluca/cooker/errata/pam_ldap-164-4.0.92mdk.i586.rpm http://www.comedia.it/~bluca/cooker/errata/nss_ldap-207-4.0.92mdk.src.rpm
btw (i commented out buildrequires for gdbm-devel and libldap-devel-static, since i don't see them used anywhere)
Buchan, Dominique could you please test it? Vincent, can you add this to errata?
L. P.S. sorry for large cc list, but i wan't to be sure you see it (message has been quoted fully for people wo don't read cooker)
On Sat, Nov 01, 2003 at 01:34:43AM +0200, [EMAIL PROTECTED] wrote:
On 31-Oct-03 at 17:32, Buchan Milne ([EMAIL PROTECTED]) wrote:
But, I don't see the problem:
[EMAIL PROTECTED] bgmilne]$ grep ^passwd /etc/nsswitch.conf passwd: files ldap [EMAIL PROTECTED] bgmilne]$ wc -l /etc/passwd 38 /etc/passwd
Same for me here, so far.
[EMAIL PROTECTED] bgmilne]$ getent passwd|wc -l 187
Here I get the same symptom as before. # getent passwd|wc -l getent: relocation error: /lib/libnss_ldap.so.2: undefined symbol: dbopen 0
# getent passwd root root:x:0:0:root:/root:/bin/bash # getent passwd etutest1 getent: relocation error: /lib/libnss_ldap.so.2: undefined symbol: dbopen
May be you have a ldap.conf file that does not trigger the call to dbopen? - could you send me the relevant part of your ldap.conf? Here is mine:
# egrep -v '^#|^$' /etc/ldap.conf host myhost.unige.ch base ou=people,dc=unige,dc=ch ldap_version 3 scope sub pam_filter objectclass=posixAccount pam_login_attribute unigeChStudentUid pam_member_attribute gid pam_password clear nss_base_passwd ou=People,dc=unige,dc=ch?sub nss_base_shadow ou=People,dc=unige,dc=ch?sub ssl on sslpath /etc/ssl/certs/cert7.db
Maybe it is this ^^^ ?
(I don't see the point in wanting to verify the SSL cert against the commercial CAs when I use my own CA cery anyway, which is available and configured)
nss_map_attribute uid unigeChStudentUid pam_template_login_attribute unigeChStudentUid
That configuration did work with Mandrake 9.0.
Here is mine, we have production machines running with configs like this, Mandrake 9.0 through 9.2:
[EMAIL PROTECTED] bgmilne]$ egrep -v '^#|^$' /etc/ldap.conf host bgmilne.cae.co.za base dc=cae,dc=co,dc=za ldap_version 3 scope one pam_filter objectclass=posixaccount pam_login_attribute uid pam_password md5 nss_base_passwd ou=People,dc=cae,dc=co,dc=za nss_base_shadow ou=People,dc=cae,dc=co,dc=za nss_base_group ou=Group,dc=cae,dc=co,dc=za ssl start_tls tls_cacertfile /etc/ssl/ca.crt tls_checkpeer yes TLS_CACERT /etc/ssl/ca.crt
Or maybe dbopen is provided by another library loaded at runtime not in the dependancies shown by ldd. It would be strange though: You would expect all symbols of a dynamic libraries to be resolved within the dependancies.
[ Florin: is it OK that dbopen is not defined in the dynamic libraries? ]
- Any suggestion on where to look now to figure this out?
Maybe try without the certdb, since this seems to be about the only thing that has anything to do with libdb (besides libsasl)?
Regards, Buchan
-- Luca Berra -- [EMAIL PROTECTED] Communication Media & Services S.r.l. /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \
