summaryrefslogtreecommitdiffstats
path: root/docs/html/readme.unix.html
diff options
context:
space:
mode:
Diffstat (limited to 'docs/html/readme.unix.html')
-rw-r--r--docs/html/readme.unix.html1590
1 files changed, 1571 insertions, 19 deletions
diff --git a/docs/html/readme.unix.html b/docs/html/readme.unix.html
index 1e7597a32..faca430af 100644
--- a/docs/html/readme.unix.html
+++ b/docs/html/readme.unix.html
@@ -4,7 +4,7 @@
>UNIX Installation</TITLE
><META
NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.61
+CONTENT="Modular DocBook HTML Stylesheet Version 1.64
"><LINK
REL="HOME"
TITLE="The Bugzilla Guide"
@@ -74,16 +74,34 @@ NAME="README.UNIX"
>2.1. UNIX Installation</A
></H1
><DIV
+CLASS="SECTION"
+><H2
+CLASS="SECTION"
+><A
+NAME="AEN190"
+>2.1.1. ERRATA</A
+></H2
+><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
-> Please consult the README included with the Bugzilla distribution
- as the current canonical source for UNIX installation instructions.
- We do, however, have some installation notes for errata from the README.
- </P
+> If you are installing Bugzilla on S.u.S.e. Linux, or some other
+ distributions with "paranoid" security options, it is possible
+ that the checksetup.pl script may fail with the error:
+ <SPAN
+CLASS="ERRORNAME"
+>cannot chdir(/var/spool/mqueue): Permission denied</SPAN
+>
+ This is because your
+ /var/spool/mqueue directory has a mode of "drwx------". Type
+ <B
+CLASS="COMMAND"
+>chmod 755 /var/spool/mqueue</B
+> as root to fix this problem.
+ </P
></BLOCKQUOTE
></DIV
><DIV
@@ -93,22 +111,1051 @@ CLASS="NOTE"
><P
><B
>Note: </B
-> If you are installing Bugzilla on S.u.S.e. Linux, or some other
- distributions with "paranoid" security options, it is possible
- that the checksetup.pl script may fail with the error:
- <SPAN
-CLASS="ERRORNAME"
->cannot chdir(/var/spool/mqueue): Permission denied</SPAN
+> Release Notes for Bugzilla 2.12 are available at docs/rel_notes.txt
+ </P
+></BLOCKQUOTE
+></DIV
+><DIV
+CLASS="NOTE"
+><BLOCKQUOTE
+CLASS="NOTE"
+><P
+><B
+>Note: </B
+> The preferred documentation for Bugzilla is available in docs/, with
+ a variety of document types available. Please refer to these documents when
+ installing, configuring, and maintaining your Bugzilla installation.
+ </P
+></BLOCKQUOTE
+></DIV
+><DIV
+CLASS="WARNING"
+><P
+></P
+><TABLE
+CLASS="WARNING"
+BORDER="1"
+WIDTH="100%"
+><TR
+><TD
+ALIGN="CENTER"
+><B
+>Warning</B
+></TD
+></TR
+><TR
+><TD
+ALIGN="LEFT"
+><P
+> Bugzilla is not a package where you can just plop it in a directory,
+ twiddle a few things, and you're off. Installing Bugzilla assumes you
+ know your variant of UNIX or Microsoft Windows well, are familiar with the
+ command line, and are comfortable compiling and installing a plethora
+ of third-party utilities. To install Bugzilla on Win32 requires
+ fair Perl proficiency, and if you use a webserver other than Apache you
+ should be intimately familiar with the security mechanisms and CGI
+ environment thereof.
+ </P
+></TD
+></TR
+></TABLE
+></DIV
+><DIV
+CLASS="WARNING"
+><P
+></P
+><TABLE
+CLASS="WARNING"
+BORDER="1"
+WIDTH="100%"
+><TR
+><TD
+ALIGN="CENTER"
+><B
+>Warning</B
+></TD
+></TR
+><TR
+><TD
+ALIGN="LEFT"
+><P
+> Bugzilla has not undergone a complete security review. Security holes
+ may exist in the code. Great care should be taken both in the installation
+ and usage of this software. Carefully consider the implications of
+ installing other network services with Bugzilla.
+ </P
+></TD
+></TR
+></TABLE
+></DIV
+></DIV
+><DIV
+CLASS="SECTION"
+><H2
+CLASS="SECTION"
+><A
+NAME="AEN204"
+>2.1.2. Step-by-step Install</A
+></H2
+><DIV
+CLASS="SECTION"
+><H3
+CLASS="SECTION"
+><A
+NAME="AEN206"
+>2.1.2.1. Introduction</A
+></H3
+><P
+> Installation of bugzilla is pretty straightforward, particularly if your
+ machine already has MySQL and the MySQL-related perl packages installed.
+ If those aren't installed yet, then that's the first order of business. The
+ other necessary ingredient is a web server set up to run cgi scripts.
+ While using Apache for your webserver is not required, it is recommended.
+ </P
+><P
+> Bugzilla has been successfully installed under Solaris, Linux, and
+ Win32. The peculiarities of installing on Win32 (Win98+/NT/2K) are not
+ included in this section of the Guide; please check out the "Win32 Installation Instructions"
+ for further advice on getting Bugzilla to work on Microsoft Windows.
+ </P
+><P
+> The Bugzilla Guide is contained in the "docs/" folder. It is available
+ in plain text (docs/txt), HTML (docs/html), or SGML source (docs/sgml).
+ </P
+></DIV
+><DIV
+CLASS="SECTION"
+><H3
+CLASS="SECTION"
+><A
+NAME="AEN211"
+>2.1.2.2. Installing the Prerequisites</A
+></H3
+><P
+> The software packages necessary for the proper running of bugzilla are:
+ <P
+></P
+><OL
+TYPE="1"
+><LI
+><P
+> MySQL database server and the mysql client (3.22.5 or greater)
+ </P
+></LI
+><LI
+><P
+> Perl (5.004 or greater)
+ </P
+></LI
+><LI
+><P
+> DBI Perl module
+ </P
+></LI
+><LI
+><P
+> Data::Dumper Perl module
+ </P
+></LI
+><LI
+><P
+> DBD::mySQL
+ </P
+></LI
+><LI
+><P
+> TimeDate Perl module collection
+ </P
+></LI
+><LI
+><P
+> GD perl module (1.8.3) (optional, for bug charting)
+ </P
+></LI
+><LI
+><P
+> Chart::Base Perl module (0.99c) (optional, for bug charting)
+ </P
+></LI
+><LI
+><P
+> DB_File Perl module (optional, for bug charting)
+ </P
+></LI
+><LI
+><P
+> The web server of your choice. Apache is recommended.
+ </P
+></LI
+><LI
+><P
+> MIME::Parser Perl module (optional, for contrib/bug_email.pl interface)
+ </P
+></LI
+></OL
+>
+ <DIV
+CLASS="NOTE"
+><BLOCKQUOTE
+CLASS="NOTE"
+><P
+><B
+>Note: </B
+> You must run Bugzilla on a filesystem that supports file locking via
+ flock(). This is necessary for Bugzilla to operate safely with multiple
+ instances.
+ </P
+></BLOCKQUOTE
+></DIV
>
- This is because your
- /var/spool/mqueue directory has a mode of "drwx------". Type
- <B
+ <DIV
+CLASS="WARNING"
+><P
+></P
+><TABLE
+CLASS="WARNING"
+BORDER="1"
+WIDTH="100%"
+><TR
+><TD
+ALIGN="CENTER"
+><B
+>Warning</B
+></TD
+></TR
+><TR
+><TD
+ALIGN="LEFT"
+><P
+> It is a good idea, while installing Bugzilla, to ensure it is not
+ <EM
+>accessible</EM
+> by other machines on the Internet.
+ Your machine may be vulnerable to attacks
+ while you are installing. In other words, ensure there is some kind of firewall between you
+ and the rest of the Internet. Many installation steps require an active Internet connection
+ to complete, but you must take care to ensure that at no point is your machine vulnerable
+ to an attack.
+ </P
+></TD
+></TR
+></TABLE
+></DIV
+>
+
+ </P
+></DIV
+><DIV
+CLASS="SECTION"
+><H3
+CLASS="SECTION"
+><A
+NAME="AEN242"
+>2.1.2.3. Installing MySQL Database</A
+></H3
+><P
+> Visit MySQL homepage at http://www.mysql.org/ and grab the latest stable
+ release of the server. Both binaries and source are available and which
+ you get shouldn't matter. Be aware that many of the binary versions
+ of MySQL store their data files in /var which on many installations
+ (particularly common with linux installations) is part of a smaller
+ root partition. If you decide to build from sources you can easily set
+ the dataDir as an option to configure.
+ </P
+><P
+> If you've installed from source or non-package (RPM, deb, etc.) binaries
+ you'll want to make sure to add mysqld to your init scripts so the server
+ daemon will come back up whenever your machine reboots.
+ You also may want to edit those init scripts, to make sure that
+ mysqld will accept large packets. By default, mysqld is set up to only
+ accept packets up to 64K long. This limits the size of attachments you
+ may put on bugs. If you add something like "-O max_allowed_packet=1M"
+ to the command that starts mysqld (or safe_mysqld), then you will be
+ able to have attachments up to about 1 megabyte.
+ </P
+><DIV
+CLASS="NOTE"
+><BLOCKQUOTE
+CLASS="NOTE"
+><P
+><B
+>Note: </B
+> If you plan on running Bugzilla and MySQL on the same machine,
+ consider using the "--skip-networking" option in the init script.
+ This enhances security by preventing network access to MySQL.
+ </P
+></BLOCKQUOTE
+></DIV
+></DIV
+><DIV
+CLASS="SECTION"
+><H3
+CLASS="SECTION"
+><A
+NAME="AEN248"
+>2.1.2.4. Perl (5.004 or greater)</A
+></H3
+><P
+> Any machine that doesn't have perl on it is a sad machine indeed. Perl
+ for *nix systems can be gotten in source form from http://www.perl.com.
+ </P
+><P
+> Perl is now a far cry from the the single compiler/interpreter binary it
+ once was. It now includes a great many required modules and quite a
+ few other support files. If you're not up to or not inclined to build
+ perl from source, you'll want to install it on your machine using some
+ sort of packaging system (be it RPM, deb, or what have you) to ensure
+ a sane install. In the subsequent sections you'll be installing quite
+ a few perl modules; this can be quite ornery if your perl installation
+ isn't up to snuff.
+ </P
+><DIV
+CLASS="TIP"
+><BLOCKQUOTE
+CLASS="TIP"
+><P
+><B
+>Tip: </B
+> You can skip the following Perl module installation
+ steps by installing "Bundle::Bugzilla" from CPAN, which includes them.
+ All Perl module installation steps require you have an active Internet
+ connection.
+ </P
+><P
+> <TT
+CLASS="COMPUTEROUTPUT"
+> <TT
+CLASS="PROMPT"
+>bash#</TT
+>
+ <B
CLASS="COMMAND"
->chmod 755 /var/spool/mqueue</B
-> as root to fix this problem.
- </P
+>perl -MCPAN -e 'install "Bundle::Bugzilla"'</B
+>
+ </TT
+>
+ </P
+><P
+> Bundle::Bugzilla doesn't include GD, Chart::Base, or MIME::Parser,
+ which are not essential to a basic Bugzilla install. If installing
+ this bundle fails, you should install each module individually to
+ isolate the problem.
+ </P
+></BLOCKQUOTE
+></DIV
+></DIV
+><DIV
+CLASS="SECTION"
+><H3
+CLASS="SECTION"
+><A
+NAME="AEN259"
+>2.1.2.5. DBI Perl Module</A
+></H3
+><P
+> The DBI module is a generic Perl module used by other database related
+ Perl modules. For our purposes it's required by the MySQL-related
+ modules. As long as your Perl installation was done correctly the
+ DBI module should be a breeze. It's a mixed Perl/C module, but Perl's
+ MakeMaker system simplifies the C compilation greatly.
+ </P
+><P
+> Like almost all Perl modules DBI can be found on the Comprehensive Perl
+ Archive Network (CPAN) at http://www.cpan.org. The CPAN servers have a
+ real tendency to bog down, so please use mirrors. The current location
+ at the time of this writing (02/17/99) can be found in Appendix A.
+ </P
+><P
+> Quality, general Perl module installation instructions can be found on
+ the CPAN website, but the easy thing to do is to just use the CPAN shell
+ which does all the hard work for you.
+ </P
+><P
+> To use the CPAN shell to install DBI:
+ <DIV
+CLASS="INFORMALEXAMPLE"
+><A
+NAME="AEN265"
+></A
+><P
+></P
+><P
+> <TT
+CLASS="COMPUTEROUTPUT"
+> <TT
+CLASS="PROMPT"
+>bash#</TT
+>
+ <B
+CLASS="COMMAND"
+>perl -MCPAN -e 'install "DBI"'</B
+>
+ </TT
+>
+ <DIV
+CLASS="NOTE"
+><BLOCKQUOTE
+CLASS="NOTE"
+><P
+><B
+>Note: </B
+>Replace "DBI" with the name of whichever module you wish
+ to install, such as Data::Dumper, TimeDate, GD, etc.</P
+></BLOCKQUOTE
+></DIV
+>
+ </P
+><P
+></P
+></DIV
+>
+ To do it the hard way:
+ <DIV
+CLASS="INFORMALEXAMPLE"
+><A
+NAME="AEN272"
+></A
+><P
+></P
+><P
+> Untar the module tarball -- it should create its own directory
+ </P
+><P
+> CD to the directory just created, and enter the following commands:
+ <P
+></P
+><OL
+TYPE="1"
+><LI
+><P
+> <TT
+CLASS="COMPUTEROUTPUT"
+> <TT
+CLASS="PROMPT"
+>bash#</TT
+>
+ <B
+CLASS="COMMAND"
+>perl Makefile.PL</B
+>
+ </TT
+>
+ </P
+></LI
+><LI
+><P
+> <TT
+CLASS="COMPUTEROUTPUT"
+> <TT
+CLASS="PROMPT"
+>bash#</TT
+>
+ <B
+CLASS="COMMAND"
+>make</B
+>
+ </TT
+>
+ </P
+></LI
+><LI
+><P
+> <TT
+CLASS="COMPUTEROUTPUT"
+> <TT
+CLASS="PROMPT"
+>bash#</TT
+>
+ <B
+CLASS="COMMAND"
+>make test</B
+>
+ </TT
+>
+ </P
+></LI
+><LI
+><P
+> <TT
+CLASS="COMPUTEROUTPUT"
+> <TT
+CLASS="PROMPT"
+>bash#</TT
+>
+ <B
+CLASS="COMMAND"
+>make install</B
+>
+ </TT
+>
+ </P
+></LI
+></OL
+>
+ If everything went ok that should be all it takes. For the vast
+ majority of perl modules this is all that's required.
+ </P
+><P
+></P
+></DIV
+>
+ </P
+></DIV
+><DIV
+CLASS="SECTION"
+><H3
+CLASS="SECTION"
+><A
+NAME="AEN296"
+>2.1.2.6. Data::Dumper Perl Module</A
+></H3
+><P
+> The Data::Dumper module provides data structure persistence for Perl
+ (similar to Java's serialization). It comes with later sub-releases of
+ Perl 5.004, but a re-installation just to be sure it's available won't
+ hurt anything.
+ </P
+><P
+> Data::Dumper is used by the MySQL related Perl modules. It can be
+ found on CPAN (link in Appendix A) and can be installed by following
+ the same four step make sequence used for the DBI module.
+ </P
+></DIV
+><DIV
+CLASS="SECTION"
+><H3
+CLASS="SECTION"
+><A
+NAME="AEN300"
+>2.1.2.7. MySQL related Perl Module Collection</A
+></H3
+><P
+> The Perl/MySQL interface requires a few mutually-dependent perl
+ modules. These modules are grouped together into the the
+ Msql-Mysql-modules package. This package can be found at CPAN.
+ After the archive file has been downloaded it should
+ be untarred.
+ </P
+><P
+> The MySQL modules are all built using one make file which is generated
+ by running:
+ <TT
+CLASS="PROMPT"
+>bash#</TT
+>
+ <B
+CLASS="COMMAND"
+>perl Makefile.pl</B
+>
+ </P
+><P
+> The MakeMaker process will ask you a few questions about the desired
+ compilation target and your MySQL installation. For many of the questions
+ the provided default will be adequate.
+ </P
+><P
+> When asked if your desired target is the MySQL or mSQL packages
+ selected the MySQL related ones. Later you will be asked if you wish
+ to provide backwards compatibility with the older MySQL packages; you
+ must answer YES to this question. The default will be no, and if you
+ select it things won't work later.
+ </P
+><P
+> A host of 'localhost' should be fine and a testing user of 'test' and
+ a null password should find itself with sufficient access to run tests
+ on the 'test' database which MySQL created upon installation. If 'make
+ test' and 'make install' go through without errors you should be ready
+ to go as far as database connectivity is concerned.
+ </P
+></DIV
+><DIV
+CLASS="SECTION"
+><H3
+CLASS="SECTION"
+><A
+NAME="AEN309"
+>2.1.2.8. TimeDate Perl Module Collection</A
+></H3
+><P
+> Many of the more common date/time/calendar related Perl modules have
+ been grouped into a bundle similar to the MySQL modules bundle. This
+ bundle is stored on the CPAN under the name TimeDate. A (hopefully
+ current) link can be found in Appendix A. The component module we're
+ most interested in is the Date::Format module, but installing all of them
+ is probably a good idea anyway. The standard Perl module installation
+ instructions should work perfectly for this simple package.
+ </P
+></DIV
+><DIV
+CLASS="SECTION"
+><H3
+CLASS="SECTION"
+><A
+NAME="AEN312"
+>2.1.2.9. GD Perl Module (1.8.3)</A
+></H3
+><P
+> The GD library was written by Thomas Boutell a long while ago to
+ programatically generate images in C. Since then it's become almost a
+ defacto standard for programatic image construction. The Perl bindings
+ to it found in the GD library are used on a million web pages to generate
+ graphs on the fly. That's what bugzilla will be using it for so you'd
+ better install it if you want any of the graphing to work.
+ </P
+><P
+> Actually bugzilla uses the Graph module which relies on GD itself,
+ but isn't that always the way with OOP. At any rate, you can find the
+ GD library on CPAN (link in Appendix "Required Software").
+ </P
+><DIV
+CLASS="NOTE"
+><BLOCKQUOTE
+CLASS="NOTE"
+><P
+><B
+>Note: </B
+> The Perl GD library requires some other libraries that may or may not be
+ installed on your system, including "libpng" and "libgd". The full requirements
+ are listed in the Perl GD library README. Just realize that if compiling GD fails,
+ it's probably because you're missing a required library.
+ </P
+></BLOCKQUOTE
+></DIV
+></DIV
+><DIV
+CLASS="SECTION"
+><H3
+CLASS="SECTION"
+><A
+NAME="AEN318"
+>2.1.2.10. Chart::Base Perl Module (0.99c)</A
+></H3
+><P
+> The Chart module provides bugzilla with on-the-fly charting
+ abilities. It can be installed in the usual fashion after it has been
+ fetched from CPAN where it is found as the Chart-x.x... tarball in a
+ directory to be listed in Appendix "Required Software". Note that as with the GD perl
+ module, only the specific versions listed above (or newer) will work. Earlier
+ versions used GIF's, which are no longer supported by the latest
+ versions of GD.
+ </P
+></DIV
+><DIV
+CLASS="SECTION"
+><H3
+CLASS="SECTION"
+><A
+NAME="AEN321"
+>2.1.2.11. DB_File Perl Module</A
+></H3
+><P
+> DB_File is a module which allows Perl programs to make use of the facilities provided by
+ Berkeley DB version 1.x. This module is required by collectstats.pl which is used for
+ bug charting. If you plan to make use of bug charting, you must install this module.
+ </P
+></DIV
+><DIV
+CLASS="SECTION"
+><H3
+CLASS="SECTION"
+><A
+NAME="AEN324"
+>2.1.2.12. HTTP Server</A
+></H3
+><P
+> You have a freedom of choice here - Apache, Netscape or any other
+ server on UNIX would do. You can easily run the web server on a different
+ machine than MySQL, but need to adjust the MySQL "bugs" user permissions
+ accordingly.
+ </P
+><P
+> You'll want to make sure that your web server will run any file
+ with the .cgi extension as a cgi and not just display it. If you're using
+ apache that means uncommenting the following line in the srm.conf file:
+ <TT
+CLASS="COMPUTEROUTPUT"
+>AddHandler cgi-script .cgi</TT
+>
+ </P
+><P
+> With apache you'll also want to make sure that within the access.conf
+ file the line:
+ <TT
+CLASS="COMPUTEROUTPUT"
+> Options ExecCGI
+ </TT
+>
+ is in the stanza that covers the directories you intend to put the bugzilla
+ .html and .cgi files into.
+ </P
+><P
+> If you are using a newer version of Apache, both of the above lines will be
+ (or will need to be) in the httpd.conf file, rather than srm.conf or
+ access.conf.
+ </P
+><DIV
+CLASS="WARNING"
+><P
+></P
+><TABLE
+CLASS="WARNING"
+BORDER="1"
+WIDTH="100%"
+><TR
+><TD
+ALIGN="CENTER"
+><B
+>Warning</B
+></TD
+></TR
+><TR
+><TD
+ALIGN="LEFT"
+><P
+> There are two critical directories and a file that should not be a served by
+ the HTTP server. These are the 'data' and 'shadow' directories and the
+ 'localconfig' file. You should configure your HTTP server to not serve
+ content from these files. Failure to do so will expose critical passwords
+ and other data. Please see your HTTP server configuration manual on how
+ to do this. If you use quips (at the top of the buglist pages) you will want
+ the 'data/comments' file to still be served. This file contains those quips.
+ </P
+></TD
+></TR
+></TABLE
+></DIV
+></DIV
+><DIV
+CLASS="SECTION"
+><H3
+CLASS="SECTION"
+><A
+NAME="AEN334"
+>2.1.2.13. Installing the Bugzilla Files</A
+></H3
+><P
+> You should untar the Bugzilla files into a directory that you're
+ willing to make writable by the default web server user (probably
+ 'nobody'). You may decide to put the files off of the main web space
+ for your web server or perhaps off of /usr/local with a symbolic link
+ in the web space that points to the bugzilla directory. At any rate,
+ just dump all the files in the same place (optionally omitting the CVS
+ directories if they were accidentally tarred up with the rest of Bugzilla)
+ and make sure you can access the files in that directory through your
+ web server.
+ </P
+><DIV
+CLASS="TIP"
+><BLOCKQUOTE
+CLASS="TIP"
+><P
+><B
+>Tip: </B
+> HINT: 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 &#60;Directory&#62; entry
+ for the HTML root.
+ </P
+></BLOCKQUOTE
+></DIV
+><P
+> Once all the files are in a web accessible directory, make that
+ directory writable by your webserver's user (which may require just
+ making it world writable). This is a temporary step until you run
+ the post-install "checksetup.pl" script, which locks down your
+ installation.
+ </P
+><P
+> 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).
+ 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.
+ <DIV
+CLASS="TIP"
+><BLOCKQUOTE
+CLASS="TIP"
+><P
+><B
+>Tip: </B
+> If you don't have root access to set this symlink up, check out the
+ "setperl.csh" utility, listed in the Patches section of this
+ Guide. It will change the path to perl in all your Bugzilla files for
+ you.
+ </P
+></BLOCKQUOTE
+></DIV
+>
+ </P
+></DIV
+><DIV
+CLASS="SECTION"
+><H3
+CLASS="SECTION"
+><A
+NAME="AEN343"
+>2.1.2.14. Setting Up the MySQL Database</A
+></H3
+><P
+> After you've gotten all the software installed and working you're ready
+ to start preparing the database for its life as a the back end to a high
+ quality bug tracker.
+ </P
+><P
+> First, you'll want to fix MySQL permissions to allow access from
+ Bugzilla. For the purpose of this Installation section, the Bugzilla username
+ will be "bugs", and will have minimal permissions. Bugzilla has
+ not undergone a thorough security audit. It may be possible for
+ a system cracker to somehow trick Bugzilla into executing a command
+ such as "; DROP DATABASE mysql".
+ </P
+><P
+> That would be bad.
+ </P
+><P
+> Give the MySQL root user a password. MySQL passwords are
+ limited to 16 characters.
+ <P
+></P
+><TABLE
+BORDER="0"
+><TBODY
+><TR
+><TD
+> <TT
+CLASS="COMPUTEROUTPUT"
+> <TT
+CLASS="PROMPT"
+>bash#</TT
+>
+ <B
+CLASS="COMMAND"
+>mysql -u root mysql</B
+>
+ </TT
+>
+ </TD
+></TR
+><TR
+><TD
+> <TT
+CLASS="COMPUTEROUTPUT"
+> <TT
+CLASS="PROMPT"
+>mysql&#62;</TT
+>
+ <B
+CLASS="COMMAND"
+> UPDATE user SET Password=PASSWORD ('new_password')
+ WHERE user='root';
+ </B
+>
+ </TT
+>
+ </TD
+></TR
+><TR
+><TD
+> <TT
+CLASS="COMPUTEROUTPUT"
+> <TT
+CLASS="PROMPT"
+>mysql&#62;</TT
+>
+ <B
+CLASS="COMMAND"
+>FLUSH PRIVILEGES;</B
+>
+ </TT
+>
+ </TD
+></TR
+></TBODY
+></TABLE
+><P
+></P
+>
+ From this point on, if you need to access MySQL as the
+ MySQL root user, you will need to use "mysql -u root -p" and
+ enter your new_password. Remember that MySQL user names have
+ nothing to do with Unix user names (login names).
+ </P
+><P
+> Next, we create the "bugs" user, and grant sufficient
+ permissions for checksetup.pl, which we'll use later, to work
+ its magic. This also restricts the "bugs" user to operations
+ within a database called "bugs", and only allows the account
+ to connect from "localhost". Modify it to reflect your setup
+ if you will be connecting from another machine or as a different
+ user.
+ </P
+><P
+> Remember to set bugs_password to some unique password.
+ <P
+></P
+><TABLE
+BORDER="0"
+><TBODY
+><TR
+><TD
+> <TT
+CLASS="COMPUTEROUTPUT"
+> <TT
+CLASS="PROMPT"
+>mysql&#62;</TT
+>
+ <B
+CLASS="COMMAND"
+>GRANT SELECT,INSERT,UPDATE,DELETE,INDEX,
+ ALTER,CREATE,DROP,REFERENCES
+ ON bugs.* TO bugs@localhost
+ IDENTIFIED BY 'bugs_password';</B
+>
+ </TT
+>
+ </TD
+></TR
+><TR
+><TD
+> <TT
+CLASS="COMPUTEROUTPUT"
+> <TT
+CLASS="PROMPT"
+> mysql&#62;
+ </TT
+>
+ <B
+CLASS="COMMAND"
+> FLUSH PRIVILEGES;
+ </B
+>
+ </TT
+>
+ </TD
+></TR
+></TBODY
+></TABLE
+><P
+></P
+>
+ </P
+><P
+> Next, run the magic checksetup.pl script. (Many thanks to Holger
+ Schurig &#60;holgerschurig@nikocity.de&#62; for writing this script!)
+ It will make sure Bugzilla files and directories have reasonable
+ permissions, set up the "data" directory, and create all the MySQL
+ tables.
+ <P
+></P
+><TABLE
+BORDER="0"
+><TBODY
+><TR
+><TD
+> <TT
+CLASS="COMPUTEROUTPUT"
+> <TT
+CLASS="PROMPT"
+>bash#</TT
+>
+ <B
+CLASS="COMMAND"
+>./checksetup.pl</B
+>
+ </TT
+>
+ </TD
+></TR
+></TBODY
+></TABLE
+><P
+></P
+>
+ The first time you run it, it will create a file called "localconfig".
+ </P
+></DIV
+><DIV
+CLASS="SECTION"
+><H3
+CLASS="SECTION"
+><A
+NAME="AEN379"
+>2.1.2.15. Tweaking "localconfig"</A
+></H3
+><P
+> This file contains a variety of settings you may need to tweak including
+ how Bugzilla should connect to the MySQL database.
+ </P
+><P
+> The connection settings include:
+ <P
+></P
+><OL
+TYPE="1"
+><LI
+><P
+> server's host: just use "localhost" if the MySQL server is
+ local
+ </P
+></LI
+><LI
+><P
+> database name: "bugs" if you're following these directions
+ </P
+></LI
+><LI
+><P
+> MySQL username: "bugs" if you're following these directions
+ </P
+></LI
+><LI
+><P
+> Password for the "bugs" MySQL account above
+ </P
+></LI
+></OL
+>
+ </P
+><P
+> Once you are happy with the settings, re-run checksetup.pl. On this
+ second run, it will create the database and an administrator account
+ for which you will be prompted to provide information.
+ </P
+><P
+> When logged into an administrator account once Bugzilla is running,
+ if you go to the query page (off of the bugzilla main menu), you'll
+ find an 'edit parameters' option that is filled with editable treats.
+ </P
+><P
+> Should everything work, you should have a nearly empty copy of the bug
+ tracking setup.
+ </P
+><P
+> The second time around, checksetup.pl will stall if it is on a
+ filesystem that does not fully support file locking via flock(), such as
+ NFS mounts. This support is required for Bugzilla to operate safely with
+ multiple instances. If flock() is not fully supported, it will stall at:
+ <SPAN
+CLASS="ERRORCODE"
+>Now regenerating the shadow database for all bugs.</SPAN
+>
+ <DIV
+CLASS="NOTE"
+><BLOCKQUOTE
+CLASS="NOTE"
+><P
+><B
+>Note: </B
+> 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
+ "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.
+ </P
></BLOCKQUOTE
></DIV
+>
+ </P
><DIV
CLASS="NOTE"
><BLOCKQUOTE
@@ -116,12 +1163,517 @@ CLASS="NOTE"
><P
><B
>Note: </B
->
- </P
+> The checksetup.pl script is designed so that you can run it at any time
+ without causing harm. You should run it after any upgrade to Bugzilla.
+ </P
></BLOCKQUOTE
></DIV
></DIV
><DIV
+CLASS="SECTION"
+><H3
+CLASS="SECTION"
+><A
+NAME="AEN401"
+>2.1.2.16. Setting Up Maintainers Manuall (Optional)</A
+></H3
+><P
+> If you want to add someone else to every group by hand, you can do it
+ by typing the appropriate MySQL commands. Run '<TT
+CLASS="COMPUTEROUTPUT"
+> mysql -u root -p bugs</TT
+>'
+ (you may need different parameters, depending on your security settings
+ according to section 3, above). Then:
+ <P
+></P
+><TABLE
+BORDER="0"
+><TBODY
+><TR
+><TD
+> <TT
+CLASS="COMPUTEROUTPUT"
+> <TT
+CLASS="PROMPT"
+>mysql&#62;</TT
+>
+ <B
+CLASS="COMMAND"
+>update profiles set groupset=0x7fffffffffffffff
+ where login_name = 'XXX';</B
+>
+ </TT
+>
+ </TD
+></TR
+></TBODY
+></TABLE
+><P
+></P
+>
+ replacing XXX with the Bugzilla email address.
+ </P
+></DIV
+><DIV
+CLASS="SECTION"
+><H3
+CLASS="SECTION"
+><A
+NAME="AEN410"
+>2.1.2.17. The Whining Cron (Optional)</A
+></H3
+><P
+> By now you've got a fully functional bugzilla, but what good are bugs
+ if they're not annoying? To help make those bugs more annoying you can
+ set up bugzilla's automatic whining system. This can be done by adding
+ the following command as a daily crontab entry (for help on that see that
+ crontab man page):
+ <P
+></P
+><TABLE
+BORDER="0"
+><TBODY
+><TR
+><TD
+> <TT
+CLASS="COMPUTEROUTPUT"
+> <B
+CLASS="COMMAND"
+>cd &#60;your-bugzilla-directory&#62; ; ./whineatnews.pl</B
+>
+ </TT
+>
+ </TD
+></TR
+></TBODY
+></TABLE
+><P
+></P
+>
+ </P
+></DIV
+><DIV
+CLASS="SECTION"
+><H3
+CLASS="SECTION"
+><A
+NAME="AEN417"
+>2.1.2.18. Bug Graphs (Optional)</A
+></H3
+><P
+> As long as you installed the GD and Graph::Base Perl modules you might
+ as well turn on the nifty bugzilla bug reporting graphs.
+ </P
+><P
+> Add a cron entry like this to run collectstats daily at 5 after midnight:
+ <P
+></P
+><TABLE
+BORDER="0"
+><TBODY
+><TR
+><TD
+> <TT
+CLASS="COMPUTEROUTPUT"
+> <TT
+CLASS="PROMPT"
+>bash#</TT
+>
+ <B
+CLASS="COMMAND"
+>crontab -e</B
+>
+ </TT
+>
+ </TD
+></TR
+><TR
+><TD
+> <TT
+CLASS="COMPUTEROUTPUT"
+> 5 0 * * * cd &#60;your-bugzilla-directory&#62; ; ./collectstats.pl
+ </TT
+>
+ </TD
+></TR
+></TBODY
+></TABLE
+><P
+></P
+>
+ </P
+><P
+> After two days have passed you'll be able to view bug graphs from the
+ Bug Reports page.
+ </P
+></DIV
+><DIV
+CLASS="SECTION"
+><H3
+CLASS="SECTION"
+><A
+NAME="AEN429"
+>2.1.2.19. Securing MySQL</A
+></H3
+><P
+> If you followed the README for setting up your "bugs" and "root" user in
+ MySQL, much of this should not apply to you. If you are upgrading
+ an existing installation of Bugzilla, you should pay close attention
+ to this section.
+ </P
+><P
+> Most MySQL installs have "interesting" default security parameters:
+ <P
+></P
+><TABLE
+BORDER="0"
+><TBODY
+><TR
+><TD
+>mysqld defaults to running as root</TD
+></TR
+><TR
+><TD
+>it defaults to allowing external network connections</TD
+></TR
+><TR
+><TD
+>it has a known port number, and is easy to detect</TD
+></TR
+><TR
+><TD
+>it defaults to no passwords whatsoever</TD
+></TR
+><TR
+><TD
+>it defaults to allowing "File_Priv"</TD
+></TR
+></TBODY
+></TABLE
+><P
+></P
+>
+ </P
+><P
+> This means anyone from anywhere on the internet can not only drop the
+ database with one SQL command, and they can write as root to the system.
+ </P
+><P
+> To see your permissions do:
+ <P
+></P
+><TABLE
+BORDER="0"
+><TBODY
+><TR
+><TD
+> <TT
+CLASS="COMPUTEROUTPUT"
+> <TT
+CLASS="PROMPT"
+>bash#</TT
+>
+ <B
+CLASS="COMMAND"
+>mysql -u root -p</B
+>
+ </TT
+>
+ </TD
+></TR
+><TR
+><TD
+> <TT
+CLASS="COMPUTEROUTPUT"
+> <TT
+CLASS="PROMPT"
+>mysql&#62;</TT
+>
+ <B
+CLASS="COMMAND"
+>use mysql;</B
+>
+ </TT
+>
+ </TD
+></TR
+><TR
+><TD
+> <TT
+CLASS="COMPUTEROUTPUT"
+> <TT
+CLASS="PROMPT"
+>mysql&#62;</TT
+>
+ <B
+CLASS="COMMAND"
+>show tables;</B
+>
+ </TT
+>
+ </TD
+></TR
+><TR
+><TD
+> <TT
+CLASS="COMPUTEROUTPUT"
+> <TT
+CLASS="PROMPT"
+>mysql&#62;</TT
+>
+ <B
+CLASS="COMMAND"
+>select * from user;</B
+>
+ </TT
+>
+ </TD
+></TR
+><TR
+><TD
+> <TT
+CLASS="COMPUTEROUTPUT"
+> <TT
+CLASS="PROMPT"
+>mysql&#62;</TT
+>
+ <B
+CLASS="COMMAND"
+>select * from db;</B
+>
+ </TT
+>
+ </TD
+></TR
+></TBODY
+></TABLE
+><P
+></P
+>
+ </P
+><P
+> To fix the gaping holes:
+ <P
+></P
+><TABLE
+BORDER="0"
+><TBODY
+><TR
+><TD
+>DELETE FROM user WHERE User='';</TD
+></TR
+><TR
+><TD
+>UPDATE user SET Password=PASSWORD('new_password') WHERE user='root';</TD
+></TR
+><TR
+><TD
+> FLUSH PRIVILEGES;</TD
+></TR
+></TBODY
+></TABLE
+><P
+></P
+>
+ </P
+><P
+> If you're not running "mit-pthreads" you can use:
+ <P
+></P
+><TABLE
+BORDER="0"
+><TBODY
+><TR
+><TD
+>GRANT USAGE ON *.* TO bugs@localhost;</TD
+></TR
+><TR
+><TD
+>GRANT ALL ON bugs.* TO bugs@localhost;</TD
+></TR
+><TR
+><TD
+>REVOKE DROP ON bugs.* FROM bugs@localhost;</TD
+></TR
+><TR
+><TD
+>FLUSH PRIVILEGES;</TD
+></TR
+></TBODY
+></TABLE
+><P
+></P
+>
+ </P
+><P
+> With "mit-pthreads" you'll need to modify the "globals.pl" Mysql-&#62;Connect
+ line to specify a specific host name instead of "localhost", and accept
+ external connections:
+ <P
+></P
+><TABLE
+BORDER="0"
+><TBODY
+><TR
+><TD
+>GRANT USAGE ON *.* TO bugs@bounce.hop.com;</TD
+></TR
+><TR
+><TD
+>GRANT ALL ON bugs.* TO bugs@bounce.hop.com;</TD
+></TR
+><TR
+><TD
+>REVOKE DROP ON bugs.* FROM bugs@bounce.hop.com;</TD
+></TR
+><TR
+><TD
+>FLUSH PRIVILEGES;</TD
+></TR
+></TBODY
+></TABLE
+><P
+></P
+>
+ </P
+><P
+> Consider also:
+ <P
+></P
+><OL
+TYPE="1"
+><LI
+><P
+> Turning off external networking with "--skip-networking",
+ unless you have "mit-pthreads", in which case you can't.
+ Without networking, MySQL connects with a Unix domain socket.
+ </P
+></LI
+><LI
+><P
+> using the --user= option to mysqld to run it as an unprivileged
+ user.
+ </P
+></LI
+><LI
+><P
+> starting MySQL in a chroot jail
+ </P
+></LI
+><LI
+><P
+> running the httpd in a "chrooted" jail
+ </P
+></LI
+><LI
+><P
+> making sure the MySQL passwords are different from the OS
+ passwords (MySQL "root" has nothing to do with system "root").
+ </P
+></LI
+><LI
+><P
+> running MySQL on a separate untrusted machine
+ </P
+></LI
+><LI
+><P
+> making backups ;-)
+ </P
+></LI
+></OL
+>
+ </P
+></DIV
+><DIV
+CLASS="SECTION"
+><H3
+CLASS="SECTION"
+><A
+NAME="AEN495"
+>2.1.2.20. Installation General Notes</A
+></H3
+><DIV
+CLASS="SECTION"
+><H4
+CLASS="SECTION"
+><A
+NAME="AEN497"
+>2.1.2.20.1. Modifying Your Running System</A
+></H4
+><P
+> Bugzilla optimizes database lookups by storing all relatively static
+ information in the versioncache file, located in the data/ subdirectory
+ under your installation directory (we said before it needs to be writable,
+ right?!)
+ </P
+><P
+> If you make a change to the structural data in your database (the
+ versions table for example), or to the "constants" encoded in
+ defparams.pl, you will need to remove the cached content from the data
+ directory (by doing a "rm data/versioncache"), or your changes won't show
+ up!
+ </P
+><P
+> That file 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"
+><H4
+CLASS="SECTION"
+><A
+NAME="AEN502"
+>2.1.2.20.2. Upgrading From Previous Versions</A
+></H4
+><P
+> The developers of Bugzilla are constantly adding new tables, columns and
+ fields. You'll get SQL errors if you just update the code. The strategy
+ to update is to simply always run the checksetup.pl script whenever
+ you upgrade your installation of Bugzilla. If you want to see what has
+ changed, you can read the comments in that file, starting from the end.
+ </P
+></DIV
+><DIV
+CLASS="SECTION"
+><H4
+CLASS="SECTION"
+><A
+NAME="AEN505"
+>2.1.2.20.3. UNIX Installation Instructions History</A
+></H4
+><P
+> This document was originally adapted from the Bonsai installation
+ instructions by Terry Weissman &#60;terry@mozilla.org&#62;.
+ </P
+><P
+> The February 25, 1999 re-write of this page was done by Ry4an Brase
+ &#60;ry4an@ry4an.org&#62;, with some edits by Terry Weissman, Bryce Nesbitt,
+ Martin Pool, &#38; Dan Mosedale (But don't send bug reports to them!
+ Report them using bugzilla, at http://bugzilla.mozilla.org/enter_bug.cgi ,
+ project Webtools, component Bugzilla).
+ </P
+><P
+> This document was heavily modified again Wednesday, March 07 2001 to
+ reflect changes for Bugzilla 2.12 release by Matthew P. Barnson. The
+ securing MySQL section should be changed to become standard procedure
+ for Bugzilla installations.
+ </P
+><P
+> Finally, the README in its entirety was marked up in SGML and included into
+ the Guide on April 24, 2001.
+ </P
+><P
+> Comments from people using this Guide for the first time are particularly welcome.
+ </P
+></DIV
+></DIV
+></DIV
+></DIV
+><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"