Open Directory

tycen's picture

Open Directory not starting on XSAN metadata controller

Help! Everything with our metadata controllers have been running fun. I have two MDC and am on XSAN 4.1/El Cap. I have added a client to the XSAN since the upgrade so I'm pretty sure nothing bad happened during the upgrade.

One of my MDC's has been acting funky - I think it's an issue with the 8 Promise Pegasus2 arrays I have connected it it via Thunderbolt - and I've had to do a few hard reboots over the last couple of weeks.

Well, yesterday I went to add a new client to the XSAN (we had to wipe and reinstall the OS on a previous client). It failed and the error led me to find that my MDC that's been giving me trouble doesn't have Open Directory running. OD won't start and from other searching it seems that the database has become corrupted. Running sudo /usr/libexec/slapd -Tt gives the error:
57880743 bdb(cn=authdata): /var/db/openldap/authdata/id2entry.bdb: unexpected file type or format
57880743 bdb_db_open: database "cn=authdata": db_open(/var/db/openldap/authdata/id2entry.bdb) failed: Invalid argument (22).
57880743 backend_startup_one (type=bdb, suffix="cn=authdata"): bi_db_open failed! (22)

I've tried recovering it using various methods posted on different forums but am having no luck at all. I did not know to be archiving my OD Master - so I do not have an archive.

The XSAN environment seems to be working fine otherwise - all the clients are happy. I just can't add the new client.

I'm only using OD for the XSAN environment - I don't use it for users or groups (the XSAN clients just have a local user).

Environment: 2 XSAN MDCs; 7 XSAN clients; all running 10.11.5.

Here's some questions:
1) is there anyway to add a client with the XSAN in this state?
2) Does Time Machine help me at all (I have had it running)?
3) How do I get this fixed long term?

Thanks for any help!

billgarmen's picture

Rebuilding OD and keeping an existing xsan volume in 10.10

So after lots of testing and trials, I got this process to work. WRSTUDEN had the steps all right, it was just missing some steps to make it work for me.

This is to fixed a 10.10 OD issues by rebuilding the OD and connecting to back to an existing Xsan system

Backup your old xsan config files from /Library/Preference/Xsan
backup the system (just in case you need to restore)
back up your users if you can
Format the hard drive and reinstall the OS and server app

Now you have a clean fresh install.

In Server App Create New OD MASTER, import your users if you want to at this stage. (I did it at the end but I don’t think it makes a difference)
In Server App turn on Xsan (For SAN NAME use the exact same name you had used before)
This creates new Xsan config files and a new xsan config group in LDAP
Close Server app
Open up the new xsan config file (config.plist) at /Library/Preferences/Xsan and copy and past the following into the original config file from your old system:
the line below certSetRevision,
the line below sanRevision
and the line below sanUUID

The idea is to trick the system into thinking it created these files, and to re connect to the existing xsan
Once you copy the strings over, replace the original xsan config files the system made with the originals with modified stings of into /Library/Preferences/Xsan (I replaced all of the config files in the folder)
Copy those config files settings into LDAP with terminal - “sudo xsanctl pushConfigUpdate”
This will update the LDAP with the new xsan settings. If you got the stings wrong, they commend will error out and not work
Open server app
You should now have your original volumes listed in the Xsan pan
You can start the SAN from the GUI
Add all your users back and you are golden. If you have to rebuild the users you will have to reset permission on the volume for you clients to work.

This took a while to figure out, I hope it will help others.

OCPSTV's picture

Open Directory Woes

I can't figure this out. Using Local Network Users for Xsan Clients. 2 Mac mini MDCs. Both Setup for Open Directory & DNS. 10.9.4 all around (but one soon to be replaced client running 10.8.5)

Open Directory "available at" - Public network. Master OD.

Everything works for about half a day, more or less, then suddenly the local network users can't log in or authenticate themselves if they are already logged in. (i.e. installing software)

Console shoots back the following:

7/2/14 1:44:52.038 PM Console[823]: Marker - Jul 2, 2014, 1:44:52 PM
7/2/14 1:44:54.612 PM opendirectoryd[22]: set-error: 1: Access to home directory not allowed
7/2/14 1:44:54.612 PM opendirectoryd[22]: set-error: 1: Access to home directory not allowed
7/2/14 1:44:54.613 PM opendirectoryd[22]: set-error: 2: open /Library/Preferences/ No such file or directory
7/2/14 1:44:54.613 PM opendirectoryd[22]: set-error: 1: Access to home directory not allowed
7/2/14 1:44:54.613 PM opendirectoryd[22]: set-error: 2: open /etc/krb5.conf: No such file or directory
7/2/14 1:44:54.613 PM opendirectoryd[22]: gss_isc running replace plugins
7/2/14 1:44:54.613 PM opendirectoryd[22]: gss-isc: negative cache 851968/-1765328377 - Server (krbtgt/METADATA.DOMAIN.NET@SERVER1.XSAN.DOMAIN.NET) unknown
7/2/14 1:44:54.613 PM opendirectoryd[22]: set-error: -1765328377: Server (krbtgt/METADATA.DOMAIN.NET@SERVER1.XSAN.DOMAIN.NET) unknown (negative cache)
7/2/14 1:44:54.613 PM opendirectoryd[22]: gss_isc: kerberos 5 maj_stat: 851968/-1765328377
7/2/14 1:44:54.613 PM opendirectoryd[22]: GSSAPI Error: Miscellaneous failure (see text (Server (krbtgt/METADATA.DOMAIN.NET@SERVER1.XSAN.DOMAIN.NET) unknown (negative cache))
7/2/14 1:44:54.614 PM authorizationhost[2339]: Failed to authenticate user (error: 9).
7/2/14 1:44:56.061 PM Console[823]: Marker - Jul 2, 2014, 1:44:56 PM

It seems to be related to the point where either the client is suddenly looking for—or the server is suddenly advertising and feeding— info from the private metadata network and not the xsan public network. But I've not the foggiest idea how to keep things in line.

I can remove and then re-add the OD from Users and Groups again, and that *fixes* the issue for a short time. however sometimes the wrong OD is advertised. It shows up as the metadata network and not the *correct* public network. I have to manually type in the correct OD server.

Subscribe to RSS - Open Directory