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?

Documentation on MCD is old, but not exactly out of date.  The basics of autoconfig have not changed since the age of the Netscape browser.  From trolling newsgroups, IRC and Google, I know many people use MCD, but share little about the subject. (Some do.)  Over the course of my work I wrote object prototypes, extended error reporting and generally tried to make using this bit of javascript easier. I want to reach out to the community and give a little back.

A quick run-through

Most people think of javascript as a browser technology. But, MCD has access to XPCOM, a bridge between C++ libraries and javascript, which gives the developer power to poke at Mozilla internals.  When Thunderbird (Firefox, Seamonkey, etc) launches, it executes a javascript script that makes use of a configuration API.

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.

defaultPref("news.server_change_xaction", 0 );
defaultPref("mail.migration.copyMailFiles", false);
defaultPref("network.cookie.disableCookieForMailNews", false);
   lockPref("mail.remember_password", false);
defaultPref("javascript.allow.mailnews", false);
defaultPref("mail.addr_book.lastnamefirst", 1);
defaultPref("mail.toolbars.showbutton.file", false);
defaultPref("mail.toolbars.showbutton.junk", true);
defaultPref("mail.forward_message_mode", 2);
defaultPref("mailnews.wraplength", 72);
defaultPref("mail.wrap_long_lines", true);
defaultPref("mail.collect_email_address_outgoing", true);
defaultPref("mail.collect_email_address_incoming", true);

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 .mozconfig file:

ac_add_options --enable-extensions=pref

To utilize LDAP (you do want to use LDAP, don’t you?) check the configure script for:

MOZ_LDAP_XPCOM=1

You can check about:buildconfig in Firefox to see if your build is good to go. While MCD documentation is sparse, the Mozilla Developer’s Center has plenty of build instructions.

Software distribution

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”

*zilla products first read a javascript configuration file in the lib directory called, for example, 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 moz_byteshift.pl.

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

When Firefox starts up it checks for and executes javascript a .cfg file giving it the autoconfig script’s path.

// $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.

These directives:

• 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

Now your Mozilla product will read and execute the javascript autoconfig script you indicated.  There you can set or lock application preferences using a specialized XPCOM API.  I will cover the API in a following post.