Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

10.8 Server: Problems Updating an Open Directory Replica

Dear community


I have two new 10.8.2 servers – one is an OD master, and the other – an OD replica.

Initial replica creation goes well, but for some reason the master can't update it after that. So, for example, a password change does not propagate to the replica. I have to delete and re-create the replica, in order to get the changes.

Here are the LDAP log entries that repeat every minute:


Feb  1 12:43:03 odmaster.example.com slapd[102]: slap_client_connect: URI=ldap://odreplica.example.com:389 ldap_sasl_interactive_bind_s failed (-2)
Feb  1 12:43:03 odmaster.example.com slapd[102]: do_syncrep1: client_connect failed (-1) - searchbase(cn=authdata)
Feb  1 12:43:03 odmaster.example.com slapd[102]: slap_client_connect: URI=ldap://odreplica.example.com:389 ldap_sasl_interactive_bind_s failed (-2)
Feb  1 12:43:03 odmaster.example.com slapd[102]: do_syncrep1: client_connect failed (-1) - searchbase(dc=odmaster,dc=example,dc=com)
Feb  1 12:43:03 odmaster.example.com slapd[102]: do_syncrepl: rid=004 rc -1 retrying
Feb  1 12:43:33: --- last message repeated 1 time ---
Feb  1 12:43:38 odmaster.example.com slapd[102]: SASL [conn=5714] Failure: no secret in database
Feb  1 12:43:38 odmaster.example.com slapd[102]: int slap_sasl_bind(Operation *, SlapReply *): Error to increment failed login count for uid=updater637333537,cn=users,dc=odmaster,dc=example,dc=com


A similar if not the same issue has been reported here, with no solution:


Note sure what to try.

Thank you for your help.

Mac mini, OS X Mountain Lion (10.8.2)

Posted on Feb 1, 2013 9:58 AM

Reply
28 replies

Feb 3, 2013 8:34 PM in response to wimpog

I'm having nearly the same problem, though I think your logs have the two lines at the bottom which may be specific to your issue.


Before I go any further, you do have SSL certificates configured properly on both the Master and the Replica correct?


If this is the case, and you are using the SSL certificates that were created for you by slapconfig in the server app, then we have exactly the same issue.


I have three machines running server. The Master, replicates without issue to replica1, replica1 isn't running any critical services. Replica2 is running some services of importance and cannot establish replication properly without this issue. All three servers are using the correct configured SSL certificates. If I configure replica2 to connect to replica1 instead of connecting directly to the master, the same issue persists. I tried today to reformat and reconfigure replica2 from scratch, and the same error persisted.


My next option is to wipe all of them and start over. I'm tempted to think that this is a Kerberos authentication error for _ldap_replicator, but I can't re-kerberize the master, as apple has convieniently removed that tool.


I'm becoming increasingly frustrated with this issue, and I really hope that the community can help.

Feb 4, 2013 6:28 AM in response to ryanhoye

Hi,

Thank you for your reply.


I do have SSL certificates – one wildcard certificate that was purchased and used on both servers, and the OD master and replica have their self-generated ones. I tried using the wildcard certificate, the self-generated certificates, and using no certificate at all – none of that helped, same errors.


I also think this has something to do with Kerberos, but I don't know how to re-kerberize that either. Since you have one replica working, do you think it is the master that's causing the problem? What kind of errors do you get in your LDAP log?


Here is an article that explains how to set a replica up manually:

http://krypted.com/mac-os-x/setting-up-troubleshooting-an-open-directory-replica -in-os-x-mountain-lion-server/

I tried that, but it didn't work. The error I was getting:

unable to determine the master's software version

Very frustrating, especially, considering that the two servers I have are brand new installs.

Feb 4, 2013 8:39 PM in response to wimpog

I tried doing the setup manually as well, with the same error. I think this is an issue with apple's version of server.


