Jeffrey D Anderson wrote:
On Thursday 22 May 2008 11:47:28 am Jeffrey D Anderson wrote:
On Thursday 22 May 2008 8:20:22 am you wrote:
On Thu, May 22, 2008 at 03:28:11PM +0100, Faye Gibbins wrote:
Hi,
Has anything relating to how ldap uses ssl changed in the last couple
of days?
In the last day or so our ldap servers (that are queried though SSL
and the nss_ldap libs) have stopped working properly.
They do part of the job then die with broken pipe signals (as seen by
running strace on for example "su").
This has shown up on both 32 and 64 bit SL5.0 boxes.
We're getting this as well since the update this mornig to
nss_ldap-253-12.el5.x86_64.
It looks like libnss_ldap.so.2 is now linked again SElinux. Is that part
of the problem?
-jkl
I am getting this on SL5.0 and SL5.1.
We use LDAP with TLS for authentication for dozens of workstations, and it
is totally broken at the moment.
I've done a 'yum clean && yum update' to see if Troy's fixed packages from
this morning rectify the situation, but still nothing.
The symptoms are that users cannot login. They type their password at KDM
or at a text VT, the password apparently is authenticated, but the screen
flashes and they are returned to the login screen.
Also, I cannot 'su' to any users. If I try, as root for example,
'su SOMEUSER' I am just brought back to the root bash prompt. 'whoami'
verifies that I am still root, not su'd to SOMEUSER.
finger and id both successfully lookup the user information, but for some
reason su, login, KDM, do not successfully log people in. I've verified
this on a number of different boxes. I've also rebooted the LDAP server
without solving the problem.
Bad for to reply to myself, but I wanted to add that reverting to
nss_ldap-253-5.el5.i386.rpm cleared up the problem for me, so there is
definitely some kind of critical bug in the updated nss_ldap.
Hi Jeff,
I have been reading all of this with interest because I hate it when things
break.
Can you try updating nss_ldap using CentOS's rpm, and see if it still breaks.
I want to see if it is us or RedHat who has the problem.
Troy
--
__________________________________________________
Troy Dawson [EMAIL PROTECTED] (630)840-6468
Fermilab ComputingDivision/LCSI/CSI DSS Group
__________________________________________________
