1

Similar to slapd daemon can't start but despite being accepted, the answer didn't really work for the asker.

Shut down Lion Server 10.7.5 (on a 2011 Mini Server) today after Time Machine got itself in a tizzy and failed to backup for several hours while claiming it was "stopping" (presumably unrelated to problem, just the why of restarting it.)

Shut down hung - after 15 minutes or so I powered it off.

When it came back up, there was a red ball at the right of the username box with a nastygram indicating that network accounts were not available. Logged in the local administrative user - when trying to get to LDAP from workgroup manager "The node .LDAPv3/127.0.0.1 couldn't be opened because an unexpected error of type -14006 occurred" is the helpful, friendly response.

Server Alerts indicates self-signed certificates expired. Offers to repair/recreate. Doesn't seem to help. Reboot after that - still doesn't seem to help. Presumably the problem occurred at first reboot after they expired; That does not actually seem to be true however, looking at the expiry dates. Server has rebooted many times and LDAPv3 has been happy up until today.

This topic at AFP548 (first I've heard of that forum) seems related, but applying it may be difficult given that my self-signed certs are expired rather than removed.

It's going to be a late night trying to get my fileserver back in shape before other people arrive and want to use it. At least I have the files, but any better insight than that provided by the linked topics would be appreciated.

1

The moment LDAP and Open Directory get themselves into a tizzy I always look towards Kerberos.

Have a prowl with kadmin and ktutil and see if Kerberos is working nicely. Have a good look at getting your certificates A-OK. Check that DNS and reverse DNS are giving valid responses.

Copy the LDAP database then blow it away and start again to see if it's a problem with that. If slapd is up then try doing some searches with ldapsearch.

0

I find that I don't recall exactly what I did when I originally asked this question - I think I may have ended up recreating the database (as in painfully by hand.) Anyway, two years on it happened again (and exactly the same start condition - shutdown did not shutdown when time machine had been "stopping" for days without stopping, or backing up, so the machine had to be powered off.)

Suggestions in the wild seem to be split between 10.6 and 10.7 commands even when they say lion server, or perhaps there are early and late 10.7 command changes; I certainly don't recall precisely. The answer I linked to in a comment above (How to fix failing Open Directory (database "cn=authdata" cannot be opened, err 12) after hang) seemed helpful, but the problem recurred within a few hours at most - and I actually had to run what by the answer's lights would be both 10.6 and 10.7 commands for even that to work.

So, on my Lion system (10.7.5) running Server.app 10.7.5(1.5.0), I'd have to do:

$ sudo launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist
$ sudo db_recover -h /var/db/openldap/authdata/ # Mac OS X 10.7
$ sudo db_recover -h /var/db/openldap/openldap-data/ # Mac OS X 10.6 (this one too, even on 10.7)
$ sudo launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist

Rebooting or not seemed to make little difference. It would work for a relatively short time, then crap out again. The users were restive, the sysadmin was sleep-deprived and grumpy.

Eventually I found a procedure that once again had to be somewhat modified on a site I'll try to link to again, as a comment on an answer similar to the above process. As modified for my system...After doing the above repairs (you can skip the load step above)

1) sudo to root

sudo -i

2) shutdown LDAP (if you started it again)

launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist

3) dump a copy of the Open Directory database to an LDIF format text file

mkdir /var/root/opendirectory
cd /var/root/opendirectory
slapcat -l dir.ldif

If you don't do the repairs (or I suppose, if they don't work) the .ldif file will be empty - so check that it seems reasonable, and if not, start digging into backups.

4) move the old (corrupt) database files out of the way (or remove them).

cd /var/db/openldap/openldap-data
mkdir SAVE
mv *.bdb SAVE/

be sure you don’t move, rename or delete the file named DB_CONFIG. It’s needed.

5) recreate the database from the LDIF format file

cd /var/root/opendirectory
slapadd -l dir.ldif
slapindex

You will see some harmless warnings during slapadd. Ignore them.

Restart LDAP

launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist

And at this point you might just as well reboot, too. Comment by "Ranj" on this page (with "service" commands that don't work for me) http://www.prestonlee.com/2009/07/08/recovering-a-corrupt-openldap-database-on-osx-server/

I won't swear that it's cured, because I thought that I had it cured two days ago and I was wrong, but it's run for 12 hours without screwing up totally, which is an improvement on where it's been since 2-1/2 days ago.

I also twigged upon an annoying (possibly related, who knows exactly what upsets the thing) issue relating to accounts created with workgroup manager rather than with server.app - they have an incorrect entry (untitled_1 rather than the user's shortname) in AltSecurityIdentities. I tried the fix as automated by this script https://github.com/arekdreyer/Lion-Server/blob/master/FixAltSecurityIdentities.sh and also by hand as described in several sites (either via GUI or by deconstructing the command line from the linked script) and it would fail every time I went to write. Once I had done the above fix to rebuild the databases I could actually re-write the incorrect data. Evidently the "cure" is to create accounts only with Server.app (but if you have this problem, you can't, until after you fix them...)

Finally, I am reminded by this joyful experience to spit out a

slapcat -l LDAPBackup<date>.ldif

on a more regular basis to make the recovery process less agonizing (as well as actually putting "what I did when this thing happened" in here as an aswer in case it happens again - or to someone else.)

Meanwhile, this whole business has also helped to crystallize the feeling that MacOS Server went to heck in a handbasket after 10.6, so given that the only thing this machine really does is file service, I'm probably going to replace it with a Nas4Free box, or perhaps two boxes in HAST configuration. I'm somehow less than interested in what delights 10.11 brings to the utter mess that is Server.app (IMHO at this point in this week) and I cannot begin to say how thrilled I'm not that upgrading to anything but 10.11 is a non-option in the days of "all software comes only from the app store, and you can't get any version you like, only the bleeding edge ones."

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .