What is MCD?
MCD (aka AutoConfig) is a script used to programmatically configure Mozilla products such as Firefox and Thunderbird in the enterprise for multiple users. Part of my job is to ensure 33,385 people have the right settings to check their email and browse the web. Centralizing their set up with autoconfig removes the burden from the user.
Why write about it?
A quick run-through
The autoconfig sets preferences exactly as a user would using
about:config. It can also render preferences immutable, locking them down according to corporate policy. When I inherited the script it was simply a long string of preference directives with a little LDAP voodoo.
Not the easiest thing to grok.
After Thunderbird executes the autoconfig it starts up normally, applying saved user preferences.
defaultPref settings are overridden by user preferences, but
lockPref are not.
If you want to turn on a proxy server and force SSL in Firefox for every user it becomes easy to do:
// Set http proxy to your.server.domain lockPref("network.proxy.http", "your.server.domain"); // Require and lock SSL lockPref("network.proxy.ssl", true);
Details, implementation details
There are a number of things required to get MCD working.
Build *zilla (Firefox, Thunderbird, etc) with support
Your Mozilla product needs to be built with pref extension support. Add this to your
To utilize LDAP (you do want to use LDAP, don’t you?) check the configure script for:
I work in a Solaris world. Servers and desktops mount a shared NFS directory from a network of servers housing some 735 programs, including Firefox & Thunderbird. The directory is mounted read-only so average users are not tempted to twiddle with the software. Although I wrote this paper from a unix perspective the implementation will work in a Linux, Windows, or MacOS environment. Mounting a shared software repository makes the system robust, however MCD works in a network of stand-alone desktops.
Breaking .cfg “encryption”
firefox.cfg. In the beginning-time, Mozilla developers chose to ROT-7 encode the file, obscuring its contents from users. When Netscape 7 came out, they did away with ROT-7 in favor of ROT-13. Many Firefox and Thunderbird .cfg files are still encoded this way using
The rotary encoding is controlled by a setting in
$MOZ_LIB_DIR/greprefs/all.js. At packaging time I patch this file, setting encoding to 0.
// ROT-encoding is bad, mmmkay? pref("general.config.obscure_value", 0); // for MCD .cfg files
This tells *zilla not to ROT-decode the .cfg file.
This shadowy file mojo likely came from the day of stand-alone workstations where users had root access and the software maintainers wanted to have just a little control over Netscape preferences. Hiding the configuration file’s location gives you the illusion of control.
Now, the .cfg file is on a read-only mounted partition and nobody on the system has super-user level access. There is little danger of a user skirting corporate policy by turning off autoconfig.
Pointing *zilla at the autoconfig
// $MOZ_LIB_DIR/firefox.cfg // the output from the obscuration is still more readable than MORK! lockPref("autoadmin.global_config_url","file:///path/to/firefox,v3.0.17/share/autoconfig.js"); lockPref("autoadmin.offline_failover", true); lockPref("autoadmin.refresh_interval", 60);
I left the MORK comment line in there to remind me how far we’ve come already.
- Set the autoconfig url
- Tell *zilla to automatically fail over to offline mode if online browsing fails
- Re-fetch the autoconfig file every 60 minutes
Any URL *zilla understands is a valid value for
autoadmin.global_config_url meaning you could house the autoconfig script on a web server.
Away you go