Bug 145310

I can confirm this, but nss_ldap-220-3.x86_64 does not work either, so
it's impossible to log in with ldap at all!

I was able to login by replacing "URI" directive with "HOST". See bug
#135228

Add bugzilla to Cc List

Regarding comment #2 -> did you log in with 227 or 220 ?
I can confirm 220 works with host, in fact this is how this box has
been setup forever

I can't remember now. The host that is working has 226-2 installed,
which was the previous version from rawhide. Unfortunately I do not
have a copy of the rpm, so for now I will have to use host.

Ok if you still have 226-2 sitting in you yum/apt cache I'm interested
- I'm pretty sure it works unlike 227 but I'd like to make sure

As for the host/uri problem -> this is not the subject of this
particular bug, since the bow I'm reporting it from uses host

I found a copy here:

http://fedora.mirrored.ca/fedora/development/x86_64/Fedora/RPMS/nss_ldap-226-2.x86_64.rpm

Ok, thanks, I can confirm then that the problem is with 227 and 226-2
works here (on x86, krb5+ldap auth)

I did a fresh installation of fc3.x86_64, and so far I have been unable to log
in at all using any version of nss_ldap. The configuration is identical to a
working i386 host. I even set /etc/ldap.conf as a symlink to
/etc/openldap/ldap.conf, and did a search with ldapsearch, which returns the
correct information.

The messages are:-

/var/log/secure:
Jan 19 11:07:48 miranda login[23221]: pam_succeed_if: error retrieving
information about user chills

/var/log/messages:
Jan 19 11:07:48 miranda login(pam_unix)[23221]: authentication failure;
logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost=
Jan 19 11:07:48 miranda login(pam_unix)[23221]: could not identify user (from
getpwnam(chills))
Jan 19 11:07:48 miranda login[23221]: User not known to the underlying
authentication module

nss_ldap.i386 0:232-1 still broken

I can confirm this bug (FC3, with openldap 2.2.23; nss_ldap > 226 does
not work).
It is also reported on the PADL-site, but I have not seen any reaction
from them.
I think it has something to do with trying to make a permanent
connection with the directory server.

With nss_ldap-234-1 all problems are gone !! Thanks ..

Alfred, I can't find that version on Rawhide. Where did you obtain it
from?

BTW I no longer have access to the systems where this bug manifested,
so I'm not the one to close this

The Fedora download server has the new version (nss_ldap-234-1)
available under the development directory !! Good luck.

It has also the new version of OpenLDAP (2.2.23) available. But be
carefull with it: it is compiled against its own version of db4
(version 4.3.27). This means that you have to upgrade your own FC3 to
db4-4.3.27, otherwise your database utilities will not work (e.g.
db_recover). If you do, please do not forget to install compat-db, for
your non-upgraded FC3 programs !!!!!

Additional remark on OpenLDAP version 2.2.23.

I found it necessary to change the init-script of OpenLDAP to remove
the __db.00? files from /var/lib/ldap/directory on every startup. This
was the only way to assure correct startup of OpenLDAP in case of a
system crash (which happens to often to me). Also add the -u option to
slaptest in the init-script to assure a proper test of the
config-files !!!! Have fun with testing ... !

I'm closing this one as it's not seing any activity and I can't test it anymore