Deploying Firefox 2 within the Enterprise: Part 1

I’m actually going to take a break from Operator for a few days to talk about deploying Firefox 2 within the Enterprise. Note that when you deploy Firefox within an enterprise or organization, you can customize Firefox without worrying about Mozilla trademark policies. Just be sure your customized Firefox is not deployed outside of your enterprise or organization.

We’re going to cover:

  1. Building a custom version of Firefox
  2. Adding Enterprise specific customizations to Firefox
  3. Creating a Firefox installer
  4. Setting up your own update server to deploy Firefox patches

My assumptions are going to be that you actually need to build Firefox for your own purposes, not that you can simply use a prepackaged build from Mozilla. Also, I’m going to focus on Windows. If you don’t need to actually build Firefox, you can use the CCK Wizard to customize Firefox (we’ll talk more about that in part 2) and the Firefox Release Repackager to repackage it. The Firefox Release Repackager is Mac only right now, but I’ve sent Ben a patch to make it work on Windows as well.

Setting up a Firefox build environment

The Windows Build Prequisites page at MDC has the information on setting up a build. In order to recreate an official build, you’ll need to have Microsoft Visual C++ version 6. Unfortunately, this is not available anymore, so you might have to get it from eBay. I can’t say enough about the MozillaBuild package that bsmedberg put together. It makes setting up a build really easy.

Building Firefox

Once you have setup the build environment, it’s time to get the code and build Firefox. Create a directory in which to check out your code and then change to that directory:

mkdir firefox
cd firefox
Checking Out the Code

Now we need to check out the code. We’re going to checkout Firefox 2.0.0.2.

cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co -r FIREFOX_2_0_0_2_RELEASE mozilla/client.mk
cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co -r FIREFOX_2_0_0_2_RELEASE mozilla/browser/config
.mozconfig file

Now we’re going to go into the mozilla directory and create a .mozconfig file. This file specifies the configuration options for the build. Here’s what ours looks like:

. $topsrcdir/browser/config/mozconfig

mk_add_options MOZ_CO_TAG=FIREFOX_2_0_0_2_RELEASE
mk_add_options MOZ_CO_MODULE=mozilla/other-licenses/bsdiff,mozilla/tools/update-packaging

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj

ac_add_options --enable-update-channel=release
ac_add_options --enable-official-branding
ac_add_options --enable-optimize
ac_add_options --disable-debug
ac_add_options --disable-tests
ac_add_options --enable-static
ac_add_options --disable-shared
ac_add_options --enable-svg
ac_add_options --enable-canvas
ac_add_options --enable-update-packaging
ac_add_options --enable-extensions=default,-inspector

Most of this file you don’t have to worry about, but let me explain a few pieces:

mk_add_options MOZ_CO_TAG=FIREFOX_2_0_0_2_RELEASE

This sets the tag we will be checking out from (not really needed since we checked out a makefile that had the corresponding tag, but we’ll put it there just in case)

mk_add_options MOZ_CO_MODULE=mozilla/other-licenses/bsdiff,mozilla/tools/update-packaging

This specifies additional code we need to check out in addition to the base Firefox code. These two directories will be needed when we do update packaging.

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj

This specifies that we want to build our code in an “obj” directory. This means that the output code is separate from the source code, so if we want to easily remove the output code, we can just remove the obj directory.

ac_add_options --enable-extensions=default,-inspector

This specified that we do not want to include the DOM Inspector in our build. This is going to be our “customization” for this build, although if this is really all we wanted to do, there are easier ways.

Incidentally, the way we knew most of these options, was by typing about:buildconfig in a Firefox 2 build. This gives us the official list of build config options.

Building a Localized Firefox

There’s a possibility you might want to build a version in another language. For instance, if you wanted to build the French version of Firefox, you could add the following to your .mozconfig file:

mk_add_options MOZ_CO_LOCALES=fr
mk_add_options LOCALES_CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org:/l10n
ac_add_options --enable-ui-locale=fr

Final Steps

In order to build “official” builds, you must set two environment variables in your build environment:

MOZILLA_OFFICIAL=1; export MOZILLA_OFFICIAL;
BUILD_OFFICIAL=1; export BUILD_OFFICIAL;

If you don’t set these, your builds will have a build ID of 00000000.

Now we’re ready to build. Go to the mozilla directory and type:

make -f client.mk

And wait patiently until the source code is pulled and the build is finished.

If you need to apply patches, you’ll need to pull and build the code separately:

make -f client.mk pull_all

Now you can any apply patches or changes that you want in your custom version of Firefox. This might be a bugzilla patch that is not included in the default Firefox, or other changes. Then:

make -f client.mk build_all

In our next installment, we’ll go over customizing and packaging an installer.

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

Your email address will not be published. Required fields are marked *

14 thoughts on “Deploying Firefox 2 within the Enterprise: Part 1

  1. I tried to get FireFox to previous company where I worked in, but they required that all browsers have proxy settings locked. Since I didn’t know how to do it, and didn’t have time to investigate, I was locked in to IE. Few days ago I saw a post in another blog that solved the same problem. http://www.progbox.co.uk/wordpress/?p=258
    I hope it helps someone else.

  2. If this is targeted at people who aren’t terribly familiar with cvs/software development or the Mozilla build system, it might be helpful to clarify that they will only be able to apply patches, etc., once the source is checked out, as the position of that paragraph might lead to people attempting to apply patches to an (almost-)empty tree 😉

    You might instead suggest make -f client.mk checkout to pull the source, then apply patches, and then make -f client.mk build to do the actual building (or re-position your “pull_all” and “make_all” note that’s currently at the end).

  3. [quote]
    ac_add_options –enable-extensions=default,-inspector

    This specified that we do not want to include the DOM Inspector in our build. This is going to be our “customization” for this build, although if this is really all we wanted to do, there are easier ways.
    [/quote]

    If this is all I want to do, where would I go to find the easier way of doing this? My only goal (currently) is to quietly install Firefox to the enterprise without either of the 2 default add-ons. I have been experimenting with the INI option during the install but have had little success with removing the DOM and QFA from the installation.