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
for guidance.
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:
C:\Program Files\Netscape\Users\kathy\
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:
...\Mozilla\Profiles\kathy\<random
string>.slt\
the path will be reduced to a more practical:
...\Mozilla\Profiles\kathy\
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
mozilla
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.
<Smile>
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.
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)
---September 29, 2004
The a tags in the article aren't working properly. Makes the article very difficult to read. Verified in FireFox PR1 & IE 6.0 on Win2000 - Gantry
---September 30, 2004
It screwed up because whatever program Steggy used wrote unusual href tags. My reformatter didn't expect that, and made things worse. But it tagged EVERY "Mozilla" - very annoying! I'm taking them out..
Don't use programs like this :-)
--TonyLawrence
---September 30, 2004
But - aside from the awful html - GREAT article!
When using the auth.pl poster, you shouldn't use program generated html. Simple HTML tags are far less likely to break it. If you DO have something with a lot of html, just email it to me and I'll post it directly.
--TonyLawrence
"Along with the browser profile data, Mozilla by default embeds the user's mail subdirectory into the Windows roaming profile. This is a significant flaw in Mozilla's design, as during a domain log-in the mail files will be transported from the server to the workstation along with the rest of the roaming profile. The result will be a major drag on network bandwidth and a relatively slow log-in..."
Something that I failed to mention here is the security hole posed by the default Mozilla design, in that a copy of the user's mail will be left on the workstation as part of the cached Windows roaming profile. This would make it possible for someone else to read E-mail that should be private. This a particularly serious issue with Windows 98/ME, neither of which prevents anyone from examining cached profile data.
BTW, sorry for the HTML mess. I didn't fully understand how the posting function handles embedded HTML, and generated a page with stuff that was improper for the environment.
--BigDumbDinosaur
---September 30, 2004
Not really your fault - it was my code that really messed it up.
Most of the problem is that my code tries to be helpful and make links for people that don't know how to do html themselves. I was looking for https:// and ignoring it if it was preceded by "a href". Unfortunately, your generator did "a target="new window" href", so my code thought your https:// needed an href tag - and thereby screwed it up badly.
My code should also strip out "html", "title" and "body" tags if present, but it doesn't - next rev, I guess..
Then, you left out the "Subject" line, so it didn't get put into the RSS or New indexes.
Finally, if I hadn't been out all day, I would have fixed it minutes after you posted it anyway, so it shouldn't have annoyed as many people as it did. But I didn't get home till late and stupidly tried fixing it by hand rather than writing some code. Because I was tired and dumb, I kept at that for an hour or more and only half-assed fixed it. In the morning, at a better level of alertness, I wrote a program that cleaned it all up.
I did not like that every Mozilla or Samba reference was a hyperlink - one or two is enough. So I stripped 'em out..
--TonyLawrence
"Not really your fault - it was my code that really messed it up."
Aww, don't blame yourself. Blame the computer. After all, everyone expects the computer to mess up, especially if it's running Windows. So when the opportunity presents itself, shift blame to something (or someone) else. That's how our politicians do it. <Grin>
--BigDumbDinosaur
---November 24, 2004
Don't forget, the Mozilla team is actually developing Netscape 4.x style roaming profiles for inclusion in Mozilla 1.8. You can track progress from https://www.zillavilla.com/
--BryanC
Sun Dec 17 17:39:09 2006: 2760 BigDumbDinosaur
As an addendum to this article, the described techniques also work with Firefox and Thunderbird.
------------------------
Printer Friendly Version
Setting up Mozilla Roaming Profiles Copyright © September 2004 BigDumbDinosaur
Have you tried Searching this site?
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.
Contact us
Printer Friendly Version