Last Comment Bug 41057 - Release notes should better describe multi-user installation process
: Release notes should better describe multi-user installation process
Status: RESOLVED FIXED
relnote-user [rtm-] suntrak-n6
: meta, relnote
Product: Core
Classification: Components
Component: XPCOM (show other bugs)
: Trunk
: All All
: P5 minor with 16 votes (vote)
: Future
Assigned To: Mike Shaver (:shaver -- probably not reading bugmail closely)
: Scott Collins
Mentors:
: 41541 44590 49345 55169 55208 56081 56256 57538 57539 59034 61715 62822 63231 66924 69058 70664 72004 74106 (view as bug list)
Depends on: 42792 54904 9282 16600 33344 39289 39808 42148 43091 49507 51240 55419 56429
Blocks: 65218
  Show dependency treegraph
 
Reported: 2000-05-30 20:21 PDT by David Krause
Modified: 2016-04-24 09:01 PDT (History)
41 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Trial patch which moves bin/component.reg to ~/.mozilla/component.reg (2.35 KB, patch)
2000-10-10 09:57 PDT, R. Saravanan
no flags Details | Diff | Splinter Review
Patch for install docs per Mike Shaver's suggestion. (1.13 KB, patch)
2000-10-17 09:53 PDT, David Krause
no flags Details | Diff | Splinter Review

Description David Krause 2000-05-30 20:21:13 PDT
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
Comment 1 Eliot Landrum 2000-06-05 18:51:56 PDT
*** Bug 41541 has been marked as a duplicate of this bug. ***
Comment 2 Asa Dotzler [:asa] 2000-06-06 17:23:07 PDT
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
Comment 3 David Krause 2000-06-10 11:13:05 PDT
reassigning to build config per doron's suggestion
Comment 4 cls 2000-06-10 13:31:23 PDT
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.
Comment 5 Ben Bucksch (:BenB) 2000-06-10 17:46:29 PDT
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.
Comment 6 Ben Bucksch (:BenB) 2000-06-10 18:14:25 PDT
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?
Comment 7 Daniel Veditz [:dveditz] 2000-06-11 09:43:14 PDT
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.
Comment 8 David Krause 2000-06-11 15:05:45 PDT
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.
Comment 9 Ben Bucksch (:BenB) 2000-06-11 15:29:19 PDT
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.
Comment 10 Ben Bucksch (:BenB) 2000-06-11 15:48:14 PDT
OK, making this the tracking bug for normal runs by users. Filed bug 42184 about
the install binary.

Where did the Architecture component go?
Comment 11 Warren Harris 2000-06-11 18:32:56 PDT
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.
Comment 12 Jon Granrose 2000-06-12 08:57:07 PDT
definitely not a build config issue.  punting to installer and reassigning to 
default component owner.
Comment 13 Daniel Veditz [:dveditz] 2000-06-12 09:06:54 PDT
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.
Comment 14 leger 2000-06-12 17:47:38 PDT
Not sure what open issue is here.  Can you clarify?
Comment 15 Daniel Veditz [:dveditz] 2000-06-12 17:55:23 PDT
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.
Comment 16 leger 2000-06-13 17:47:25 PDT
Putting on [nsbeta2+] radar for beta2 fix. 
Comment 17 Warren Harris 2000-06-15 23:59:40 PDT
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.
Comment 18 David Hyatt 2000-06-19 01:09:01 PDT
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.

Comment 19 Peter Trudelle 2000-06-20 16:39:35 PDT
Adding the '+' to [nsbeta2], per leger's comment
Comment 20 David Hyatt 2000-06-20 17:06:02 PDT
I removed the + after her last comment.
Comment 21 Jay Patel [:jay] 2000-06-21 13:41:44 PDT
Putting on [nsbeta2-] radar. Not critical to beta2. 
Comment 22 Ben Bucksch (:BenB) 2000-06-21 13:57:32 PDT
> We can do it in beta3.

OK, nominating for nsbeta3
Comment 23 Peter Trudelle 2000-07-27 16:44:27 PDT
skin-switching problem is fixed. resolving as fixed per hyatt.
Comment 24 Ben Bucksch (:BenB) 2000-07-27 16:57:25 PDT
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.
Comment 25 Ben Bucksch (:BenB) 2000-07-27 16:57:58 PDT
/
Comment 26 Richard Zach 2000-07-29 17:56:15 PDT
Note that it seems that you can't run mailnews unless you have write access to
the bianry directory.
Comment 27 Ben Bucksch (:BenB) 2000-07-29 18:01:40 PDT
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.
Comment 28 Richard Zach 2000-07-30 10:58:19 PDT
/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.
Comment 29 Ben Bucksch (:BenB) 2000-07-30 19:45:57 PDT
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).
Comment 30 Ben Bucksch (:BenB) 2000-07-30 20:11:47 PDT
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.
Comment 31 Ben Bucksch (:BenB) 2000-07-30 20:18:05 PDT
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.
Comment 32 Warren Harris 2000-07-31 13:57:27 PDT
See possibly related bug 42184, Mozilla-bin must not write to bin dir during 
installation.
Comment 33 Warren Harris 2000-07-31 21:24:13 PDT
Taking this back from nobody@mozilla.org
Comment 34 David Krause 2000-08-07 22:27:16 PDT
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.
Comment 35 Ben Bucksch (:BenB) 2000-08-08 00:03:13 PDT
David, that would be bug 42184.
Comment 36 Doug Collinge 2000-08-31 19:20:07 PDT
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.
Comment 37 WD 2000-09-05 08:50:20 PDT
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!
Comment 38 Richard Zach 2000-09-05 09:05:10 PDT
Adding dependency: bug 49507 (nsbeta3, P4): PSM does not work if Mozilla doesn't
run as root. CC: ddrinan@netscape.com
Comment 39 Doug Collinge 2000-09-05 11:39:38 PDT
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.
Comment 40 Ben Bucksch (:BenB) 2000-09-05 12:17:37 PDT
Adding mostfreq. This propduces completely confusing problems, in which many
users run.
Comment 41 cls 2000-09-05 17:41:54 PDT
*** Bug 51164 has been marked as a duplicate of this bug. ***
Comment 42 Ben Bucksch (:BenB) 2000-09-22 09:49:54 PDT
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.
Comment 43 Ben Bucksch (:BenB) 2000-09-22 09:53:01 PDT
Because many, many users ("testers") run into this problem, marking DOGFOOD,
finally.
Comment 44 Warren Harris 2000-09-22 17:09:05 PDT
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?
Comment 45 Phil Peterson 2000-09-27 23:07:58 PDT
Not holding PR3 for this; marking nsbeta3-.
Comment 46 Jim Roskind 2000-09-28 13:31:06 PDT
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.
Comment 47 WD 2000-10-01 09:57:07 PDT
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
Comment 48 R.K.Aa. 2000-10-01 11:11:49 PDT
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)
Comment 49 R.K.Aa. 2000-10-01 22:23:09 PDT
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)
Comment 50 Tobias Burnus 2000-10-02 05:36:38 PDT
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.)
Comment 51 Daniel Veditz [:dveditz] 2000-10-02 10:02:45 PDT
It's nsbeta3- because that ship has already sailed. If it gets [rtm-] we're 
dead.
Comment 52 Ben Bucksch (:BenB) 2000-10-02 12:21:52 PDT
> 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 :).
Comment 53 Ben Bucksch (:BenB) 2000-10-02 12:26:07 PDT
> I will take some time

s/I/It/ *g*
Comment 54 Adam Sjøgren 2000-10-04 09:20:26 PDT
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.
Comment 55 verah (gone) 2000-10-04 11:43:16 PDT
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.
Comment 56 Matthew Paul Thomas 2000-10-04 16:08:55 PDT
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. :-/
Comment 57 Akkana Peck 2000-10-04 17:57:20 PDT
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.
Comment 58 Doug Collinge 2000-10-04 19:09:46 PDT
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?
Comment 59 Ben Bucksch (:BenB) 2000-10-05 10:35:50 PDT
> 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".)
Comment 60 Aleksander Adamowski 2000-10-06 01:41:41 PDT
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.
Comment 61 Warren Harris 2000-10-06 08:03:53 PDT
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.
Comment 62 tdanner 2000-10-06 11:03:02 PDT
Adding cc
Comment 63 verah (gone) 2000-10-06 13:24:31 PDT
Matthew, thanks for the explanation for the release notes!
Comment 64 Asa Dotzler [:asa] 2000-10-06 17:54:52 PDT
*** Bug 55208 has been marked as a duplicate of this bug. ***
Comment 65 cls 2000-10-08 14:44:44 PDT
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?

Comment 66 Ben Bucksch (:BenB) 2000-10-08 15:45:55 PDT
cls, see bug 51677 (Ship pre-generated chrome files if possible).
Comment 67 Daniel Veditz [:dveditz] 2000-10-08 22:58:44 PDT
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.
Comment 68 R. Saravanan 2000-10-09 09:45:27 PDT
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?)
Comment 69 Daniel Veditz [:dveditz] 2000-10-09 11:24:03 PDT
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.
Comment 70 R. Saravanan 2000-10-10 09:54:53 PDT
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.
Comment 71 R. Saravanan 2000-10-10 09:57:30 PDT
Created attachment 16651 [details] [diff] [review]
Trial patch which moves bin/component.reg to ~/.mozilla/component.reg
Comment 72 Ben Bucksch (:BenB) 2000-10-10 10:39:16 PDT
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.
Comment 73 Warren Harris 2000-10-10 17:08:22 PDT
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.
Comment 74 Warren Harris 2000-10-10 17:12:59 PDT
*** Bug 42184 has been marked as a duplicate of this bug. ***
Comment 75 Asa Dotzler [:asa] 2000-10-11 15:35:19 PDT
*** Bug 56081 has been marked as a duplicate of this bug. ***
Comment 76 robin shaw 2000-10-12 10:44:23 PDT
*** Bug 56256 has been marked as a duplicate of this bug. ***
Comment 77 R.K.Aa. 2000-10-12 12:37:11 PDT
*** Bug 56256 has been marked as a duplicate of this bug. ***
Comment 78 Peter Trudelle 2000-10-12 23:36:54 PDT
rtm-/future, no time left for this.
Comment 79 Matthew Paul Thomas 2000-10-13 03:23:46 PDT
> If it gets [rtm-] we're dead.

relnoteRTM ...
Comment 80 Jason Eager 2000-10-13 03:58:01 PDT
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.
Comment 81 WD 2000-10-13 05:30:02 PDT
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> 
Comment 82 Mike Shaver (:shaver -- probably not reading bugmail closely) 2000-10-13 06:43:10 PDT
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.
Comment 83 timeless 2000-10-13 07:53:09 PDT
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.
Comment 84 Ben Bucksch (:BenB) 2000-10-13 09:27:29 PDT
> 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.
Comment 85 Frank Belew 2000-10-13 09:44:05 PDT
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.
Comment 86 Mike Shaver (:shaver -- probably not reading bugmail closely) 2000-10-13 10:01:54 PDT
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.)
Comment 87 David Hyatt 2000-10-13 10:29:45 PDT
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.
Comment 88 Mike Shaver (:shaver -- probably not reading bugmail closely) 2000-10-13 11:24:20 PDT
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?
Comment 89 R. Saravanan 2000-10-13 12:13:15 PDT
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?
Comment 90 timeless 2000-10-13 13:30:37 PDT
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?
Comment 91 Daniel Veditz [:dveditz] 2000-10-13 13:36:38 PDT
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
Comment 92 Daniel Veditz [:dveditz] 2000-10-13 13:50:40 PDT
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.
Comment 93 Daniel (Leaf) Nunes 2000-10-13 17:07:35 PDT
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?
Comment 94 tenthumbs 2000-10-14 07:41:01 PDT
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.
Comment 95 Mike Shaver (:shaver -- probably not reading bugmail closely) 2000-10-14 13:27:03 PDT
*** Bug 56616 has been marked as a duplicate of this bug. ***
Comment 96 David Krause 2000-10-15 16:53:39 PDT
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
Comment 97 Samir Gehani 2000-10-16 01:28:05 PDT
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.
Comment 98 Ben Bucksch (:BenB) 2000-10-16 06:50:10 PDT
> 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.
Comment 99 tenthumbs 2000-10-16 08:00:46 PDT
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?
Comment 100 tenthumbs 2000-10-16 08:45:17 PDT
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.
Comment 101 Ben Bucksch (:BenB) 2000-10-16 09:22:42 PDT
Temthumbs, please keep the discussion about bug 56811 in that bug.
Comment 102 Mike Shaver (:shaver -- probably not reading bugmail closely) 2000-10-17 09:28:19 PDT
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).
Comment 103 David Krause 2000-10-17 09:53:09 PDT
Created attachment 17340 [details] [diff] [review]
Patch for install docs per Mike Shaver's suggestion.
Comment 104 David Krause 2000-10-17 10:00:53 PDT
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.
Comment 105 tenthumbs 2000-10-17 10:09:00 PDT
I believe a command line utility is within reach right now.
Comment 106 Ben Bucksch (:BenB) 2000-10-17 10:11:11 PDT
shaver, this is what bug 42184 is about.
Comment 107 Asa Dotzler [:asa] 2000-10-19 17:43:21 PDT
*** Bug 55169 has been marked as a duplicate of this bug. ***
Comment 108 Minko Markov 2000-10-22 16:20:45 PDT
*** Bug 57538 has been marked as a duplicate of this bug. ***
Comment 109 Michael Leary 2000-10-27 10:53:03 PDT
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.
Comment 110 timeless 2000-10-27 11:36:49 PDT
Erm no
iirc user-*.rdf should land in the user profile directory not in the app chrome 
directory
Comment 111 Asa Dotzler [:asa] 2000-10-27 16:13:00 PDT
*** Bug 57539 has been marked as a duplicate of this bug. ***
Comment 112 Michael Leary 2000-10-28 14:09:31 PDT
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!>
Comment 113 tenthumbs 2000-10-28 14:15:09 PDT
Bug 42184 is the appropriate one for installation problems. It has more
information about the user-*.rdf issue.
Comment 114 tenthumbs 2000-11-02 07:16:27 PST
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.
Comment 115 David Hyatt 2000-11-02 10:29:39 PST
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.
Comment 116 tenthumbs 2000-11-02 14:25:58 PST
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.
Comment 117 timeless 2000-11-02 19:12:19 PST
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.
Comment 118 Sitsofe Wheeler 2000-11-05 09:34:39 PST
*** Bug 44590 has been marked as a duplicate of this bug. ***
Comment 119 Dan Stromberg 2000-11-06 10:50:18 PST
*** Bug 59034 has been marked as a duplicate of this bug. ***
Comment 120 verah (gone) 2000-11-30 17:29:47 PST
Removing myself from cc's... this was release noted.
Comment 121 Matthew Miller 2000-12-02 15:16:46 PST
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.
Comment 122 Ben Bucksch (:BenB) 2000-12-02 16:07:05 PST
> 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.
Comment 123 timeless 2000-12-14 13:35:33 PST
*** Bug 62822 has been marked as a duplicate of this bug. ***
Comment 124 Arne Bergseth 2001-01-08 13:59:46 PST
*** Bug 63231 has been marked as a duplicate of this bug. ***
Comment 125 Roland Mainz 2001-01-16 14:51:42 PST
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 ?
Comment 126 Randy Oo 2001-02-11 07:49:06 PST
*** Bug 66924 has been marked as a duplicate of this bug. ***
Comment 127 Randy Oo 2001-02-11 07:49:31 PST
*** Bug 66924 has been marked as a duplicate of this bug. ***
Comment 128 Bob McElrath 2001-02-16 11:48:41 PST
*** Bug 69058 has been marked as a duplicate of this bug. ***
Comment 129 timeless 2001-03-01 20:17:24 PST
*** Bug 70664 has been marked as a duplicate of this bug. ***
Comment 130 Boris Zbarsky [:bz] (TPAC) 2001-03-15 14:13:59 PST
*** Bug 72004 has been marked as a duplicate of this bug. ***
Comment 131 Gervase Markham [:gerv] 2001-03-20 06:22:31 PST
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
Comment 132 Mike Shaver (:shaver -- probably not reading bugmail closely) 2001-03-20 09:37:22 PST
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?)
Comment 133 Matthew Miller 2001-03-20 10:22:43 PST
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
Comment 134 Luis Villa 2001-03-20 10:30:59 PST
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.
Comment 135 Mike Shaver (:shaver -- probably not reading bugmail closely) 2001-03-20 11:17:08 PST
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_.
Comment 136 Reinout van Schouwen 2001-03-20 13:04:26 PST
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?
Comment 137 Mike Shaver (:shaver -- probably not reading bugmail closely) 2001-03-20 13:43:43 PST
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?
Comment 138 timeless 2001-03-28 10:34:09 PST
*** Bug 61715 has been marked as a duplicate of this bug. ***
Comment 139 Reinout van Schouwen 2001-03-30 08:40:35 PST
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.
Comment 140 Frank Belew 2001-03-30 10:39:46 PST
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
Comment 141 Boris Zbarsky [:bz] (TPAC) 2001-03-30 12:10:40 PST
*** Bug 74106 has been marked as a duplicate of this bug. ***
Comment 142 Gervase Markham [:gerv] 2001-04-01 09:01:39 PDT
shaver: do you know which particular lying (Mozilla) release notes need updating 
so that you never have to hear about this again?

Gerv
Comment 143 Mike Shaver (:shaver -- probably not reading bugmail closely) 2001-04-03 09:06:16 PDT
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.
Comment 144 Roland Mainz 2001-04-03 09:53:23 PDT
> 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... ;-((
Comment 145 Roland Mainz 2001-04-03 10:14:36 PDT
> 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... ;-((
Comment 146 Matthew Miller 2001-04-03 10:56:08 PDT
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....)
Comment 147 Mike Shaver (:shaver -- probably not reading bugmail closely) 2001-04-03 11:55:17 PDT
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.)

Comment 148 Reinout van Schouwen 2001-04-03 14:35:08 PDT
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.

Comment 149 Matthew Miller 2001-04-03 18:18:33 PDT
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.
Comment 150 Grace Bush 2001-04-04 11:08:05 PDT
changing QA contact
Comment 151 Kari Hurtta 2001-12-23 00:43:56 PST
"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.

Comment 152 timeless 2001-12-23 06:42:40 PST
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.
Comment 153 Diego Biurrun 2002-06-25 10:36:55 PDT
*** Bug 49345 has been marked as a duplicate of this bug. ***
Comment 154 Diego Biurrun 2002-07-01 02:59:30 PDT
*** Bug 49345 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.