From 4294a4f48a5949a181acb033e108a5ea897e1a3c Mon Sep 17 00:00:00 2001 From: "barnboy%trilobyte.net" <> Date: Thu, 26 Apr 2001 08:51:39 +0000 Subject: Added .htaccess files for shadow/, data/, and /. I added related information to the Bugzilla Guide, and tacked in a couple of last-minute additions. Also fixed the annoying "Tip: HINT:" thing. --- docs/html/Bugzilla-Guide.html | 756 +++++++++++++++++++++++++++--------------- 1 file changed, 496 insertions(+), 260 deletions(-) (limited to 'docs/html/Bugzilla-Guide.html') diff --git a/docs/html/Bugzilla-Guide.html b/docs/html/Bugzilla-Guide.html index 0712a5146..809fd745e 100644 --- a/docs/html/Bugzilla-Guide.html +++ b/docs/html/Bugzilla-Guide.html @@ -306,37 +306,37 @@ HREF="#AEN334" >
Tip: HINT: If you symlink the bugzilla directory into your Apache's +> If you symlink the bugzilla directory into your Apache's HTML heirarchy, you may receive "Forbidden" errors unless you add the "FollowSymLinks" directive to the <Directory> entry for the HTML root. @@ -2329,12 +2339,45 @@ CLASS="TIP" installation.
Lastly, you'll need to set up a symbolic link from /usr/bonsaitools/bin - to the correct location of your perl executable (probably /usr/bin/perl). +> Lastly, you'll need to set up a symbolic link to /usr/bonsaitools/bin/perl + for the correct location of your perl executable (probably /usr/bin/perl). Otherwise you must hack all the .cgi files to change where they look for perl. To make future upgrades easier, you should use the symlink approach.
Example 2-1. Setting up bonsaitools symlink
Here's how you set up the Perl symlink on Linux to make Bugzilla work. + Your mileage may vary; if you are running on Solaris, you probably need to subsitute + "/usr/local/bin/perl" for "/usr/bin/perl" below; if on certain other UNIX systems, + Perl may live in weird places like "/opt/perl". As root, run these commands: +
bash# mkdir /usr/bonsaitools +bash# mkdir /usr/bonsaitools/bin +bash# ln -s /usr/bin/perl /usr/bosaitools/bin/perl + |
2.1.2.14. Setting Up the MySQL Database
2.1.2.15. Tweaking "localconfig"
Note: The second time you run checksetup.pl, it is recommended you be the same - user as your web server runs under, and that you be sure you have set the +> The second time you run checksetup.pl, you should become the + user your web server runs as, and that you ensure you have set the "webservergroup" parameter in localconfig to match the web server's group - name, if any. Under some systems, otherwise, checksetup.pl will goof up - your file permissions and make them unreadable to your web server. + name, if any. I believe, for the next release of Bugzilla, this will + be fixed so that Bugzilla supports a "webserveruser" parameter in localconfig + as well. +
Example 2-2. Running checksetup.pl as the web user
Assuming your web server runs as user "apache", and Bugzilla is installed in + "/usr/local/bugzilla", here's one way to run checksetup.pl as the web server user. + As root, for the second run of checksetup.pl, do this: +
+
bash# chown -R apache:apache /usr/local/bugzilla +bash# su - apache +bash# cd /usr/local/bugzilla +bash# ./checksetup.pl +
If you want to add someone else to every group by hand, you can do it @@ -2683,7 +2762,7 @@ CLASS="SECTION" >
Tip: "Brian" had this to add, about upgrading to Bugzilla 2.12 from previous versions:Example 2-1. Removing encrypt() for Windows NT installationsExample 2-3. Removing encrypt() for Windows NT installations
Replace this: @@ -3762,6 +3841,63 @@ open SENDMAIL, "|\"C:/General/Web/tools/Windmail 4.0 Beta/windmail\" -t > ma >
Tip: This was some late breaking information from Jan Evert. Sorry for the lack of formatting. +
I'm busy installing bugzilla on a WinNT machine and I thought I'd notify you
+at this moment of the commments I have to section 2.2.1 of the bugzilla
+guide (at http://www.trilobyte.net/barnsons/html/).
+
+Step 1:
+I've used apache, installation is really straightforward.
+After reading the Unix installation instructions, I found that it is
+necessary to add the ExecCGI option to the bugzilla directory. Also the
+'AddHandler' line for .cgi is by default commented out.
+
+Step 3: although just a detail, 'ppm install <module%gt;' will also work
+(wihtout .ppd). And, it can also download these automatically from
+ActiveState.
+
+Step 4: although I have cygwin installed, it seems that it is not necessary.
+On my machine cygwin is not in the PATH and everything seems to work as
+expected.
+However, I've not used everything yet.
+
+Step 6: the 'bugs_password' given in SQL command d needs to be edited into
+localconfig later on (Step 7) if the password is not empty. I've also edited
+it into globals.pl, but I'm not sure that is needed. In both places, the
+variable is named db_pass.
+
+Step 8: all the sendmail replacements mentioned are not as simple as
+described there. Since I am not familiar (yet) with perl, I don't have any
+mail working yet.
+
+Step 9: in globals.pl the encrypt() call can be replaced by just the
+unencrypted password. In CGI.pl, the complete SQL command can be removed.
+
+Step 11: I've only changed the #! lines in *.cgi. I haven't noticed problems
+with the system() call yet.
+There seem to be only four system() called programs: processmail.pl (handled
+by step 10), syncshadowdb (which should probably get the same treatment as
+processmail.pl), diff and mysqldump. The last one is only needed with the
+shadowdb feature (which I don't use).
+
+There seems to be one step missing: copying the bugzilla files somehwere
+that apache can serve them.
+
+Just noticed the updated guide... Brian's comment is new. His first comment
+will work, but opens up a huge security hole.
+
Ensure you have adequate access controls for the $BUGZILLA_HOME/data/ and
- $BUGZILLA_HOME/shadow/ directories, as well as the $BUGZILLA_HOME/localconfig file.
+ $BUGZILLA_HOME/shadow/ directories, as well as the $BUGZILLA_HOME/localconfig and
+ $BUGZILLA_HOME/globals.pl files.
The localconfig file stores your "bugs" user password,
which would be terrible to have in the hands
- of a criminal. Also some files under $BUGZILLA_HOME/data/ store sensitive information, and
+ of a criminal, while the "globals.pl" stores some default information regarding your
+ installation which could aid a system cracker.
+ In addition, some files under $BUGZILLA_HOME/data/ store sensitive information, and
$BUGZILLA_HOME/shadow/ stores bug information for faster retrieval. If you fail to secure
these directories and this file, you will expose bug information to those who may not
be allowed to see it.
Note: Bugzilla provides default .htaccess files to protect the most common Apache
+ installations. However, you should verify these are adequate according to the site-wide
+ security policy of your web server, and ensure that the .htaccess files are
+ allowed to "override" default permissions set in your Apache configuration files.
+ Covering Apache security is beyond the scope of this Guide; please consult the Apache
+ documentation for details.
+ If you are using a web server that does not support the .htaccess control method,
+ you are at risk! After installing, check to see if you can
+ view the file "localconfig" in your web browser (ergo:
+ http://bugzilla.mozilla.org/localconfig. If you can read the contents of this
+ file, your web server has not secured your bugzilla directory properly and you
+ must fix this problem before deploying Bugzilla. If, however, it gives you a
+ "Forbidden" error, then it probably respects the .htaccess conventions and you
+ are good to go.
+ On Apache, you can use .htaccess files to protect access to these directories, as outlined
in A.1.9. Terry Weissman answers,
Here's Terry Weissman's comment, for some historical context:
Dave Lawrence, the original Red Hat Bugzilla maintainer, mentions:
A.3.1. Loki Games has a customized version of Bugzilla available at
http://fenris.lokigames.com. From that page,
A.4.7. The index.html page doesn't show the footer. It's really annoying to have
+ to go to the querypage just to check my "my bugs" link. How do I get a footer
+ on static HTML pages?
+ This was a late-breaking question for the Guide, so I just have to
+ quote the relevant newsgroup thread on it.
+ > AFAIK, most sites (even if they have SSI enabled) won't have #exec cmd A.4.8. Does Bugzilla provide any reporting features, metrics, graphs, etc? You
know, the type of stuff that management likes to see. :)
A.4.8. A.4.9. Is there email notification and if so, what do you see when you get an
email? Do you see bug number and title or is it only the number?
A.4.9. A.4.10. Can email notification be set up to send to multiple
people, some on the To List, CC List, BCC List etc?
A.4.10. A.4.11. If there is email notification, do users have to have any particular
type of email application?
A.4.11. A.4.12. If I just wanted to track certain bugs, as they go through life, can I
set it up to alert me via email whenever that bug changes, whether it be
owner, status or description etc.?
@@ -9000,10 +9236,10 @@ CLASS="QANDAENTRY"
CLASS="QUESTION"
> A.4.12. A.4.13. Does Bugzilla allow data to be imported and exported? If I had outsiders
write up a bug report using a MS Word bug template, could that template be
imported into "matching" fields? If I wanted to take the results of a query
@@ -9045,10 +9281,10 @@ CLASS="QANDAENTRY"
CLASS="QUESTION"
> A.4.13. A.4.14. Does Bugzilla allow fields to be added, changed or deleted? If I want to
customize the bug submission form to meet our needs, can I do that using our
terminology?
@@ -9069,10 +9305,10 @@ CLASS="QANDAENTRY"
CLASS="QUESTION"
> A.4.14. A.4.15. Has anyone converted Bugzilla to another language to be used in other
countries? Is it localizable?
A.4.15. A.4.16. Can a user create and save reports? Can they do this in Word format?
Excel format?
A.4.16. A.4.17. Can a user re-run a report with a new project, same query?
A.4.17. A.4.18. Can a user modify an existing report and then save it into another name?
A.4.18. A.4.19. Does Bugzilla have the ability to search by word, phrase, compound
search?
A.4.19. A.4.20. Can the admin person establish separate group and individual user
privileges?
A.4.20. A.4.21. Does Bugzilla provide record locking when there is simultaneous access
to the same bug? Does the second person get a notice that the bug is in use
or how are they notified?
@@ -9235,10 +9471,10 @@ CLASS="QANDAENTRY"
CLASS="QUESTION"
> A.4.22. A.4.23. Can users be on the system while a backup is in progress?
A.4.23. A.4.24. What type of human resources are needed to be on staff to install and
maintain Bugzilla? Specifically, what type of skills does the person need to
have? I need to find out if we were to go with Bugzilla, what types of
@@ -9326,10 +9562,10 @@ CLASS="QANDAENTRY"
CLASS="QUESTION"
> A.4.24. A.4.25. What time frame are we looking at if we decide to hire people to install
and maintain the Bugzilla? Is this something that takes hours or weeks to
install and a couple of hours per week to maintain and customize or is this
@@ -9357,10 +9593,10 @@ CLASS="QANDAENTRY"
CLASS="QUESTION"
> A.4.25. A.4.26. Is there any licensing fee or other fees for using Bugzilla? Any
out-of-pocket cost other than the bodies needed as identified above?
A.7.4. You can call bug_email.pl directly from your aliases file, with
an entry like this:
Microsoft has some advice on this matter, as well:
Version 1.1, March 2000
+> enabled. Perhaps what would be better is a #include virtual and a
+> footer.cgi the basically has the "require 'CGI.pl' and PutFooter command.
+>
+> Please note that under most configurations, this also requires naming
+> the file from index.html to index.shtml (and making sure that it will
+> still be reconized as an index). Personally, I think this is better on
+> a per-installation basis (perhaps add something to the FAQ that says how
+> to do this).
+
+Good point. Yeah, easy enough to do, that it shouldn't be a big deal for
+someone to take it on if they want it. FAQ is a good place for it.
+
+> Dave Miller wrote:
+>
+>> I did a little experimenting with getting the command menu and footer on
+>> the end of the index page while leaving it as an HTML file...
+>>
+>> I was successful. :)
+>>
+>> I added this line:
+>>
+>>
+>>
+>> Just before the </BODY> </HTML> at the end of the file. And it worked.
+>>
+>> Thought I'd toss that out there. Should I check this in? For those that
+>> have SSI disabled, it'll act like a comment, so I wouldn't think it would
+>> break anything.
+