Mountain Lion and MCX

GregN

In my last post, I asserted that Local MCX still works in Mountain Lion. And it does. But that doesn’t mean there aren’t issues to deal with.

There have been various reports of certain MCX settings not behaving correctly — for example, it appears that currently you can’t use MCX to manage Dock settings “Once” — only “Always” management works. (And that’s not useful for us — it doesn’t allow one to set certain Dock defaults and then leave the Dock alone for the user to modify as they’d like.)

There’s another challenge if you use Local MCX in an alternate local DirectoryService node, as described here:

In Mountain Lion, dscl refuses to write to non-default local nodes:

# sudo dscl /Local/MCX create /Computers/foo
create: Invalid Path
<dscl_cmd> DS Error: -14009 (eDSUnknownNodeName)

This makes manipulating things in a non-default local node much harder than it was in Leopard through Lion.

You can still copy files into /private/var/db/dslocal/nodes/MCX, and that can serve as a workaround for now. All of the packages I use to configure Local MCX do exactly that — they install plist files into /private/var/db/dslocal/nodes/MCX/computergroups. But there is one major exception.

I have one package that does the setup for Local MCX. It makes sure the /Local/MCX node is present, makes sure it is in the search path, and makes sure that an appropriate record exists in /Local/MCX/Computers to represent the current local machine. This requires writing to the /Local/MCX node to dynamically create the computer record. We can’t just install a file, because the contents of the data in the computer record are unique for each computer.

So there’s our problem: we can’t use dscl to create a computer record in the /Local/MCX node, yet we must dynamically create an object in that node.

There are two solutions, both which rely on the fact that all objects in Local DirectoryService nodes are actually just plist files.

The first:  We could use another plist creation tool to create the needed plist. We could use defaults or PlistBuddy, for example. But that would require us to take the time to figure out how to use one of those tools to create a file that is the same as if dscl created it.

The second: Use dscl to create the record in the /Local/Default node. Then just move the plist from /private/var/db/dslocal/nodes/Default/computers/foo.plist to /private/var/db/dslocal/nodes/MCX/computers/

The second approach is the one I decided to take, since it seemed easier.

Here is the script I currently use for initial Local MCX setup. If you are currently using Local MCX on Lion or earlier, I hope it is of some help if you want to continue to use Local MCX on Mountain Lion.

Advertisement
Mountain Lion and MCX

16 thoughts on “Mountain Lion and MCX”

  2. todd says:

    might it not be best to just get to using profiles, as apple can and likely will break this hack, they seem to enjoy breaking us doing useful things like not having to look at the lame linen login screen.

    1. Absolutely it’s a good idea to move to profiles:

      – They are officially supported by Apple
      – They can do basically everything that can be done with Local MCX
      – They can manage things Local MCX can’t, like VPN and 802.1X configurations.

      1. Brian says:

        But profiles aren’t supported on the “lion’s” share of machines our school division uses. We’re still running Tiger eMacs in some classrooms for students.

        We’re staying with Snow Leopard server for the time being, but we will be looking at replacing a round of servers here soon and that’s going to introduce some interesting problems.

      1. Roy says:

        Thanks, I will check it out, I am running local MCX on some boxes and softwareupdateserver is one of those managed prefs, thats how I think google directed me here.

  4. David Haines says:

    Thanks for this, Greg !

    Question: What are you accomplishing with the hard-coded laptop & desktop GUID(s) ?

    1. The “meat” of my LocalMCX implementation is in ComputerGroups, which are installed on local machines by simply installing the relevant plist file. The group membership is by GeneratedUID, so they need to be specific values. Thus the hard-coded values.

  6. CMG says:

    Does dscl’s inability to write to a non-default node also affect Workgroup Manager as well? The reason I ask: we’re moving directly from Snow Leopard to Mountain Lion, and I’ve got a working prototype using the managed preferences from our Snow Leopard setup.

    I want to now go and edit them, but I’m getting an error (sorry, don’t have the error in front of me here) every time I attempt to do so.

    Additionally, what is the best way to create a mcxadmin account? I created the account in the default node, edited it to change the default group to 80, then moved it into the MCX node. It seems to work, I think, but I’m wondering if this is the best way to do it.

    1. “Does dscl’s inability to write to a non-default node also affect Workgroup Manager as well?”

      Almost certainly!

      I think the method you used to create an mcxadmin account is the “right” way.

      Apple is really pushing us toward profiles…

      1. CMG says:

        Well, right now they’re just pushing me to stay on 10.7.x for the academic year. Path of least resistance and all. 🙂 Thank goodness we haven’t bought any new hardware this year.

        I’ll use this year to get used to the new world of profiles and all the other “joys” that Mountain Lion brings. (Yay?)

Comments are closed.