[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
OpenLDAP keeps on dying sporadically
Hi fellows
my OpenLDAP keeps on dying sporadically. Unfortunately it doesn't leave
ANY trace of why it crashes. It stays alive for a while .... takes a
couple of queries as expected ... and then suddenly it dies after
another request. This could mean working perfectly for a day or working
only for a couple of minutes before it crashes. The requests are all
known to work (Dovecot auth and system PAM auth). At first I thought it
could be related to newsyslog(8) ... I did some testing - unfortunately
this doesn't change anything at all. It keeps on dying sporadically even
if newsyslog is completely deactivated for the slapd(8) log file.
I experenced this behauviour since I first used OpenLDAP approximately 5
years ago. My OpenLDAP configurations have been changed many times and
quite a lot over those 5 years. Unfortunately I was never able to figure
out what the sudden crashes caused - so I wrote a supervisor script ,
which periodically checks if the slapd(8) is still running. If slapd(8)
is not running, then my supervisor script starts it automatically again.
Of course with every major change in the configuration of OpenLDAP, I
also tried to debug this problem of the sudden crashes - but as I said:
even with all debug levels activated - slapd(8) didn't want to share its
root of the pain. This workaround was the only way I could use OpenLDAP
at all over the past five years.
Two days ago I got to the point where my workaround came to its capacity
boundary. The time between the slapd(8) crashes has become so little, so
my script can't handle them anylonger. I would have two options now:
a) Fix my supervisor script, so it detects and starts slapd(8) even if
the time between crashes is less than 3 sec.
b) I ask for help in order to discover this mysterious cause of the
crashes and FINALLY fix it FOREVER.
So this time I set my foot down and go for b). This is why I decided to
contact you. The following link containes a more detailed debugging of
the problem:
https://forums.freebsd.org/threads/openldap-slapd-dies-sporadically.47634/
And this is the current / latest configuration I deploy on my servers.
Also, it doesn't make a difference whether I have monitoring activated
or not. It keeps on dieing the same as before. The very same ocours to
the "ldapab.schema" - it doesn't make a difference for the crashes to
happen whether it is commented out or activated. Logging hapens through
syslogd(8).
# ============================================================ #
#======================================#
# slapd.conf #
#======================================#
# LDAP Attribut Schema Definitions:
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/nis.schema
include /usr/local/etc/openldap/schema/ldapab.schema
include /usr/local/etc/openldap/schema/mail.schema
#include /usr/local/etc/openldap/schema/qouta.schema
# Logging
loglevel 256
# If "logfile" is activated, then newsyslog must restart slapd after
rotation
#logfile /var/log/slapd.log
# Important Files
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Allow LDAPv2 client connections. This is required for iOS suppoprt via
SSL.
#allow bind_v2
# Time limits
#idletimeout 0
#writetimeout 0
#timelimit 3600
# Dynamic Modules:
modulepath /usr/local/libexec/openldap
moduleload back_mdb
moduleload back_monitor
# Access from 127.0.0.1 without encryption
access to dn.subtree="dc=MyDomain,dc=local"
by peername.ip=127.0.0.1 write
by * none break
# Access from other than 127.0.0.1 requires TLS
# encryption with min. 128 bit encryption
access to dn.subtree="dc=MyDomain,dc=local"
by ssf=128 write
by * none
# TLS-Certificate
TLSCertificateFile /etc/ssl/PKI/CA/Signing-CA/Certs/WM-01.MyDomain.Local.crt
TLSCertificateKeyFile
/etc/ssl/PKI/CA/Signing-CA/Private/WM-01.MyDomain.Local.key
TLSVerifyClient allow
# Restrict write access for password attributes to root user only
by dn="uid=dovecot,ou=systemuser,ou=mail,dc=MyDomain,dc=Local"
access to attrs=userPassword
by self write
by anonymous auth
by * none
# All the other atributes can be read by everyone else
access to *
by * read
# ================================== #
# Internal Monitoring #
# ================================== #
# DB type
database monitor
# Name of Administrator
rootdn "cn=monitoring,cn=Monitor"
# Password of Administrators
rootpw {SSHA}SomeHash
# ACL for moitoring
access to dn.subtree="cn=Monitor"
by dn.exact="cn=admin,dc=MyDomain,dc=local" write
by peername.ip=127.0.0.1 read
by users read
by * none
# ================================== #
# Lightning Memory-Mapped Database #
# ================================== #
# Datenbanktyp
database mdb
# DB location on FS
directory /var/db/openldap-data
# Datenbank-Pfad
suffix "dc=MyDomain,dc=local"
# Name of Administrator
rootdn "cn=admin,dc=MyDomain,dc=local"
# Password of Administrators
rootpw {SSHA}SomeHash
# Max size of DB in Byte [ 5368709120 Byte => 5 GB ]
maxsize 5368709120
# Index search related attributes
index objectClass eq
index uid eq
index uidNumber eq
index uniqueMember eq
index gidNumber eq
index cn eq
index memberUid eq
index mailAccountStatus eq
index mailAddress eq
index associatedDomain eq
# ============================================================= #
I compiled OpenLDAP from FreeBSD ports with following options:
- DYNAMIC_BACKENDS
- MDB
- PPOLICY
- SYNCPROV
- TCP_WRAPPERS
Please let me know what kind of further information I could deliver to
you in order to detect the root of the problem.
Thank you
Best regards
Leander