Currently Being ModeratedJul 22, 2013 10:18 AM (in response to carlosribas)
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.
Currently Being ModeratedJul 22, 2013 5:35 PM (in response to carlosribas)
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.
Currently Being ModeratedJul 25, 2013 11:28 AM (in response to etblack)
I gave up too. I think you are right, the best thing to do is a backup. Could you share your script archiving?
Currently Being ModeratedJul 25, 2013 12:14 PM (in response to carlosribas)
This is the script I am using. Created a launch daemon to run it.
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:
on working server:
Currently Being ModeratedJul 25, 2013 12:54 PM (in response to etblack)
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!
Currently Being ModeratedAug 20, 2013 9:33 AM (in response to chrisgrave)
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.