I’ve done some testing now with MCX records moved into a new local node as described here. It seems to work well. In practice, it’s really no different than putting the MCX info in the Default local node, but there are a few advantages:
- This refinement eliminates the MCXCCacheGraph() warnings in the system.log. They seemed to be harmless, but one can never be certain.
- The underlying reason for the above error is now addressed – active computer records are now properly cached in the local directory service node. Specifically, you’ll find a cached copy of the active computer record from /var/db/dslocal/nodes/MCX/computers stored in /var/db/dslocal/nodes/Default/computers. When computer records were stored in the default local node, the caching mechanism failed because it was trying to cache a computer record in the same place and with the same name as the original record.
- I’m hopeful that this will also address an issue I’ve seen on occasion myself, and have heard of others seeing — that during startup, some of the computer records in the default local node seem to get deleted. I think this is a result of the MCX caching mechanism as well.
- Finally, this organization (putting all the MCX records in a separate directory node) makes it really easy to temporarily turn off all MCX management for a machine. You might see this as a net plus or a net minus. To temporarily turn off all MCX management, just remove the /Local/MCX node from the authentication search path, using Directory Utility or dscl. When you want to turn MCX back on, re-add the /Local/MCX node.
Some additional notes:
Brian Warsing made the excellent suggestion of adding a local admin user to the new /Local/MCX node as a way to be able to authenticate to that node using Workgroup Manager. I really didn’t want to keep track of a second local admin account and associated password, so I tried copying a local admin plist from the default local node to the /Local/MCX node. This failed to work to authenticate in Workgroup Manager, I suspect for much the same reason local accounts “mask” network accounts with the same name: OS X searches the directory services in the order given in the authentication search path. So it found my local admin account in the default local node and did not even check the new MCX node. It might be possible to at least link the passwords of an admin account in the default local node and the mcxadmin password by linking their shadow files in /var/db/shadow/hash — this way when you change your local admin account’s password, the mcxadmin’s password changes at the same time.
I haven’t tested this approach yet, but will soon.
Setting up this configuration for Local MCX is a bit more work than simply using the default local node, but I think it will be worth it.