Closed
Bug 42184
Opened 24 years ago
Closed 21 years ago
Mozilla-bin must not write to bin dir during installation
Categories
(Core :: XPCOM, defect, P3)
Core
XPCOM
Tracking
()
RESOLVED
FIXED
People
(Reporter: BenB, Assigned: dveditz)
References
Details
(Keywords: arch, relnote, Whiteboard: [relnote-user] For tarballs, fixed by bug 90879.)
Split-off from bug 41057.
The problem is security. You should not run a beast like Mozilla 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.
Reporter | ||
Comment 1•24 years ago
|
||
The workaround is to run Mozilla as user and then change access rights. Not
quite a good solution.
Assignee | ||
Comment 2•24 years ago
|
||
So if mozilla can't write to the bin directory during installation, then how
does it get installed? Your description of the problem you're trying to solve
is a bit muddled.
What does running as root have to do with it? Mozilla just needs to be run by
someone with permission to write in those directories.
Anyway I'm passing this bug off to warren for lack of anyone better. It's not
the install that's doing this writing, it's XPCOM autoreg, chrome registration,
profile creation and other parts of mozilla.
Reporter | ||
Comment 3•24 years ago
|
||
> So if mozilla can't write to the bin directory during installation, then how
> does it get installed?
I was speaking about mozilla-bin, the app suite. Running a small (!)
command-line install tool is fine.
> What does running as root have to do with it? Mozilla just needs to be run by
> someone with permission to write in those directories.
Yes, this is what I addressed with my comment at 2000-06-11 15:50. Yes, you can
change the access rights of <mozbindir> and all parent folders (at least on
Unix, if I'm right), install Mozilla and then change all of them back. I don't
think, this is a good solution.
Mozilla should distinguish between the destination location and the
installation location. The first is Mozilla's final resting place and
the second is an intermediate directory. For the more trusting they
would be the same; for the more paranoid they would not. For the really
paranoid, a normal user could run Mozilla's installation script,
including any configuration executables, and then root could look over
what was done and change anything she thought was inappropriate,
including permissions and ownership. The really paranoid root never runs
an untrusted program. All she has to do is run system utilities.
Note that the GNU autoconf system allows exactly that. For the typical
source package, one can say:
./configure --prefix=/usr
make
make install prefix=/tmp/package-foo/usr
and the right thing happens. Obviously, a binary package just does the
last step. RPM .spec files often make use of this feature so Mozilla
could also please binary packagers with no extra effort.
Comment 5•24 years ago
|
||
I don't see what the difference is between this and the other bug (bug 41057).
Essentially there are two stages
install time
run time
I think bug 41057 is run time
this is install time
Admins want both types to not require root. But they are separate stages
possibly [likely] to use different applications.
Comment 7•24 years ago
|
||
I'm sorry, but why can't you write to bin during install time? When else are you
going to write this data?
Updated•24 years ago
|
Target Milestone: --- → M18
Reporter | ||
Comment 8•24 years ago
|
||
They are different in that you must *never* write to bin dir at run time. You
can (and propably have to) write to it during installation, but it must not be
mozilla-bin, the app suite. Running a small (!) command-line install tool is
fine. It should be minimal, so that it is easy to make a security audit (i.e.
check, if there are any possible explaits), as it is often run by root. Some
(see timeless' comments) prefer to not even run that app as root.
Comment 9•24 years ago
|
||
Yes, and isn't that covered by the other bug? I think this bug is invalid.
Reporter | ||
Comment 10•24 years ago
|
||
warren,
-- Comments From dveditz@netscape.com 2000-06-11 09:43 in bug 41057 --
> 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.
This bug is about creating a small programm, which does all necessary writes to
the bin dir in order to allow mozilla-bin to run. The other bug is about
removing all writes of mozilla-bin to the bin dir. Yes, there is propably some
intersection. But you don't want hyatt (who you assigned the other bug to) to
write command line install tools, do you?
Updated•24 years ago
|
Whiteboard: [nsbeta3+]
Reporter | ||
Comment 11•24 years ago
|
||
Seems like there is some progress: there are regxpcom, regchrome and regExport.
But we need a user-friendly, non-GUI way to run them. And we need to make sure,
that's all.
Comment 12•24 years ago
|
||
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.
Assignee | ||
Comment 13•24 years ago
|
||
If you want a non-gui way of creating all the necessary files you can currently
run "mozilla -CreateProfile" which will do all the necessary registrations,
create a default profile and exit.
Comment 14•24 years ago
|
||
Comment seen on x.themes.org:
"re Netscape Install
I tried to installed per the instructions, but what they dont tell you: I could
not install it as root and run it as a user. I had to install it into my user
directory and then it would work."
We need to better document this.
Reporter | ||
Comment 15•24 years ago
|
||
*** Bug 45229 has been marked as a duplicate of this bug. ***
Comment 16•24 years ago
|
||
dveditz: (sorry to reply so late after your comment - I just found this bug)
As Ben Bucksh says in the 8th comment on this bug, it is okay to write to the
bin directory at install time, but it is *not* okay to require that mozilla
itself be run. Even just with the CreateProfile flag. Mozilla is *way* too big
to audit for security.
From a later comment by Ben, it looks like this issue might be addressed by
simply running regxpcom, regchrome and regExport from a shell script as part of
the unix installation (does the tarball have an install script? I use the debian
packages...) If the tarball doesn't have an install script, having a
README.packaging file that documents that it is necessary to run these three
programs in the "postinst" part of your packaging script would be good.
If these three scripts really do do *all* the processing that ever needs to be
done as root, then creating a README.packaging file or modifying the install
script would probably be all that was necessary to mark this bug FIXED. Right?
Assignee | ||
Comment 17•24 years ago
|
||
*** Bug 48235 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 18•24 years ago
|
||
*** Bug 50528 has been marked as a duplicate of this bug. ***
Comment 19•24 years ago
|
||
*** Bug 43091 has been marked as a duplicate of this bug. ***
Comment 20•24 years ago
|
||
I just tried to re-open 43091 but this is just as good. I can't even
run moz as a user anymore - segfault. Could someone answer this
question - doesn't Moz have to write into the component registry during
normal operation? Like, I change the skin or something? If so, then
I should have my own, user-owned copy of the registry, right?
Assignee | ||
Comment 21•24 years ago
|
||
Doug -- you should try to reopen that bug or some other child of bug 41057
which deals with Mozilla at run-time. You should NOT need access at run time in
general, your private selections are written to files in your profile
directory.
*this* bug deals with the fact that Mozilla requires write permissions the
first time in order to do the initial registrations. 41057 is a simple bug
(ok, lots of bugs), this one is a tougher architectural problem since we
assumed an "install" step.
Comment 22•24 years ago
|
||
Ok, *MY* copy of Mozilla is definitely writing into the install directory.
Here's what I did today:
-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.
To me this is a watertight case that it is writing in the install
directory. I'll go and post this again on bug 43091 to try to
focus some attention on this SEVERE PROBLEM.
Comment 23•24 years ago
|
||
Warren's away this week, can we get someone who is around to fix this? It is
indeed a bad thing for a Unix app to try to write to system directories. Dan,
can you help?
/be
Reporter | ||
Comment 24•24 years ago
|
||
Bug 51677 is a workaround (or alternate implementation, if you want), not
dependency.
Comment 25•24 years ago
|
||
*** Bug 53693 has been marked as a duplicate of this bug. ***
Comment 26•24 years ago
|
||
*** Bug 53918 has been marked as a duplicate of this bug. ***
Comment 27•24 years ago
|
||
Not holding PR3 for this; marking nsbeta3-.
Whiteboard: [nsbeta3+] → [nsbeta3-]
Comment 28•24 years ago
|
||
*** Bug 53639 has been marked as a duplicate of this bug. ***
Reporter | ||
Updated•24 years ago
|
Keywords: mozilla1.0
Reporter | ||
Comment 29•24 years ago
|
||
Bug 55419 would regress this bug.
Assignee | ||
Comment 30•24 years ago
|
||
How can you regress a bug that isn't fixed?
Reporter | ||
Comment 31•24 years ago
|
||
Making it worse than it was before. Like ill (a cold) -> more ill (cancer).
Comment 32•24 years ago
|
||
At this point, I really don't see the difference between this bug and bug 41057.
There is a complaint that you shouldn't run mozilla at install time because it's
too big to do a security audit on, but we're not fixing that now.
Marking dup.
*** This bug has been marked as a duplicate of 41057 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 33•24 years ago
|
||
warren, please! "we're not fixing that now" is really no reason to close a bug.
REOPENing.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Assignee | ||
Comment 34•24 years ago
|
||
warren: yes, that's *exactly* why this bug was split off from bug 41057 --
because we knew that one needed fixing NOW and this one needs some thinking and
redesign.
Assignee | ||
Comment 35•24 years ago
|
||
I don't know who nominated it for rtm though -- no way we'll get this
rearchitected in that time frame. Giving [rtm-]
relnoteRTM text: (something like) On systems where Mozilla (Netscape 6) is
installed into a directory protected from writing by users, it must be run
the first time by a privileged account to write out necessary system
information files. This task is normally performed automatically by the
installer.
Keywords: relnoteRTM
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm-]
Comment 36•24 years ago
|
||
Then perhaps you should rename this "mozilla shouldn't be run during install".
I really don't know why that's interesting though.
As I said in bug 41057, there's only one remaining problem, and Hyatt thinks
there's an easy fix. But I'll let you be the judge, Dan.
Assignee: warren → dveditz
Status: REOPENED → NEW
Reporter | ||
Comment 37•24 years ago
|
||
The summary warren suggested would be OK with me.
warren, apps running as root should undergo a detailed security review. Doing
that with mozilla-bin is practically impossible. E.g., IIRC, the GTK developers
recommend not to run GTK as root.
Comment 38•24 years ago
|
||
I believe it's relatively easy to eliminate the need for running Mozilla
at install time.
If I run regxpcom and then regchrome the only thing running Mozilla does
is to create package/chrome/user-*.rdf files.
With a 1012 build, if userA has no ~/.mozilla, unpacks a tarball, and
runs Mozilla from there then package/chrome/user* files are created. Any
other user can then run mozilla quite happily. If userA switches themes,
say, then she acquires a local user-skins.rdf file. Now let's say she
want to install a newer tarball so she removes the old one and repeats
her steps. Mozilla now notices that she has a local user-skins.rdf file
and does *not* create a global one. All other users are now screwed
because Mozilla can read neither a global file nor a local file but is
trying to write a global file which fails. Mozilla hangs and just sits
there looking stupid.
Since Mozilla appears to be happy with just local user-* files, and they
appear to really be per-user files, then I think Mozilla should write
these files to the local location always.
If you do that then everything falls into place. A non-privileged user
can unpack a tarball and then run regxpcom and regchrome. A privileged
user can then come along and change the ownership and permissions as
desired and move the directory tree to its final home or even create a
functional binary tarball. What's nice is that this could easily be a
shell script. Best of all, the privileged user never has to run
untrusted applications.
There are some minor problems. Regxpcom is currently linked to the GTK
and X11 libs. This appears to be unnecessary and is probably just a
build bug. A somewhat bigger problem is that behaves poorly when it
can't write to a file but that's not this bug.
Comment 39•24 years ago
|
||
regchrome should cause the user-*.rdf files to be written as well. If not, then
the installed-chrome.txt is probably misordered such that a select command is
happening prior to the install command of a package that the select command
wants to operate on. Move the select commands to the very bottom of
installed-chrome.txt and then run regchrome, and you shouldn't even see any
user-*.rdf files generated.
Comment 40•24 years ago
|
||
What does a select line look like? All lines in installed-chrome.txt are of
the form *,install,* .
Comment 41•24 years ago
|
||
*** Bug 56444 has been marked as a duplicate of this bug. ***
Comment 42•24 years ago
|
||
*** Bug 56616 has been marked as a duplicate of this bug. ***
Comment 43•24 years ago
|
||
Once the user-*.rdf problem is solved, it becomes (almost) trivial to write a
command-line install script although something like ./configure; make install
would probably be more useful.
Comment 44•24 years ago
|
||
Here's something to try. As userA unpack a mozilla nightly. Then run this
script:
#!/bin/sh
HERE=`pwd`
THERE=$HERE/package
export LD_LIBRARY_PATH=$THERE
export MOZILLA_FIVE_HOME=$THERE
(cd $THERE; ./regxpcom)
(cd $THERE; ./regchrome)
touch $THERE/chrome/user-skins.rdf
touch $THERE/chrome/user-locales.rdf
Do not run mozilla as userA. Instead try it as userB. It works for me with
empty user-*.rdf files.
Reporter | ||
Updated•24 years ago
|
Reporter | ||
Comment 45•24 years ago
|
||
Is there a commandline xpi package installer in the works?
Assignee | ||
Comment 46•24 years ago
|
||
Ben: please elaborate -- isn't that what the Linux installer already is? It
downloads and installs .xpi files. Are you just asking for an admin-friendly
"silent" mode?
Reporter | ||
Comment 47•24 years ago
|
||
dveditz, the Linux installer is an X11 app, not?
Comment 48•24 years ago
|
||
regxpcom also creates $HOME/.mozilla but does nothing with it. It seems
superfluous and is not a confidence builder. Bug 57644 filed.
Updated•24 years ago
|
Comment 49•24 years ago
|
||
Unsetting target milestone - M18 is long past. Side note: This bug has a patch
posted in the comments.
Gerv
Target Milestone: M18 → ---
Comment 50•24 years ago
|
||
Uhm, X11 installer is a _bad_ idea on Unix/Linux - some multiuser systems on big
sites are running headless as servers and share their dirs with their client
machines. An unix installer should have an option to run without X11 during
installation (does someone remember these =x)(&//!! Oracle installer which can't
run without X11 but does not use it... =:-)
Updated•24 years ago
|
Keywords: mozilla0.9.1
Reporter | ||
Comment 51•24 years ago
|
||
FYI: I tried to use regchrome and regxpcom (as the owning user) only, but
Mozilla coredumped (when run as a different user). After I ran mozilla-bin (as
the owning user), everything worked fine (also when run as a different user).
I didn't track down the reason.
Comment 52•24 years ago
|
||
Filed bug 77365 to request a command-line xpinstall binary (as discussed in this
bug).
I wonder if this bug should be marked fixed? Most people seem to be having
success with regxpcom+regchrome+touching those two skin files. Ben, did you try
the full script suggested by tenthumbs above?
One other question: Could we possibly run regxpcom and regchrome and create the
skin files as part of "make install"? That would stop people who just run
./configure && make from running into this and complaining because they didn't
read the docs.
Thoughts?
Comment 53•24 years ago
|
||
if that script works, why don't we include the script also in .tar.gz binary
packages, so that after unpacking, you only have to run the script and are able
to run the program?
I think this is also what an rpm installation (of some distributor) would need
and would be able to do, right?
Note Ben's comments about having problems running only regchrome and regxpcom -
what about that? Does it mean the script will also fail? What can be done
against that?
Comment 54•24 years ago
|
||
*** Bug 78487 has been marked as a duplicate of this bug. ***
Comment 55•24 years ago
|
||
That you need to run mozilla once with write permission to MOZILLA_FIVE_HOME,
before Mozilla is installed, is one thing. But it's really annoying, that if you
don't know about that (and I couldn't find that in the release notes), you won't
easily find out, because neither regxpcom nor regchrome will tell you. They just
exit without printing something like "no write permission to MOZILLA_FIVE_HOME".
Comment 56•24 years ago
|
||
I 've just installed mozilla0.9 on a LinuxBox for multi-user-access.
Postinstall I did a ./mozilla as root but when I did start mozilla as normal
user I got a SegFault!!!
An "strace $prog ${1+"$@"} " in run-mozilla told me, an "open(...
/mozilla/chrome/user-skins.rdf ...) " failed!
During running mozilla first time as root this file wasn't created!
After cp an old one from mozilla0.8.1 into "/mozilla/chrome/" everything is
fine, and I can run mozilla as normal user!
I hope this is the right place to post this error!
Hajo
Comment 57•24 years ago
|
||
> During running mozilla first time as root this file wasn't created!
I think I can answer this one. The RDF files such as user-skins will NOT be
created in the install tree if they already exist in the user's profile tree.
If you're running Mozilla from root with the intention of having it create the
RDF files in the install tree, then root must have a clean profile tree.
Comment 58•24 years ago
|
||
It seems awfully silly to impose a restriction that the installer
process not have a ~/.mozilla tree.
In any event, touching $MOZILLA_FIVE_HOME/chrome/user-skins.rdf has
always worked for me. The only thing left in this bug is why Mozilla is
why mozilla fails so miserably if the global user-*.rdf files don't
exist.
Comment 59•24 years ago
|
||
You can have a ~/.mozilla tree, you just can't have the RDF files in it.
I'm not saying this is desired or even acceptable, I'm just saying that's the
I've observed it working.
Reporter | ||
Comment 60•24 years ago
|
||
Why shoudn't regchrome create the user-*.rdf files? They are for chrome.
Also filed bug 79520.
Comment 61•24 years ago
|
||
*** Bug 78742 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 62•24 years ago
|
||
*** Bug 80205 has been marked as a duplicate of this bug. ***
Comment 63•24 years ago
|
||
*** Bug 79520 has been marked as a duplicate of this bug. ***
Comment 64•23 years ago
|
||
This problem resulted in my inability to run Mozilla after upgrading to 0.9.1
from 0.9. An entry in the README or installation instructions along with a
descriptive error message when the RDF files are not found or can not be created
would be greatly appreciated. Simply crashing when this is the case is highly
misleading.
Comment 65•23 years ago
|
||
*** Bug 83282 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 66•23 years ago
|
||
See bug 90879. It describes a way to generate a tarball, which can just be
extracted to a dir by root and be used by users. root never has to run any
Mozilla binary.
Reporter | ||
Updated•23 years ago
|
Whiteboard: [nsbeta3-][rtm-] relnote-user → [relnote-user] For tarballs, fixed by bug 90879.
Comment 67•23 years ago
|
||
This one should be nominated as a MUSTFIX for
Mozilla 1.0 (I see no entry for the target milestone)!
Up to now three system administrators of larger institutes
(> 100 employees) said to me they will not install Mozilla
if it must be installed for every user (will take up too much
space and too much worktime). So this one gets to be a major
blocker for Mozilla's success on multiuser systems in larger
companies.
We here (124 employees) are anxious to install even the
beta releases, as they are more stable now than Nav 4.x on
Solaris, but we probably must wait forever if this is not
fixed.
By the way, that one is a really ugly design error, such
bad things shouldn't happen in the future !
Comment 68•23 years ago
|
||
FWIW, I've been able to do a shared installation for several thousand users
on both Solaris and Linux. The trick is to install it in the shared system
directory, then run it once as the owner (i.e. the user with write access).
After that all the other users can run it read-only. Kind of messy, and
perhaps there are undiscovered problems with this approach, but so far it
seems to work OK for us.
Comment 69•23 years ago
|
||
I agree, this is a MUSTFIX for 1.0.
I, also, have had no problems with this procedure:
as root: untar everything to /usr/local/mozilla
as root: chown -R me.users /usr/local/mozilla
as me: run-mozilla.sh and exit
as root: chown -R root.root /usr/local/mozilla
thereafter, it runs fine for everyone.
The workaround is so simple, I can't believe it's that hard to just make it
work like it should.
Comment 70•23 years ago
|
||
*** Bug 94584 has been marked as a duplicate of this bug. ***
Comment 71•23 years ago
|
||
*** Bug 94771 has been marked as a duplicate of this bug. ***
Comment 72•23 years ago
|
||
*** Bug 99887 has been marked as a duplicate of this bug. ***
Comment 73•23 years ago
|
||
This bug requires a release notes entry. Can someone provide a one or two
explanation of the problem along with any worksaround?
"Correct Mozilla installation requires initialization of component and chrome
registries. If installing on a multi-user system, the initialization must be
performed by a user (such as "root" on Unix systems) with sufficient privileges
to create and modify files in the Mozilla installation area."
Blizzard, can you provide a quick bulleted list of the steps required to
initialize the databases? I'll love you forever.
Comment 75•23 years ago
|
||
I had written the doc how to add language pack to
Mozilla that is installed in shared directory on
UNIX platform. Does this help?
http://www.mozilla.org/projects/l10n/mlp_distrib.html
Comment 76•23 years ago
|
||
Here's the shell script that's run after any component is installed. It
contains all the bits that need to be done.
[snip]
#!/bin/sh
umask 022
if [ -f /usr/lib/mozilla/regxpcom ]; then
/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
MOZILLA_FIVE_HOME=/usr/lib/mozilla \
/usr/lib/mozilla/regxpcom >/dev/null 2>/dev/null
MOZILLA_FIVE_HOME=/usr/lib/mozilla \
/usr/lib/mozilla/regchrome >/dev/null 2>/dev/null
fi
exit 0
Comment 77•23 years ago
|
||
*** Bug 79520 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Comment 78•21 years ago
|
||
how is this any different than bug 57089?
Comment 79•21 years ago
|
||
Bug #57089 is installer only, this one applies to tarball only installation as
well. Note that #57089 is in the dependence list of this bug, so it fixes parts
of this problem.
Comment 80•21 years ago
|
||
(In reply to comment #79)
> Bug #57089 is installer only, this one applies to tarball only installation as
no one is forcing anyone to run Mozilla to write to the installation dir after a
tarball installation.
Comment 81•21 years ago
|
||
Indeed. But if you don't run the script shown in comment #76 (and mentioned
explicitly in the release notes), you run exactly into the same problems
as in bug #57089. So you ARE forced to run it if it should work for anyone
else than yourself (aka 'root' in a multi-user installation).
Comment 82•21 years ago
|
||
you really just need to run regxpcom and regchrome. The stuff deleted in
comment 76 does not exist on installation, and the directory is made
automagically. Moreover, what is it preventing you from running the script? I
don't understand what changes need to be implemented in the Mozilla source to
fix this bug.
I think the summary here is not helping me.
> Mozilla-bin must not write to bin dir during installation
1. No one forces you to run mozilla during tarball installation.
2. If you do run mozilla and you haven't run regxpcom/regchrome, it *must* write
to the installation dir, or it will crash and burn.
Comment 83•21 years ago
|
||
All what is left in this bug is that the script is not automagically
fired up in a tarball installation. Yes, it must write to the bin directory
(if calling Mozilla or the script here is irrelevant, one of them must be
run to get the desired effect). I think that the alternative (that is, rewriting
Mozilla so that it does not need the scripts) is not worth discussing any longer,
since the script solution is adequate. From my point of view, this bug is of no
practical relevance anymore, so it may should be closed now.
Comment 84•21 years ago
|
||
Hmmmm... maybe it should be said another way.
The fact that the release notes even has a section named "Multi-User Linux
Installations" is a bug. It is a work-around for a broken install. Multi-user
is the norm on Unix and Linux. I might find it understandable to see special
instruction for single-user installs but even that would be unusual.
The install instructions should NOT tell the installer to "Run Mozilla with the
./mozilla run script". The installer is often root and this is a security
concern for most system administrators.
A posible fix is to elliminate the "Multi-User Linux Installations" work-arround
section and the "Run Mozilla with the ./mozilla run script" step. Package the
script mentioned in the "Multi-User Linux Installations" that runs regxpcom and
regchrome, perhaps in a "smarter" form if necessary, and include it in the
installation. Maybe call it "mozsetup" or something. Then add a step to the
directions telling the installer to run this setup script.
Comment 85•21 years ago
|
||
bug 57089 is now fixed, so I don't know what issues remain here.
David: if you think the website docs/README need updating, please file a new bug.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 21 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•