Skip navigation

Error creating Open Directory Replica in Mountain Lion

8090 Views 35 Replies Latest reply: Aug 20, 2013 9:33 AM by makkintosshu RSS
  • etblack Calculating status...

    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.

  • Don Roedl Level 2 Level 2 (210 points)

    Today I upgraded 4 existing 10.6.8 servers to ML Server 10.8.3. One ODM and 3 Replicas and everthing went fine. Took all pre-cautions with Carbon Copy Cloner backups of the boot volumes, exporting all server settings, archiving OD, exporting WGM users/groups/computers/computer list. I did not need to return to the backups however because everything upgraded in place, and replicas all created successfully on the first try. Go figure.

    The 10.6.8 servers were all clean installs from one year ago.

  • carlosribas Level 1 Level 1 (0 points)

    I gave up too. I think you are right, the best thing to do is a backup. Could you share your script archiving?

  • etblack Level 1 Level 1 (0 points)

    This is the script I am using. Created a launch daemon to run it.

     

    http://www.practiceofcode.com/post/36837763894/open-directory-7-day-rotating-bac kup-script

     

    What I have figured out from testing is that to fix it I would need to do a full install of both systems, run the updates before installing Server.app (It broke in a different way if I installed server.app and then ran the 10.8.4 updates), promote the server re-import the information and setup the replica.

     

    On my system the rootDSE.ldif file is missing from /etc/openldap/. I created a replica but that doesn't work because /etc/openldap/slapd.d/cn=config.ldif does not reference the rootdse file. And I can't use ldapadd or ldapconfig because the gssapi authentication fails because the rootdse information is missing.

     

    If I run this command on the not working production server and the working test server, this is what I get.

    ldapsearch -LLL -x -H ldap://ldap.example.org -s "base" -b ""

     

    On not working server:

    dn:

    objectClass: top

    objectClass: OpenLDAProotDSE

     

    on working server:

    dn:

    objectClass: top

    objectClass: OpenLDAProotDSE

    dNSHostName: servername.domain.lan

    krbName: ldap/servername.domain.lan@SERVERNAME.DOMAIN.LAN

    saslRealm: SERVERNAME.DOMAIN.LAN

  • carlosribas Level 1 Level 1 (0 points)

    Well, I am using a new ML server and I did all the updates before installing Server.app. I have the rootDSE.ldif file and it seems ok. I really dont understand this problem.

     

    Thanks for pointing the script. Good luck for us!

  • makkintosshu Level 1 Level 1 (0 points)

    I had the exact same problem and, in testing, found that I also had the same symptoms that Nigel describes in https://discussions.apple.com/thread/4547470?start=0&tstart=0: `sudo slapconfig -ver` was resulting in the "Error execing slapcat: 50b51fdb /etc/openldap/slapd_macosxserver.conf: line 303: unknown directive <TLSCertificatePassphrase> inside backend database definition." I had persused these and other threads related to being unable to perform an authenticated bind or create a replica between 10.8.4 Servers (the master was upgraded from 10.6.8, but the replica issues occurred on both other servers that were upgraded from 10.6.8 to 10.8.4 and clean installs of 10.8.4).

     

    I found that while we had a valid signed cert installed (a wildcard for our organization), there was also a self-signed cert. I removed the self-signed cert, commented out the "TLSCertificatePassphrase" line in /etc/openldap/slapd_macosxserver.conf, stopped & slarted slapd (`sudo launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist` followed by `sudo launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist`), and `sudo slapconfig -ver` now prints the version info without error. This also means I'm now able to perform authenticated binds & configure new replicas, so clearly is what was causing authenticated binding & replica creation to fail since it never spit back a version number.

1 2 3 Previous Next

Actions

More Like This

  • Retrieving data ...

Bookmarked By (1)

Legend

  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.