OpenLDAP on Fedora

Bevan C. Bennett bevan at fulcrummicro.com
Tue Feb 3 21:59:20 UTC 2004


I'm trying to use an FC1 system as a departmental LDAP server.
I previously had an ageing RH7.1 box happily performing this task.

The first  hurdle was that approximately once per week slapd would start 
to syslog messages about how it couldn't open /etc/hosts.deny because 
there were too many open files.

I tried to address this with the following:
# /etc/security/limits.conf
ldap             hard    nofile          65535

#!/bin/sh
#/usr/sbin/slapd-wrapper
ulimit -n 65535
exec /usr/sbin/slapd $@

And changing /etc/init.d/ldap from:
daemon ${slapd} -u ldap -h "ldap:///" -l daemon $OPTIONS $SLAPD_OPTIONS
to:
daemon ${slapd}-wrapper -u ldap -h "ldap:///" -l daemon $OPTIONS 
$SLAPD_OPTIONS

This seems to have settled that issue, as the number of open files 
appears to happily edge over the 1024 former line of death.
[root at urd sbin]# cat /proc/sys/fs/file-nr
1508    890     209708

However, something is still wrong. Still approximately once per week 
(possibly corresponding with open files exceeding 1024), my slapd now 
appears to be failing in the same manner, only silently (no syslog 
messages).

Clients (even the ldap server itself) start reporting:
nss_ldap: could not get LDAP result - Can't contact LDAP server
and applications that try to do authentication start failing fatally.

Could there be other per-user limits that are preventing openldap from 
servicing new requests?
Does anyone have any ideas of how to avoid this behavior?
Why do Redhat7.x (and presumably RHEL) not suffer from similar problems?
Has anyone actually gotten LDAP clients to successfully fail over to an 
alternate server? (I have it configured, but it never seems to work...)





More information about the fedora-list mailing list