Deploying Firefox 2 within the Enterprise: Part 4

My original topic was Setting up your own update server to deploy Firefox patches. I think what I am going to do is split things up into two sections – Creating Firefox Update files and setting up a Firefox Update Server. So…

Creating Firefox Update Files (MARs)

Firefox 2.0.0.3 and 1.5.0.11 were released yesterday (March 21, 2007), and at some point in the next few days, if you use Firefox, you’ll receive a message telling you that an update is available. Alternatively, you can go to Help->Check for Updates… and Firefox will connect to an update server to check to see if there is an update available. If you deploy Firefox in a large corporation, you might want to either prevent your users from getting Firefox updates until you have certified them, or you might want to push your own updates to Firefox that include additional function. Today we’re going to talk a little about how the update process works and how you can create your own update files. In the next installment we’ll talk more about how the update process works and how to push updates to your users.

In the distant past, whenever there was an update to Firefox, users had to download a new installer and basically reinstall Firefox. To solve this problem, a new update system for Firefox was created. This system uses a file format called MAR which is short for Mozilla Archive. The MAR file contains the binary diffs for files that have changed in the update, or if the bzipped diffs are larger than the file they are patching, it contains the entire file. Whenever a new version of Firefox is released, two MAR files are created as can be seen with Firefox 2.0.0.3. The partial MAR is used to upgrade users directly from Firefox 2.0.0.2 to Firefox 2.0.0.3. The complete MAR is used if the partial upgrade could not be applied correctly or if you are on a version of Firefox that is more than one version behind.

To provide an update server within your enterprise, you’ll have to create your own MAR files based on your custom Firefox builds. Today we’re going to talk about creating those files.

Before we get started, we need to make a few fixes to our build tree. Basically the problem is that the update packaging scripts weren’t working with the MozillaBuild tools in Firefox 2.0.0.2. First we need to patch the update files. Download the patch from bug 373121 and place it in the mozilla/tools/update-packaging directory. Then type:

patch < bugmsysupdate-packaging-1.8.patch

Once this change has been made, we need to make a small change to our build tools. Go to the mozilla-build/msys/bin directory and copy the file sh.exe to bash.exe. (Future versions of MozillaBuild will have bash.exe.) Alternatively, you can just grab the latest version of MozillaBuild (1.1).

OK, now we’re ready to get started. First we need to build the diff utility we need. Go to the mozilla/obj/other-licenses/bsdiff directory and type make. Next we’re going to build the full MAR file. This is the easy part. Go to the mozilla/obj/tools/update-packaging directory and type make. Once this process completes, if you look in the mozilla/obj/dist/update directory, you’ll see the file firefox-2.0.0.2.en-US.win32.complete.mar. This is the complete MAR file we talked about earlier.

Creating the partial MAR file requires a little more work. Since a partial MAR is a diff between two versions of Firefox, we’ll need to have the two versions of Firefox we want to diff against in separate directories so that we can create the partial MAR. If you want to create a partial MAR against your own custom Firefox 2.0.0.3, you’ll need to create a new build tree and build Firefox 2.0.0.3 using the instructions in the first post. (Change FIREFOX_2_0_0_2_RELEASE to FIREFOX_2_0_0_3_RELEASE) We’re going to take a shortcut and use the files that were created as part of the official Firefox 2.0.0.3 release.

The partial MARs are created by diffing the contents of two complete MAR files. So what we’ll need to do is create two directories and unpack the complete MAR files into those directories. Let’s make two directories. For convenience, we’ll put them under the mozilla/tools/update-packaging directory. One we’ll call ff2002 and the other we’ll call ff2003. Copy the complete MAR that you created above into ff2002 and download the complete MAR for Firefox 2.0.0.3 and put it into ff2003.

In order to unpack the MAR files, there are tools in the mozilla/tools/update-packaging directory. There is a PERL script called unwrap_full_update.pl and a shell script called unwrap_full_update.sh. Either one can be used. The tools assume that mar.exe is in the path or pointed to by an environment variable. Let’s go ahead and put it in the path by copying mar.exe from mozilla/obj/dist/host/bin to mozilla-build/moztools-180compat/bin. (Ugly I know, but convenient). Now we need to go to the ff2002 directory where we put the MAR file and unpack it. The unwrap scripts work in the current directory, so running them will look something like this:

perl ../unwrap_full_update.pl firefox-2.0.0.2.en-US.win32.complete.mar

or

sh ../unwrap_full_update.sh firefox-2.0.0.2.en-US.win32.complete.mar

Once you have unpacked the MAR file, delete the original MAR file or move it out of the way so that we don’t diff it. Then do the same process for the 2.0.0.3 MAR file.

Creating the partial MAR is actually done using make, so once we’ve unpacked the MAR files, we’ll need to go back to the mozilla/obj/tools/update-packaging directory. There are a few environment variables we need to set in order to tell the partial MAR packaging what to do.

SRC_BUILD_ID and DST_BUILD_ID
These names aren’t totally accurate. They are actually the version numbers of the two builds. They will be used to name the output MAR file. For our builds, they are 2.0.0.2 and 2.0.0.3
SRC_BUILD and DST_BUILD
These actually point to the locations of the files we just unpackaged.

So:

SRC_BUILD_ID=2.0.0.2; export SRC_BUILD_ID;
DST_BUILD_ID=2.0.0.3; export DST_BUILD_ID;
SRC_BUILD=../../../tools/update-packaging/ff2002; export SRC_BUILD;
DST_BUILD=../../../tools/update-packaging/ff2003; export DST_BUILD;

Then type make partial-patch.

And that’s it! In the mozilla/obj/dist/update directory, you’ll see the file firefox-2.0.0.2.en-US.win32.partial.2.0.0.2-2.0.0.3.mar. Which is the partial MAR between Firefox 2.0.0.2 and Firefox 2.0.0.3.

Obviously in this post I chose to place files in certain locations that made it easier to describe the process. With the information I have presented, you might find a way to simplify this process. If you have better ideas on how to do this stuff, please let me know. I’m going to look at making changes to the build process to try to simplify this.

Next time we’ll talk about how to get those files to our users.

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 *

5 thoughts on “Deploying Firefox 2 within the Enterprise: Part 4

  1. > So what is the complete MAR actually? All changes from the last major release?

    The complete MAR is an actual complete install of the browser. So when a complete mar is installed, it’s as if the entire browser was installed.

  2. Isn’t the problem with this approach to updating Firefox that the application specific internal “update agent” runs as the user?

    In most corporate networks this is not what you would want as your users would not have access to %ProgramFiles% and any machine-level entities.

    Of course you might have thought of that already, so I’m waiting to see if you have any tricks up your sleeve in the next part 😉

  3. Jan,

    I have been thinking about this myself. I was wondering if there was a way to force Firefox to load and do the check for update, because you could potentially host the MAR locally and then create a service or even startup script which loads Firefox in the System context and then it would do the update.

  4. As soon as I get few minutes I’m going to try running this as a GPO script applied to the computer. That should get around the user account restrictions.