Recovering from a -14002

[Anonymous]

Around 8 days ago our master server started to show signs of corruption, and, sure enough, I had lost the ability to authenticate and make changes to the database. Luckily, at this point, the database was still functioning. So I handed off the the replica, and took the master offline to sort things out.

My normal routine when this happens(and it seems to, at least once a year) is to simply replace the /var/db folder with the backup — while I admit this is a rather ugly method, it normally works. This time, it didn’t. I presume the backup was already poisoned. Many days of hair pulling, googling, and poking around left me no better off — i’d really like to avoid a fresh install.

As a last resort, I nuked(read:renamed/moved) the /var/db folder, inhope of invoking some kind of rebuild mechanism. This has worked to the extent that i was able to re-enter all the configuration data, however the ldap now displays a -14002.

A terrible hackjob, I know — but i ran into tremendous frustration tracking down troubleshooting information for ldap(the Apple Mac OSX Server discussion fora seem to have a poor signal:noise ratio).

And so, dear readers, my question is — how does one force a complete rebuild of the LDAP database under Mac OSX Server 10.3.5? Is a clean install now my only option?

Many thanks for your time,
Mikir.

[mike]

Just wanted to bump up this post and see if anyone had the answer how to force a OS 10.3.5 server to rebuild or verify the contents of the LDAP directory.

Thanks!

[econz]

What if you don’t have a replica or a backup of the database? Is there a way to create a clean LDAP database?

[jkp]

[QUOTE BY= Dave] What if you don’t have a replica or a backup of the database? Is there a way to create a clean LDAP database?[/QUOTE]

Everytime I want to do that I have just erased (moved) /var/db/openldap/openldap-data. This is where all the important data resides AFAIKT. Any imports and changes to the DB rely on that folder being present and they will not work without it so I think this is the way to go.

[Anonymous]

I had the same type issue this past week. I finally got a clean LDAP database (actually my goal—not real experienced with LDAP) and was going to restore from my backup and be in great shape. Unfortantly, when I got ready to restore I discovered that the way I had backed up was not appropriate (exporting from WGM). It wouldn’t give me anything back. So—I have NO LDAP. I’m going to have to re-import my accouts.

I need to know—how can I get a good, solid, backup of that LDAP database so that, should this ever happen in the future, I have something I can restore from and how would I go about that restore??

Perhaps a replica is the answer—I’m just not familiar with how to set that up etc. I have a knowledge of NDS and those replicas—but WGM sure ain’t no ConsoleOne!

Maybe someone can point me in the direction of a good TID for LDAP on OS X Server??

Thanks for any and all help!

[Anonymous]

Another note—is their anything else critical system wise that I should backup. We store no files on this server…just have accounts and authenticate the users through Macintosh Manager.

Thanks!

[mkalien]

I have yet to recover from a -14002 error. I ended up in this state from testing an import user script. Everytim the server crashed while dsimportexport was running the ldap database or something got messed up.

I have tried deleting /var/db/openldap/, /var/db/openldap/openldap-data, and even deleted /var/db/.AppleSetupDone. None of these were successful, but perhaps that’s because I had was hacking around a bit already.

I guess it’s another clean install for me. I’m getting good at headless server installs.

[AMSR]

There is a complete description of what to back up in OD in the OSX Server manual that deals with OD.

[Anonymous]

I am getting this error after trying to change IP addresses with the changeip command. Now none of the servers can authenticate to the directory server. I know they are connecting to each other because I can get Remote Desktop to work. They just won’t authenticate in ldap.

[Anonymous]

Finally, some people with similar problems!! Thanks for your postings. I am in my third day at a new job – switching from primarily a Windows network to a Mac network. Yesterday, we had a power outage/surge, the battery backup failed on our OS X server, and upon restart the LDAP directory is gone/corrupted. We had no secondary (backup) or replica server running (though this had happened twice I guess in the last year or so). I have these questions from your above postings:

1. How do I create a clean, new network database? I am always getting a message that my current directory is local only, not network.
2. How can I re-import my accounts as the posting on Oct. 16 discusses?

Thanks so much!

dwb

[Sean Howard]

Okay. I’m still a bit of a newbie on LDAP. I’ve been reading a lot but this is our first Mac Server. We’ve been hacking at it for some time now as we’re looking to host multiple domains (something Apple did not foresee it appears *grin*).

But there is some of what I know.

Just deleting the /var/openldap/openldap-data will not work in itself as someone earlier posted a problem with. One must recreate this directory for the dbd files to rebuild. It will not create the directory. So one can MV the current one to a new name and then recreate openldap-data. CHMOD it 700.

There is a way to backup the database (I believe), based on another persons question. This is how I have been doing it anyway.

slapcat -l ldif

will give you a text version of the current dbd file in the file “ldif” or whatever you specifiy after the -l. One can then use the following steps to recreate the database from a backup (I believe, jump in Troll or Admins if I’m wrong *smile*)

Kill slapd
kill -INT `cat /var/run/slapd.pid`

Create an empty /var/db/openldap/openldap-data
(I MV the current one then recreate the folder and CHMOD it 700)

Restart slapd
sudo /usr/libexec/slapd

Ensure it has started. I check to make sure the pid file is there.
cat /var/run/slapd.pid

Load the backed up LDIF made with the slapcat command (WHEN SLAPD WAS RUNNING into the empty database
slapadd -l e.g. slapadd -l backup.ldif

I then run a slapcat -l ldif_postmigration

and then I check the file to ensure everything loaded in correctly.

[Author]

Posts