Firefox Hacks [Electronic resources] نسخه متنی

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

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 Paths

Interchanging file paths and URLs can be confusing. Here are a few
noteworthy Firefox items:

Both UNC pathnames, such as
\\server\share\subpath, and drive pathnames,
such as c:\tmp, are supported.

Environment variables such as %APPDATA% are
respected and used, even if mapped to other locations by Active
Directory or other mechanisms.

Paths put in Firefox configuration files cannot
include %FOO% syntax. The only macro expansion
available is [ProfD], which is used only for
Thunderbird email.

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

That is five forward slashes in the preceding URL, which is different than in Internet Explorer.

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 Install

The 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:

http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.0/win32/en-US/Firefox1.0.zip

3.8.3. Imaging an Instance of Firefox

If 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 Install

This section provides three tactics for customizing the
install.

h5

The 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:

http://lxr.mozilla.org/mozilla/source/browser/installer/windows/7zip.bat

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:

Modifying install.js (an XPInstall script) to
add registry hacks or extra files

Modifying bin/defaults/pref/firefox.js (a
preferences file) to add preferences

3.8.4.2 During install: customize user profile creation

A 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 login

A 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.