74574 - Release notes should better describe multi-user installation process

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[Mike Shaver (:shaver emeritus)]

To save us from 41057, and clearly describe the limitations of our current system.

Comment 1

[Gervase Markham [:gerv]]

I got the following mail re: The Bug Which Must Not Be Named, so I'm attaching 
it here in case it's useful in formulating the release notes.

Gerv

<snip>

Subject: [[e-mail]: [Bug 41057] - Mozilla should not need 
write access to the binary directory]
   Date: Mon, 2 Apr 2001 08:34:03 -0700
   From: Doug McMahon <[e-mail]>
     To: [e-mail]

Thanks, I've read this bug, which my initial search didn't turn up, and
I think I can see what's going on now.  Seems like to get things to work I
had to run mozilla once as "root" before any other user is allowed to run it.

You're correct, this is in the release notes, which I confess I did not
read carefully.  I stupidly assumed that mozilla would install just like
any other product on Linux, pretty much unzip it and you're good to go.
I also assumed that any further installation steps would be documented
somewhere in the zip file itself.  Here are some thoughts on how to
avoid this problem with future users:

  1. Please put the release notes in a README or relnotes.txt file
     as part and parcel of the unzipped image.  A lot of us just click
     on the download, and expect that anything we need to do in the
     way of setup will be documented in such a file.  I would certainly
     have read and understood the requirement to run once as root had
     such a file been present in the image.  I know I'm not the only
     person who made this error - several other Linux users I asked prior
     to filing the bug were unable to tell me this (of course, mozilla
     was working fine for them because they *always* ran stuff as root!).
  2. Can you make the failure mode a bit friendlier, e.g. some sort of
     useful error message?  The current failure mode where mozilla just
     seems to hang is inadequate - even the simplest hint might have
     alerted me to what was going on.
  3. Obviously I agree with several commenters in bugzilla that running
     once as root should not be necessary at all, and that it would be
     best if this requirement were removed entirely prior to the
     production release.

Comment 2

[Stuart Ballard]

I honestly don't understand why the release notes suggest running as root at
all, when there exists a solution that's so much simpler...

Why don't we put a script in the installed directory, called something like
"multiuser-install.sh" containing:

#!/bin/sh
cd `dirname "$0"`
MOZILLA_FIVE_HOME=.
LD_LIBRARY_PATH=.
export MOZILLA_FIVE_HOME LD_LIBRARY_PATH
./regxpcom
./regchrome
touch chrome/user-skins.rdf chrome/user-locales.rdf

Then we can just tell people that they should run that script before using the
program, and reference it from a README as described by the email quoted above.

I'd provide a patch but I don't know how to add a file in the build system that
would get copied verbatim to the installation directory and appear in the
tarballs. But I don't see why just adding the above script and a README is so
hard...

Comment 3

[Frank Belew]

Adding to CC

Comment 4

[Stuart Ballard]

I'm nominating this for 0.9.2, because:
1) It's primarily a documentation issue, not a coding issue.
2) It's a *small* documentation issue - just including, for example, the
contents of my script above in the release notes would solve it.
3) Even adding the script and a README would be pretty darn easy.
4) I'm fed up of making the same damn post on the newsgroups and slashdot and
gnotices and linuxtoday and everywhere else I see this same complaint come up
over and over and over. It's so EASY to run mozilla multiuser, but it's
completely undocumented except for some buried comments in the last bug and what
seems like several hundred posts by me on various forums.

Comment 5

[Gervase Markham [:gerv]]

Stuart - is this script for use with a tarball? Could it be automatically run by 
the installer in an installer build? What happens if a single-user runs it on 
their install? After they've used Moz for a bit?

Gerv

Comment 6

[Stuart Ballard]

It's for a tarball - I don't use the installers but I'd actually always assumed
they already did the equivalent of this. From my experience, though, unix people
tend to be scared of anything called an "installer" from windows experiences - I
know I am :)

I'm pretty sure that this script should be safe to use on an existing
installation, and it doesn't do anything beyond what running mozilla as root
would do. I don't know regxpcom or regchrome well enough to *guarantee* that
there are no circumstances when they can be harmful, but I doubt it (the only
way I can even imagine it hurting is if there were bad side-effects from chrome
packages or components that were installed from xpis, and even that seems a long
shot). I'm certain that this wouldn't do any harm even if the installation *was*
in a single user's home directory and owned by them, either.

Unfortunately, I only really know this works from experience - I had pulled it
out from deep in the comments of bug 41057 or one of the related bugs and found
it useful for several milestones now. I don't know who came up with it or *why*
it works, though :)

Comment 7

[Ben Bucksch (:BenB)]

I can confirm what Stuart said. The script is not harmful. The regchrome /
regxpcom apps do only what running mozilla-bin would do, and |touch| *is*
harmless. The user does no matter, as long as he can write (an error msg is
displayed otherwise). Installer users probably won't even notice the script,
but, as said, it wouldn't be harmful.
IMO, it is a no-brainer to include this script. It should have been done long ago.
(Ideally, the tarballs would ship with the files already sat up correctly, but
that's another bug.)

Comment 8

[Ben Bucksch (:BenB)]

As for the script, I'd do:

dist_bin=`dirname $0`
MOZILLA_FIVE_HOME=$dist_bin
LD_LIBRARY_PATH=$dist_bin
dist_bin/regxpcom
dist_bin/regchrome
touch dist_bin/chrome/user-skins.rdf dist_bin/chrome/user-locales.rdf

- No cd, because I don't know, if that will change the current dir in the user's
environment.
- No |export MOZILLA_FIVE_HOME LD_LIBRARY_PATH|, because there are security
reasons why the current dir is not in the default search paths and we shouldn't
change that in the user's environment without the user realizing.

Comment 9

[Gervase Markham [:gerv]]

Aren't you missing some $ signs in there?

Gerv

Comment 10

[Ben Bucksch (:BenB)]

yes, before "dist_bin", sorry.

Comment 11

[Reinout van Schouwen]

STILL not documented properly in the 0.9.2 release notes. 

Can someone with enough permissions add mozilla0.9.3 and 
relnote keywords? Everyone, please vote for this bug!

Comment 12

[Stephan Jaensch]

It's a pity that this bug hasn't been fixed long ago especially since it is so easy to fix. I know that Mozilla hasn't been deployed at our university because there is absolutely NO documentation about multi-user setup. This is certainly a prerequisite for university deployment.Adding keywords.

Comment 13

[Gervase Markham [:gerv]]

Please review:

<p>
<b>Multi-user installs</b>:
To install Mozilla for multiple users, install Mozilla as normal,
then create the following script in your
Mozilla directory, make it executable (<tt>chmod u+x scriptname</tt>), and run 
it.

<pre>
#!/bin/sh
$dist_bin=`dirname $0`
MOZILLA_FIVE_HOME=$dist_bin
LD_LIBRARY_PATH=$dist_bin
$dist_bin/regxpcom
$dist_bin/regchrome
touch $dist_bin/chrome/user-skins.rdf $dist_bin/chrome/user-locales.rdf
</pre>

(Bug <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=74574">74574</a>). 

You should then be able to run that installation of Mozilla as any user who has
permissions to access it.

</p>

Gerv

Comment 14

[Stuart Ballard]

1) The notes should mention that this script must be run as root.

2) If we aren't going to provide the script as part of the installation, they
might as well just run the commands themselves as root - it saves them having to
make the script and chmod it. So the release notes might as well just read:

To install Mozilla for multiple users, install Mozilla as normal, then run the
following commands as root in the directory you installed mozilla to:

LD_LIBRARY_PATH=.
MOZILLA_FIVE_HOME=.
export LD_LIBRARY_PATH MOZILLA_FIVE_HOME
./regxpcom
./regchrome
touch chrome/user-skins.rdf chrome/user-locales.rdf


The only reason for making a script is that we (the mozilla project) could
provide this script and thus save the users the effort of typing in all these
commands. If they have to type them into a script anyway, they might as well
just type them in directly.

3) I believe I saw in the Debian changelog that MOZILLA_FIVE_HOME is no longer
required. If someone can confirm this, we can shorten the script a bit.

4) Has anyone actually tried it without the "export" line? Based on my
understanding of how the shell works, the "export" is actually necessary.

Comment 15

[Per Olofsson]

Both the scripts have small bugs that make them incompatible with one platform
or another, so here's a new one that should work on all systems (I hope :)

  #!/bin/sh
  
  dist_bin=`dirname $0`
  MOZILLA_FIVE_HOME=$dist_bin
  LD_LIBRARY_PATH=$dist_bin
  export MOZILLA_FIVE_HOME LD_LIBRARY_PATH
  $dist_bin/regxpcom
  $dist_bin/regchrome
  touch $dist_bin/chrome/user-skins.rdf $dist_bin/chrome/user-locales.rdf

The export command is necessary, otherwise they're just internal shell variables
that won't be inherited. I also recommend against running commands like
LD_LIBRARY_PATH=. in your shell as it can have security implications or just
generally screw things up for inexperienced admins. In a script it'll be
executed in a subshell and LD_LIBRARY_PATH will be restored afterwards.

Comment 16

[timeless]

hrm, so where are the NT Relnotes for this bug? :-( I feel so left out.
Begin Relnote Proposal:
Installing applications on a multiuser system that is concerned about security 
means that you need to restrict write access to the application, on NT that 
usually means setting access controls (ACLs) ACLs aren't supported on 
FAT(12/16/32), so the following advise is for NTFS.  Ideally any network 
file/operating system that supplies drivers for NT will provide equivalency 
either at the driver level or at the application level to the features used 
here.

::Lines beginning w/ :: are comments, you do not need to enter them.
::You need to be some sort of administrator (probably just a power user)
::But you need to be able to control the directory containing mozilla
start runas /user:administrator cmd /k title "Configuring Mozilla for multiuser 
use."
::The next line is cheating, we're sorry but there's no real good way to do it
::so we ask you to drop mozilla into the command, you could just as easily 
::enter the path but it's kind of hard for us to suggest that because it could 
::look like just about anything.
for %a in (<drop mozilla.exe here>) do cd /d %~dpa
regxpcom
regchrome
for %a in (chrome\user-skins.rdf chrome\user-locales.rdf) do @(
:::use the following line if you have touch
::touch %a
:::otherwise you'll have to use this messy thing.
if not exist %a copy nul %a
)
::The following line is untested, use of this line is suggested only if you
::understand ACLs. If you see an error in this line please send mail to someone
::responsible for the relnotes because we don't like giving out bad advice.
CACLS /T /E /C /D /P Users:W .
CACLS /T /E /C /G "Power Users":C .
exit
::End Of Comment

-- and now back to our regularly scheduled confusion:
> The notes should mention that this script must be run as root.
actually this is rather wrong.  You should run as the user that installed 
mozilla (or some user who has at least as much access as that user). On linux 
this is typically root* but on many unices and on large multiuser installations 
is often _not_ root.  [* on Bastille'd Linuxes you shouldn't install mozilla as 
root - read the bastille docs].

--Is there another bug about installing components and themes etc?  Otherwise 
we should explain:
If you want additional components to be available to all users you should 
install them as the same user as owns/installed mozilla, for unix that probably 
means trusting mozilla to run because we probably haven't documented 
commandline installation of xpis.

Comment 17

[David Highley]

*** Bug 91277 has been marked as a duplicate of this bug. ***

Comment 18

[Gervase Markham [:gerv]]

I've added multi-user install release notes for Unix. The others seem
complicated enough to deserve their own document on www.mozilla.org.

Gerv

Comment 19

[Gervase Markham [:gerv]]

... so let's close this puppy.

Gerv