 | | | nss-ldap/nscd problems | nss-ldap/nscd problems 2005-08-11 - By Matthew B. Brookover
Back
I tend to agree, nscd is a huge pain. Unfortunately, nscd does speed
things up when it works.
I think we found the problem, the ldap servers were moved behind a
firewall that times out connections after one hour. We reset the timout
for ldap to 10 hours. So far, the server has let me log in after 6
hours. The network people assure me that as long as there is traffic,
the connection will stay open. I think I would like to dump the fire
wall along with nscd.
I have not looked at the source code for nss_ldap, but I would guess
that keepalive is not set on the socket. Nscd and/or nss_ldap also have
problems reconnecting after a network failure. Fedora core 3 did not
have any trouble, suggesting that these problems were fixed in later
versions of nss_ldap and glibc.
The server is on its way to processing several thousand email messages a
day for quite a few users. I doubt it will be possible without nscd.
I would prefer to upgrade to Enterprise 4, but we have an ISCSI based
san from Left Hand Networks. Last work was iscsi is not supported in
Enterprise 4. I hope they will get that fixed soon.
Matt
On Thu, 2005-08-11 at 16:26 -0500, Chris St. Pierre wrote:
> This may be off-base, but is there any reason you can't just kill
> nscd, remove it from your init scripts, and never speak the name of
> the grotesque beast again? That's probably one of my least favorite
> programs *ever* (right up there with Microsoft Bob and netinfo) and is
> one of the first things I get rid of. Do you need it?
>
> Chris St. Pierre
> Unix Systems Administrator
> Nebraska Wesleyan University
>
> On Wed, 10 Aug 2005, Matthew B. Brookover wrote:
>
> >I have a host running RedHat Enterprise 3 AS Release 5 academic version.
> >
> >NSCD seems to hang after a cache entry has timed out. If you bounce
> >ncsd, all of the hung processes will continue like there was no problem.
> >
> >Nscd is configured to time out entries after 1 hour. To recreate the
> >hang, bounce nscd to get it working, log in to the host, wait for 1
> >hour, then try an ls -l or any other command that will call getpw*.
> >There are times when it does not hang, but most of the time nscd is
> >hung.
> >
> >We are using openldap 2.2.26, Kerberos 1.4.1, and sasl 2.1.21 on
> >dedicated ldap and kerberos servers.
> >
> >Other clients running Fedora Core 3 work fine.
> >
> >The client running redhat enterprise 3 AS release 5 is using the
> >versions of sasl, nss-ldap, nscd, etc that came with the release:
> >cyrus-sasl-2.1.15-10
> >pam_krb5-1.75-1
> >krb5-devel-1.2.7-47
> >cyrus-sasl-gssapi-2.1.15-10
> >openldap-clients-2.0.27-17
> >openldap-devel-2.0.27-17
> >nss_ldap-207-15
> >krb5-workstation-1.2.7-47
> >krb5-libs-1.2.7-47
> >nscd-2.3.2-95.33
> >
> >nss-ldap and nscd log these errors in /var/log/messages:
> >Aug 8 10:36:04 imagine nscd: nss_ldap: reconnecting to LDAP server...
> >Aug 8 10:36:04 imagine nscd: nss_ldap: reconnected to LDAP server after
> >1 attempt(s)
> >
> >Kerberos, GSSAPI, SASL, etc all work correctly.
> >
> >When nscd is hung, any program that calls getpwuid, getpwnam or getpwent
> >will hang. I presume other functions that would cause a lookup through
> >nscd and nss_ldap will also hang.
> >
> >The server running RHEL 3.5 was originally installed with 3.4 and then
> >upgraded to 3.5. After the upgrade, Kerberos, ldap, etc were
> >configured. This may be a problem that is new to 3.5. I did not test
> >ldap, kerberos, sasl, etc under 3.4.
> >
> >When nscd is hung, you can log in as root and run an ldapsearch. The
> >results are returned correctly. I followed these steps to test the ldap
> >and kerberos servers:
> >1) rebooted the RHEL 3 release 5 ldap/kerberos client
> >2) logged in as my self
> >3) logged off
> >4) waited an hour for nscd's cache to time out
> >5) logged in as my self (the login hung before printing the password
> >prompt) I waited several minutes to make sure that it was not going to
> >continue
> >6) logged in as root on another terminal.
> >7) ran an ldap search for my user and ran kinit (both worked)
> >8) ran 'service nscd restart'
> >9) went back to the first termianl, entered my password and was able to
> >log in.
> >10) waited 1 hour
> >11) ran an ls -l, ls -l then hung. CTRL-c will unhang ls or other
> >process that does not catch the signal.
> >
> >There are times when nscd or nss-ldap will unhang on their own. Any
> >process calling getpw* will continue.
> >
> >/etc/nsswitch.conf is set with:
> >passwd: files ldap
> >shadow: files ldap
> >group: files ldap
> >
> >#hosts: db files nisplus nis dns
> >hosts: files dns
> >
> ># Example - obey only what nisplus tells us...
> >#services: nisplus [NOTFOUND=return] files
> >#networks: nisplus [NOTFOUND=return] files
> >#protocols: nisplus [NOTFOUND=return] files
> >#rpc: nisplus [NOTFOUND=return] files
> >#ethers: nisplus [NOTFOUND=return] files
> >#netmasks: nisplus [NOTFOUND=return] files
> >
> >bootparams: nisplus [NOTFOUND=return] files
> >
> >ethers: files
> >netmasks: files
> >networks: files
> >protocols: files
> >rpc: files
> >services: files
> >
> >netgroup: files
> >
> >publickey: nisplus
> >
> >automount: files
> >aliases: files nisplus
> >
> >-- ---- ---- ---- ---- ---- ---- ---- ---- --
> >
> >The server is a Gateway 9515 with 2 3GHZ Xeon processors and 4GB RAM.
> >It will be serving email and other services very soon. Fortunately, it
> >is not in production yet.
> >
> >Any ideas?
> >
> >thank you.
> >
> >Matt Brookover
> >mbrookov@(protected)
> >303-273-3436
> >
> >
> >--
> >redhat-list mailing list
> >unsubscribe mailto:redhat-list-request@(protected)?subject=unsubscribe
> >https://www.redhat.com/mailman/listinfo/redhat-list
> >
>
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@(protected)?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
Earn $52 per hosting referral at Lunarpages.
|
|
|