bugzilla-guide.txt

bugzilla的安装文件

   There is also a parameter in Bugzilla called 'maxattachmentsize' (default =
   1000 Kb) that controls the maximum allowable attachment size. Attachments
   larger than either the 'max_allowed_packet' or 'maxattachmentsize' value
   will not be accepted by Bugzilla.
     _________________________________________________________________

2.2.2.2. Allow small words in full-text indexes

   By default, words must be at least four characters in length in order to be
   indexed by MySQL's full-text indexes. This causes a lot of Bugzilla specific
   words to be missed, including "cc", "ftp" and "uri".

   MySQL can be configured to index those words by setting the ft_min_word_len
   param to the minimum size of the words to index. This can be done by
   modifying the /etc/my.cnf according to the example below:
  [mysqld]
  # Allow small words in full-text indexes
  ft_min_word_len=2

   Rebuilding the indexes can be done based on documentation found at
   http://www.mysql.com/doc/en/Fulltext_Fine-tuning.html.

   Note The ft_min_word_len parameter is only suported in MySQL v4 or higher.
     _________________________________________________________________

2.2.2.3. Permit attachments table to grow beyond 4GB

   By default, MySQL will limit the size of a table to 4GB. This limit is
   present even if the underlying filesystem has no such limit. To set a higher
   limit, follow these instructions.

   Run the MySQL command-line client and enter:
  mysql> ALTER TABLE attachments
          AVG_ROW_LENGTH=1000000, MAX_ROWS=20000;

   The above command will change the limit to 20GB. Mysql will have to make a
   temporary copy of your entire table to do this. Ideally, you should do this
   when your attachments table is still small.
     _________________________________________________________________

2.2.2.4. Add a user to MySQL

   You need to add a new MySQL user for Bugzilla to use. (It's not safe to have
   Bugzilla use the MySQL root account.) The following instructions assume the
   defaults in localconfig; if you changed those, you need to modify the SQL
   command appropriately. You will need the $db_pass password you set in
   localconfig in Section 2.2.1.

   We use an SQL GRANT command to create a "bugs" user. 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.

   Run the mysql command-line client.

   If you are using MySQL 4.0 or newer, enter:
  mysql> GRANT SELECT, INSERT,
         UPDATE, DELETE, INDEX, ALTER, CREATE, LOCK TABLES,
         CREATE TEMPORARY TABLES, DROP, REFERENCES ON bugs.*
         TO bugs@localhost IDENTIFIED BY '$db_pass';
  mysql> FLUSH PRIVILEGES;

   If you are using an older version of MySQL,the LOCK TABLES and CREATE
   TEMPORARY TABLES permissions will be unavailable and should be removed from
   the permissions list. In this case, the following command line can be used:
  mysql> GRANT SELECT, INSERT,
         UPDATE, DELETE, INDEX, ALTER, CREATE, DROP,
         REFERENCES ON bugs.* TO bugs@localhost IDENTIFIED BY
         '$db_pass';
  mysql> FLUSH PRIVILEGES;
     _________________________________________________________________

2.2.3. checksetup.pl

   Next, rerun checksetup.pl. It reconfirms that all the modules are present,
   and notices the altered localconfig file, which it assumes you have edited
   to your satisfaction. It compiles the UI templates, connects to the database
   using the 'bugs' user you created and the password you defined, and creates
   the 'bugs' database and the tables therein.

   After that, it asks for details of an administrator account. Bugzilla can
   have multiple administrators - you can create more later - but it needs one
   to start off with. Enter the email address of an administrator, his or her
   full name, and a suitable Bugzilla password.

   checksetup.pl will then finish. You may rerun checksetup.pl at any time if
   you wish.
     _________________________________________________________________

2.2.4. Web server

   Configure your web server according to the instructions in the appropriate
   section. (If it makes a difference in your choice, the Bugzilla Team
   recommends Apache.) Regardless of which webserver you are using, however,
   ensure that sensitive information is not remotely available by properly
   applying the access controls in Section 4.3.1.
     _________________________________________________________________

