Error creating Open Directory Replica in Mountain Lion

Then make a new replica.

Ack. That didn't work for me.

Me nither

i ran sudo /usr/sbin/slapconfig -ver on my OD master

2013-05-14 20:51:39 +0000 command: /usr/libexec/slapd -T cat -c -f /etc/openldap/slapd.conf -s ou=macosxodconfig,cn=config,dc=test249,dc=home

2013-05-14 20:51:39 +0000 Error execing slapcat: slapcat: slap_init no backend for "ou=macosxodconfig,cn=config,dc=test249,dc=home"

LDAP Setup Tool (slapconfig), Apple, Inc., Version 1.2

https://discussions.apple.com/thread/4547470?start=0&tstart=0

I had a new idea on how to attack this problem.

If the problem is the ssl certificate can we copy the certificate for the OD master to the replica?

I tired to bind to my OD master but it wont accept any password, could this be related?

I have been having this error for a couple days now and finally got my head around it. With a little help from Apple. Turns out Open Directory was corrupted entirely. Also, make sure that the server you want to be the replica isnt bound to the Master via System Prefrences-Users and Groups-Login Options. When you make the replica through Server app it will bind there.

Steps we took to fix:

Export an archive of the Open Directory by opening Server app-Open Directory-Click the cog-Archive Open Directory. Save this somewhere you can access it easily, I simply made a folder on the desktop.

Open work group manager-authenticate as diradmin-select all users in the OD EXCEPT for diradmin. Then click Server-Export, again save somewhere you can get to easily. Then do the same for the groups you have created. Now I think this backups passwords as well but it might not so dont quote me on that one. So it might be a good idea to get a list of all users passwords before you do this next step.

Turn off all services running on the server that require user authentication. You can leave DNS and DHCP running if your server is handling those. But nothing else.

Open Terminal and run: sudo slapconfig -destroyldapserver , enter password and this will destroy your current OD. I also did this on the server intended to be the replica, because it seemed in the process of trying to join as a replica it attempted to write the files but then it failed out. So there was a few files that were left; destroying them is a good idea.

Restart both servers. When the master comes back up. Open Server app and go to Open Directory, turn the service on and select the open to "Restore from Open Directory archive" option (its the last option might not have the wording correct). It should restore without any problem and you will have all your users back.

After the OD is restored highlight the master and click + again. Fill in the appropriate fields.

This took about 10 minutes, if that. And it created the OD replica without any errors. After you verify that the replica went through correctly, you can turn back on all services.

Hope this is the solution for you all as well.

Also, if you are running mail services on the master using self-sign certs. They will be broken and need to be recreated/reapplied.

Still having a probem here creating a replica. I tried the last fix posted but it does not work for me. In fact now it reports the error right away instead of showing users being sent to the server with a status bar. If anyone has any ideas I would appreciate hearing them.

Console output:

6/19/13 5:35:54.162 PM digest-service[858]: label: default

6/19/13 5:35:54.162 PM digest-service[858]: dbname: od:/Local/Default

6/19/13 5:35:54.162 PM digest-service[858]: mkey_file: /var/db/krb5kdc/m-key

6/19/13 5:35:54.162 PM digest-service[858]: acl_file: /var/db/krb5kdc/kadmind.acl

6/19/13 5:35:54.196 PM digest-service[858]: digest-request: uid=0

6/19/13 5:35:54.282 PM digest-service[858]: digest-request: init request

6/19/13 5:35:54.283 PM digest-service[858]: digest-request: init return domain: STU server: STU

6/19/13 5:35:54.318 PM digest-service[858]: digest-request: uid=0

6/19/13 5:35:54.318 PM digest-service[858]: digest-request: init request

6/19/13 5:35:54.320 PM digest-service[858]: digest-request: init return domain: STU server: STU

6/19/13 5:35:54.321 PM digest-service[858]: digest-request: uid=0

6/19/13 5:35:54.322 PM digest-service[858]: digest-request: od failed with 22 proto=lm

6/19/13 5:35:54.322 PM digest-service[858]: digest-request: user=\

6/19/13 5:35:54.322 PM digest-service[858]: digest-request: kdc failed with 22 proto=unknown

6/19/13 5:35:54.323 PM digest-service[858]: digest-request guest: ok user=STU\GUEST proto=lm flags: NEG_KEYEX, ENC_128, NEG_VERSION, NEG_TARGET_INFO, NEG_NTLM2, NEG_ALWAYS_SIGN, NEG_ANONYMOUS, NEG_NTLM, NEG_SIGN, NEG_TARGET, NEG_UNICODE

6/19/13 5:35:54.348 PM smbd[846]: anonymous connected to path /var/rpc/ncacn_np

Well in my case the error is quite accurate. When you go to etc/openldap the rootdse file that should be created is not there. And I am unable to get the file to show up on any of my systems when I create them as an od master.

Does anybody have news about this issue? I still cant create the replica

My intended replica was an existing 10.6.8 server which I migrated to Mountain Lion Server. I wound up just wiping the drive and beginning with a fresh 10.6.8 install and then going to ML Server. Now everything works.

The OD was a new ML Server from the start.

That last line should be "The OD master" was a new ML Server from the start.

My ODM is also a new ML server from the start and now I'm trying to do the replica with another new ML server. I checked the settings with "changeip -checkhostname" and is all fine, but I am still getting this message box:

any help would be grateful...

No. I gave up. It looked like if I did a clean install on both systems. Exported the users and groups out, imported into a fresh install and ODMaster and reset all the passwords it might work. It worked on a test system, but with this problem I've had things work on test that didn't work in practice. I've already nuked the directory once and had everyone in the company reset their passwords and am unwiling to do that again. Currently I just have a script archiving the directory on a nightly basis.

I have tried manually creating a rootDSE file with the correct entries in /etc/openldap/ and adding a reference to it in /etc/openlodap/slapd.d/cn=config.ldif to no avail.