[warrens]

I’ll second that, create groups specifically for mcx, nest the other group in those.

But to actually answer your question it’s my understanding that the plist data is stored in the LDAP database as binary data. You can view this via dscl, workgroup manager via the inspector panel or an LDAP tool. The inspector should allow copy and paste of mcx data, as does an LDAP tool such as Apache Directory studio.

Work on cleaning up the groups, i feel your pain I have 76 groups the result of organic not fully planned growth.

[warrens]

Examine the file sync logs, the logs can get big and have an effect on file sync performance. If in doubt delete them.

[warrens]

We took this issue up with Apple, they filed a bug report on the matter. We changed to using ldaps and while not completely happy with having to do so it is working for us. Soon after doing so this article was posted here:

https://www.afp548.com/article.php?story=20100425082436137

Which helped fill in some of the documentation holes that made tracing down the issue a pain for us.

[warrens]

sudo serveradmin settings all

This will give you a complete list of server settings that can be read back in. Is this what you were looking for?

[warrens]

We are seeing the same issue, it’s hit all of our home servers, though the older G5 cluster node is by far the most troublesome. Has the above operation proved to be a lasting solution?

[warrens]

I’ve had some luck restoring archive functionality though I have yet to get a full understanding of the keychain item and the circumstances of it’s creation:

Built test server of OD master, same IP, name, version.

Pulled and an archive previous to the occurrence of the problem.

Restored the archive to the test master.

Opened Keychain Access, exported system keychain after confirming existence of com.apple.opendirectory entry.

Moved exported keychain to OD master, imported under a unique name.

Copied com.apple.opendirectory entry and pasted it into system keychain.

Archives now completed successfully.

Currently working under the assumption that the keychain item is machine related, perhaps to the OD masters machine record’s passwordplus field.

[warrens]

Attempted to force a change in the Open Directory keychain item on a test server:

Changed passwords for diradmin and root. No modification of keychain.

Deleted out default cert, Created new cert, configured it for us in LDAP. this created keychain item for the cert’s pass-phrase but no modification on OD keychain occurred.

Would very much like to know under what circumstances the OD keychain is created or modified….

[warrens]

Attempted to recreate keychain item last night, using a password string from a previous archive. The archive process again failed but this time with –25308 (Interaction with the Security Server is not allowed.) I tried the full DNS name and the .local name, both producing the same error.

From the error I am guessing that the string is wrong or since our diradmin password has changed around the time of the last successful archive creation that the two are linked- the keychain item may relate to the diradmin password. I was too tired to realize this at the time, but I will be testing this.

[warrens]

I have the same problem with the same error. What I’ve found so far:

Using a test server I recreated the error. On the test server the system keychain had a password entry for com.apple.opendirectory with account name of servername.local$ and a password not used on the machine for diradmin or root account. The production server has no such entry. Deleting the keychain from the test server reproduces the error. Note, the test server was setup in the .local domain.

Looking at a successful archive from the test server there is a file at the top level of the sparse image called keychain, inside the file is a string consisting of the password from com.apple.opendirectory only.

It would seem that recreating the keychain entry would solve the problem, but the password in the keychain item (on both the test and production) is not one that’s been used on the server. We’ve discussed using the one in the last successful production server OD archive, but we are not inclined to live test on our OD master. Pending any explanation of how the keychain entry is created and specifically what for, I’ll image the server and test in the off hours later this week.

Information on the error was found on Apple’s Developer site:

http://developer.apple.com/documentation/Security/Reference/keychainservices/Reference/reference.html

errSecItemNotFound –25300
The item cannot be found.
Available in Mac OS X v10.2 and later.

[Author]

Posts