2.2.4.1. Apache httpd

   To configure your Apache web server to work with Bugzilla, do the following:
    1. Load httpd.conf in your editor. In Fedora and Red Hat Linux, this file
       is found in /etc/httpd/conf.
    2. Apache uses <Directory> directives to permit fine-grained permission
       setting. Add the following lines to a directive that applies to the
       location of your Bugzilla installation. (If such a section does not
       exist, you'll want to add one.) In this example, Bugzilla has been
       installed at /var/www/html/bugzilla.

<Directory /var/www/html/bugzilla>
  AddHandler cgi-script .cgi
  Options +Indexes +ExecCGI
  DirectoryIndex index.cgi
  AllowOverride Limit
   </Directory>
       These instructions: allow apache to run .cgi files found within the
       bugzilla directory; instructs the server to look for a file called
       index.cgi if someone only types the directory name into the browser; and
       allows Bugzilla's .htaccess files to override global permissions.

       Note It is possible to make these changes globally, or to the directive
   controlling Bugzilla's parent directory (e.g. <Directory /var/www/html/>).
   Such changes would also apply to the Bugzilla directory... but they would
   also apply to many other places where they may or may not be appropriate. In
   most cases, including this one, it is better to be as restrictive as
      possible when granting extra access.
    3. checksetup.pl can set tighter permissions on Bugzilla's files and
       directories if it knows what group the webserver runs as. Find the Group
       line in httpd.conf, place the value found there in the $webservergroup
       variable in localconfig, then rerun checksetup.pl.
    4. Optional: If Bugzilla does not actually reside in the webspace
       directory, but instead has been symbolically linked there, you will need
       to add the following to the Options line of the Bugzilla <Directory>
       directive (the same one as in the step above):

        +FollowSymLinks
       Without this directive, Apache will not follow symbolic links to places
       outside its own directory structure, and you will be unable to run
       Bugzilla.
     _________________________________________________________________

2.2.4.2. Microsoft Internet Information Services

   If you are running Bugzilla on Windows and choose to use Microsoft's
   Internet Information Services or Personal Web Server you will need to
   perform a number of other configuration steps as explained below. You may
   also want to refer to the following Microsoft Knowledge Base articles:
   245225 "HOW TO: Configure and Test a PERL Script with IIS 4.0, 5.0, and 5.1"
   (for Internet Information Services) and 231998 "HOW TO: FP2000: How to Use
   Perl with Microsoft Personal Web Server on Windows 95/98" (for Personal Web
   Server).

   You will need to create a virtual directory for the Bugzilla install. Put
   the Bugzilla files in a directory that is named something other than what
   you want your end-users accessing. That is, if you want your users to access
   your Bugzilla installation through "http://<yourdomainname>/Bugzilla", then
   do not put your Bugzilla files in a directory named "Bugzilla". Instead,
   place them in a different location, and then use the IIS Administration tool
   to create a Virtual Directory named "Bugzilla" that acts as an alias for the
   actual location of the files. When creating that virtual directory, make
   sure you add the "Execute (such as ISAPI applications or CGI)" access
   permission.

   You will also need to tell IIS how to handle Bugzilla's .cgi files. Using
   the IIS Administration tool again, open up the properties for the new
   virtual directory and select the Configuration option to access the Script
   Mappings. Create an entry mapping .cgi to:
<full path to perl.exe >\perl.exe -x<full path to Bugzilla> -wT "%s" %s

   For example:
c:\perl\bin\perl.exe -xc:\bugzilla -wT "%s" %s

   Note The ActiveState install may have already created an entry for .pl files
   that is limited to "GET,HEAD,POST". If so, this mapping should be removed as
      Bugzilla's .pl files are not designed to be run via a webserver.

   IIS will also need to know that the index.cgi should be treated as a default
   document. On the Documents tab page of the virtual directory properties, you
   need to add index.cgi as a default document type. If you wish, you may
   remove the other default document types for this particular virtual
   directory, since Bugzilla doesn't use any of them.

   Also, and this can't be stressed enough, make sure that files such as
   localconfig and your data directory are secured as described in Section
   4.3.1.
     _________________________________________________________________