The errors I get in the LDAP are only the SASL authentication errors like yours. My only deductive reasoning is that there is something wrong with the Master, but the Master replicates fine to another server. Just not the one I want.


Feb 3 20:04:49 master.example.com slapd[2012]: slap_client_connect: URI=ldap://replica2.example.com:389 ldap_sasl_interactive_bind_s failed (-2)

Feb 3 20:04:49 master.example.com slapd[2012]: do_syncrep1: client_connect failed (-1) - searchbase(cn=authdata)

Feb 3 20:04:49 master.example.com slapd[2012]: do_syncrepl: rid=008 rc -1 retrying



I've tried re-installing server.app I've tried wiping the machine and installing from scratch on replica2, and to no avail.


I've seen other answers saying that this is just a password issue for _ldap_replicator and I've matched the passwords previously and that's not it either. At the time of writing I have a successful replication from Mater to Replica1, but Replica2 won't co-operate.


Other posts have also mentioned something about computer records on the master not being removed and having to clean those out in order for the replication to happen. I've seen this happen, where I've destroyed the replica and the computer replica records for that replica remain in the directory for the master. Cleaning those out still doesn't work.


I'm at a loss as to why this replication is so troublesome. Especially when you're dealing with a fresh install. It's as if the replication tools weren't completed, or tested to completion.

Feb 5, 2013 8:46 AM in response to ryanhoye

When you set your master up, did you create all user accounts from scratch, or did you import your LDAP database from an older OSX server?

By the way, not related to this issue, but you may also want to check, and correct, if needed, this:

http://meandmymac.net/1434/or-maybe-its-broken-anyway/

Do you know if we can get some help from Apple? Seems like it is their problem, since you and I tried fresh installs and it ain't working.

Feb 5, 2013 9:12 AM in response to wimpog

I had created all of my users from scratch initially, and have since exported and re-imported them a few times in order to test functionality, and the lack of replication.


I have not yet looked into that one, but it could prove to be part of the issue. If that hash is incorrect on _ldap_replicator then it may be part of the issue, I may have to test it at some point.


We may be able to get some help from apple if you have applecare, they supposedly have extended support of server app functions in applecare now. Though I think they might tell you to start over. Which I don't think is realistic.

Feb 5, 2013 1:36 PM in response to ryanhoye

I applied the update to no avail.

How did you change the kerberos hashes?

In the error messages (yours and mine) you can see it tries to communicate on port 389, but that's insecure LDAP port, whereas the secure one is 636. I wonder if it is trying to communicate securely over an insecure port and hence the failure?

Not sure what's going on.

Feb 6, 2013 7:40 AM in response to ryanhoye

I thought, if you set choose to use SSL certificates for certain services, they become secure, otherwise what's the point of the certificates.

I keep getting errors, and don't know what to do now. I can't find successful replication logs either. The only way to push changes for me, is to delete and re-create the replica.

Did you compare the Kerberos hashes on the master and the replica that's not working, and found them to be the same?

What is going on with this? Don't know what else to do...

Feb 6, 2013 10:49 AM in response to wimpog

Double check that you have the matching SSL certificates setup for the LDAP by checking the slapconfig -getldapconfig terminal commands.


I compared Kerberos hashes on the master and on the replica and they do match. I even checked the information in the authdata files inside /var/db/openldap and found exactly the same infomation for _ldap_replicator on both, including the correct Kerberos domain information.


I did find extra .ldif files for previous replications, but I don't think this is the issue if your system hasn't been replicated before.

Feb 6, 2013 12:39 PM in response to ryanhoye

AuthenticationAuthority is a Kerberos ID, but I'd still like to know where the password hashes are. I think they're in AuthenticationAuthority.


My master is also a DNS master, and the replica – DNS slave. That's working fine. The sudo changeip -checkhostname command verifies that. I had it wrong at one point, but have corrected since.

10.8 Server: Problems Updating an Open Directory Replica

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.