Local MCX update

GregN

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:

  1. This refinement eliminates the MCXCCacheGraph() warnings in the system.log. They seemed to be harmless, but one can never be certain.
  2. 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.
  3. 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.
  4. 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.

Advertisement
Local MCX update

12 thoughts on “Local MCX update”

  1. Thanks for the update Greg!

    It’s really good to know what the MCXCCacheGraph() warnings were all about. I didn’t realize others were seeing them as well and I had incorrectly assumed it had something to do with the MCX settings I was deploying. It had caused me some anxiousness, but I eventually ignored it since things seemed to work in practice.

    We’ve been doing some major overhauls to our deployment/scripts with 10.6 over what we did with 10.5 and I’m going to add your suggestions here to the LocalMCX portion of it.

  2. Matt says:

    Hi Greg,

    Thanks for the great tip – I’d been wondering about those messages as well.
    Could you point me in the direction of the method you used to add an admin user to the new local directory?

    If I run:

    dseditgroup -o create -n /Local/MCX -u mcxadmin -P somepswd -i 80 -L Administrators

    I receive the error “Failed to set credentials”.

    I’m guessing this is not how you did it….

    Thanks in adavance,

    Matt

  3. sudo dscl /Local/MCX create /Users/mcxadmin
    sudo dscl /Local/MCX create /Users/mcxadmin uid 8080
    sudo dscl /Local/MCX create /Users/mcxadmin gid 80
    sudo dscl /Local/MCX create /Users/mcxadmin shell /dev/null
    sudo dscl /Local/MCX passwd /Users/mcxadmin
    New Password: (enter your desired mcxadmin password here)

    1. Matt says:

      Thanks Greg, that worked perfectly, though I have noticed a side-effect, I presume, from not using the /Default local directory:

      We like to have the Directory Status in the Heading of the Login Window as it alerts us to the fact that we’ve plugged the machine into the wrong network (among other things), only now, because /MCX isn’t the ‘local’ directory it once was, we get the false positive ‘Network Accounts Available’ status if /MCX is in the authentication search path, on a machine that isn’t bound to anything.

      Did you come across something similar in your testing?

  4. No, I didn’t notice that until you pointed it out, as we don’t use the Directory Status in the loginwindow.

    So you get to pick your poison:

    1) MCXCCacheGraph errors in the log and possible computer account deletions

    2) “Network accounts available” shows up in the loginwindow if you’re looking at the Directory Status.

    1. Matt says:

      As I suspected. I think the benefit of knowing the network is unavailable outweighs the irritation of the log entries. Back to /Default for me.

      Thanks again for your invaluable help and insight.

      Matt

      1. Is it really that big a deal? If the machine is truly not connected to a network Directory Service, who cares what it says about the availability of network accounts?

        And in my testing, on machines that _are_ connected to a network Directory Service, if the network DS is not available, the message is “Some network accounts available” and the status light is yellow.

        So if you’ve told your users to wait for a green light and “Network accounts available”, the advice still stands.

  5. Matt says:

    The directory service we’re using is NIS and if there’s no network, we lose the ability to log-in completely, from any account, including root.

    I’ve always found it extremely handy to just be able to glance at a machine to tell whether I’m going to be able to log-in or not. The alternative is that I’ll have to unbind the machine by going into single user mode, in order to troubleshoot what might be just a patching problem.

    In any other environment but the one I’m dealing with, I’d say it’s not a big deal.

    1. Unless the NIS plugin works differently than the LDAPv3 plugin and the AD plugin in this regard, you _still_ should be able to tell at a glance.

      In my testing with MCX moved into a new /Local/MCX node, if the LDAPv3 directory wasn’t available, you’d see a _yellow_ light with the message “Some network accounts available”. Once the LDAPv3 directory was available, the indicator would turn green and the message would change to “Network accounts available”.

      I imagine the behavior with NIS would be similar. If, “at a glance”, you saw a _yellow_ light, NIS would not be available. Fix the network issue, and the light should turn green.

Comments are closed.