Skip navigation

Open Directory - Local Network User/Group - GONE

1229 Views 20 Replies Latest reply: Jan 2, 2014 1:05 AM by UKenGB RSS
1 2 Previous Next
UKenGB Level 2 Level 2 (270 points)
Currently Being Moderated
Dec 14, 2013 6:04 AM

This morning everything seemed to be working normally, then an email couldn't be sent through my local server. Kept asking me to sign in. Eventually tracked it down to Open Directory playing up. In Server.app, the 'Local Network' option for both Users and Groups was empty. After a restart of the server (and half a dozen more since) there is no longer any pop-up in Users or Groups at all. There's just the list of locals and that's all.

 

Trying to look into this with either WorkGroup Manager or Directory utility just results in an error, so looks like OD has comprehensively shot itself in the foot, all by itself. Nothing has been done to the server for weeks, this is entirely of its own doing.

 

Admittedly there's not many Users and/or Groups to re-create, but at the moment I can't even do that as it doesn't even know there's an LDAP directory to add them to. So looks like I'll have to destroy the entire OD setup and start again from scratch. Just what I wanted to do this weekend. Thanks Apple.

 

Anyone got any info on how Server.app manages to do this and what can be done to fix it and hopefully stop it from occurring again?

  • Strontium90 Level 4 Level 4 (2,895 points)
    Currently Being Moderated
    Dec 14, 2013 8:50 AM (in response to UKenGB)

    While I don't have a magic bullet to solve your problem, I can suggest reviewing your logs.  OS X does a rather decent job of recording events and something like the corruption and loss of an Open Directory master is likely recorded somewhere.  While discovering this moment and possible cause may not result in the ability to fix the issue, it will at least provide some closure to why it happened and when.

     

    Next, it is best practice to backup your Open Directory regardless of how small or large it is.  LDAP can be a finicky technology and many things can cause it to flake out.  If you were backing up your OD on a regular basis, you would likely be able to simply restore from a backup and everything would be back in place.

     

    The importance of a backup can not be dismissed.  Accounts in OS X are backed by GUID values and these can be very difficult to nearly impossible to rebuild in the event of a rebuild of the server.  Many of the services in OS X will define access based on the accounts GUID value.  If your OD blows up and you simply recreate new accounts, you end up with all new GUID values for the accounts.  This can make linking users to data a challenging ordeal.

     

    Now, LDAP does have some tools to attempt to repair an Open Directory database.  This has historically not worked well in my experiences.  However, you can research the db_recover tool.  Generally sudo db_recover -v -h /var/db/openldap/openldap-data/  Research before attempting.  Once you are back up and running, make sure you have a backup plan in place.

     

    R-

    Apple Consultants Network

    Apple Professional Services

    Author "Mavericks Server – Foundation Services" :: Exclusively available in Apple iBooks Store

  • Strontium90 Level 4 Level 4 (2,895 points)
    Currently Being Moderated
    Dec 14, 2013 12:18 PM (in response to UKenGB)

    Glad to help.  Count yourself a lucky one.  Go get a lottery ticket.  I think db_recover has saved me twice in the last 7 years.  Glad it helped out!

     

    And yes!  Do run a backup.  Since I am on a winning streak with advice, I will also point your toward slapconfig as a method of automating a backup outside of TM.

     

    sudo slapconfig -backupdb ~/path/to/backup

     

    This can be automated with an expect script.

     

    Glad to save your weekend.

     

    R-

    Apple Consultants Network

    Apple Professional Services

    Author "Mavericks Server – Foundation Services" :: Exclusively available in Apple iBooks Store

  • Strontium90 Level 4 Level 4 (2,895 points)
    Currently Being Moderated
    Dec 15, 2013 4:11 AM (in response to UKenGB)

    No argument perceived.  I tend to run a backup on a daily basis regardless of the environment simply because I never know when a user may change a password.  Having a regular backup means that I will only miss a potential 23 hours and 59 minutes of changes.

     

    And yes, slapconfig is the same as using the User Interface.  I approach this from the field consultant perspective.  I am not present at any of my deployments on a daily basis.  That being said, I rely on automation to do the backups for me.  This is why I will use an expect script to automate the creation of the backup dmg.  And no, you do not need to embed the admin password in the script.  You only need to embed the disk image's encryption password.

     

    OD is one of those technologies that we feel we don't change often.  But when I look at an environment, there are those "hey can you add me to a group" request or the "he we have a new user" or, as mentioned, the use who changes a password.  The backup of OD contains all users, groups, and passwords.  This allows for rapid restoration and reduces the amount of reconstruction required.

     

    If you are the admin of the environment, you define an acceptable risk policy for backup interval.  If you have a small set of users (under 20), with no password policy, a quarterly manual backup may be appropriate.  If you are managing over 50 people with a password policy in place and high staff turnover, you will be surprised how much OD changes.

     

    By the way, using TM on the server should accomplish the same task.  I am just a paranoid sort and have seen TM fail me when needed most.  Thus, I craft multiple backup routes for the important stuff.  Trust but verify. 

  • Strontium90 Level 4 Level 4 (2,895 points)
    Currently Being Moderated
    Dec 15, 2013 8:10 AM (in response to UKenGB)

    Automate the script using cron or launchd.  That way you define the user who runs the script.  Cron example is:

     

    30     1     *     *     *     root     /path/to/script

     

    Launchd requires a properly formatted plist file but you can achieve the same.

     

    Never log in as root

  • Strontium90 Level 4 Level 4 (2,895 points)
    Currently Being Moderated
    Dec 16, 2013 4:19 AM (in response to UKenGB)

    I hope not.  To be honest, your two reports are the first ones I've heard of under Mavericks.  Mountain Lion was known to do this periodically as well.  Right now, Mavericks Server (in my world) is still mostly in lab testing.  Only customers buying new hardware are being placed on Mavericks at this point.  All others are waiting on the first patch release or later. 

     

    So far, in my testing, I've been pleased with the 10.9.0 release.  Usually, it takes until a .3 or so before a new OS is ready for release.  So far, aside from some issues with Calendar server and SMB connections to Windows workstations, I have had great success and stability.  But, there is always the specter of disaster. 

  • curriebwoi Level 1 Level 1 (0 points)
    Currently Being Moderated
    Dec 18, 2013 2:03 PM (in response to UKenGB)

    What is the command for db_recover from the terminal window?

  • Strontium90 Level 4 Level 4 (2,895 points)
    Currently Being Moderated
    Dec 18, 2013 2:49 PM (in response to curriebwoi)

    It is in the solution post.  Generally it is:

     

    sudo db_recover -v -h /var/db/openldap/openldap-data/

     

    Read the man page first and make sure you are understand what you are attempting.

     

    Then craft a backup plan.

1 2 Previous Next

Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)

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.