Novell is now a part of Micro Focus

Distributing the Mozilla 1.x Web Browser Using Novell ZENworks for Desktops

Articles and Tips: article

Anders Gustafsson
Engineer, CNE, ASE
Novell Support Forum SysOp
Anders.Gustafsson@pedago.fi

Thanks to all my colleagues at the Novell Support Forums for their continued support, and especially to Shaun Pond for testing, feedback, and proofreading.

01 Jan 2003


This AppNote shows you how to use Novell's ZENworks for Desktops to distribute a locked down, customised version of the Mozilla 1.x Web browser to Windows workstations on your networks.

Note: This AppNote retains the British spelling used by the author.


Topics

application distribution, Application objects, Mozilla, Web browsers, workstation management, ZENworks for Desktops

Products

ZENworks for Desktops, Mozilla 1.x

Audience

network administrators

Level

intermediate

Prerequisite Skills

familiarity with ZENworks for Desktops

Operating System

n/a

Tools

AXTClean (Novell CoolSolutions for ZENworks)

Sample Code

no

Introduction

Novell's ZENworks for Desktops has enjoyed great success as an efficient way to distribute and manage applications in a network environment. Using the snAppShot utility that comes with ZENworks, you can create a template file that contains all of the modifications that must occur at a Windows-based workstation in order to run a given application (executable files, Windows registry entries, *.INI files, and so on). From this template, an Application object is created in Novell Directory Services (eDirectory). This object is a logical representation of the application. Users, groups, or containers can be associated with the Application object to determine who can access and run the application.

This AppNote shows how you can use the power of ZENworks to provide a "just-in-time" installation of the Mozilla Web browser with an extremely small local footprint. In addition, you can give your users roaming profiles, something that is not available in standard Mozilla 1.x. You can also provide the same profile for Windows 9x and NT/2000, something Windows roaming profiles cannot do alone.

With some tweaking, the profile thus stored on the network could also be shared by computers running Linux or MacOS, but that is beyond the scope of this AppNote. Send an e-mail to novell_research@novell.com if you would like to see an AppNote covering this.

The procedures described in this AppNote have been tested with ZENworks for Desktops 2.0, 3.2, and 4 running on Windows 95, 98, and 2000. The release of Mozilla used for testing was the Mozilla 1.1 English version. However, since there is no language-specific information in the Application object or the configuration files, you can move the files between different language versions of Mozilla.

A Little Background

Before getting into the details of creating and configuring the Mozilla Application object for ZENworks, it is helpful to understand a little background information.

Why Mozilla?

People often try to convince me that the browser wars are over and that Microsoft Internet Explorer (IE) has won out over all the other contenders. I disagree. True, you might see a very high percentage of IE hits on a Web server, especially if the sites are designed in such a way as to force people to use IE to access it. But such design is contrary to the entire idea of the World Wide Web. A well-designed Web site should work with any HTML-compliant browser.

Other issues to consider are security and administration. Tracking and following up on the almost-weekly Microsoft security bulletins for IE can be an overwhelming task, especially if it involves replacing local files. A less complex, stripped-down browser like Mozilla or Opera could very well be the ticket if you want a more secure environment that is easier to manage.

The solution proposed in this AppNote provides roaming access to the Mozilla browser, with just one or two files installed locally. The rest of Mozilla runs from the network. This makes it ideal for environments such as schools and universities. As an added benefit, the granularity of the Mozilla installation lets you select just the tools you need. For example, if you don't allow newsgroups, simply don't install that part of Mozilla. The same applies to other browser functions such as e-mail, Web design, and Java debugging.

Looking Back

Two previous AppNotes, entitled "Distributing Netscape Navigator Using Novell's ZENworks" (February 1999) and "Distributing Netscape 4.5 and Higher Using Novell's ZENworks" (December 1999) described procedures that have worked well for thousands of installations of Netscape. With the recent release of Mozilla 1.x, it is now time to adapt these procedures to the Mozilla browser. If you have not read these previous AppNotes, I suggest you do so before continuing with this one. They can be found online at the following URLs:

