Closed Bug 74574 Opened 21 years ago Closed 21 years ago
Release notes should better describe multi-user installation process
To save us from 41057, and clearly describe the limitations of our current system.
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: [email@example.com: [Bug 41057] - Mozilla should not need write access to the binary directory] Date: Mon, 2 Apr 2001 08:34:03 -0700 From: Doug McMahon <firstname.lastname@example.org> To: email@example.com 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.
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...
Adding to CC
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.
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
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 :)
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.)
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.
Aren't you missing some $ signs in there? Gerv
yes, before "dist_bin", sorry.
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!
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.
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
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.
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.
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.
*** Bug 91277 has been marked as a duplicate of this bug. ***
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
... so let's close this puppy. Gerv
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.