Based on some ideas in this thread I started experimenting with some changes to my Local MCX setup with the goal of eliminating warnings like these from /var/log/system.log:
Mar 7 10:41:19 allure com.apple.loginwindow: MCXCCacheGraph(local_laptop, dsRecTypeStandard:Computers): Cannot cache because an existing record named "local_laptop" has conflicting attributes and must be deleted before caching.
This is a common warning when managing MCX data in the local directory service and seems to be harmless. Another seemingly related problem in when the OS deletes local_computer type records from the local DS node at startup, which isn’t so harmless, as it stops local MCX settings from being applied.
So as, root, I did this:
mv Default/computers/* MCX/computers/
mv Default/computergroups/* MCX/computergroups/
Then I needed to restart DirectoryService so it will notice the changes:
I then opened Directory Utility and added the new /Local/MCX node to the authentication search path; higher than my LDAPv3 directory, so the search path looked like this:
I rebooted for good measure, logged back in and checked the MCX settings – they were all being applied and worked as expected. Better yet, no sign of any MCXCCacheGraph warnings in the log. Success!
So this looked like a good refinement to the way I was implementing Local MCX. I opened up Workgroup Manager, and authenticated to localhost as a local admin. It showed me the /Local/Default node. I switched nodes to /Local/MCX. It showed that I wasn’t authenticated, so I clicked the padlock icon. Workgroup Manager then prompted me for an administrator’s name and password. I entered the same admin name and password i used to authenticate to the /Local/Default node.
Nothing I’ve tried works. I cannot use Workgroup Manager to edit records in a non-default local node.
This makes using a special MCX node very cumbersome. You could work around this issue by using the shell to move records back and forth between nodes.
Or you could put just the computer record(s) in the /Local/MCX node, since those are the ones that are problematic in /Local/Default.
But none of these are as appealing as just working with the records directly in a /Local/MCX node.
Has anyone else experimented with this configuration?
Has anyone else figured out how to use Workgroup Manager with non-default local nodes?
UPDATE: reader Brian Warsing suggested that I try adding an admin user to the new /Local/MCX node.
I created a user named mcxadmin in /Local/MCX and set its gid to 80, making it a member of the admin group. I did not add an admin group; I assumed (rightly) that it would honor the admin group from /Local/Default.
I could then authenticate to the /Local/MCX node and use Workgroup Manager to edit records.