This discussion is locked
jessereynolds

Q: How to rebuild OpenDirectory databases / replica agreements etc?

Hello

We have some major issues with our OpenDirectory setup. We're running 10.5 Server on two machines, one as Master and one as Replica. We used to have another replica in another office but that was decomissioned (but still lives on like a ghost in the Replica Tree in server admin.)

Because of the problems listed below, I'd like to know how to:
- export the users, groups, passwords (or password hashes), and other data contained in OpenDirectory
- nuke the OpenDirectory configuration and data on both servers
- set up the Master freshly and import the data
- set up the Replica freshly

Current Symptoms:

- Workgroup Manager doesn't let administrators make any changes to users (no create, modify, etc just read only). (Doesn't matter if I've pointed Workgroup Manager at the Master or the Replica.)
- The master is not listening for LDAP connections on port 389 or 636 (but the replica is, and it's working)
- One user has disappeared from the directory (could be human error but I suspect not)

If anyone can point me in the direction of a method to rebuild my OpenDirectory servers it would be very much appreciated.

Thank you
Jesse

Message was edited by: jessereynolds

MacBook Pro 17" 2.5GHz, Mac OS X (10.6.3)

Posted on Oct 19, 2010 4:46 AM

Close

Q: How to rebuild OpenDirectory databases / replica agreements etc?

  • All replies
  • Helpful answers

  • by Jolin Warren,

    Jolin Warren Jolin Warren Nov 5, 2010 3:16 PM in response to jessereynolds
    Level 1 (5 points)
    Nov 5, 2010 3:16 PM in response to jessereynolds
    Jesse,

    Have you got any further with rebuilding your Open Directory databases? I would like to do the same (with just a single OD Master) but cannot find any documentation on how to do so.

    Cheers,
    Jolin
  • by Antonio Rocco,

    Antonio Rocco Antonio Rocco Nov 5, 2010 4:44 PM in response to jessereynolds
    Level 6 (10,606 points)
    Desktops
    Nov 5, 2010 4:44 PM in response to jessereynolds
    Hi

    I'm surprised either of you have not found anything on these Forums as instructions regarding how to do this have been posted many times before. It's a question that comes up time and time again.

    Assuming you're not interested in using the command line launch Server Admin > Open Directory. You should see an Archive Icon. Click on this and the rest is fairly obvious. In addition it's advisable to export Users, Groups and Computer lists (just in case) as well as unsharing any share points that have been designated as automounts for Users Home Directories.

    Once you've done that select the Open Directory Service again, select Settings and in the General tab select Change. Demote the Server to Standalone. Everything to do with the LDAP Database, Users, Groups, MCX, Passwords etc gets 'blown' away on Demotion except for Users' Home Directories. These will be retained. I would have a backup of these just in case. Make sure it's a backup that preserves the default POSIX owner permissions. Use ditto or something similar to do the backup.

    Fix whatever it was that was broken or not done properly when you initially promoted the Server to an OD Master role. Almost invariably this will be down to misconfigured DNS. However don't rule out a drive/directory problem. Once you're happy DNS is properly configured - there are many tools you can use to test this - go for Promotion again. Server Admin > Open Directory > Settings > General. Change the Role from Standalone to Open Directory Master. if everything is as it should be this should take no longer than 30 seconds. A minute at most. Verify all elements of the LDAP Directory are 'Running' by clicking on the Overview icon. If Kerberos is 'Stopped' demote again and double check DNS. If you've used .local as the .TLD Kerberos will never start. Use your real world domain (if you have one) or use any other word that is not .local.

    On successful Promotion re-share the shares you'd designated for automounting Users Home Directories and restore the archived LDAP Database. That should be it. However sometimes the Archived LDAP database will contain inconsistencies or even corruption that will re-introduce whatever caused the problems you're seeing now. This is where exporting the Users, Groups etc comes in. You can import these back into the LDAP node again. The only thing you've lost is the Passwords. You can define a password policy that forces the users themselves to change it to whatever they were using before at next login.

    Tony
  • by Jolin Warren,

    Jolin Warren Jolin Warren Nov 6, 2010 6:54 AM in response to Antonio Rocco
    Level 1 (5 points)
    Nov 6, 2010 6:54 AM in response to Antonio Rocco
    Hi Antonio,

    Thanks very much for your reply. I have seen information about the method you describe, but your explanation is the clearest I've seen (at least, it makes the interaction between the various components clear to me!).

    The problem I have is that I can't demote our OD server to standalone, as we are running in 'standard' (as opposed to 'advanced') mode, so that it is possible to use Server Preferences to administer the server (I only provide help to the organisation 1/month and there is a less technically minded administrator day-to-day). I should also say that we are running Leopard Server 10.5.8, so it is not possible to from standard to advanced and then back to standard mode again. Also, as the server was installed in standard mode, OD was never promoted in the first place -- it started as a master. And it has been running fine until recently. So I don't think there are underlying configuration issues.

    When in standard mode, Server Preferences will not let one demote the OD to a standalone server. So I was hoping there are command-line tools that can be run against the database files (in /var/db/openldap/openldap-data/ ?) that can verify and repair their structure. Or is there some other way of wiping and then recreating a blank OD master structure. If so, I could then import the User, Group, and Computer lists in Workgroup Manager.

    Thanks again for your response.

    Cheers,
    Jolin
  • by Antonio Rocco,

    Antonio Rocco Antonio Rocco Nov 6, 2010 8:58 AM in response to Jolin Warren
    Level 6 (10,606 points)
    Desktops
    Nov 6, 2010 8:58 AM in response to Jolin Warren
    Jolin

    There are command line utilities you can use however I would advise you use the Interface as much as possible. If you launch Server Admin you should see a prompt. It should warn you that you can't go back to Server Preferences. A kind of 'Promotion' to Advanced will take place. Something along these lines at any rate. You should be able to effect a Demotion from there.

    As ever try and make sure you have as many backups as possible.

    To be honest it's been a while and I only ever used Server Preferences a handful of times when 10.5 Server was first released. I found it underwhelming. I think most of us veteran users only use Server Admin and WorkGroup Manager as these were the only applications available prior to 10.5

    What is interesting is whenever I see questions or posts regarding Server Preferences there's generally not much of a response. It seems to me hardly any of the 'older hands' bother to respond at any rate. As a consequence there seems to be very little insight on this Forum or elsewhere on how to troubleshoot the application.

    If it was me I would always go for Advanced having first made sure DNS is correctly configured.

    Tony
  • by jessereynolds,

    jessereynolds jessereynolds Nov 9, 2010 6:21 PM in response to Antonio Rocco
    Level 1 (10 points)
    Nov 9, 2010 6:21 PM in response to Antonio Rocco
    Hi Antonio

    Thanks very much for your procedure, it's very helpful.

    Doing the following has worked in that I can make changes to the directory again:

    1/ Take Open Directory Archive, also export Users, Groups, Computer Groups from Workgroup Manager
    2/ Demote Master to Standalone
    3/ Promote Standalone to Master
    4/ Restore the Open Directory Archive taken in step 1

    However, calendar home has been lost. iCal gives the following message to users:

    "There was an unexpected error with the request (domain CalDAVErrorDomain / error 5 / description 'The server has not specified a calendar home for the account at "/principals/_uids_/1A5A8486-38B3-44DA-845E-C951E35FA38E/ -- https://calendar.xyz.dom:8443/".')."

    I guess the Open Directory Archive doesn't do a full export of the user record, including calendar home? Perhaps I need to not do the Restore, but instead Import users using Workgroup Manager? Urgh.

    There's not many users, perhaps I can manually fix up each calendar home.

    Thanks again
    Jesse

    Message was edited by: jessereynolds
  • by jessereynolds,

    jessereynolds jessereynolds Nov 9, 2010 9:51 PM in response to jessereynolds
    Level 1 (10 points)
    Nov 9, 2010 9:51 PM in response to jessereynolds
    Fixed!

    Prior to the Archive and Restore we had the CalDAV Data folder set different to the default (/Library/CalendarServerWorking/Documents instead of /Library/CalendarServer/Documents). I stopped CalDAV, renamed this folder back to the default and fixed up the setting for it in Server Admin, rebooted the server, and now I am able to enable calendaring for the users in WGM, and have that setting stick. After enabling calendaring on a user it's necessary to restart CalDAV it seems.
  • by frequencydip,

    frequencydip frequencydip Nov 28, 2010 3:59 PM in response to jessereynolds
    Level 2 (295 points)
    Nov 28, 2010 3:59 PM in response to jessereynolds
    I had OD issues and the Server Admin application wouldn't eaven run so I had to do this via command line. Here is what I did:

    First you will need to be root:
    su root
    check what type of directory you have:
    slapconfig -getstyle
    backup your LDAP data:
    slapconfig -backupdb /path/to/backup/location
    destroy your OD server:
    slapconfig -destroyldapserver

    Also if you want to read the slapconfig man pages:
    slapconfig -help
  • by Jolin Warren,

    Jolin Warren Jolin Warren Nov 30, 2010 6:31 AM in response to Jolin Warren
    Level 1 (5 points)
    Nov 30, 2010 6:31 AM in response to Jolin Warren
    I managed to solve my problem (which must have been a corrupted database) without demoting my OD to standalone. This has allowed me to leave the server running in 'standard' mode so that the day-to-day administrator can still use Server Preferences. The procedure I followed was:

    1) Using Workgroup Manager export all users, groups, and computers (and computer groups if you have them). Then using the terminal making a copy of the openldap-data directory (eg. cp -R /var/db/openldap/openldap-data /Users/adminuser/). Once this was done, I felt confident that I had a backup of the data should something go wrong.

    2) Stop the Open Direcotry service:
    sudo launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist

    3) Check the Open Direcotry database:
    sudo /usr/libexec/slapd -Tt

    4) Rebuild the database:
    sudo db_recover -h /var/db/openldap/openldap-data/

    At this point I re-enabled the Open Direcotry service (sudo launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist) to see if the problem was fixed, but it wasn't. So I stoped the Open Direcotry service again and did the following:

    5) Sudo to root
    sudo -i

    6) Dump a copy of the Open Diectory databse in LDIF format:
    mkdir /Users/adminuser/opendirectory
    cd /Users/adminuser/opendirectory
    slapcat -l dir.ldif

    7) Move the (corrupt) database and log files out of the way:
    cd /var/db/openldap/openldap-data
    mkdir SAVE.2010-11-30
    mv *.bdb SAVE.2010-11-30/
    mv log.000000001* SAVE.2010-11-30/

    8) Recreate the database from the LDIF file (there were some apparently harmless warnings which I ignored):
    cd /Users/adminuser/opendirectory
    slapadd -l dir.ldif
    slapindex

    9) Restart the Open Directory service:
    launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist

    10) Exit from root:
    exit

    All running well now! I've posted this in case it helps someone else who can't demote the OD server to standalone to fix their problems.