http://support.novell.com/techcenter/articles/ana19990202.html

http://support.novell.com/techcenter/articles/ana19991205.html

Assumptions

As in the previous AppNotes, it is assumed that the browser application is installed under the F:/Program directory and that all users have drive P mapped to their home directories. However, you can easily adapt the Application object to other paths if need be. Note that if you change drive P to something else, you need to use the Mozilla Profile Manager to create a new registry.dat, copy that to the SOURCE_PATH, and adjust the RANDOM_DIR macro accordingly (this will be explained in more detail later in this AppNote).

Note: The TARGET_PATH is not used, so it can either be set to the same as the source path or left blank.

Mozilla Configuration Files

Several changes have been made to the Netscape-branded browser and the open-source Mozilla 1.x release since the previous AppNotes were written. This section summarizes those changes.

Netscape 4.5 and later versions use a "netscape registry," a hashed file that is very inconveniently located in the Windows directory. This file contains a pointer to where the actual user profile is. Additional lockdown of the browser is done with a hashed configuration file (NETSCAPE.CFG) in the Netscape program directory.

With Mozilla, the local registry also exists, but it is called "registry.dat" and it is placed in the "Application Data" directory, a directory that normally is part of the roaming profile. All you need to do is to push down this single file to %*APPDATA% and make sure it points to a known location.

Note: Some releases of Windows 95 do not support the concept of an Application Data directory. In this case, Mozilla stores the file under %*WINDIR%\Mozilla. If you are supporting Windows 95 in your tree, I recommend that you create a separate Application object for Windows 95.

Global settings are in the prefcalls.js file, located in the program directory.

The user profile is stored under ..\Mozilla\profiles\<name>\<xxxxx> where name is the name you enter when creating the profile and xxxxx is a random number Mozilla adds for some unknown reason.

Individual settings are put into a Javascript file called "user.js", located in P:/Mozilla/Users/default/xxxxx. This file is then changed by the Novell Application Launcher (NAL) to reflect the individual settings of each user. The syntax and layout of this file is almost identical to the "prefs.js" file described in the earlier AppNotes. The same settings can be made in both prefcalls.js and user.js, but for sanity's sake I recommend that you keep all settings that are global for all users in prefcalls.js and put only those items that change per user in user.js.

I have chosen P:\Mozilla as the profile directory, where drive P is mapped to the home directory of the logged-in user. I then relocate the Mozilla profile to this directory instead of storing the entire profile under Application Data.

To overcome the problem with the random location, I simply push down a copy of registry.dat where the location is known. There will still be a random string in the profile, but it will be the same random string for all users.

You can also "hack" registry dat to change the location and get rid of the random element. Just take care not to remove the Hex00 right in front of the path, and to not overwrite the Hex04 after the path. (I myself would not use this method for fear of breaking some other aspect of Mozilla.)

Mozilla and the Client Configuration Kit

As mentioned previously, Netscape 4.x and later versions use a hashed file named NETSCAPE.CFG to lock down global settings. To manipulate this file, you need the Netscape Client Configuration Kit (CCK). A similar project is planned for Mozilla (that is, a GUI configuration editor), but that project is currently in limbo. Mozilla does not read a NETSCAPE.CFG file created by the Netscape 4.x CCK, even though it is supposed to. Since other means exist for lockdown, I have not pursued this issue further.

Preparing the Mozilla Configuration Files

All Mozilla lockdown is done in the prefcalls.js file, located in ..\Mozilla\defaults\ autoconfig. To accomplish the level of lockdown you need, edit this Javascript file with a text editor such as Notepad and add lockPref() commands, as shown here:

//

// Startpage

//

lockPref("browser.startup.homepage", "http://www.pedago.fi");

//

// Proxy addresses. Need to change them all...

//

lockPref("network.proxy.type", 1);

lockPref("network.proxy.http", "10.0.20.5");

lockPref("network.proxy.http_port", 8080);

lockPref("network.proxy.ssl", "10.0.20.5");

lockPref("network.proxy.ssl_port", 8080);

lockPref("network.proxy.socks", "10.0.20.5");

