LDAP Strikes again

17 03 2007

Last night around 1Am i was called in @ work due to ‘ a few strange techie things happening here, Sid ‘.
Once got there figured out it was a lack of internal networking due.
For this to be thanked was our Microdowell UPS System holding the web/auth/smb machine.

This last pc is a Fedora 6 machine, which amongst many services runs also Ldap, for smb and mail authentication.

Trying to restart the machine, i was stuck forever on:

Starting System Message Bus ....

As i had the chance to figure out from the booting info, there was a previous failure to startup ldap.
At least to start the machine, the solution seemed to be getting in Runlevel 1 ( which i basically the only mode that will be able to go through ) and edit /etc/nssswitch.conf.
In this file commented all the lines that take info from Ldap.

#protocols: files ldap

This will allow the system to start the services without the slapd support-

Now, i have heards a lot of folks around blaming Samba for the same problem.

I suggest them to look in the same file and they will probably notice that Ldap is set to give samba auth too.

So that started the server which after i edited the nsswitch again and tried to restart ldap, responded with the following:

[root@tserver]# /etc/rc.d/init.d/ldap start
Checking configuration files for slapd: bdb_db_open: unclean shutdown detected; attempting recovery.
bdb_db_open: Recovery skipped in read-only mode. Run manual recovery if errors are encountered.
bdb_db_open: Database cannot be opened, err 13. Restore from backup!
bdb(dc=domain,dc=com): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem
backend_startup_one: bi_db_open failed! (13)
slap_startup failed (test would succeed using the -u switch)
stale lock files may be present in /var/lib/ldap

so the server won’t start at all.

Now, Ldap is a wonderful piece of software but this is a very very annoying problem to have.

This is what will help you:

[root@theserver]# /usr/sbin/slapd_db_recover -v -h /var/lib/ldap
Finding last valid log LSN: file: 1 offset 5324863
Recovery starting from [1][5213551]
Recovery complete at Sat Mar 17 09:13:51 2007
Maximum transaction ID 8000040d Recovery checkpoint [1][5324863]

And at the end of this process you have to chown the files in /var/lib/ldap to

Conclusively, if this happens (and knowing Ldap, it will) this is what’s to be done:

  • Enter in runlevel 1, edit /etc/nsswitch.conf and comment out the lines that have ldap and reboot.
    Edit the file again.
    try service ldap start ( to make sure this is your case)
    If the result is similar to mine above do:

    /usr/sbin/slapd_db_recover -v -h /var/lib/ldap
    chown -R ldap.ldap /var/lib/ldap

  • Advertisements



    3 responses

    11 08 2009

    Thank you…… works perfect to me!!!

    29 08 2009
    Sidrit Trandafili

    glad i could help 🙂

    13 12 2011

    thanks for you help. that worked me. really appreciate it.

    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s

    %d bloggers like this: