Closed Bug 41057 Opened 24 years ago Closed 23 years ago

Release notes should better describe multi-user installation process

Categories

(Core :: XPCOM, defect, P5)

defect

Tracking

()

RESOLVED FIXED
Future

People

(Reporter: mozilla, Assigned: shaver)

References

(Depends on 2 open bugs)

Details

(Keywords: meta, relnote, Whiteboard: relnote-user [rtm-] suntrak-n6)

Attachments

(2 files)

Overview Description:
Mozilla writes several files into the binary directory upon startup.  On most
multi-user OSes, users don't have write permission to the binary files.  Not
only that but mozilla will CRASH about 50% of the time on startup if it can't
write to that directory.

Steps to Reproduce:
1) Download and unpack the latest mozilla nightly.
2) Make the directory writeable only by the super-user.
3) Try to use mozilla as a normal-user.
4) Then make the directory world writeable by anyone.
5) Try to use mozilla as a normal-user.

Actual Results:
About 50% of the time mozilla will SEG FAULT on startup with the following in
the debug window when it can't write to the binary directory.
WEBSHELL+ = 1
WEBSHELL+ = 2
CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:
///home/david/.mozilla/default/chrome/user.css' failed.  Error code: 16389
Segmentation fault.
If the binary directory is world-writable then mozilla works fine.  It
add/removes/changes some files in the binary directory (see below).

Expected Results:
Mozilla should start nomally and not try to create files in the binary
directory.  This a big security risk to require that binaries be writeable by
anyone.  If this can't be fixed by M16, this should at least be in the release
notes.

Reproducibility:
everytime

Build Date & Platform Bug Found:
2000053008 i686 linux

Additional Builds and Platforms Tested On:
none

Additional Information:
If mozilla has write permission to the binary directory it will
create/edit/remove the following files.

Add:    package/chrome/all-locales.rdf
Add:    package/chrome/all-packages.rdf
Add:    package/chrome/all-skins.rdf
Add:    package/chrome/overlayinfo
Add:    package/chrome/user-locales.rdf
Add:    package/chrome/user-skins.rdf
Delete: package/chrome/installed-chrome.txt
Modify: package/component.reg
*** Bug 41541 has been marked as a duplicate of this bug. ***
Sorry for the spam.  New QA Contact for Browser General.  Thanks for your help
Joseph (good luck with the new job) and welcome aboard Doron Rosenberg
QA Contact: jelwell → doronr
reassigning to build config per doron's suggestion
Assignee: asa → cls
Component: Browser-General → Build Config
QA Contact: doronr → granrose
There are two other bugs that deal with the specific files not being writeable
by not the problem in general.  Setting deps & nominating for nsbeta2 status.
Status: NEW → ASSIGNED
Depends on: 16600, 39808
Keywords: nsbeta2
Whem I filed bug 16600, only the first start failed. If Mozilla once ran
withwrite access to its bin dir, it ran fine without it after that IIRC. This
might have changed with the rdf files.

Files a new bug 42148 specific for the rdf files to more easily track work.

The COMPONENT is wrong, right?

Background: IMO, it is generally a design fault to write to the app dir. Under
unix, the file system layout (/usr, /etc and /home) was defined the way it is
exactly to remove those writes and so to make e.g. app protection or network
sharing possible.
Depends on: 42148
More background for PDT:
The whole Unix security bases on the fact that users have no write access to
apps. So, if e.g. a JS sec hole is discovered which lets webscripts write to the
local filesystem, it should only harm the user who visited that page, *not* the
whole system. If users have write access to |<mozbin>/chrome|, the script can
place a script there and it would have full access rights *for all users* who
start the Mozilla instance. Not sure about invokation, but I guess there are
ways to achieve that (maybe some autodiscovery for JS components, and then
overwriting a common progid or so).

Why don't we have a security keyword?
We need to split this into two cases, the install case and a regular run. 
Mozilla cannot be just unpacked into a directory, it must be run once as part 
of the installation process by a person with installation rights in those 
directories. If that's what this bug is about it'll be closed INVALID. In fact 
i think this is a duplicate but I'll leave this open until I can find the other 
bug.

It's a legitimate problem if you find that Mozilla needs write access 
after initial installation. Not just uses it if it can get it, but fails it if 
can't.  CC'ing warren because I suspect problems like this fall under his 
group's perview, it's definitely not a "Build" problem.
I don't understand why it is necessary for mozilla to be run once by a system
administrator before it can be used by regular users.  Most applications are
just unpacked and ready to go.  If it really is necessary for a sys admin to do
this, then there should be a command line flag -install that will do this
without actually starting the gui part of mozilla.


Example: I have 20 linux workstations.  I want to install mozilla on them.  I
would have to go around individually to each workstation and log in as root,
download and unpack the tarball, start the X Windows, run mozilla, and then
logout. If there was a -install option I could do all of this remotely without
the need for a gui.
David, you can start X apps remotely. The problem is security. You should not
run such a beast as root, you can't be sure that it has no security holes.

I think, the install process (if needed at all) should run as separate binary.
OK, making this the tracking bug for normal runs by users. Filed bug 42184 about
the install binary.

Where did the Architecture component go?
There's an 'arch' keyword now instead. But I don't understand why this is an 
architectural issue. It just seems like a (security) bug.
Depends on: 39282
Depends on: 6464
No longer depends on: 6464
definitely not a build config issue.  punting to installer and reassigning to 
default component owner.
Assignee: cls → ssu
Status: ASSIGNED → NEW
Component: Build Config → Installer
QA Contact: granrose → gbush
Not an install issue either. This is a basic architectural issue that should be 
tracked by warren's team. Some of it is bugs, but the XPCOM need to create 
component.reg and the xpti.dat files are fundamental parts of the product. The 
first-time run issues have been moved into a different bug, but people have a 
good point that they shouldn't have to bring up a GUI to install the product.
Assignee: ssu → warren
Component: Installer → XPCOM
Keywords: arch
Not sure what open issue is here.  Can you clarify?
Whiteboard: [NEED INFO]
Unix and Win NT systems are generally set up so users cannot write to the 
directories where programs--including Mozilla--are installed. Mozilla, 
unfortunately, expects to be able to write into those directories on occassion 
and then fails when it does.

The need to write as an install step is OK, but bug 42184 describes the need 
for a non-gui automatable way for admins to install.
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: [NEED INFO] → [nsbeta2+]
This is really Hyatt's bug. installed-chrome.txt should go away in favor of 
"xap" files (which I'll build the infrastructure for). Hyatt needs to find 
another location for all-packages.rdf, etc. They're really caches of what's in 
the chrome manifests and the xap file (which can come from read-only locations). 
Maybe they should go somewhere near the user's cache directory.
Assignee: warren → hyatt
Depends on: 42792
The cache can be per-profile, and as far as newly-downloaded skins or apps are 
concerned, it will be.  all-packages.rdf, etc. are quite capable of living in 
the user's profile dir.  

The only bug that needs to be fixed for nsbeta2 is the fact that skin-switching 
is done at the install level and not the profile level.  This is not the chrome 
registry's fault.  Ben is using the wrong flag in the chrome registry API, and 
that's why stuff is being written to the install dir.

I do agree that installed-chrome.txt needs to be fixed eventually, but I don't 
think it's an nsbeta2 issue.  We can do it in beta3.

Whiteboard: [nsbeta2+] → [nsbeta2]
Adding the '+' to [nsbeta2], per leger's comment
Whiteboard: [nsbeta2] → [nsbeta2+]
I removed the + after her last comment.
Keywords: nsbeta2
Whiteboard: [nsbeta2+]
Keywords: nsbeta2
Putting on [nsbeta2-] radar. Not critical to beta2. 
Whiteboard: [nsbeta2-]
> We can do it in beta3.

OK, nominating for nsbeta3
Keywords: nsbeta3
Target Milestone: --- → M20
Depends on: 39289
Depends on: 44338
skin-switching problem is fixed. resolving as fixed per hyatt.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Bug 42148 is about the skin-switching problem. This is a meta.bug now. Some of
the particular problems seem *not* to be fixed. REOPENing.

I guess, hyatt just doesn't want to own it, so I'll reassign to nobody. If
somebody has a better idea, reassign.
Status: RESOLVED → REOPENED
Keywords: meta
Resolution: FIXED → ---
/
Assignee: nobody
Status: REOPENED → NEW
Note that it seems that you can't run mailnews unless you have write access to
the bianry directory.
Wow, Richard, can you figure out, which file is the culprit (the blocking bugs
might help you)?

Assuming Richard is right, this is pretty severe and IMO needs to be fixed for
nsbeta2. Removing [nsbeta2-], so PDT at least sees this.
Whiteboard: [nsbeta2-]
/usr/local/mozilla/chrome/overlayinfo and its subdirectories is not
world-readable or searchable. chmod a+xr seems to fix it.  So this part is
probably just a packaging problem. Filed bug 46984 against Instakller component
for it.
Depends on: 43091
Keywords: relnote, relnote2
Summary: Mozilla should not need write access to the binary directory. → [Meta] Read-write permission problems on multi-user systems.
Depends on: 42184
Restoring SUMMARY. "Read-write permission problems on multi-user systems." is
not specific enough, see bug 42184. Also, it is misleading, as this bug is also
a problem for well-setup practically-single-user systems (which are just
technically multi-user systems, like WinNT and Unix).
Summary: [Meta] Read-write permission problems on multi-user systems. → Mozilla should not need write access to the binary directory.
Restoring the {nsbeta2-] I removed, because bug 43091 has been filed
specifically about the Mailnews disappearing problem.

Also, removing dependency on some bugs. This bug is *only* about mozilla-bin
trying to write to the inst dir during normal runs, not a catch-all about
permission problems.
No longer depends on: 42184, 43091
Whiteboard: [nsbeta2-]
I was wrong in once case. The problem in bug 43091 is actually, that Mozilla
tries to write to the chrome dir. Readding the dependancy.
Depends on: 43091
See possibly related bug 42184, Mozilla-bin must not write to bin dir during 
installation.
Taking this back from nobody@mozilla.org
Assignee: nobody → warren
No longer depends on: 44338
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3+]
Looking at recent builds, if you unpack and chown mozilla as root without first
running it to "install" the application then mail/news and themes do NOT work.
This should be a relnote for M17.
David, that would be bug 42184.
Depends on: 33344
I can't even run Mozilla as a user anymore and haven't been for several
days now.  Here's what I did just now:

-Downloaded the Daily Dump.
-Untarred xzpf.
-Ran mozilla as user: Segfault.
-Against my better judgement, ran mozilla as root: no problem.
-Ran as user again: Segfault.
-Back to root and "chmod -R a+w ."
-Back to user and run mozilla: no problem.

So this means it's dependent again on writing into the install directory.
As we all agree, this is a Bad Idea, and "fixing" this SEVERE PROBLEM
by changing the file permissions - well, if you are going to do that,
then it should only be installed completely in user filespace and
there should be a release note to that effect.
Depends on: 51240
I have a cron job that automatically downloads and unarchives the latest nightly 
Mozilla.    It's worked perfectly up until about a week ago.

When it was working, there was a file in the /package directory called 
"component.reg"       When it stopped working, it was when that file was left 
out of the mozilla-i686-pc-linux-gnu.tar.gz file.   When I go to start mozilla, 
it tries to create component.reg, and since I don't have write access to that 
directory as a regular user, it just dumps me back to the shell prompt.

Even running the installer version as root and trying to launch Mozilla as a 
regular user  (which is the standard way of installing / using software on a 
Unix-like OS) did not work for me!  (same problem)

I sure don't like it, but there may be some way of justifying the first case, 
where I can't just unpack and go from the nightly build.    It sure breaks any 
automated way of installing Mozilla!    But as for the Installer version 
failing, this is a BIG problem!
Adding dependency: bug 49507 (nsbeta3, P4): PSM does not work if Mozilla doesn't
run as root. CC: ddrinan@netscape.com
Depends on: 49507
In case it helps, I have a script just like wdormann's and it started failing at
the same time.

I just put Mozilla onto a fresh RedHat 6.2 install and it works properly when
run as a user after installing "tar xzpf" and running mail after starting
Mozilla as root (yuck). On my Mandrake 7.1 system with Helixcode Gnome it runs
if I start it in the install directory but segfaults if I start it elsewhere.
This does not happen on the RedHat system, which is very strange.

Huh? What does the current working directory have to do with it? This may
explain some of the "works for me" responses to this issue.
Adding mostfreq. This propduces completely confusing problems, in which many
users run.
Keywords: mostfreq
*** Bug 51164 has been marked as a duplicate of this bug. ***
warren, ping? I know, you're the most doomed, but should you give th bug away then?

This continues to be a big problem. I am sick of reading/evaluating
dups/dependant bugs of this bug and bug 42184. I gave up to understand this
mess. Please someone investigate, make a plan and clean it up.
Because many, many users ("testers") run into this problem, marking DOGFOOD,
finally.
Keywords: dogfood
Keywords: relnote3
My idea was to put these files in the cache directory (or someplace like it 
specifiable by a pref). I'll try to get it in this weekend.

How come Hyatt isn't cc'd on this?
Not holding PR3 for this; marking nsbeta3-.
Whiteboard: [nsbeta2-][nsbeta3+] → [nsbeta2-][nsbeta3-]
Keywords: rtm
I don't think this stops dogfood usage, probably just large central deployments.
 I'm marking dogfood-minus.
