A challenge with software
Managing software for thousands of users presents a formidable challenge to the system administrator. Publishing corporate policy, using standard environments and providing clear end-user documentation helps. However, it doesn’t beat automatically doing it right. This is the power of MCD autoconfig.
First, a quick rehash of my world. I work in a Solaris shop with over 33,000 users. Supported users log into a shared Sun Ray server or their personal workstation which mounts a shared NFS directory. That directory houses the software I support along with about 700 other programs.
While this post is unix-centric, other operating environments that launch managed software can make use of MCD. See the introductory post for a little more detail.
Mozilla Preference System
Firefox and Thunderbird use a simple preference tree to store all configuration options. Leaves of the tree are strings that store the option’s value. For example, the preference
browser.startup.homepage is a string containing the URL(s) of Firefox’s homepage.
mail.forward_message_mode contains an integer indicating how Thunderbird should forward email messages (inline or as an attachment). You can find every available setting and their values in the config editor for Thunderbird and about:config in Firefox.
When a user changes his or her preferences the changed values are stored in a file called
prefs.js in their home directory. On my MacOS laptop, this is
The Application Programming Interface
MOZILLA_LIB_DIR/defaults/autoconfig/prefcalls.js. I will talk about the most useful in this post and cover the LDAP parts of the API later.
// Used most often
function defaultPref(prefName, value);
function lockPref(prefName, value);
// Sometimes used
function displayError(funcname, message);
defaultPref() and lockPref()
These two functions perform the bulk of work in an autoconfig script. A default preference setting may be overridden by the user, but a locked preference may not.
getenv() and displayError()
getenv() acts as you would expect from its name. This function returns the value of an environment variable. I use it to get
displayError() pops up an error message. It is useful for debugging, but a user should rarely see it.
Putting it all together
We now have some basic building blocks to configure thousands of users. Here is a look at a simple autoconfig.js file for Firefox. These settings will apply to every user.
// Catch errors
// Set downloads directory to a folder on the user's desktop
var download_dir = getenv("HOME") + "/Desktop/Downloads";
// Length of Time to Remember Visited Pages For (Days) - 30
// Automatically Add 'www.' and '.com' to the Location if a Web Page is Not Found - Enabled
// Lock the cache size to 60MB for shared performance
// fix memory usage with lots of tabs
// Set animated images to loop once
displayError("autoconfig.js failed", e);
Learning preference strings
Finding the right preference setting or combination of preferences that change the program’s behavior sometimes presents a challenge. I use the About:config entries page on the Mozilla Zine knowledge base. That page also has a pointer to three more resources.
Another technique is to watch your own
prefs.js file for changes when you twiddle settings. Save a copy of prefs.js before flipping a preference. Immediately quit the application after the change and diff the two files.
[Edit: I wrote up an entire post on this subject.]
Using LDAP and more fun things to do
In following posts I will cover retrieving information from LDAP, better error reporting, reading local files like
$HOME/.printers, and simplifying Thunderbird email account management. Stay tuned.