lockPref("network.proxy.socks_port", 8080);

lockPref("network.proxy.ftp", "10.0.20.5");

lockPref("network.proxy.ftp_port", 8080);

lockPref("network.proxy.gopher", "10.0.20.5");

lockPref("network.proxy.gopher_port", 8080);

// Proxy exclusions

lockPref("network.proxy.no_proxies_on", "10.0.1.4");

Since this file is located in the program directory, there is no way for users to modify it.

There is one added complexity though. By default, Mozilla will not read this file. To activate the code that reads the settings in this file, you need to add one line to the all.js file, located in ..\defaults\pref:

pref("general.config.filename", "netscape.jsc");

This is really supposed to be the support for a file created by the Netscape CCK, but to have autoconfig work, you just need a file there. Mozilla does not appear to care about the contents of the file. (A sample netscape.jsc file is supplied with the Application object you can download for this AppNote.)

You can customise almost every aspect of Mozilla through prefcalls.js; I suggest you take the time to go through all the options and familiarise yourself with them. Unfortunately, the documentation is somewhat lacking. There is some info on http://www.mozilla.org and at Web sites like http://www.vorstrasse91.com/ moztips/mozillaprofiles.html and http://www.geocities.com/pratiksolanki/. However, the best reference is the help included with Mozilla itself. Simply type "about:config" in the address bar and Mozilla will list all allowed options and their settings. It will also show what is locked in red.

Figure 1 shows an example of the "about:config" information you will see.

Figure 1: Mozilla's about:config shows configuration information.

Once all these files are set up, this is what happens when a user starts Mozilla:

  1. Mozilla.exe looks for the registry file in the Application Data directory, finds it, and reads it.

  2. Based on information in that registry file, Mozilla locates the user's profile data, which is located in the HOME_DIRECTORY so that it can roam.

  3. Mozilla.exe reads the prefcalls.js file for global settings.

  4. The user.js file is dowloaded to the user's profile directory every time the program is started, and the user's personal data is inserted at that time.

  5. The user now runs a locked down, personalised copy of Mozilla.

The best way to obtain troubleshooting information about this procedure is to use about:config. As shown in Figure 2, you can easily see what the settings are and where they came from.

Figure 2: Mozilla's about:config information can be used for troubleshooting.

Creating the Mozilla Application Object

