Background
I’ve worked with OS X client and the server counter part for a few years now and I’ve experienced a few different deployment models. When I first started, my site was brand-new and thus had all-new equipment purchased at the same time. This included a 10.4 based xServe and a medium sized allotment of 10.4 eMacs (along with a sampling of iBooks). Management, maintenance, and authentication was very easy in this model. All of the hardware was the same architecture. There was a standard single server Open Directory deployment with network home folders and server side management. It all fit in well together. This was also back when 20GB drives were standard on the iBook, so file sizes were of course smaller than today. Today, a standard OS X install, with the full iLife suit would easily occupy a majority share on the small hard drive (if it fits at all).
These days we’ve started authenticating our Macs against Microsoft’s Active Directory. On top of that, there is new hardware in the mix, both clients machines and network infrastructure, and we still cling to our old hardware.
For the most part, it does all work together. However, the management piece has always been a bit of a headache when working with Active Directory. You of course have a few choices to choose from:
- Dual Directory (Golden Triangle)
- Add Additional Schema to AD for OS X MCX
- Local MCX on OS X Client
- Others…?
For the dual directory approach I have three primary issues, first, you have a second directory to maintain, and keep up to date. Second, the “Login Window” has an option to display the directory status (red/yellow/green light). With a dual directory configuration, there can be a disconnect with your end-users. For a single directory, a simple red/green light is an easy indicator for anyone to understand. However a yellow light could mean a few different things, you can’t tell at a quick glance if it is “ok” for a user to log on. It makes the diagnostic task more difficult for your end-user. Lastly, when you have older OS X clients that interface with newer OS X servers (or vice versa) there is the potential for the configuration to not apply as expected.
The schema expansion approach is more a matter of opinion on whether to implement it or not, for our site, we decided against it. We have a large Active Directory system and a we didn’t want to risk causing irreversible damage if we implemented something incorrectly.
Local management however, avoids these issues, there is no schema to expand, there is no second server, and the management is created on the client itself, so there is no risk of incompatibility.
There are two ways to approach local management, you can either apply it to a local user account, which everyone uses on that machine, or you can apply it to the machine itself. If you apply it to the machine, it will apply to all users who log on, including network users. You can also add in the ability for administrators to disable the management as a part of the MCX.
I use the following process to create a package file that I then use to install local MCX on clients:
- Create MCX on a client using WGM.
- Export MCX into a file using -mcxexport from dscl.
- Create installer package, pairing the file from the mcxexport and a small script that creates the local computer object and imports the MCX using dscl’s mcximport.
Creating MCX
The first step is creating the actual policy. This is straight forward and anyone who is familiar with Workgroup Manager should have no issues.
The first step would be to get the Server Admin tools from Apple and install them on a sample client machine. Be sure to get the correct server admin tools for the version of OS X you’re working on (links checked on: 12.06.11):
- 10.4 -> OS X Server Admin Tools 10.4.11
- 10.5 -> OS X Server Admin Tools 10.5.7
- 10.6 -> OS X Server Admin Tools 10.6.8
- 10.7 -> OS X Server Admin Tools 10.7.2
After the tools are installed, launch Workgroup Manager and close the connection window that comes up.
Click on the “Server” drop-down menu at the top and select “View Directories” (Short-Cut: Commad+d). This should change your view to the local directory on the computer. You can then authenticate to the directory by clicking the the lock in the upper right.
After authentication, I generally make a “dummy” computer account to apply management to, usually named “test” or “example” and I don’t specify any additional information other than the name. I am just using it to create my template policy.
You can then apply policy to this object as normal, in this case, I manually set a software update server through MCX.
If we run the -mcxexport command we can see the defined policy for the computer object just created on the machine.
Exporting MCX
Exporting the MCX created from the previous step is a simple one line command:
sudo dscl . -mcxexport /Computers/example > mcx-policy
This creates a file in your current working directory containing the policy that was created in Workgroup Manager which can then be used to import the policy on a new machine.
Importing MCX
The next step is creating the a package to distribute the policy, but before that, I’ll go over how the import works.
Inside the package I include a small script to create a local computer account to apply the MCX to. To create the local computer account the following commands are used:
sudo dscl . -create /Computers/localhost
sudo dscl . -create /Computers/localhost RealName localhost
sudo dscl . -create /Computers/localhost GeneratedUUID $(uuidgen)
sudo dscl . -create /Computers/localhost ENetAddress $(ifconfig en0 | grep ether | awk '{print $2}')
sudo dscl . -create /Computers/localhost IPAddress 127.0.0.1
After that, the following command can be used to import the MCX into the created computer account:
sudo dscl . -mcximport /Computers/localhost ~/mcx-policy
Packaging
The final step is creating a package installer to install the final product on machines.
In my deployments, I like to install all of my modifications in a folder I create off of the root path. However, that isn’t necessary for this, the end product resides inside directory services and thus you don’t have to leave files behind on the computer. We will use /tmp as a working directory, we will then remove our mcx file after installation.
First the script to apply the MCX to directory services and to clean up our policy file. Write the following lines into a blank text document and save as “instMCX.sh”.
#!/bin/bash
dscl . -create /Computers/localhost
dscl . -create /Computers/localhost RealName localhost
dscl . -create /Computers/localhost GeneratedUUID $(uuidgen)
dscl . -create /Computers/localhost ENetAddress $(ifconfig en0 | grep ether | awk '{print $2}')
dscl . -create /Computers/localhost IPaddress 127.0.0.1
dscl . -mcximport /Computers/localhost /tmp/mcx-policy
rm -f /tmp/mcx-policy
exit 0
After saving, run:
chmod +x instMCX.sh
to make the script executable.
Next is the Package Assembly in Package Maker. (I am using 3.0.4 in this example.)
First we create the package project. This is where you define the organization that created the package and the minimum target it can be installed on. In this case, I chose 10.5 since we make use of DSCL and it doesn’t exist in previous versions of OS X.
Next we have the basic package information. Here is where we name the package. In this example, I’ve named it “Example MCX” and I specified that the system volume is the only volume where it can be installed. /tmp is located on the system volume.
Next, we add the mcx-policy that we exported. This is added by use the + in the bottom left, or by just dragging and dropping it. The first window, is the “choice settings”. The only chance I make here is to make the choice hidden.
Next we configure the actual item the choice installs, this is the actual mcx-policy file. The only thing I change on this window is the destination (to /tmp).
On the contents tab, you can change the security attributes the file inherits when it is installed. I change it to be root/wheel rather than my credentials.
On the last page, we configure the script that was configured, in this case, it runs after the mcx-policy has been copied to /tmp.
After that, the package can be built, where it asks for a file name, and then the complete package can be used to apply MCX to a local client.