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