Files
Mozilla/mozilla/webtools/bugzilla/docs/html/geninstall.html
gerv%gerv.net 37c7a8a963 More serious documentation whackage. This is now ready for review.
git-svn-id: svn://10.0.0.236/branches/BUGZILLA-2_16-BRANCH@122165 18797224-902f-48f8-a5cc-f745e15eee43
2002-05-25 15:36:59 +00:00

509 lines
9.8 KiB
HTML

<HTML
><HEAD
><TITLE
>General Installation Notes</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
"><LINK
REL="HOME"
TITLE="The Bugzilla Guide"
HREF="index.html"><LINK
REL="UP"
TITLE="Installation"
HREF="installation.html"><LINK
REL="PREVIOUS"
TITLE="Mac OS X Installation Notes"
HREF="osx.html"><LINK
REL="NEXT"
TITLE="Troubleshooting"
HREF="troubleshooting.html"></HEAD
><BODY
CLASS="section"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>The Bugzilla Guide</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="osx.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 4. Installation</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="troubleshooting.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="section"
><H1
CLASS="section"
><A
NAME="geninstall">4.5. General Installation Notes</H1
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="AEN1144">4.5.1. Modifying Your Running System</H2
><P
>Bugzilla optimizes database lookups by storing all relatively
static information in the
<TT
CLASS="filename"
>versioncache</TT
> file, located in the
<TT
CLASS="filename"
>data/</TT
>
subdirectory under your installation directory.</P
><P
>If you make a change to the structural data in your database (the
versions table for example), or to the
<SPAN
CLASS="QUOTE"
>"constants"</SPAN
>
encoded in <TT
CLASS="filename"
>defparams.pl</TT
>, you will need to remove
the cached content from the data directory (by doing a
<SPAN
CLASS="QUOTE"
>"rm data/versioncache"</SPAN
>
), or your changes won't show up.</P
><P
> <TT
CLASS="filename"
>versioncache</TT
>
gets automatically regenerated whenever it's more than
an hour old, so Bugzilla will eventually notice your changes by itself,
but generally you want it to notice right away, so that you can test
things.</P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="AEN1155">4.5.2. Upgrading From Previous Versions</H2
><P
>A plain Bugzilla is fairly easy to upgrade from one version to a
newer one. However, things get a bit more complicated if you've made
changes to Bugzilla's code. In this case, you may have to re-make or
reapply those changes. It is recommended that you take a backup of your
database and your entire Bugzilla installation before attempting an
upgrade. You can upgrade a 'clean' installation by untarring a new
tarball over the old installation. If you are upgrading from 2.12 or
later, you can type
<TT
CLASS="filename"
>cvs -z3 update</TT
>
, and resolve conflicts if there are any.</P
><P
>Because the developers of Bugzilla are constantly adding new
tables, columns and fields, you'll probably get SQL errors if you just
update the code and attempt to use Bugzilla. Always run the
<TT
CLASS="filename"
>checksetup.pl</TT
>
script whenever you upgrade your installation.</P
><P
>If you are running Bugzilla version 2.8 or lower, and wish to
upgrade to the latest version, please consult the file,
"UPGRADING-pre-2.8" in the Bugzilla root directory after untarring the
archive.</P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="htaccess">4.5.3. <TT
CLASS="filename"
>.htaccess</TT
>
files and security</H2
><P
>To enhance the security of your Bugzilla installation, Bugzilla's
<TT
CLASS="filename"
>checksetup.pl</TT
> script will generate
<I
CLASS="glossterm"
>&#13; <TT
CLASS="filename"
>.htaccess</TT
>
</I
>
files which the Apache webserver can use to restrict access to the
bugzilla data files.
These .htaccess files will not work with Apache 1.2.x - but this
has security holes, so you shouldn't be using it anyway.
<DIV
CLASS="note"
><P
></P
><TABLE
CLASS="note"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>If you are using an alternate provider of
<SPAN
CLASS="productname"
>webdot</SPAN
>
services for graphing (as described when viewing
<TT
CLASS="filename"
>editparams.cgi</TT
>
in your web browser), you will need to change the ip address in
<TT
CLASS="filename"
>data/webdot/.htaccess</TT
>
to the ip address of the webdot server that you are using.</P
></TD
></TR
></TABLE
></DIV
>
</P
><P
>The default .htaccess file may not provide adequate access
restrictions, depending on your web server configuration. Be sure to
check the &#60;Directory&#62; entries for your Bugzilla directory so that
the
<TT
CLASS="filename"
>.htaccess</TT
>
file is allowed to override web server defaults. For instance, let's
assume your installation of Bugzilla is installed to
<TT
CLASS="filename"
>/usr/local/bugzilla</TT
>
. You should have this &#60;Directory&#62; entry in your
<TT
CLASS="filename"
>httpd.conf</TT
>
file:</P
><P
>&#13;
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="programlisting"
>&#13; &#60;Directory /usr/local/bugzilla/&#62;
Options +FollowSymLinks +Indexes +Includes +ExecCGI
AllowOverride All
&#60;/Directory&#62;
</PRE
></FONT
></TD
></TR
></TABLE
>
</P
><P
>The important part above is
<SPAN
CLASS="QUOTE"
>"AllowOverride All"</SPAN
>
. Without that, the
<TT
CLASS="filename"
>.htaccess</TT
>
file created by
<TT
CLASS="filename"
>checksetup.pl</TT
>
will not have sufficient permissions to protect your Bugzilla
installation.</P
><P
>If you are using Internet Information Server (IIS) or another
web server which does not observe
<TT
CLASS="filename"
>.htaccess</TT
>
conventions, you can disable their creation by editing
<TT
CLASS="filename"
>localconfig</TT
>
and setting the
<TT
CLASS="varname"
>$create_htaccess</TT
>
variable to
<TT
CLASS="parameter"
><I
>0</I
></TT
>.
</P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="mod-throttle">4.5.4. <TT
CLASS="filename"
>mod_throttle</TT
>
and Security</H2
><P
>It is possible for a user, by mistake or on purpose, to access
the database many times in a row which can result in very slow access
speeds for other users. If your Bugzilla installation is experiencing
this problem , you may install the Apache module
<TT
CLASS="filename"
>mod_throttle</TT
>
which can limit connections by ip-address. You may download this module
at
<A
HREF="http://www.snert.com/Software/Throttle/"
TARGET="_top"
>&#13; http://www.snert.com/Software/Throttle/</A
>.
Follow the instructions to install into your Apache install.
<EM
>This module only functions with the Apache web
server!</EM
>
You may use the
<B
CLASS="command"
>ThrottleClientIP</B
>
command provided by this module to accomplish this goal. See the
<A
HREF="http://www.snert.com/Software/Throttle/"
TARGET="_top"
>Module
Instructions</A
>
for more information.</P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="content-type">4.5.5. Preventing untrusted Bugzilla content from executing malicious
Javascript code</H2
><P
>It is possible for a Bugzilla to execute malicious Javascript
code. Due to internationalization concerns, we are unable to
incorporate the code changes necessary to fulfill the CERT advisory
requirements mentioned in
<A
HREF="http://www.cet.org/tech_tips/malicious_code_mitigation.html/#3"
TARGET="_top"
>&#13; http://www.cet.org/tech_tips/malicious_code_mitigation.html/#3</A
>.
Executing the following code snippet from a UNIX command shell will
rectify the problem if your Bugzilla installation is intended for an
English-speaking audience. As always, be sure your Bugzilla
installation has a good backup before making changes, and I recommend
you understand what the script is doing before executing it.</P
><P
>&#13; <TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="programlisting"
>bash# perl -pi -e "s/Content-Type\: text\/html/Content-Type\: text\/html\; charset=ISO-8859-1/i" *.cgi *.pl
</PRE
></FONT
></TD
></TR
></TABLE
>
</P
><P
>All this one-liner command does is search for all instances of
<SPAN
CLASS="QUOTE"
>"Content-type: text/html"</SPAN
>
and replaces it with
<SPAN
CLASS="QUOTE"
>"Content-Type: text/html; charset=ISO-8859-1"</SPAN
>
. This specification prevents possible Javascript attacks on the
browser, and is suggested for all English-speaking sites. For
non-English-speaking Bugzilla sites, I suggest changing
<SPAN
CLASS="QUOTE"
>"ISO-8859-1"</SPAN
>, above, to
<SPAN
CLASS="QUOTE"
>"UTF-8"</SPAN
>.</P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="osx.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="troubleshooting.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Mac OS X Installation Notes</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="installation.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Troubleshooting</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>