I can believe this is an rtm bug, and I sure hope we see a small fix RSN.
Whiteboard: [nsbeta2-][nsbeta3-] → [nsbeta2-][nsbeta3-][dogfood-]
Another permissions problem is this:
If you install Mozilla as root (which I think is expected)
and then run it as a normal user (again, quite standard in the Unix world)
The word "Composer" does not appear in the preferences.
Check out bug 53674
it's a little bit worse than wdorman states:
It can seem likt it is not only required to run browser once anymore (to create
files/dir's under chrome according to installed components). Seems i have to
start each and every installed module once as root as well; mailnews, composer,
addressbook. (for instance.) If i don't start at least Composer as root once,
bug 53674 and bug 53680 triggers when i run moz as regular user.
(missing menuitems for composer in prefs, and missing items in composer's menubar)
not sure, but a slightly worse phenomena MAY be that talkback for installed
builds are affected. I've crashed about as often as "usual" the past two days or
so, but no talkbacks anymore. (currently 2000-100106)
I'm not quite sure why this is nsbeta3- and not + (or ++) since this essentially
prevents to use Mozilla/Netscape 6.0 to run on Unix. (I neither want to have 200
copies of 32MB or want to have allow 300 users to have write access to a shared
directory.) This prevents the usage at out computer cluster :-(
(And is even on a single unix pc rather irritating not very usefull.)
Depends on: 54904
It's nsbeta3- because that ship has already sailed. If it gets [rtm-] we're 
dead.
> If it gets [rtm-] we're dead.

You don't even need [rtm-]. [rtm+] (not [rtm++]) or the bug lying around for too
long will be enough. ;-) I will take some time to clean up this mess.
Nice to see you agree on the importance, though :).
> I will take some time

s/I/It/ *g*
Depends on: 53680
This also seems to affect the functionality of http-authentification.

If I run Mozilla (build id: 2000100308) as a normal user and try to enter a page
that has a password (test-example here:
<http://www.koldfront.dk/mozilla/password/>) I get the window asking for user
name and password, but when I click "Ok" nothing happens (the password-protected
page isn't shown).

If I run Mozilla as root and try the same, the password-protected page is loaded
as intended after correct user name and password entry.
If this and bug 42184 are to go into the release notes, I need a plain-English
summary of the problem and what the users can do about it. Also, is really all
platforms? And finally, is there any relationship to 49507?

Thanks.
No longer depends on: 53680
Suggested relnote: `If installing Netscape 6 on a multi-user operating system 
such as Linux, Unix, or Windows 2000, you should install it separately in the 
user directory of each user who plans to use the program. If you install Netscape 
in a shared write-protected directory, it may not run properly.'

I don't think there's a nicer way of putting it. :-/
Summary: Mozilla should not need write access to the binary directory. → Mozilla should not need write access to the binary directory
Can't you do a chmod -R u+w on the installation directory (or chmods on whatever
specific files/directories mozilla is rude enough to stomp on) after installing
as root?  Not a good situation, I agree, but some sysadmins (especially on
systems that only have a few well-known users) might prefer it to installing
many separate copies so it might be worth mentioning in the release notes.
Why is this so difficult to fix?  There seem to be other parts of the code that
know how to fall back to the user directory when the install directory is R/O
so there must be some code or interfaces or something to handle the job.
Mozilla will also not run on a properly administered NT system for the same
reasons, so doesn't that leave Win98 as the only PC OS that a normal
installation of Mozilla currently works on?
> Can't you do a chmod -R u+w on the i

I guess, the owner (that's |u|, not?) already has sufficient rights. So, this
wouldn't help.

> especially on systems that only have a few well-known users

The problem is not so much the user himself, but what the user does
unintentionally. If one user is compromised, all other also are, if you make all
files user-writeable. I think, we should not suggest that. Sysadmins wanting to
do that will see that it is possible from Matthew's suggested text.

Matthew suggested:
> "[...] If you install Netscape
> in a shared write-protected directory, it may not run properly"

I would make that the first sentence, i.e.
"If you install Netscape in a shared write-protected directory, it may not run
properly. So, if you install Netscape 6 on a multi-user operating system such as
Linux, Unix or Windows 2000, you should install it separately in the user
directory of each user who plans to use the program." (Note: no comma between
"Unix" and "or".)
Whiteboard: [nsbeta2-][nsbeta3-][dogfood-] → [nsbeta2-][nsbeta3-][dogfood-] suntrak-n6
Depends on: 55419
To add some more info about permissions in UNIXes: Users (application
non-owners) running application need only:

for app files: execute permissions to app's binaries (read perms. are not
necessary!) and read permisions to its configuration files.
for app directories: read permissions (not absolutely necessary for some apps),
execute permissions.

Having to give the non-owners of application write access to aplication's dirs,
binaries and global configuration files is _absolutely_ unacceptable!

Particular users' config files are to be stored in their home directories
(thanks to this, after the application is upgraded (deleted and reinstalled with
a new version), all users keep their previous configuration.

That's how it works on UNIX systems. That's how it works on Linux.
We're not having trouble understanding the problem or reproducing it here... 
just trouble getting to the task due to too many other things. Send me a patch 
instead of more description.
Adding cc
Matthew, thanks for the explanation for the release notes!
*** Bug 55208 has been marked as a duplicate of this bug. ***
When I installed PR3 as root, I was not able to run it as cls.  After I ran
regxpcom & regchrome (regchrome I had to copy from my cvs build), it started up
fine.  Still waiting to see if there will be other side-effects.

Samir, how hard would it be to run regxpcom and regchrome during installation? 
Or better yet, before those files are packaged?  If we know that component.reg &
chrome/all-*.rdf need to exist before the browser can run, why aren't we
shipping them?

cls, see bug 51677 (Ship pre-generated chrome files if possible).
See also bug 55419 where the installer needs to launch mozilla with the 
"-installer" flag to take care of these "first time" initializations, 
performing the regxpcom and regchrome actions as well as 4.x profile migration.

Shipping the pregenerated files instead might be OK for Mozilla tarballs but 
doesn't work well in a component installer with optional pieces. It probably 
doesn't hurt much to have extra components in component.reg (wastes memory, 
and the failure to load a component would take an OS call that would normally 
be avoided) but I think extra registered chrome could be disastrous, especially 
if dynamic overlays are registered that don't really exist.
I have managed to run NS PR3 as non-privileged user, after installing and
running once as root. However, to install any optional component, such as
chatzilla or xmlterm, I need to run as root again to get the component installed
in the bin/components directory and then registered in component.reg. This means
that for a shared install of mozilla, a non-privileged user will only be able to
try out browser add-ons that the sys admin chooses to install. This sort of
defeats the purpose of XPCOM in a multi-user system. Allowing user-specific
chrome does not solve this problem, because this has to do with user-specific
component installation and registration, which is an XPCOM issue. (Should this
be in a different bug?)
R. Saravanan: local components are covered by bug 14923. We should think about 
whether that's part of mozilla1.0 or not -- it probably is.
Disclaimer: I know very little about XPCOM, and I'm doing this only because
nobody else seems to be doing anything about this bug!

I have attached a (trial balloon) patch to xpcom/io/nsDirectoryService.cpp that
moves the component.reg directory from the bin directory to the $HOME/.mozilla
directory (for Unix platforms only). I'm not proposing that this be checked in,
but it may be worth trying out and testing. The patch checks if a file called
$HOME/.mozilla/component.reg exists, and if so uses it as the component
registry. Otherwise, it uses bin/component.reg. At the moment, you need to
create at least a zero-length component.reg file in the user's mozilla directory
for this patch to work (this behaviour can easily be changed). With this patch,
I managed to install a mozilla tarball as root and then run it as an ordinary
user.
svn, cool!

This approach sound like the right way, given that users might install
components, too. Would be nice, if we could get the patch ready for checkin (and
actually do checkin) ASAP.
Hyatt is going to take this. We think there is really only 1 remaining problem 
here after doing an initial install as root: user-locales.rdf and user-skins.rdf 
can still be written because of the way the select rules are processed in 
installed-chrome.txt. He can fix that by deferring the select rule actions until 
after everything else in installed-chrome.txt is processed.
Assignee: warren → hyatt
*** Bug 42184 has been marked as a duplicate of this bug. ***
*** Bug 56081 has been marked as a duplicate of this bug. ***
*** Bug 56256 has been marked as a duplicate of this bug. ***
*** Bug 56256 has been marked as a duplicate of this bug. ***
rtm-/future, no time left for this.
Whiteboard: [nsbeta2-][nsbeta3-][dogfood-] suntrak-n6 → [nsbeta2-][nsbeta3-][dogfood-] suntrak-n6[rtm-]
Target Milestone: M20 → Future
> If it gets [rtm-] we're dead.

relnoteRTM ...
Keywords: relnoteRTM
So we've basically killed the viability of Netscape on Unix?

Great.

Adding Keyword ns601 to the status bar and hoping that we come out
with Netscape 6.01 less then a month after 6.0, before anyone knows
that 6.0 exists.

This bug has 17 votes for a reason. It should be a "pull it off the wire" bug,
because
this bug makes it impossible for the sys-admin to install one copy for everyone
to use.

Simple crashers pale compared to the prospect of a browser that cannot be installed
properly for multi-user use IMHO.
Keywords: ns601
Sorry for the spam, but I just though I'd voice my opinion.   Yes, vote-wise, 
this bug is a top-20 bug.   This is no coincidence.

Mozilla isn't following the *NIX mentality of how software should behave:
1.   -Install as root
     -Run as normal user
2.   -Binaries are put in the program directory and never touched again
     -System-wide configuration goes in /etc
     -User-specific configuration goes in ~/     (User's home directory)

The Linux market is an important target.  Right now, Mozilla/NS6 is a Linux 
user's only hope for a *good* web browser.    NS4 is a joke in the Linux 
world.    You want mass acceptance?   Alienating Linux users isn't the way to 
go.    Windows / Mac users?   Hell, they've already got a "great" browser 
(IE).   Why should they switch?

Good luck, folks...

</soapbox> 
I am currently running Mozilla M18 installed (as root, perhaps obviously) from
RPMs.  I am not root.  Everything works fine.

The packager had to be a little bit clever, but it can certainly be done.  In
light of the fact that Mozilla _can_ be installed such that it doesn't require
write access to the installation directory, I think the severity of this bug is
overstated.

(You don't use RPM?  Follow blizzard's spec file to see how he does it, and make
Politically Correct packages for your platform:
http://people.redhat.com/blizzard/software/ .)

There's no way hyatt will ever fix this, or probably even shepherd in a fix, so
I'm taking this bug to add to my graveyard.

I also disagree that system-wide configuration should always go in /etc, but I
don't care enough to argue further: you're more than welcome to tweak and
package up something that puts things in /etc, if it really turns you on.
Assignee: hyatt → shaver
Severity: critical → minor
Priority: P3 → P5
NTLM has more votes than this bug. NetBSD had 2 binary (2) orders of magnitude 
more votes than either of these.
Stop abusing soapboxes. We have newsgroups; please use them.

Can a bunch of people test the following:
as i_don't_care:
wget mozilla.tar.gz | wget mozilla.zip [ftp, http, lynx, netscape, mozilla, I 
DON'T CARE]
as future mozilla owner:
tar xzpf mozilla.tar.gz | unzip mozilla.zip [winzip, pkunzip, zipinfo, I DON'T 
CARE]
regxpcom  [probably from bin/]
regchrome [probably from bin/]
as mortal:
run mozilla.
If you have problems please use:
lin: strace
sol: truss
win: filemon

QA people who could do this testing, zach and i have w2k accounts both are 
willing to be victimized. 
world: if you don't trust mozilla, find someone willing to let you testdrive it 
on their system.
I filed bug 56429 based on my w2k testing.
Depends on: 56429
> as future mozilla owner:

Wrong. Install as root. Users have no write access to /usr.

*I* install Mozillas as the user that runs them, and I have no problem
whatsoever. But that's not how it should be.

Shaver, this bug is certainly not a minor problem.

Anybody, if Netscape wants to ship crap - its problem. Let's hope this bug gets
fixed soon after N6.
As much as everyone thinks this is evil, since regchrome and regxpcom have been
fixed, mozilla itself can be installed as root. The only problem occurs when a
user wants to install something besides a chrome pack.
IE, sysadmin doesn't have PSM, user installs it, doesn't work because mozilla
only looks in global component registry. Replace with aphrodite, or whatever the
mozilla appthingy of the week is.

While I still think its bull that this ever happened from a design perspective,
it has a workaround right now.
I'm sorry that you feel our design to be bovine in nature. There have certainly
been alternate designs proposed to permit installation of components in other
directories, but this is not a new problem: how does a user install mod_perl for
use on their home page?  Why hasn't the Apache crowd rushed, klaxons wailing and
editors at the ready, to remedy this grievous error?

Of course, nobody -- obviously including yourself -- has chosen to implement
those alternate designs, and given that there are ways to make this work if you
want to, I'm not impressed enough by the urgency to want to devote my personal
resources to making it better.  I don't think that the mechanisms here are that
onerous, but if you disagree you're more than welcome to put your money
somewhere _near_ your mouth and come up with ones that are less onerous -- this
means ``implement'', not just ``describe fancifully on newsgroups and bug
reports''; we have had ample of the latter on this particular issue, including
from yours truly.

I agree that the ability to install local components would be _nice_ (see 14923,
which I started and then graceless dumped on blizzard), but I'm not sufficiently
motivated by that particular flavour of ``nice'' to drop the other stuff I'm
doing.  Maybe someone else is, though -- the source is available.

(I don't agree with the concept of moving component.reg to ~/.mozilla/, because
it doesn't really improve the situation: you still need to write to the
$MOZILLA_FIVE_HOME/components directory to put anything new in place.  When you
can install components in ~/.mozilla, and have them be found, I'll be more
interested.)
Status: NEW → ASSIGNED
And for the record (to the person who claimed you couldn't install Aphrodite),
the chrome registry is capable of operating entirely out of the profile
directory.  That includes newly installed packages.  You don't have to run as
root to install Aphrodite for yourself (or any other packages you desire).

Local components may have problems, but local chrome does not.  If you're going
to come onto this bug and accuse us of poor design, get your damn facts straight.
Hyatt: I think the problem with aphrodite is that the XPI interface doesn't
expose a way to install a component in the profile directory.  Maybe dveditz can
say more about this issue?
I'm reconciled to having this bug in NS6.0x, but I do think it should be fixed
for mozilla 1.0, at the latest.

shaver: I agree that moving component.reg to ~/.mozilla doesn't solve the
problem, but it is the first step and I would argue a logical one. One has to
choose either to have two component registries or a single one. Logistically, it
seems it would be better to have just a single one. On multi-user Unix systems,
~/.mozilla seems the natural place to put it. There is a slight inefficiency in
that components are registered separately for each user; but that is a much
smaller price to pay than the current workaround of installing all the component
DLLs for each user that wants to add a local component. This does not solve the
problem of autoregistration of local components in ~/.mozilla/components (?),
but as a workaround, one can manually install a local component and register it
using an absolute file path (I think). (But this discussion actually belongs to
14923, which is the one I'm more worried about, and I'm willing to devote some
time to fixing that.) Fixing this particular bug, once component.reg is moved to
~/.mozilla, requires dealing with chrome stuff (per warren's last comment) and
it would take me too long to spin up on that.

Perhaps I should start a thread on this topic on n.p.m.xpcom?
benb, I said owner because on w2k that is usually administrator and on unix 
that is usually root. But there is nothing wrong w/ that being a user Wheel 
that maintains the package suite and does not touch hardware.

wrt regchrome: I still don't have it, so you can't call that fixed until it 
appears in the win32 .zips

Leaf: any thoughts?
Shaver: actually, you *can* install profile chrome using XPInstall. To unpack 
the files you'd want to use getFolder("Profile") to get the currently running 
profile's directory (or perhaps getFolder("Profile","chrome")), then in the 
call to registerChrome() you'd want to OR in PROFILE_CHROME as part of the 
first type argument.

So...
   dest = getFolder("Profile","chrome");
   addFile("","myapp.jar",dest,"");
   registerChrome(PACKAGE | PROFILE_CHROME, dest);

assuming myapp.jar has a manifest.rdf at the top level. If you've got 
contents.rdf scattered throughout you'd have to call the 3-arg form of 
registerChrome() once for each contents.rdf
           getFold
svn: moving component.reg to the user profile misses one important point -- if 
the admin adds a new component all the user component.reg files are now out of 
date. To make this work we'd have to turn "AutoReg" back on in optimized 
builds, and we turned it off specifically because of startup time issues.

I'd argue we need to add a local component.reg to support local components, but 
should keep the global component.reg for globally installed components.
regchrome.cpp isn't even apparently built on non-unix systems (which explains
the absence in windows builds). Are you sure this is the tool you need?
It is very Unixish to read global and then local config files so I agree
that there should always be a global component.reg. I think it would be
a mistake to move it to ~/.mozilla.

You might be interested in my comment to bug 42184 which makes regchrome
necessary but very useful.
*** Bug 56616 has been marked as a duplicate of this bug. ***
There's enough Netscape people cc'ed on this bug that I'm just going to put this
here.  We need to also do something similar for Mozilla so this is relevant to
bugzilla.  Someone from Netscape please open a bug for this in bugscape.  I'm
even going to attach this patch to make it clearer.  This message needs to be in
notes that you see when you install not just in the relnotes.  We should change
the default install location for the mozilla installer also.

diff -u netscape-installer/README netscape-installer.new/README
--- netscape-installer/README	Fri Sep 29 13:25:33 2000
+++ netscape-installer.new/README	Sun Oct 15 18:52:52 2000
@@ -64,6 +64,12 @@
 exit all programs before running the setup program. Also, you
 should temporarily disable virus-detection software.

+If installing Netscape 6 on a multi-user operating system such as
+Linux, Unix, or Windows 2000, you should install it separately in
+the user directory of each user who plans to use the program.  If
+you install Netscape in a shared write-protected directory, it may
+not run properly.
+
 Install into a clean (new) directory. Installing on top of released
 product builds may cause problems.

diff -u netscape-installer/config.ini netscape-installer.new/config.ini
--- netscape-installer/config.ini	Tue Oct  3 17:50:54 2000
+++ netscape-installer.new/config.ini	Sun Oct 15 18:54:08 2000
@@ -1,7 +1,7 @@
 ;-------------------------------------------------------------------------
 [General]
 ;-------------------------------------------------------------------------
-Default Location=/usr/local/netscape
+Default Location=$HOME/netscape
 ; *** LOCALIZE ME BABY ***
 Title=Netscape Installer
To address David Krause's last comment: I am convinced that there is enough 
installer behavior difference expected that we should ask the installer user at 
startup (through the shell script or the GUI) whether the install is intended to 
be an administrator install or end-user install and present a user experience 
accordingly.  Feature for the next rev.
> Feature for the next rev.

David Krause's patch makes a lot of sense to me *right now*..

Currently, the installer defaults to a patch that will not work. What sense does
this make?

Filed bug 56811.
Depends on: 56811
Assuming that one has worked around bug 42184 then what exactly is broken these
days when *running* mozilla from a read-only directory? The only things I see are
PSM, component registration, and maybe skin stuff. I can't see how changing the
default _installation_ path does anything more than paper over the issue.

I also don't see how describing mozilla's inability to deal with OS security
issues is going to inspire confidence about the product. But what do I know?
Forgot to add that private copies of mozilla also means private copies of all
those shared libraries. Mozilla sometimes grows to >50MB when I read mail.
Imagine the fun when three or more users do so.
Temthumbs, please keep the discussion about bug 56811 in that bug.
I don't think David Krause's patch makes sense.  We _should_ mention, in the
install notes, the need to run regxpcom and regchrome after install (initial and
component), but I don't think we should be encouraging people to put Mozilla in
their user directories.

David, do you want to whip up text about running regxpcom and regchrome
(assuming that we get regchrome building on Windows)?  I think that would make
this bug be a lot less mostfreq.

For the next release -- perhaps meaning Mozilla 1.0 -- we might want a
command-line xpinstall utility, such that system administrators wouldn't have to
run Big Bad Mozilla to install software for their users.  (I agree that they
should be nervous about running Mozilla as root -- I would be.)  If people are
interested in such an idea, please file another bug in which to discuss it, and
reference it here (perhaps as a dependency).
I've attached a patch for the install docs.  It only covers the linux install,
until we find out about regchrome on windows.  I assume that Mac OSX also has
this problem.

Comments on the wording, maybe someone would like to make it sound better?
Also, I just noticed that it didn't linewrap.

If we document this well enough, then I agree my previous patch may not be
needed.  Just trying to throw out all the possible solutions.
I believe a command line utility is within reach right now.
shaver, this is what bug 42184 is about.
Depends on: 57089
No longer depends on: 57089
*** Bug 55169 has been marked as a duplicate of this bug. ***
*** Bug 57538 has been marked as a duplicate of this bug. ***
Keywords: relnote2, relnote3
Whiteboard: [nsbeta2-][nsbeta3-][dogfood-] suntrak-n6[rtm-] → [nsbeta2-][nsbeta3-][dogfood-] suntrak-n6[rtm-] relnote-user
Keywords: ns601
Running regxpcom and regchrome as root after install (of M18) is not sufficient
to avoid the problem when running mozilla as regular user.

# diff -r package.orig/ package
Only in package/chrome: all-locales.rdf
Only in package/chrome: all-packages.rdf
Only in package/chrome: all-skins.rdf
Only in package/chrome: overlayinfo
Binary files package.orig/component.reg and package/component.reg differ

some files are still missing:

package/chrome/user-locales.rdf
package/chrome/user-skins.rdf

There may be other problems too, but this is sufficient to prevent a clean
install.
Erm no
iirc user-*.rdf should land in the user profile directory not in the app chrome 
directory
*** Bug 57539 has been marked as a duplicate of this bug. ***
erm yes.  Here's your repro steps...

cd /space/src
rm -rf package*
tar xvfz mozilla-i686-pc-linux-gnu-M18.tar.gz 
cp -pR package/ package.orig
chown -R root:root package
export MOZILLA_FIVE_HOME=/space/src/package
package/regxpcom 
## OUTPUT:
RegSelf Shift_JIS to Unicode converter complete
RegSelf EUC-JP to Unicode converter complete
RegSelf ISO-2022-JP to Unicode converter complete
RegSelf Unicode to Shift_JIS converter complete
RegSelf Unicode to EUC-JP converter complete
RegSelf Unicode to ISO-2022-JP converter complete
RegSelf Unicode to jis_0201 converter complete
RegSelf Unicode to jis_0208-1983 converter complete
RegSelf Unicode to jis_0212-1990 converter complete
RegSelf Unicode to Big5 converter complete
RegSelf Unicode to x-x-big5 converter complete
RegSelf Big5 to Unicode converter complete
## END OUTPUT
package/regchrome
## no output
## run as user, doesn't work. output:
MOZILLA_FIVE_HOME=/space/src/package
  LD_LIBRARY_PATH=/space/src/package
     LIBRARY_PATH=/space/src/package:/space/src/package/components
       SHLIB_PATH=/space/src/package
          LIBPATH=/space/src/package
       ADDON_PATH=/space/src/package
      MOZ_PROGRAM=/space/src/package/mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
wait ... wait ... wait ... <CTRL+C>
## kill zombie mozilla...
## now as root again:
diff -r package package.orig/
## OUTPUT:
Only in package/chrome: all-locales.rdf
Only in package/chrome: all-packages.rdf
Only in package/chrome: all-skins.rdf
Only in package/chrome: overlayinfo
Binary files package/component.reg and package.orig/component.reg differ
## END OUTPUT
chown -R leary:leary package
## run as user, runs fine
## OUTPUT:
MOZILLA_FIVE_HOME=/space/src/package
  LD_LIBRARY_PATH=/space/src/package
     LIBRARY_PATH=/space/src/package:/space/src/package/components
       SHLIB_PATH=/space/src/package
          LIBPATH=/space/src/package
       ADDON_PATH=/space/src/package
      MOZ_PROGRAM=/space/src/package/mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
Setting content window
*** Pulling out the charset
Loading page specified via openDialog
in SetSecurityButton
Document about:blank loaded successfully
we don't handle eBorderStyle_close yet... please fix me
start message pane with: http://www.mozilla.org/mailnews/start.html
In SortColumn
SetupCommandUpdateHandlers
in SetSecurityButton
in showthreads
In NewEditorWindow()...
failed to get command manager number 3
failed to get command manager number 2
Registering commands
Have Find = true
Have SpellChecker = false
we don't handle eBorderStyle_close yet... please fix me
failed to set webshell window
JavaScript error: 
chrome://communicator/content/bookmarks/bm-panel.js line 30: window._content has
no properties

wallet.crypto pref is missing from all.js
wallet.enabled pref is missing from all.js
imageblocker.enabled pref is missing from all.js
we don't handle eBorderStyle_close yet... please fix me
In EditorShutdown..

OnUnload from XUL
Clean up ...
we get here
## END OUTPUT
## now as root again:
diff -r package package.orig/
## OUTPUT:
Only in package/chrome: all-locales.rdf
Only in package/chrome: all-packages.rdf
Only in package/chrome: all-skins.rdf
Only in package/chrome: overlayinfo
Only in package/chrome: user-locales.rdf
Only in package/chrome: user-skins.rdf
Binary files package/component.reg and package.orig/component.reg differ
## END OUTPUT

<gak!>
Bug 42184 is the appropriate one for installation problems. It has more
information about the user-*.rdf issue.
There's been a regression. For a while, Mozilla would write the
chrome/user-*.rdf files to the current profile if they didn't exist. With a
110108 build, Mozilla is back to its old ways and tries to write to the global
location if and only if the original user had these files when he first ran
Mozilla.
Mozilla must write user-rdf files to the install dir for the global and 
communicator packages only.  That's what it's doing right now.  It will do it 
only the first time you run.  After that, it will write only to the profile.
I'm confused.

With the 1101 build, there are three cases:

1) user A has no $HOME/.mozilla. If user A unpacks and runs Mozilla,
then Mozilla creates the global user-*.rdf files and also creates local
ones in user A's profile. Other users can run user A's Mozilla whether
or not they have a profile of their own.

2) user A has a $HOME/.mozilla from a previous installation. There are
user-*.rdf files in the profile. In this case, running a new Mozilla
does *not* create the global files. If another user comes along and does
not have a profile of his own, then he's screwed when he tries to run
Mozilla because his instance tries to write into user A's directory
which, of course, fails. If yet another user happens to have a profile,
then she *can* run user A's Mozilla.

3) user A is a hacker and runs regxpcom, regchrome, and then creates
0-length global user-*.rdf files. As far as I can tell any user can use
this installation without apparent ill effect.

About a week ago, Mozilla was not writing global user-*.rdf files under
any condition. Maybe that was an error but it had nice side effects.
That's interesting. However, imo case 2 should not be supported behavior.  The 
release notes should say to behave like case 3 if you intend to share your 
install.  Otherwise, we have instructions for single users that say to delete 
your profile (yes we know that's disliked, there are other bugs on that) before 
installing/running mozilla.
*** Bug 44590 has been marked as a duplicate of this bug. ***
*** Bug 59034 has been marked as a duplicate of this bug. ***
Removing myself from cc's... this was release noted.
I want to make sure I'm understanding this properly. PSM is distributed under a 
restrictive license ("Redistribution Or Rental Not Permitted"). This means that 
it's impossible for a Linux distributor to make mozilla packages which contain 
PSM already installed and registered. And, there's no way for individual 
users to install it into their own directories. So, https won't work until the 
root user has manually gone through the web-based PSM install process on each 
machine. In a lab with 100 machines (not using NFS), this would be a fairly 
time-consuming procedure.

Furthermore, doing so goes directly against good Linux practice -- all files in 
/usr (excepting /usr/local) should be managed by the package manager (RPM, dpkg, 
whatever). Dumping stuff in the Mozilla bin dir without going through the 
package system is ugly and breaks things.

Am I missing something?

I've read through all of the comments on this bug, and realize it's been well 
hashed-out, but this seems significantly more important than minor/P5.
> PSM is distributed under a
> restrictive license ("Redistribution Or Rental Not Permitted")

No, PSM is under the MPL. Just the binary version distributed by iPlanet is
restrictive, just as Netscape 6 is.
*** Bug 62822 has been marked as a duplicate of this bug. ***
*** Bug 63231 has been marked as a duplicate of this bug. ***
Blocks: 65218
On Solaris there is a workaround for this available:
1. Create a temp. dir for registry files for each user:
  % mkdir $HOME/.mozilla/regtmp
2. Soft-link each file in /usr/local/mozilla5 (readonly) which requires r/w
permissions to /xfn/thisuser/fs/.mozilla/regtmp/

That should be all... :-)

Comments ?
*** Bug 66924 has been marked as a duplicate of this bug. ***
*** Bug 66924 has been marked as a duplicate of this bug. ***
*** Bug 69058 has been marked as a duplicate of this bug. ***
*** Bug 70664 has been marked as a duplicate of this bug. ***
Keywords: dogfoodnsdogfood
*** Bug 72004 has been marked as a duplicate of this bug. ***
Keywords: nsCatFood
Adding yet more keywords... shaver, are you still owning this issue in a 
meaningful sense (just want to know it's in good hands ;-)?

Gerv
The only ownership that needs to happen right now it to correct the (lying)
release notes.  Beyond that, I just sit here and suck up abuse.

(Why is this nsdogfood and nscatfood?  Are Netscape people not clever enough to
either use the installer or run regxpcom/regchrome after install?)
A key problem related to this is the inabilty for normal users to install
plugins. (Especially given that when one comes to a page that requires a plugin,
it prompts one to get the plugin and install it -- leading to very confused
users....)

Bug #45699
Shaver- One problem with "use the installer" is that large installations of
netscape are very difficult to roll out that way. Doing that on one machine is
fine; doing it across several thousand (in a corporate or university
environment) is a PITA. It is one of the key reasons why Duke's Office of
Information Technology has not yet done a rollout (or so I hear through the
grapevine.) So, it isn't a dogfood issue for those of us with one desktop but it
is for those with hundreds or thousands.
First off, I don't give a sweet fig about Netscape installations, so if the
suggestions here work only for Mozilla, I will not shed a single tear.

Now, as has been mentioned _repeatedly_ in this bug, it's quite possible to
  - install as root
  - not use the Mozilla installer
  - have it be runnable by non-root users
Chris Blizzard's RPMs do it, the Debian packages do it, I do it with a tarball
install, the world is a joyous and sunshiney place.  And as if that weren't
enough to make this a non-problem for those who actually want to solve the
problem, you can actually relocate the installed mozilla directory to another
machine -- people, including myself, worked hard to make paths in the registry
be related to the install dir, and Duke's IT department is welcome to the fruits
of our labour.

It might well not be trivial to install Mozilla on 1000 machines, but there's
not much about maintaining 1000 machines that _is_ trivial, and I think there
exists ample evidence that it's quite possible, and reasonable, to deploy
Mozilla ``correctly'' without the graphical installer.

Man, is my déja vu meter _pegged_.
Joining into the discussion...

Mike. You mention several Linux distributions for which it is possible to run as
non-root. But how about Solaris? Yes, there is a Solaris workaround posted in
this bug. Unfortunately, on our university Solaris network, xfn is disabled and
since I am not a sysadmin I cannot do anything about that except asking the
sysadmin to activate it. Since he is already swamped with work and it's not
considered an important issue this has not been done yet. Installing in users'
home directories isn't feasable because each student has a ~40MB quota limit.
See the problem?
What Solaris-specific issue?  You don't cite a bug, and I don't know what xfn
is, but I don't think there's anything Linux-specific about the techniques
employed by the RPM and Debian packages.  You could do the same thing in
whatever package format you choose for Solaris, or use the oft-mentioned
install-and-copy technique.

Can you elaborate here (or, better, file a _different_ bug about
Solaris-specific things setup bugs) as to why the techniques that work on a pile
of Linux distributions don't work for you?
Keywords: nsdogfood-
Keywords: nsdogfood
*** Bug 61715 has been marked as a duplicate of this bug. ***
Mike, 

The Solaris workaround I mentioned is from Roland Mainz, posted on 2001-01-16.
Perhaps I'm just too inexperienced to figure this out. But although I can run
regxpcom and regchrome as a user with write access, as a normal user this means
mozilla will hang at startup (no crash, just a freeze after plugin
registration). I don't know what techniques are used in Blizzards' RPMs but sure
as hell they are not going to work on Solaris. If there is a solution then I
obviously missed it and would like a reference to some FAQ where it is
mentioned. Thanks.
I've seen this hang before when I was first creating debian packages
I figured out that it only hangs if you don't set a default chrome to use
I have this in my postinst for mozilla and each of the peices that provides chrome


        /bin/rm -rf /usr/lib/mozilla/chrome/overlayinfo
        /bin/rm -f /usr/lib/mozilla/chrome/*.rdf
        /bin/mkdir -p /usr/lib/mozilla/chrome/overlayinfo
        /bin/rm -f /usr/lib/mozilla/component.reg
        for line in "skin,install,select,classic/1.0"
"locale,install,select,en-US"; do if grep -q $line
/usr/lib/mozilla/chrome/installed-chrome.txt; then :; else echo $line >>
/usr/lib/mozilla/chrome/installed-chrome.txt; fi; done
        env MOZILLA_FIVE_HOME=/usr/lib/mozilla /usr/bin/regxpcom >/dev/null
2>/dev/null
        env MOZILLA_FIVE_HOME=/usr/lib/mozilla /usr/bin/regchrome >/dev/null
2>/dev/null
*** Bug 74106 has been marked as a duplicate of this bug. ***
shaver: do you know which particular lying (Mozilla) release notes need updating 
so that you never have to hear about this again?

Gerv
Reinout:

The Solaris workaround posted by Roland should not be necessary, just as it
isn't necessary on any other Unix.  I'm not sure what he was thinking, to be honest.

How can you be ``sure as hell'' that Blizzard's techniques won't work on
Solaris, when you are apparently completely ignorant of those techniques? 
Unless Solaris differs from Linux with respect to fundamental Unix filesystem
semantics, or there is some _extremely_ subtle bug in the XPCOM registration,
they should certainly work. If they do not, you should either a) file a bug
detailing the specific behaviour that you see on Solaris that leads to this
problem, or b) go away.

You give next to no information as to what's happening with your build, just
that it ``hangs'' after printing some random message to the console.  Are you by
any chance attempting to use a DEBUG build here, which will always auto-register
unless you set an environment variable?  If so, I respectfully suggest that you
stick to mozilla.org builds.

Gerv: Last I checked, the release notes recommended that Mozilla be installed in
each person's home directory, and didn't mention the regxpcom or regchrome
utilities for setting up the Mozilla installation for non-installing-user use. 
I'll try and send some corrected text today.

All: as I have seen no evidence that a properly-installed Mozilla will actually
attempt the heinous sin mentioned in the summary (and I do quite believe that
such a thing would be a serious bug), I'm updating the summary to indicate the
real issue, which is one of installer education.  If you have comments regarding
the text that should be in updated release notes, please comment in this bug. 
If you have comments regarding a perceived failure by Mozilla, on your platform,
to avoid autoregistration in a properly-installed setup, please file another
bug, against me, with exhausting details of your installation process, and
attach a truss/strace/etc. log detailing the attempts to write to the directory.

Thank you all for your contributions.
Summary: Mozilla should not need write access to the binary directory → Release notes should better describe multi-user installation process
> The Solaris workaround posted by Roland should not be necessary, just as it
> isn't necessary on any other Unix.  I'm not sure what he was thinking, to be 
> honest.

The idea is to move the registration files into a directory which is r/w for the
user which likes to use Mozilla. The "tricky" point is that this must not be a
file shared by all users, otherwise corruption will occur sooner or later.
Solaris FNS/XFN implementation has a nice feature somewhere burried in the
automounter which links /xfn/thisuser/fs/ everytimes to the homedir of the
requesting EUID.
The idea is simple (uhm... for people with FNS/XFN/NIS+ programming
experience... =:-):
1. List /xfn/thisuser as user "snail":
-- snip --
snail@castor/home/snail% ls -ld /xfn/thisuser
lr-xr-xr-x 1 root root 1 Apr  3 18:43 /xfn/thisuser -> user/snail
-- snip --
2. List /xfn/thisuser as user "mozilla":
-- snip --
mozilla@castor/home/mozilla% ls -ld /xfn/thisuser
lr-xr-xr-x 1 root root 1 Apr  3 18:46 /xfn/thisuser -> user/mozilla
-- snip --

/xfn/user/${LOGNAME}/fs/ is always an equivalent for ${HOME}. 
The Mozilla binaries cannot use $HOME - but /xfn/thisuser/fs/ may be used
instead to access users home directory.

Create softlinks for the registration files which need r/w permissions and link
this stuff to a temp. dir in users home dir (CDE users may use
/xfn/thisuser/fs/.dt/tmp/) or /xfn/thisuser/fs/.mozilla/ (question is if
registration is "smart" enougth to create non-existing dirs first...)...

Thanks all... :-)

P.S.: this only works if FNS/XFN has been configured first - othwise /xfn
directory is mainly empty... ;-((
> The Solaris workaround posted by Roland should not be necessary, just as it
> isn't necessary on any other Unix.  I'm not sure what he was thinking, to be 
> honest.

The idea is to move the registration files into a directory which is r/w for the
user which likes to use Mozilla. The "tricky" point is that this must not be a
file shared by all users, otherwise corruption will occur sooner or later.
Solaris FNS/XFN implementation has a nice feature somewhere burried in the
automounter which links /xfn/thisuser/fs/ everytimes to the homedir of the
requesting EUID.
The idea is simple (uhm... for people with FNS/XFN/NIS+ programming
experience... =:-):
1. List /xfn/thisuser as user "snail":
-- snip --
snail@castor/home/snail% ls -ld /xfn/thisuser
lr-xr-xr-x 1 root root 1 Apr  3 18:43 /xfn/thisuser -> user/snail
-- snip --
2. List /xfn/thisuser as user "mozilla":
-- snip --
mozilla@castor/home/mozilla% ls -ld /xfn/thisuser
lr-xr-xr-x 1 root root 1 Apr  3 18:46 /xfn/thisuser -> user/mozilla
-- snip --

/xfn/user/${LOGNAME}/fs/ is always an equivalent for ${HOME}. 
The Mozilla binaries cannot use $HOME - but /xfn/thisuser/fs/ may be used
instead to access users home directory.

Create softlinks for the registration files which need r/w permissions and link
this stuff to a temp. dir in users home dir (CDE users may use
/xfn/thisuser/fs/.dt/tmp/) or /xfn/thisuser/fs/.mozilla/ (question is if
registration is "smart" enougth to create non-existing dirs first...)...

Thanks all... :-)

P.S.: this only works if FNS/XFN has been configured first - othwise /xfn
directory is mainly empty... ;-((
Updated release notes should mention bug #45699 -- plug-ins can't be installed
on a per-user basis. That seems to be the most serious remaining issue related
to this. (As always, IMHO....)
This bug does not depend on the ``install to homedir'' bug (56811).  I think
that bug should be marked WONTFIX or FIXED, since the release notes currently do
the (wrong) thing that's mentioned in there.

The W2K-specific (and Netscape-specific!) issues in 56249 are well-described in
that bug, and I think discussion of that issue should be moved there.

Ditto for 54904, which is a request for a better solution to Myth's
installed-chrome hack.  49272 is basically the same bug.

39808 is a non-bug, as far as I can tell: the XPT caching code does what XPCOM
does, so use of regxpcom is sufficient.

So, I'm closing this bug, because it's a horrible waste of people's time. 
Nobody, it seems, is willing to read the complete history.  I've filed bug 74574
to track the release note change; please cc: yourself to your heart's content.

(Matthew: the 4xp plugin-install issue will certainly be mentioned.  Thanks.)

Status: ASSIGNED → RESOLVED
Closed: 24 years ago23 years ago
Depends on: 9282
No longer depends on: 39282, 56811
Resolution: --- → FIXED
Mike:

> How can you be ``sure as hell'' that Blizzard's techniques won't work on
> Solaris, when you are apparently completely ignorant of those techniques? 

I was referring to specific RPMs for Linux, that obviously will not install or
run on Solaris. Furthermore I have only used release builds from mozilla.org
(mirrors). The post-install procedure described by Myth I will try as soon as
0.8.1 for solaris/sparc is available.

Reinout: the binary RPMs wouldn't work, but the source RPMs actually might --
RPM is available for Solaris and many other platforms (see http://www.rpm.org/).
But that's not the real point -- the *techniques* used certainly would work.
changing QA contact
QA Contact: gbush → scc
"Release notes should better describe multi-user installation process"

Bug is marked as FIXED -- this just does noot like it is ....

Or alternatively Summary is incorrect and "Release notes should better 
describe multi-user installation process" belong to some other bug.


mozilla-installer/README on BUild ID 2001122108 reads:
========================================================================
*Installation Instructions -- Unix
 
        1.Create a directory named "mozilla" and move the tar.gz file
        into the mozilla directory.
 
                mkdir mozilla;
                mv mozilla*.tar.gz mozilla
 
        2.Change to the mozilla directory and untar the archive. This will
        create a directory called "package".
 
                cd mozilla;
                gzip -dc mozilla-i686-pc-linux-gnu.tar.gz | tar -xvf -
 
        3.Change to the "package" directory.
 
                mv mozilla*.tar.gz ../ ;
                cd package
 
        4.Run the Mozilla Preview Release software with the run script:
 
                ./mozilla                                

==========================================================================
mozilla-installer directoru is created when extrack 
mozilla-i686-pc-linux-gnu-0.9.7-sea.tar.gz .

That text is zero relevance to that what need to be done. 

Instead I do wollowing:

             cd mozilla-installer directory

             Run mozilla-installer as root.

posted Bug 116669 references to mozilla directory should be changed to mozilla-
installer based on comment 151.  If people have issues small or large they 
should file new bugs.
Keywords: arch, nsbeta2, nsbeta3
Whiteboard: [nsbeta2-][nsbeta3-][dogfood-] suntrak-n6[rtm-] relnote-user → relnote-user [rtm-] suntrak-n6
*** Bug 49345 has been marked as a duplicate of this bug. ***
*** Bug 49345 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.