2.2.4.3. AOL Server

   Ben FrantzDale reported success using AOL Server with Bugzilla. He reported
   his experience and what appears below is based on that.

   AOL Server will have to be configured to run CGI scripts, please consult the
   documentation that came with your server for more information on how to do
   this.

   Because AOL Server doesn't support .htaccess files, you'll have to create a
   TCL script. You should create an aolserver/modules/tcl/filter.tcl file (the
   filename shouldn't matter) with the following contents (change /bugzilla/ to
   the web-based path to your Bugzilla installation):
  ns_register_filter preauth GET /bugzilla/localconfig filter_deny
  ns_register_filter preauth GET /bugzilla/localconfig~ filter_deny
  ns_register_filter preauth GET /bugzilla/\#localconfig\# filter_deny
  ns_register_filter preauth GET /bugzilla/*.pl filter_deny
  ns_register_filter preauth GET /bugzilla/syncshadowdb filter_deny
  ns_register_filter preauth GET /bugzilla/runtests.sh filter_deny
  ns_register_filter preauth GET /bugzilla/data/* filter_deny
  ns_register_filter preauth GET /bugzilla/template/* filter_deny

  proc filter_deny { why } {
      ns_log Notice "filter_deny"
      return "filter_return"
  }

   Warning This probably doesn't account for all possible editor backup files
   so you may wish to add some additional variations of localconfig. For more
      information, see bug 186383 or Bugtraq ID 6501.

   Note If you are using webdot from research.att.com (the default
   configuration for the webdotbase paramater), you will need to allow access
   to data/webdot/*.dot for the reasearch.att.com machine.

   If you are using a local installation of GraphViz, you will need to allow
   everybody to access *.png, *.gif, *.jpg, and *.map in the data/webdot
      directory.
     _________________________________________________________________

2.2.5. Bugzilla

   Your Bugzilla should now be working. Access http://<your-bugzilla-server>/ -
   you should see the Bugzilla front page. If not, consult the Troubleshooting
   section, Appendix B.

   Log in with the administrator account you defined in the last checksetup.pl
   run. You should go through the parameters on the Edit Parameters page (see
   link in the footer) and see if there are any you wish to change. They key
   parameters are documented in Section 3.1; you should certainly alter
   maintainer and urlbase; you may also want to alter cookiepath or
   requirelogin.

   This would also be a good time to revisit the localconfig file and make sure
   that the names of the priorities, severities, platforms and operating
   systems are those you wish to use when you start creating bugs. Remember to
   rerun checksetup.pl if you change it.

   Bugzilla has several optional features which require extra configuration.
   You can read about those in Section 2.3.
     _________________________________________________________________

2.3. Optional Additional Configuration

   Bugzilla has a number of optional features. This section describes how to
   configure or enable them.
     _________________________________________________________________

2.3.1. Bug Graphs

   If you have installed the necessary Perl modules you can start collecting
   statistics for the nifty Bugzilla graphs.
   bash# crontab -e

   This should bring up the crontab file in your editor. Add a cron entry like
   this to run collectstats.pl daily at 5 after midnight:
   5 0 * * * cd <your-bugzilla-directory> ; ./collectstats.pl

   After two days have passed you'll be able to view bug graphs from the
   Reports page.

   Note Windows does not have 'cron', but it does have the Task Scheduler,
   which performs the same duties. There are also third-party tools that can be
      used to implement cron, such as nncron.
     _________________________________________________________________

2.3.2. Dependency Charts

   As well as the text-based dependency trees, Bugzilla also supports a
   graphical view of dependency relationships, using a package called 'dot'.
   Exactly how this works is controlled by the 'webdotbase' parameter, which
   can have one of three values:

    1. A complete file path to the command 'dot' (part of GraphViz) will
       generate the graphs locally
    2. A URL prefix pointing to an installation of the webdot package will
       generate the graphs remotely
    3. A blank value will disable dependency graphing.

   The easiest way to get this working is to install GraphViz. If you do that,
   you need to enable server-side image maps in Apache. Alternatively, you
   could set up a webdot server, or use the AT&T public webdot server. This is
   the default for the webdotbase param, but it's often overloaded and slow.
   Note that AT&T's server won't work if Bugzilla is only accessible using
   HARTS. Editor's note: What the heck is HARTS? Google doesn't know... 
     _________________________________________________________________

2.3.3. The Whining Cron

   What good are bugs if they're not annoying? To help make them more so you
   can set up Bugzilla's automatic whining system to complain at engineers
   which leave their bugs in the NEW or REOPENED state without triaging them.