This section describes the process of creating the Application object for Mozilla. A pre-packaged archive with the actual Application object and additional files is available at http://www.pedago.fi/products/utils/MozillaZEN.zip, for your convenience. These instructions assume you already have ZENworks for Desktops installed on your network.

  1. Download Mozilla 1.x from http://www.mozilla.org.

  2. Start ZENworks' snAppShot and perform the initial discovery on a Windows workstation. I used a Windows 98 PC for this. You need to set SnAppShot to watch drive P in addition to C.

  3. When prompted to, run the Mozilla installation program. Select F:\Program\Mozilla as the target directory. Then select what parts of Mozilla to install. Allow the installation to complete.

  4. If Mozilla starts automatically, exit the program.

  5. Start MOZILLA.EXE with the "-ProfileManager" option to bring up the Profile Manager. Remove all profiles and create a new one, name it "default", and point it to P:\Mozilla.

  6. Exit Mozilla and resume the snAppShot.

  7. Use the AXTClean snAppShot cleanup utility (available from http://www.novell.com/coolsolutions/zenworks) to clean up the AXT file. Then create the Application object.

  8. Add the information necessary to manipulate the users' personal data.

Configuring the Mozilla Application Object

Once you have created the Application object for Mozilla, use Novell's NetWare Administrator (NWAdmin) or ConsoleOne utilities to modify the object's properties as described in the sections below.

Application Run Options

The Run Options > Application settings (see Figure 3) are to ensure that Mozilla starts with your customised profile in case there is more than one profile available.

Figure 3: The Run Options > Application screen.

For more information on all available start-up options for Mozilla, see http://www.mozilla.org.

Scripts

The setting shown in Figure 4 (made from the Scripts tab) is a security precaution. Since the cache is local, you want to make sure it is empty when users exit Mozilla.

Figure 4: Specifying a batch file to run after termination.

The DELCACHE.BAT file looks like this:

echo off

echo Clearing the local cache...

echo Y|del c:\netscape\cache\*.*

If you want to do this more elegantly and not have an ugly DOS window pop up, you could write a small Windows application to do this.

Registry Settings

Figure 5 shows some basic registry settings to tell Windows what you have installed and where.

Figure 5: The Distribution Options > Registry screen.

Be sure to check the "Track distribution per user" and "Distribute Always" boxes.

Application Files

Under the Distribution Options > Application Files tab (see Figure 6), you ensure that all the local files needed are copied. You also make sure that the local cache directory exists, as well as the directories you need in the users' home directories.

Figure 6: The Distribution Options > Application Files screen.

Be sure to check the "Track distribution per user" and "Distribute Always" boxes.

Note: I have created a macro for the random directory name to make later changes easier. I will discuss this further under "Macros" below.

Naturally, you want to make sure that all users have the same registry.dat file. Figure 7 shows the necessary settings.

Figure 7: Setting to be able to push down the registry.dat file for each user.

Be sure to check the "Track distribution per user" and "Distribute Always" boxes.

In the program directory is a skeleton user.js file, which looks like this:

user_pref("network.hosts.smtp_server", "OUTGOINGMAILSERVER");

user_pref("network.hosts.pop_server", "INCOMINGMAILSEVER");

user_pref("network.hosts.nntp_server", "NEWSSERVER");

user_pref("mail.smtp_name", "MAILSERVERUSER");

user_pref("mail.identity.organization", "ORGANIZATION");

user_pref("mail.identity.reply_to", "USERSREPLYTOADDRESS");

user_pref("mail.identity.username", "USERSFULLNAME");

user_pref("mail.identity.useremail", "USERSEMAILADDRESS");

Unfortunately Mozilla does not support the lockPref() or lock_pref commands in this file. The lock_pref() command is actually defined in one of the header files in the Mozilla source, but there is no code for it.

Note the uppercase strings in each line, such as user_pref("mail.identity.reply_to", "USERSREPLYTOADDRESS");. These are just placeholders that you will change later, as described under "Text Files" below.

Another thing worth considering is to create a sample bookmarks file for your users. You can use your own bookmarks file as a template or create a new one with Mozilla. When finished, save it to your SOURCE_DIRECTORY and have NAL copy it down to P:/mozilla/profiles/xxxx/default if it does not exist.

Text Files

Under the Distribution Options > Text Files tab (see Figure 8), you change the placeholders mentioned above to values taken from eDirectory.

Figure 8: The Distribution Options > Text Files screen.

For example, Figure 9 shows how you would change the USERSREPLYTO- ADDRESS placeholder to %CN%.pedago.fi, which will prepend the user's Common Name in eDirectory to the string ".pedago.fi" to form an address such as "jdoe.pedago.fi".

Figure 9: Changing a placeholder to a character string.

For static values, you can define macros under the Macros tab and then use them in the substitutions. This helps you keep the design of the Application object clean, as it collects all static variables in one place. It also helps avoid errors in cases where a variable appears in more than one place, such as in the registry and the user.js file.

Macros

I have moved the random string to a macro to make things easier in case I need to create a new registry.dat using the Mozilla Profile Manager. In that case, I would simply create a profile in Mozilla, name it "default", and point to P:\Mozilla. Then I would copy the newly created registry.dat to my SOURCE_PATH and change the RANDOM_DIR macro to whatever the new randomly-named directory is called (see Figure 10).

Figure 10: The random directory macro.

Conclusion

Using ZENworks for Desktops to distribute the Mozilla 1.x browser in the way outlined in this AppNote provides many benefits. The initial rollout can happen faster and subsequent updates are easily made. Changes in settings such as proxy server addresses can also be pushed out if needed, without someone having to visit every desktop. Lastly, integrating the application settings with eDirectory means that users do not have to enter information such as e-mail addresses manually, thus eliminating a possible source of errors.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates