|
|
Hack 28. Prepare Firefox for Wide Deployment
Choose from several strategies for rolling out Firefox across an enterprise. This hack describes how to deploy Firefox when there's a large community of users to support. It covers changing Firefox from the standard install bundle provided by the Mozilla Foundation to a set of files laid out correctly for the user. These files can be deployed to a workstation, a server, or both. If profile files are stored on a server, you can improve performance by moving the location of the Firefox disk cache back to the local disk [Hack #22] . It also makes sense to put the profile somewhere separate from any Windows user profile that's also on the server (i.e., any roaming profile), because you don't want Windows replicating the Firefox profile information down to the client when it logs on, as it does for everything else in the Windows user profile. If the base install files (executables) are stored on a server, only the registry.dat file (Windows) needs to be on the local client, and even that can be faked by mapping %APPDATA% to a server location via Active Directory. It is also possible to arrange installation so that Firefox can be centrally managed after it is installed [Hack #29] . It makes sense, however, to leave Firefox's automatic update system on [Hack #13] . It's too much work to hand-manage patches from http://update.mozilla.org. You might as well let Firefox do it as though it were a virus checker. At the time of writing, the Mozilla Client Customization Kit (CCK), Mozilla's equivalent to Microsoft's Internet Explorer Administration Kit (IEAK), is still in development and unusable. Recommended reading for smaller stopgap techniques can be found at http://www.alain.knaff.lu/~aknaff/howto/MozillaCustomization/index.html. Alain's small tools make reading and writing Mozilla registry files easier to handle. You can also graphically display the registry with an extension. 3.8.1. Getting Leverage on Windows File PathsInterchanging file paths and URLs can be confusing. Here are a few noteworthy Firefox items:
If a server is described by a UNC, files on that server can be addressed either by a path, a mapped drive, or a URL. This path: \\server\share\dir\dir2\filename when mapped to X: is equivalent to this path: X:\dir\dir2\filename or to this URL: file://localhost///server/share/dir/dir2/filename or, more briefly, to this URL: file://///server/share/dir/dir2/filename
The mapped drive can also be stated as these URLs: file://localhost/X|/dir/dir2/filename file:///X|/dir/dir2/filename file:///X:/dir/dir2/filename In general, there is little need for URL versions of UNCs when configuring Firefox. They cannot be put into web pages as links anyway, unless standard security restrictions are overcome. The most reliable format for configuration text is simple drive paths: X:\dir\dir\filename 3.8.2. Using the Standard InstallThe standard Firefox install might be enough for you. Write up a set of install prompt responses as a documented procedure and publish it. Get users to download Firefox from http://www.mozilla.org or from your server staging area, and then follow the bouncing ball. In the case of a normal install, there's little state retained by the browser that's business critical, although use of POP email via Thunderbird can complicate matters. By itself, Firefox can be treated in a more cavalier manner than complex tool installations like Word or Office. Except for bookmarks, there's little that's too precious to lose. There is an alternative distribution you can use instead of the standard install. A non-self-extracting, simple ZIP file of Firefox install files is available here: 3.8.3. Imaging an Instance of FirefoxIf you are building user workstations from scratch, you can build an installed version of Mozilla as part of a standard disk image, perhaps with a tool such as Norton Ghost. This image will work, but it will have a slight weakness. Each Firefox profile is salted with a random name, even the default profile, to prevent villains from guessing it and using server-based attacks. The name is calculated randomly at profile creation time. If all of your Firefox installations are derived from the one image, that salting will be the same across the organization and will be well known internally. That ruins salting as a defense against internal villains who are collecting user data through a server exploit. It also decreases the security margin against external villains. It is an obscure matter, however, and it is irrelevant if access to local disks is otherwise easy. Using the registry-editing tools noted earlier, it's possible to remove salted names from the profile's path completely. Just modify registry.dat so that the profile paths point somewhere else and copy them to that location. Update any preferences dependent on the salt. 3.8.4. Customizing the InstallThis section provides three tactics for customizing the install. 3.8.4.1 Preinstall: change the install bundleThe Firefox Setup 1.0.exe file is a 7-Zip (http://www.7-zip.com) self-extracting executable that has been squeezed into a smaller file with UPX (http://www.upx.org). You can hack it. The script responsible for constructing it is located here: At the moment, it looks like this, but beware that it's just part of a larger bundling process: cd 7zstage 7z a -t7z ..\7z\app.7z *.* -mx -m0=BCJ2 -m1=LZMA:d24 -m2=LZMA:d19 -m3=LZMA:d19 -mb0:1 -mb0s1:2 -mb0s2:3 cd ..\7z upx -9 7zSD.sfx copy /b 7zSD.sfx+app.tag+app.7z SetupGeneric.exe cd .. The + syntax in copy is used to concatenate three files into one final file, in the style of Unix's cat(1). 7z (7za on Linux) can be used to unpack and repack this final self-extractor. You can unpack either a UPX-squeezed or UPX-unsqueezed copy. If you repack, the file content order must be preserved, so do a test repacking before making any modifications. One simple modification is to change the unpacked config.ini file. It's human readable, heavily documented, and easy to follow. More generally, you must change the unpacked browser.xpi file. It's in plain ZIP format, so it needs to be unpacked once more. Inside the file, easy changes include:
3.8.4.2 During install: customize user profile creationA small Windows program called mozptch can be used to customize the construction of Firefox profiles. Once initial customization is complete, it can be repeated in a fully automated way. The process is involved and takes some study. Read about it at http://mozptch.mozdev.org/. Another in-process alternative is to exploit the preference-locking system [Hack #23], which allows scripts to retrieve details from an LDAP server at startup time and use those details to set preferences. That's a good way to acquire user login details that can be used to construct server pathnames. 3.8.4.3 Post-install: overwrite files on loginA brute-force approach that ensures Firefox profiles and Mozilla registries are behaving properly is to dump down copies of required files to the client workstation when the user first logs in. This covers all Firefox profile files and the registry.dat file, leaving only the Window registry to manage. This command will do that last part: regedit /s file.reg where file.reg is an exported Windows registry fragment to be reapplied. |
|
|
