[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LDAP hangs requiring slapd stop and deleting __db.00* files
Hello and thanks for the quick response.
I am posting some more relevant information in case that will help
diagnose the situation better.
Hardware information & Versions used.
a) openldap-2.1.30
b) Berkeley DB 4.2.52
c) Hardware: CPU - Intel p4 1.4 GHz, 1 GB RAM, 250 GB IDE Hard Drive
We have around 5000 registered users of which 350 check email daily. However being popular domains, we get a lot of spam as well as bounced invalid mail (where someone is using our domain as return mail). So after putting some filters/firewall in place we can determine that we get around 3/4 requests a second.
You have suggested using db_recover which we have tried.
As per what we understood, db_recover can be used when our database is corrupt and we need to recover
data but in our case ldap goes off not the data. In log file it shows
authdaemon.ldap TEMP fail. I am pasting below the contents of our slapd.conf file if that will further assist in debugging the issue we are facing.
If you could tell me what other information is required, I'll be glad to fish it out for you.
===============================================================================================================
# $OpenLDAP: pkg/ldap/servers/slapd/slapd.conf,v 1.23.2.8 2003/05/24 23:19:14 kurt Exp $
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/nis.schema
include /usr/local/etc/openldap/schema/jamm.schema
# Define global ACLs to disable default read access.
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/slapd.pid
argsfile /var/run/slapd.args
loglevel 1
# Load dynamic backend modules:
# modulepath /usr/local/libexec/openldap
# moduleload back_bdb.la
# moduleload back_ldap.la
# moduleload back_ldbm.la
# moduleload back_passwd.la
# moduleload back_shell.la
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
#Allow bind_v2
allow bind_v2
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy is:
# Allow read by all
#
# rootdn can always write!
#######################################################################
# ldbm database definitions
#######################################################################
database bdb
suffix "dc=myhosting,dc=example"
rootdn "cn=Manager,dc=myhosting,dc=example"
rootpw xxxxxxxxxxxx
directory /usr/local/var/openldap-data
index objectClass pres,eq
index mail,cn eq,sub
#Access Control
access to dn=".*,jvd=([^,]+),o=hosting,dc=myhosting,dc=example"
attr=userPassword
by self write
by group/jammPostmaster/roleOccupant="cn=postmaster,jvd=$1,o=hosting,dc=myhosting,dc=example" write
by anonymous auth
by * none
access to dn=".*jvd=([^,]+),o=hosting,dc=myhosting,dc=example"
by self write
by group/jammPostmaster/roleOccupant="cn=postmaster,jvd=$1,o=hosting,dc=myhosting,dc=example" write
by * read
access to *
by * read
=================================================
Quanah Gibson-Mount wrote:
Facing the following issues with openLDAP from time to time.
a) OpenLdap seems to get locked up every once in a while. i.e. While the
process is running, it fails to authenticate.
Because process is still running, our monitoring system, Monit, does not
recognize that as a failure.
Then we need to stop slapd. delete the /usr/var/openldap-data/__db.00*
files, restart ldap for it to start working again.
You should use db_recover, not delete the files.
I would guess that your system is either
a) Poorly configured (DB_CONFIG, slapd.conf)
or
b) You are using a rather old version of OpenLDAP
or
c) a & b