I've removed advertising from most of this site and will eventually clean up the few pages where it remains.
While not terribly expensive to maintain, this does cost me something. If I don't get enough donations to cover that expense, I will be shutting the site down in early 2020.
If you found something useful today, please consider a small donation.
Wed Sep 29 19:59:36 2004
Posted by BigDumbDinosaur
Search Keys: Linux,UNIX,Windows, Samba,Mozilla, Roaming Profile
The Mozilla open source web browser has
started to achieve critical mass in the Windows world. If you
are a Windows user there are a variety of reasons why you should
consider abandoning Internet Explorer (IE) in favor Mozilla, such as the latter's
substantially better security, more up-to-date user interface and
ability to squelch annoying pop-up windows. In simple terms,
Mozilla offers a level of technical excellence that is sorely
lacking in IE. I switched my business's workstations to
Mozilla about a year ago and can personally testify to the
browser's quality, performance and ease of use.
Mozilla has many features in common with its Netscape ancestors, one of which is the concept of browser profiles. Profiles, which first appeared in the Netscape 4.x family, allow multiple users of a standalone PC to customize the browser's look and feel to suit individual tastes, as well as maintain separate bookmarks, cookies, mail, and so forth. Mozilla profiles are essentially similar to the "favorites" feature of IE, but are not an integral part of the Windows environment as is the case with IE. However, on a PC configured to operate in a Windows domain supporting roaming profiles, the default is for Mozilla profiles and E-mail(!) to be buried into the user's Windows roaming profile subdirectory, which can cause more than a little grief.
Our first large scale installation of Mozilla was at an insurance agency with a multitude of PC workstations supported by one of our Uni-FITM servers running Samba on top of SCO OSR5. A full Windows domain has been implemented, complete with roaming profiles, log-in scripts, server-controlled printing, several types of secure storage, and five flavors of freshly-brewed coffee (just kidding!). Previously, web browsing was via Netscape 4.8, which worked well in this setting. Unfortunately, compatibility issues with some insurance company websites (mostly those prepared with FrontPage, another Microsoft abomination) necessitated the replacement of Netscape with something else. Due to security concerns, migrating to IE was not desired by this client, which opened the door for Mozilla.
Complicating matters at this client, each employee normally works at his or her own desk, but on occasion may work at someone else's desk. Everyone is accustomed to a personalized web browser look and feel, courtesy of Netscape's profiles feature and the judicious use of server resources. In this environment, if Kathy logs on at Paul's or Nancy's workstation, she will see exactly the same browser configuration that she would see on her own machine without having to tell the browser which profile to use. In other words, not only does this system support Windows roaming profiles, it also implements browser roaming profiles.
Unfortunately, Mozilla was not as cooperative as Netscape 4.8 in establishing browser roaming profiles, which made it necessary to experiment a bit to determine how to proceed. Therefore, I thought I'd share some of the fruits of that experimentation with you so as to reduce teeth gnashing, profane utterances, mouse abuse and other manifestations of the frustration that often accompanies Windows configuration tasks. With minor exceptions, everything that follows applies equally to a Windows domain supported by Samba or other UNIX/Linux based SMB server (e.g., FacetWin), or a "real" Windows server, with the obvious exception of any UNIX based stuff that necessarily would not apply to Windows. Also, although we have not attempted to implement any of this with Netscape 7, there is no obvious no reason why it should not work.
As is often the case when
confronted with a new challenge, it is useful to examine the past
As mentioned above, before I switched this client to Mozilla they were on Netscape 4.8. Netscape 4 uses a simple directory hierarchy: by default, binaries, DLL's, help files, etc., are stored in C:\Program Files\Netscape\Communicator, and profile data (including E-mail) is kept in C:\Program Files\Netscape\Users\<user>, where <user> is a profile name established by the Netscape profile manager. Since the C:\Program Files\Netscape\Users\ part of the profile path is not hard coded into Netscape, it is possible to relocate browser profiles by merely renaming and/or moving the profile subdirectory and telling Netscape where to find it.
In order to achieve a consistent browser interface for each user throughout the entire domain, it was clear that the system would have to be arranged so Netscape would go to the server to get the user's profile. Although Netscape 4 has support for LDAP (lightweight directory access protocol) and thus can store profiles on an LDAP server, I did not have access to an LDAP package for OSR5 at the time this system was placed into service. This meant I was on my own in finding a solution to the browser roaming profile requirement.
My method was to store each user's Netscape profile subdirectory in their home or private Windows server share, which in Samba is defined by the PATH= statement in the [HOMES] section of smb.conf. To avoid a major mess in the event the server and/or user shares were renamed, I arranged for each user's home share to always map to a particular drive letter at log-in time. For Windows 98 clients, NET USE P: /HOME in each user's login script did the trick. For Windows 2000 clients, a LOGON DRIVE=P statement in smb.conf accomplished the same task. With this arrangement, if something had to be renamed/relocated, I merely had to edit the user's login scripts (a simple task in UNIX or Linux via shell commands), edit smb.conf and send Samba a sighup to recognize the edits made to smb.conf. At the next log-in the changes would take effect.
With a fixed storage location established, I set up a subdirectory named .netscape in each user's home directory, this being the repository for the browser profile. To get Netscape to always go to this path, I configured a single profile at each workstation, named default, and told Netscape that default's profile was stored at P:\.netscape. That way, no matter which workstation the user logged on, Netscape, having only one defined profile (default), would always go to P:\.netscape to find the profile, and since P: was always mapped to the user's home directory, Netscape would, in effect, go to \\<server>\<user>\.netscape and automatically set up that user's personal browser configuration (where <server> is the server's NetBIOS name and <user> is the user's home share). Incidentally, if the Samba HideDotFiles option is set in smb.conf, filenames that begin with a dot are mapped into Windows as hidden files. Hence .netscape is not visible when the home share is browsed, which tends to discourage users from accidentally trashing their Netscape profiles.
Incidentally, there is a bit of a booby-trap built into this arrangement. If a Windows 98 user bypasses the domain log-in procedure by pressing [ESC] or clicking on the Cancel button and then attempts to run Netscape, the mapping between the P: drive and the user's home share will be invalid, Netscape will not be able to find a profile, and the Netscape profile manager will start up and ask the user to create one. If the user proceeds, the link between Netscape and the server-based profile will be broken. As the broken link can be readily repaired by anyone with a modicum of Windows skill and some knowledge of how the browser profiles are maintained, this flaw was considered to be a minor nuisance, so I never bothered work out a solution for it.
Anyhow, following the installation of Mozilla, I had planned to carry forward my Netscape 4 roaming profile methodology. Sadly, I discovered that Mozilla's means of storing user profiles mirrored those of Netscape 7, which technique was not compatible with the Netscape 4 approach. Therefore, the simple expedient of moving the browser profiles to the server wouldn't work and a new way had to be devised.
Like Netscape 4, Mozilla stores
profile data separately from the code base. That's the good
news. The not-so-good news is that unlike Netscape 4, Mozilla
may use anyone of several paths to store profiles, depending on
which version of Windows is in use and whether roaming profiles are
in effect. Also, Mozilla by default adds a randomly named
subdirectory to the profile path, which exacerbates the problem of
relocating the profiles.
By way of example, Netscape 4 might have stored Kathy's profile in:
With Windows 2000, Mozilla would probably store the profile in:
C:\Documents and Settings\kathy\Application Data\Mozilla\Profiles\kathy\<random string>.slt\
or in Windows 98:
C:\Program Files\mozilla.org\Mozilla\Profiles\kathy\<random string>.slt\
If Windows roaming profiles are in use, the profile as stored on the domain server might be:
\\<server>\profiles\kathy\Application Data\Mozilla\Profiles\kathy\<random string>.slt\
where <server> is the NetBIOS (Windows) name of the server and profiles is the share name into which roaming profiles have been stored (a location that is further influenced by whether the client is Windows 95/98/ME or Windows NT/2000/XP/95/98/ME profiles are typically stored somewhere in the user's home directory). In all of the above examples, the blue text represents the path component that can be expected to remain constant in a given Windows installation (i.e., the \\<server-name>\profiles\ reference is where Windows roaming profiles would be found). The red text represents the path component that is generally determined by the browser, as well as the person who installed it. The examples assume that the browser was installed to the default installation path.
In all cases, the Mozilla component of the default profile path will also include two files named pluginreg.dat and registry.dat. Neither file is actually part of the user profile, but both are critical to the operation of Mozilla (registry.dat stores, among other things, the names of the Mozilla profiles that have been created, as well as their paths).
In a domain that has been set up to use Windows roaming profiles, everything in the Mozillaprofile path will be transported from the server to the PC at log-on time and will be copied back to the server when the user logs out. Also, a copy of the profile will be locally cached on Windows 95/98/ME workstations, and on any Windows 2000/XP workstation where the registry has not been hacked to discard the local profile once the user logs out. Assuming that all log-ins are policed by the primary domain controller (PDC) the cached roaming profiles on the workstations will uselessly consume disk space.
What is particularly nasty about the transporting of the Mozilla profile from the server to the PC and back is the potentially heavy load imposed on the network and the server. Over time, some of the files in the Mozilla profile (especially files containing E-mail) could become very large, resulting in the consumption of signficant network bandwidth during the copying of the user's Windows roaming profile which also schleps a lot of non-Mozilla stuff. Aside from the effect this may have on other users who are trying to get to server resources, the time required for a workstation to complete the log-in or log-out process will substantially increase as the size of the Mozilla profile files increases.
Further complicating matters is the last part of the path, that is, the <random string>.slt component. This is a feature that was added several years ago to the Netscape code base (and then into Mozilla) in response to the theoretical possibility of an attack exposing the user profiles, from which a cracker could supposedly steal passwords, read mail, peruse bookmarks, etc. As it turns out, the <random string>.slt component of the path can be derived from registry.dat, as that file is not encrypted. Therefore, it's my opinion that the randomizing of the profile path adds scant security.
Continuing with the profile subdirectory discussion, the <random string>, an eight character alphanumeric sequence that is (surprise!) randomly generated each time a Mozilla profile is created on a workstation, will in all likelihood be globally unique in the domain. Even if the same username is used to create a Mozilla profile on each workstation, the probability of any given random string being generated more than once will be about 1 in 3.24 x 1032. Therefore, <random string>.slt will be different for each workstation and, in fact, will be valid only on the workstation where the user profile was first created. Hence, Mozilla would fail to find the server-resident profile, except when run from the first machine on which the profile was created. Adding insult to injury, if a different user runs Mozilla on the same workstation, they will be told that the profile can't be found and that a new one must be created. When that is done, Mozilla will forever forget about the original profile, which means the original user will no longer be able to run Mozilla with his/her original profile. A secondary effect of this will be that the user will not be able to read his/her mail, since those files are normally stored in the profile subdirectory as well.
Fortunately, a back door exists that can be used to avoid these contretemps. If a Mozilla profile is created from scratch and pointed to a directory that has already been populated with at least one key file expected by the browser, the "salting" of the profile directory name will not occur and the <random string>.slt path component will not be present to annoy us. That is to say, instead of having:
the path will be reduced to a more practical:
which can be stored on a server (where it less likely to be cracked, assuming a proper security model has been adopted) and accessed from any workstation running Mozilla. In fact, we would now be able to define a single profile on all workstations and get rid of the Mozilla\profiles\ part of the path, thus essentially achieving what was possible with Netscape 4: true browser roaming profiles. How would we accomplish this? Read on, my friend!
The process of creating Mozilla
roaming profiles is somewhat convoluted, but not at all difficult
to follow. However, before undertaking anything described in
this section, please read it in its entirely so you will know what
to expect. The procedure will assume that you are performing
a scratch Mozilla installation on each workstation, although it
will be apparent that the methodology can be adapted to systems
that already have a running copy of Mozilla. Also, if you
haven't already done so, download the latest version of Mozilla and
store it on the server in a location that will be accessible to a
Windows user with administrative rights. Keeping your Mozilla
installation up to date is an important part of maintaining a
reasonably secure environment.
If it hasn't already been done, configure your server so each user has a home share that is mapped into an MS-DOS drive letter when s/he logs on. On many Windows servers, the user's home drive will be H:, but the actual drive letter choice is arbitrary. I prefer to use P: for "personal" or "private" storage (it's private in that the only users who can see it are the owner and the server administrator - root on a UNIX or Linux box). Whatever your choice, drive mapping must be done on the server via a login script or static configuration, not on the client. This arrangement will assure that the home drive will be invalid if user log-in to the domain fails for any reason (e.g., server off-line, network down, etc.).
As described in the previous section, Mozilla will recognize an existing profile subdirectory if a new profile is pointed to it. Minimally, this subdirectory has to be populated with a single file, which would be prefs.js. Alternatively, the subdirectory could be populated with all of the subdirectories and files that constitute an active Mozilla profile: you could create a boilerplate profile to get each user started and copy it into each user's Mozilla profile subdirectory. In either case, Mozilla would always look to that subdirectory for a valid profile. There is a bit of complication involving the pluginreg.dat and registry.dat. files read by Mozilla at startup, but nothing earthshaking.
Now that I have thoroughly inundated you with a bunch of tedious minutiae, I'm sure you're eager to get something useful accomplished. First, I'll describe the server side activities, which require that you be logged in as root if you are on UNIX or Linux, or as a user with full administrator rights if you are working with a Windows server:
In each Windows user's home directory, create a subdirectory named mozilla, using whatever method is appropriate for your environment. Incidentally, you can use any name you wish for this subdirectory, but it must be the same for all users. The balance of this procedure will assume that the subdirectory is named mozilla.
Create an empty file named
prefs.js in the new
subdirectory. In UNIX or Linux, type the command >mozilla/prefs.js in response
to that friendly shell prompt (Whaddya mean you don't know how to
use the shell!). In Windows, change into the new mozilla subdirectory, open Notepad
and then immediately execute a Save, using a
file type of All Files (*.*)
(not .txt, which will
create an empty file named prefs.js.txt).
If you are working on a Windows server, the process is more involved: you have to change the directory and file properties in separate steps, which requires more work than the equivalent steps in UNIX.
Repeat the above process for each
Windows user who is to have access to Mozilla. By the way, if
you are working in UNIX or Linux and there are a lot of users
involved, you might want to write a simple shell script to automate
the entire process. For you Windows administrators, good luck
with the mouse. You'll be getting a lot of use from it.
With the server side finished, it's time to play with the workstations. The procedure is the same at each PC: load Mozilla and create a profile for testing, and then log in as each regular user who is to use the workstation and run the Mozilla profile manager to create a default profile. First the loading and testing operations:
Log on to the workstation using a
username with read access rights to the location on the server
where the Mozilla setup program has been domiciled. If the PC
is running Windows 2000/XP, you also must have workstation
administrative rights in order to install software (unless security
has been relaxed).
Run the Mozilla setup program from
the server as you would any other Windows program and choose the
desired installation options. For example, it might be
prudent to not install Chatzilla so users aren't goofing off on IRC
when they are supposed to doing company work. Do install the
spell checker so your users can clean up their E-mail before
launching it into the abyss.
When the Mozilla installation has been completed, the browser will automatically start and, assuming the workstation has Internet access, you should see a Mozilla website welcome page. If the welcome page appears, congratulations! You have completed a successful installation. But, you're not done just yet.
Exit from Mozilla, browse the
Windows Programs menu and find the entry for Mozilla. In it
you should find the Profile Manager. Run the Profile Manager
and when it starts, delete the default profile that was created
during the Mozilla installation. If Mozilla asks you to
delete the associated files, do so.
Next, click on Create Profile. In response, a new dialog box will appear and Mozilla will request a profile name. Enter mozilla or the name used to create the profile subdirectory directory on the server. Be sure the profile name is spelled exactly the same as the profile subdirectory name!
Below the profile name entry field click the Choose Folder button. Browse to and select the P:drive (or whatever drive letter is mapped to the users' home shares). Do not click on the profile subdirectory itself, just the drive letter. If you have correctly performed this step, Mozilla will inform you that the path P:\mozilla is where the profile will be stored. If the path is incorrect you must correct it before proceeding.
Click Finish and the new profile will be stored and the Profile Manager will return to the opening screen. Close the Profile Manager and run Mozilla to verify proper operation. If Mozilla complains about not being able to find the profile or if Mozilla attempts to migrate an older browser profile, your setup is incorrect. Recheck the server side and if necessary, restart the Profile Manager, delete all profiles and start over.
Repeat the above process for each
workstation on which Mozilla is to be installed. If you have
a lot of workstations to do, send out for an extra large pizza and
several liters of soda. That way you'll be able to entice
some of your friends to help out.
Earlier, I mentioned two special Mozilla files: pluginreg.dat and registry.dat. As explained before, these files are normally buried into the user's Windows profile directory tree, and are essential to the operation of Mozilla. In particular, registry.dat maintains a list of all the Mozilla profiles that have been configured. Following the first time installation of Mozilla, registry.dat will be valid only for the installing user. So, when some other user logs on and tries to run Mozilla registry.dat will not exist: there is no Mozilla data in the other user's Windows roaming profile, which means no valid profile will appear to exist. The solution to this problem is to recreate the mozilla profile and point it to the P: drive (assuming that is where the user's home share has been mapped). Just so you are clear on this configuration aspect, I'll repeat the required steps:
Domiciling Mozilla profiles in each user's home directory on the server produces a consistent browser look and feel throughout the domain, something that your users will appreciate. Also, with the browser profile no longer part of the Windows roaming profile, less network bandwidth will be consumed during log-in, as the browser profile will not be copied to the workstation at log-on time. The procedures described above were tested both on my office system (Samba running on OSR5) and at two different client installations (both also running on Samba). I believe I have covered all that you will need to know to set up Mozilla roaming profiles in your Windows domain. If something isn't clear, please leave some Wiki feedback and I'll try to help out.
If you found something useful today, please consider a small donation.
Got something to add? Send me email.
More Articles by BigDumbDinosaur © 2009-11-07 BigDumbDinosaur
Unfortunately, people are not rebelling against Microsoft. They don’t know any better. (Steve Jobs)