I was having many problems with LDAP after my server lost power. See below for the various issues I was having and bellow that the solution, which was basically dumping the contents of ldap, blowing away the database and adding them back in. It was actually quite simple.
I was finding that some machines, which I have adding themselves to ldap via a script, are not showing up in LDAP. Some though are showing up in dscl.
For example the machine hse118-20 does not show up in workgroup manager.
in dscl when I cd to the Computers container and do “read hse118-20″ I get what looks like the appropriate data back.
in dscl when I cd to the Computers container and do an “ls” hse118-20 does not appear in the listing.
****
slapd in debug mode and saw these errors in the slapd.log when I go to create the mslib group:
May 18 11:12:05 chetwood slapd[14034]: => bdb_dn2id_add: subtree (cn=mslib,cn=computer_groups,dc=chetwood,dc=local) put failed: -30996
May 18 11:12:05 chetwood slapd[14034]: entry failed schema check: value of naming attribute ‘cn’ is not present in entry
May 18 11:12:05 chetwood slapd[14034]: => bdb_dn2id_add: subtree (cn=mslib,cn=computer_lists,dc=chetwood,dc=local) put failed: -30996
May 18 11:12:05 chetwood slapd[14034]: entry failed schema check: value of naming attribute ‘cn’ is not present in entry
I can add a group called “test.” I get something similar when I try to add a group (which I think I’ve added before) called hse118, but without the “put failed” line:
May 18 11:19:43 chetwood slapd[14034]: entry failed schema check: value of naming attribute ‘cn’ is not present in entry
May 18 11:20:13: — last message repeated 1 time —
****
Here’s what I get using slapadd (with slapd halted), this does work for other group names (just changing mslib to test for example):
chetwood:~ root# slapadd -v << EOF
> dn: cn=mslib,cn=computer_lists,dc=chetwood,dc=local
> objectClass: apple-computer-list
> objectClass: top
> structuralObjectClass: apple-computer-list
> cn: mslib
> EOF
overlay_config(): warning, overlay “dynid” already in list
overlay_config(): warning, overlay “dynid” already in list
overlay_config(): warning, overlay “dynid” already in list
overlay_config(): warning, overlay “dynid” already in list
overlay_config(): warning, overlay “dynid” already in list
=> bdb_dn2id_add: subtree (cn=mslib,cn=computer_lists,dc=chetwood,dc=local) put failed: -30996
=> bdb_tool_next_id: dn2id_add failed: DB_KEYEXIST: Key/data pair already exists (-30996)
=> bdb_tool_entry_put: txn_aborted! DB_KEYEXIST: Key/data pair already exists (-30996)
slapadd: could not add entry dn=”cn=mslib,cn=computer_lists,dc=chetwood,dc=local” (line=6): txn_aborted! DB_KEYEXIST: Key/data pair already exists (-30996)
****
And lastly — I did a db_verify on the cn.bdb with slapd stopped and it came up with some errors. I ran db_recover on the database and it hung on a log file (there were 3), which was dated early march. I didn’t know what else to do so I removed that file (this was all last night) and the recover completed without error. The db_verify still errors on cn.bdb
****
And here is the solution:
- Login as root and Stop Ldap:
launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist
- create a directory to hold a backup, in root’s home is fine:
mkdir opendirectory
- enter the directory and dump the LDAP database
cd opendirectory/
slapcat -l ldap.ldif
Use a text editor to look at the file and make sure it looks like the data in ldap
- Move all files except the config file from the OpenLDAP db location:
find /var/db/openldap/openldap-data -type f | grep -v DB_CONFIG | xargs -I arg mv arg openldap-data/
- create a new database from the dump file created above:
slapadd -l ldap.ldif
slapindex
- start ldap
launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist
Now test ldap with workgroup manager or dscl and make sure your entries are there. If anything goes wrong then the original database can be copied back.
Tags: Apple, Technical // Add Comment »