SHARE

LDAP Master Server Problems

LDAP allows you to have a master+slave server setup, with automatic failover in case of problems or just to spread the load. This has obvious advantages, but it can hide problems with the master server. If your master server is down but the slaves are OK, ldapsearch and other lookups will work fine. But if […]

Written By

Juliet Kemp

Oct 8, 2008

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More

LDAP allows you to have a master+slave server setup, with automatic failover in case of problems or just to spread
the load. This has obvious advantages, but it can hide problems with the
master server.

If your master server is down but the slaves are OK, ldapsearch
and other lookups will work fine. But if you try to modify the database (e.g.,
with ldapadd), you’ll get this kind of error message:

ldap_add: Referral (10)
	referrals:
		ldaps://masterldap.example.com/uid=test,ou=People,
dc=example,dc=com

Slave servers can’t modify the database, so it tries to redirect to the
master, and fails. If you now use ldapsearch to look for your new
entry, you will not find it.

You can confirm the diagnosis by trying:
ldapsearch -H ldaps://masterldap.example.com to force a bind to
the master server.

The next stage is to find out what’s causing the problem. Set the loglevel
in /etc/ldap/slapd.conf to 1, then restart slapd and check
the logs.

Two common problems:

An old slapd process that hasn’t been killed off
properly. Check with ps and kill it if
necessary.
An alock problem, which looks like this in the log:
slapd[27069]: bdb_db_open: alock package is unstable slapd[27069]: backend_startup_one: bi_db_open failed! (-1)
To resolve, remove the /var/lib/ldap/alock file (or check your

slapd.conf for your local data directory). Run
db_recover to fix the database, or just restart
slapd and it should recover itself. You
may need to give it a little time or restart it again.

Remember to return the loglevel to normal afterward, or the server will be
very slow. Also, consider using monitoring software to catch these silent
problems!

This article was first published on ServerWatch.com.