Blog

This is such a hack and is posted mainly for academic reasons

Here is a quick hack for pushing out environment variables via MCX ( Managed Preferences ), This only will work with 10.4 and its a silly mishmash of stuff that is totally unsupported which of-course makes it the best kind of hack.
First a little background on the file that allows us to do this (environment.plist) curiosity of Apple.

From page 24 of the Command_Line_v10.4_2nd_Ed[PDF]

“Another way to set environment variables in Mac OS X is with a special property list in
your home folder. At login, the computer looks for the ~/.MacOSX/environment.plist
file. If the file is present, the computer registers the environment variables in the
property-list file.”

Here is the official document for configuring this file as well.

So thats a property list, and MCX can push out property list files right?
Well yes it can but only to places like ~/Library/Preferences/ and the other preference domains.
So this is where this hack doesn’t allow you to “push” these items with out a local step, which is to sym link either the file or the directory (The latter shown here ). As always feel free to click the code.
ln -s "$HOME/Library/Preferences" "$HOME/.MacOSX"
now this alone would tell you that you can’t just go and push this out without modifying each users home folder, and logic would say that if you going that far you might just generate a rc file for them but keep reading for some more interesting ideas.

To actually implement this you can use Preference Manifests, If your not familiar with Preference Manifests[PDF} , they are a way of pushing out preferences of 3rd party and Apple applications (10.4+) not already listed in Workgroup Manager, though not a lot of Applications sans Safari.app “Officially” support them ( and its not even 3rd party!). When you get right down to it an application does not have to support preference manifests to get some benefit from them. The basic premise is, as if you where to drop a preference in to say ~/Library/Preferences/org.wallcity.monkey every login, If the application (Monkey.app) actually supported this preference it would be able to “grey” out content so that user would see feedback for an “always” on setting. But even if your application doesn’t support this you can typically push these preferences out and they will work as a “often” preference, meaning that users can change the preference during the session but all changes will be reset on next login, just as if you replaced the preference file eveytime you logged in to you account.

Once you have sym linked your ~/.MacOSX folder you can then generate a default preference, by using, well “defaults”:

defaults write "$HOME/Library/Preferences/environment" 'MCXFOO' 'BAR'

Note my *nix snobby use of single and double quotes.

Now that you have your default preference you can upload it your directory domain using Work Group Manager’s details section, and then manage for per User, WorkGroup, or Computer List.

The “Details” tab is right next to the “Overview” tab in Workgroup manager, when your in “Preferences” mode.
You can the just click “add” and navigate to your ~/Library/Preferences/environment.plist file. From then on you can “edit” these varibles using WGMRs quaint version of a property list editor showed in the screen shot below.

You can view the variable by using echo:
echo $MCXFOO or if you don’t see feedback you can “trap” the variable to see if its broke.
echo ${MCXFOO:?"Whoops didn't work"}
While this won’t quite work for $PATH as the rc (.bashrc, .bash_profile) files will override the environment.plist values, it does present the interesting idea that you could have scripts that keyed their values off of MCX ,here is an example of how to do that with applescript’s
system attribute:

set MCXFOO to (system attribute "MCXFOO") as string


display dialog MCXFOO

For me a practical example of this would be that while you can push out proxy settings via MCX ,which work fine and dandy for UI applications like Safari.app applictaions like curlthat don’t pull their settings that way and will be unable to connect (or just bypass the proxy) ,in contrast using the method you could store an environmental variable such as “ALL_PROXY” (man curl) in a central place. While the sym linking lowers the coolness factor, its a one time act and could be added to the user template for new users. This would mainly lend its self to making changes to these varibles, as you could change it centrally and not have to push out a new .bashrc file everytime you wanted to add a variable.

Ryan Faas has a good overview on MCX settings in general here

If would you like to contact me with comments or inaccuracies about this article, feel free but support requests will be ignored unless you would like to sign up for Iris Professional Services service. Thanks