2.3.1. Create a Bugzilla Account

First things first! If you want to use Bugzilla, first you need to create an account. Consult with the administrator responsible for your installation of Bugzilla for the URL you should use to access it. If you're test-driving the end-user Bugzilla experience, use this URL: http://landfill.tequilarista.org/bugzilla-tip/

1. Click the "Open a new Bugzilla account" link.

2. Enter your "E-mail address" and "Real Name" (or whatever name you want to call yourself) in the spaces provided, then select the "Create Account" button.

3. Within 5-10 minutes, you should receive an email to the address you provided above, which contains your login name (generally the same as the email address), and a password you can use to access your account. This password is randomly generated, and should be changed at your nearest opportunity (we'll go into how to do it later).

4. Click the "Log In" link in the yellow area at the bottom of the page in your browser, then enter your "E-mail address" and "Password" you just received into the spaces provided, and select "Login".

   If you ever forget your password, you can come back to this page, enter your "E-mail address", then select the "E-mail me a password" button to have your password mailed to you again so that you can login.

   Many modern browsers include an "Auto-Complete" or "Form Fill" feature to remember the user names and passwords you type in at many sites. Unfortunately, sometimes they attempt to "guess" what you will put in as your password, and guess wrong. If you notice a text box is already filled out, please overwrite the contents of the text box so you can be sure to input the correct information.

Congratulations! If you followed these directions, you now are the proud owner of a user account on landfill.tequilarista.org (Landfill) or your local Bugzilla install. You should now see in your browser a page called the "Bugzilla Query Page". It may look daunting, but with this Guide to walk you through it, you will master it in no time.

2.3.2. The Bugzilla Query Page

The Bugzilla Query Page is the heart and soul of Bugzilla. It is the master interface where you can find any bug report, comment, or patch currently in the Bugzilla system. We'll go into how to create your own bug report later on.

There are efforts underway to simplify query usage. If you have a local installation of Bugzilla 2.12 or higher, you should have "quicksearch.html" available to use and simplify your searches. There is also, or shortly will be, a helper for the query interface, called "queryhelp.cgi". Landfill tends to run the latest code, so these two utilities should be available there for your perusal.

At this point, please visit the main Bugzilla site, bugzilla.mozilla.org, to see a more fleshed-out query page.

The first thing you need to notice about the Bugzilla Query Page is that nearly every box you see on your screen has a hyperlink nearby, explaining what it is or what it does. Near the upper-left-hand corner of your browser window you should see the word "Status" underlined. Select it.

Notice the page that popped up? Every underlined word you see on your screen is a hyperlink that will take you to context-sensitive help. Click around for a while, and learn what everything here does. To return to the query interface after pulling up a help page, use the "Back" button in your browser.

I'm sure that after checking out the online help, you are now an Expert on the Bugzilla Query Page. If, however, you feel you haven't mastered it yet, let me walk you through making a few successful queries to find out what there are in the Bugzilla bug-tracking system itself.

1. Ensure you are back on the "Bugzilla Query Page" Do nothing in the boxes marked "Status", "Resolution", "Platform", "OpSys", "Priority", or "Severity". The default query for "Status" is to find all bugs that are NEW, ASSIGNED, or REOPENED, which is what we want. If you don't select anything in the other 5 scrollboxes there, then you are saying that "any of these are OK"; we're not locking ourselves into only finding bugs on the "DEC" Platform, or "Windows 95" OpSys (Operating System). You're smart, I think you have it figured out.

   Basically, selecting anything on the query page narrows your search down. Leaving stuff unselected, or text boxes unfilled, broadens your search!

2. You see the box immediately below the top six boxes that contains an "Email" text box, with the words "matching as", a drop-down selection box, then some checkboxes with "Assigned To" checked by default? This allows you to filter your search down based upon email address. Let's put my email address in there, and see what happens.

   Type "barnboy@trilobyte.net" in the top Email text box.

3. Let's narrow the search some more. Scroll down until you find the box with the word "Program" over the top of it. This is where we can narrow our search down to only specific products (software programs or product lines) in our Bugzilla database. Please notice the box is a scrollbox. Using the down arrow on the scrollbox, scroll down until you can see an entry called "Webtools". Select this entry.

4. Did you notice that some of the boxes to the right changed when you selected "Webtools"? Every Program (or Product) has different Versions, Components, and Target Milestones associated with it. A "Version" is the number of a software program.

   Example 2-1. Some Famous Software Versions

   Do you remember the hype in 1995 when Microsoft Windows 95(r) was released? It may have been several years ago, but Microsoft(tm) spent over $300 Million advertising this new Version of their software. Three years later, they released Microsoft Windows 98(r), another new version, to great fanfare, and then in 2000 quietly released Microsoft Windows ME(Millenium Edition)(r).

   Software "Versions" help a manufacturer differentiate their current product from their previous products. Most do not identify their products by the year they were released. Instead, the "original" version of their software will often be numbered "1.0", with small bug-fix releases on subsequent tenths of a digit. In most cases, it's not a decimal number; for instance, often 1.9 is an older version of the software than 1.11, but is a newer version than 1.1.1.

   In general, a "Version" in Bugzilla should refer to released products, not products that have not yet been released to the public. Forthcoming products are what the Target Milestone field is for.

   A "Component" is a piece of a Product. It may be a standalone program, or some other logical division of a Product or Program. Normally, a Component has a single Owner, who is responsible for overseeing efforts to improve that Component.

   Example 2-2. Mozilla Webtools Components

   Mozilla's "Webtools" Product is composed of several pieces (Components):

   Bonsai, a tool to show recent changes to Mozilla

   Bugzilla, a defect-tracking tool

   Build, a tool to automatically compile source code into machine-readable form

   Despot, a program that controls access to the other Webtools

   LXR, a utility that automatically marks up text files to make them more readable

   MozBot, a "robot" that announces changes to Mozilla in Chat

   TestManager, a tool to help find bugs in Mozilla

   Tinderbox, which displays reports from Build

   A different person is responsible for each of these Components. Tara Hernandez keeps the "Bugzilla" component up-to-date.

   A "Milestone", or "Target Milestone" is a often a planned future "Version" of a product. In many cases, though, Milestones simply represent significant dates for a developer. Having certain features in your Product is frequently tied to revenue (money) the developer will receive if the features work by the time she reaches the Target Milestone. Target Milestones are a great tool to organize your time. If someone will pay you $100,000 for incorporating certain features by a certain date, those features by that Milestone date become a very high priority. Milestones tend to be highly malleable creatures, though, that appear to be in reach but are out of reach by the time the important day arrives.

   The Bugzilla Project has set up Milestones for future Bugzilla versions 2.14, 2.16, 2.18, 3.0, etc. However, a Target Milestone can just as easily be a specific date, code name, or weird alphanumeric combination, like "M19".

5. OK, now let's select the "Bugzilla" component from its scrollbox.

6. Skip down the page a bit -- do you see the "submit query" button? Select it, and let's run this query!

7. Congratulations! You've completed your first Query, and have before you the Bug List of the author of this Guide, Matthew P. Barnson (barnboy@trilobyte.net). If I'm doing well, you'll have a cryptic "Zarro Boogs Found" message on your screen. It is just a happy hacker's way of saying "Zero Bugs Found". However, I am fairly certain I will always have some bugs assigned to me that aren't done yet, so you won't often see that message!

I encourage you to click the bug numbers in the left-hand column and examine my bugs. Also notice that if you click the underlined links near the top of this page, they do not take you to context-sensitive help here, but instead sort the columns of bugs on the screen! When you need to sort your bugs by priority, severity, or the people they are assigned to, this is a tremendous timesaver.

A couple more interesting things about the Bug List page:

There are many more options to the Bugzilla Query Page and the Bug List than I have shown you. But this should be enough for you to learn to get around. I encourage you to check out the Bugzilla Home Page to learn about the Anatomy and Life Cycle of a Bug before continuing.

2.3.3. Creating and Managing Bug Reports

2.4.1. Account Settings

On this page, you can change your basic Account Settings, including your password and full name. For security reasons, in order to change anything on this page you must type your current password into the "Old Password" field. If you wish to change your password, type the new password you want into the "New Password" field and again into the "Re-enter new password" field to ensure you typed your new password correctly. Select the "Submit" button and you're done!

2.4.2. Email Settings

2.4.2.1. Email Notification

The email notification settings described below have been obsoleted in Bugzilla 2.12, and this section will be replaced with a comprehensive description of the amazing array of new options at your disposal. However, in the meantime, throw this chunk out the window and go crazy with goofing around with different notification options.

Ahh, here you can reduce or increase the amount of email sent you from Bugzilla! In the drop-down "Notify me of changes to", select one of

All qualifying bugs: sends you every change to every bug where your name is somewhere on it, regardless of who changed it.

Only those bugs which I am listed in the CC line: prevents you from receiving mail for which you are the reporter,' owner, or QA contact. If you are on the CC list, presumably someone had a good reason for you to get the email.

All qulifying bugs except those which I change: This is the default, and a sensible setting. If someone else changes your bugs, you will get emailed, but if you change bugs yourself you will receive no notification of the change.

---

2.4.2.2. New Email Technology

This option may not be available in all Bugzilla installations, depending upon the preferences of the systems administrator responsible for the setup of your Bugzilla. However, if you really want this functionality, ask her to "enable newemailtech in Params" and "make it the default for all new users", referring her to the Administration section of this Guide.

Disregard the warnings about "experimental and bleeding edge"; the code to handle email in a cleaner manner than that historically used for Bugzilla is quite robust and well-tested now.

I recommend you enable the option, "Click here to sign up (and risk any bugs)". Your email-box will thank you for it. The fundamental shift in "newemailtech" is away from standard UNIX "diff" output, which is quite ugly, to a prettier, better laid-out email.

---

2.4.2.3. "Watching" Users

This option may not be available in all Bugzilla installations, depending upon the preferences of the systems administrator responsible for the setup of your Bugzilla. However, if you really want this functionality, ask her to "enable watchers in Params".

By entering user email names into the "Users to watch" text entry box, delineated by commas, you can watch bugs of other users. This powerful functionality enables seamless transitions as developers change projects, managers wish to get in touch with the issues faced by their direct reports, or users go on vacation. If any of these three situations apply to you, you will undoubtedly find this feature quite convenient.

2.4.3. Page Footer

By default, this page is quite barren. However, go explore the Query Page some more; you will find that you can store numerous queries on the server, so if you regularly run a particular query it is just a drop-down menu away. On this page of Preferences, if you have many stored queries you can elect to have them always one-click away!

If you have many stored queries on the server, here you will find individual drop-downs for each stored query. Each drop-down gives you the option of that query appearing on the footer of every page in Bugzilla! This gives you powerful one-click access to any complex searches you may set up, and is an excellent way to impress your boss...

By default, the "My Bugs" link appears at the bottom of each page. However, this query gives you both the bugs you have reported, as well as those you are assigned. One of the most common uses for this page is to remove the "My Bugs" link, replacing it with two other queries, commonly called "My Bug Reports" and "My Bugs" (but only referencing bugs assigned to you). This allows you to distinguish those bugs you have reported from those you are assigned. I commonly set up complex Boolean queries in the Query page and link them to my footer in this page. When they are significantly complex, a one-click reference can save hours of work.

2.4.4. Permissions

This is a purely informative page which outlines your current permissions on this installation of Bugzilla. If you have permissions to grant certain permissions to other users, the "other users" link appears on this page as well as the footer. For more information regarding user administration, please consult the Administration section of this Guide.

3.2.1. Introduction

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.

Bugzilla has been successfully installed under Solaris, Linux, and Win32. The peculiarities of installing on Win32 (Microsoft Windows) are not included in this section of the Guide; please check out the Win32 Installation Notes for further advice on getting Bugzilla to work on Microsoft Windows.

The Bugzilla Guide is contained in the "docs/" folder in your Bugzilla distribution. It is available in plain text (docs/txt), HTML (docs/html), or SGML source (docs/sgml).

3.2.2. Installing the Prerequisites

If you want to skip these manual installation steps for the CPAN dependencies listed below, and are running the very most recent version of Perl and MySQL (both the executables and development libraries) on your system, check out Bundle::Bugzilla in Using Bundle::Bugzilla instead of manually installing Perl modules

The software packages necessary for the proper running of bugzilla are:

1. MySQL database server and the mysql client (3.22.5 or greater)

2. Perl (5.004 or greater, 5.6.1 is recommended if you wish to use Bundle::Bugzilla)

3. DBI Perl module

4. Data::Dumper Perl module

5. Bundle::Mysql Perl module collection

6. TimeDate Perl module collection

7. GD perl module (1.8.3) (optional, for bug charting)

8. Chart::Base Perl module (0.99c) (optional, for bug charting)

9. DB_File Perl module (optional, for bug charting)

10. The web server of your choice. Apache is recommended.

11. MIME::Parser Perl module (optional, for contrib/bug_email.pl interface)

It is a good idea, while installing Bugzilla, to ensure it is not accessible 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.

3.2.3. Installing MySQL Database

Visit MySQL homepage at http://www.mysql.com/ 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.

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.

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.

3.2.4. Perl (5.004 or greater)

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. Although Bugzilla runs with most post-5.004 versions of Perl, it's a good idea to be up to the very latest version if you can when running Bugzilla. As of this writing, that is perl version 5.6.1.

Perl is now a far cry from the the single compiler/interpreter binary it once was. It 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.

Many people complain that Perl modules will not install for them. Most times, the error messages complain that they are missing a file in "@INC". Virtually every time, this is due to permissions being set too restrictively for you to compile Perl modules or not having the necessary Perl development libraries installed on your system.. Consult your local UNIX systems administrator for help solving these permissions issues; if you are the local UNIX sysadmin, please consult the newsgroup/mailing list for further assistance or hire someone to help you out.

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. If you wish to use Bundle::Bugzilla, however, you must be using the latest version of Perl (at this writing, version 5.6.1) bash# perl -MCPAN -e 'install "Bundle::Bugzilla"' 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.

3.2.5. DBI Perl Module

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.

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.

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.

To use the CPAN shell to install DBI:

bash# perl -MCPAN -e 'install "DBI"'

Replace "DBI" with the name of whichever module you wish to install, such as Data::Dumper, TimeDate, GD, etc.

3.2.6. Data::Dumper Perl Module

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.

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.

3.2.7. MySQL related Perl Module Collection

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.

The MySQL modules are all built using one make file which is generated by running: bash# perl Makefile.pl

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.

When asked if your desired target is the MySQL or mSQL packages, select the MySQL related ones. Later you will be asked if you wish to provide backwards compatibility with the older MySQL packages; you should answer YES to this question. The default is NO.

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.

3.2.8. TimeDate Perl Module Collection

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 link link may be found in Appendix B, Software Download Links. 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.

3.2.9. GD Perl Module (1.8.3)

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.

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 B, Software Download Links).

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.

3.2.10. Chart::Base Perl Module (0.99c)

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 B, "Software Download Links". Note that as with the GD perl module, only the version listed above, or newer, will work. Earlier versions used GIF's, which are no longer supported by the latest versions of GD.

3.2.11. DB_File Perl Module

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.

3.2.12. HTTP Server

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.

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: AddHandler cgi-script .cgi

With apache you'll also want to make sure that within the access.conf file the line: Options ExecCGI is in the stanza that covers the directories you intend to put the bugzilla .html and .cgi files into.

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.

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 .htaccess files and security for details.

3.2.13. Installing the Bugzilla Files

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.

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.

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.

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.

If you don't have root access to set this symlink up, check out the The setperl.csh Utility, listed in Useful Patches and Utilities for Bugzilla. It will change the path to perl in all your Bugzilla files for you.

3.2.14. Setting Up the MySQL Database

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.

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. That would be bad.

Give the MySQL root user a password. MySQL passwords are limited to 16 characters.

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.

Remember to set bugs_password to some unique password.

Next, run the magic checksetup.pl script. (Many thanks to Holger Schurig <holgerschurig@nikocity.de> 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.

3.2.15. Tweaking "localconfig"

This file contains a variety of settings you may need to tweak including how Bugzilla should connect to the MySQL database.

The connection settings include:

1. server's host: just use "localhost" if the MySQL server is local

2. database name: "bugs" if you're following these directions

3. MySQL username: "bugs" if you're following these directions

4. Password for the "bugs" MySQL account above

You may also install .htaccess files that the Apache webserver will use to restrict access to Bugzilla data files. See .htaccess files and security.

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.

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.

Should everything work, you should have a nearly empty copy of the bug tracking setup.

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: Now regenerating the shadow database for all bugs.

The second time you run checksetup.pl, you should become the user your web server runs as, and that you ensure that you set the "webservergroup" parameter in localconfig to match the web server's group 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 3-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

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.

3.2.16. Setting Up Maintainers Manually (Optional)

If you want to add someone else to every group by hand, you can do it by typing the appropriate MySQL commands. Run ' mysql -u root -p bugs' You may need different parameters, depending on your security settings. Then:

3.2.17. The Whining Cron (Optional)

By now you have 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):

Depending on your system, crontab may have several manpages. The following command should lead you to the most useful page for this purpose: man 5 crontab

3.2.18. Bug Graphs (Optional)

As long as you installed the GD and Graph::Base Perl modules you might as well turn on the nifty bugzilla bug reporting graphs.

Add a cron entry like this to run collectstats daily at 5 after midnight:

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

3.2.19. Securing MySQL

If you followed the installation instructions 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.

Most MySQL installs have "interesting" default security parameters:

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.

To see your permissions do:

To fix the gaping holes:

If you're not running "mit-pthreads" you can use:

With "mit-pthreads" you'll need to modify the "globals.pl" Mysql->Connect line to specify a specific host name instead of "localhost", and accept external connections:

Use .htaccess files with the Apache webserver to secure your bugzilla install. See .htaccess files and security

Consider also:

1. 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.

2. using the --user= option to mysqld to run it as an unprivileged user.

3. starting MySQL in a chroot jail

4. running the httpd in a "chrooted" jail

5. making sure the MySQL passwords are different from the OS passwords (MySQL "root" has nothing to do with system "root").

6. running MySQL on a separate untrusted machine

7. making backups ;-)

3.5.1. Modifying Your Running System

Bugzilla optimizes database lookups by storing all relatively static information in the versioncache file, located in the data/ subdirectory under your installation directory.

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.

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.

3.5.2. Upgrading From Previous Versions

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.

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.

3.5.3. .htaccess files and security

To enhance the security of your Bugzilla installation, Bugzilla will generate .htaccess files which the Apache webserver can use to restrict access to the bugzilla data files. The checksetup script will generate the .htaccess files.

If you are using an alternate provider of webdot services for graphing (as described when viewing editparams.cgi in your web browser), you will need to change the ip address in data/webdot/.htaccess to the ip address of the webdot server that you are using.

If you are using Internet Information Server or other web server which does not observe .htaccess conventions, you can disable their creation by editing localconfig and setting the $create_htaccess variable to 0.

3.5.4. UNIX Installation Instructions History

This document was originally adapted from the Bonsai installation instructions by Terry Weissman <terry@mozilla.org>.

The February 25, 1999 re-write of this page was done by Ry4an Brase <ry4an@ry4an.org>, with some edits by Terry Weissman, Bryce Nesbitt, Martin Pool, & 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).

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.

Finally, the README in its entirety was marked up in SGML and included into the Guide on April 24, 2001 by Matt Barnson. Since that time, it's undergone extensive modification as Bugzilla grew.

Comments from people using this Guide for the first time are particularly welcome.

3.6.1. Win32 Installation: Step-by-step

You should be familiar with, and cross-reference, the rest of the Chapter 3 section while performing your Win32 installation. Making Bugzilla work on Microsoft Windows is no picnic. Support for Win32 has improved dramatically in the last few releases, but, if you choose to proceed, you should be a very skilled Windows Systems Administrator with both strong troubleshooting abilities and a high tolerance for pain. Bugzilla on NT requires hacking source code and implementing some advanced utilities. What follows is the recommended installation procedure for Win32; additional suggestions are provided in The Bugzilla FAQ.

If you are using IIS 5.0 or higher, you must add cgi relationships to Properties -> Home directory (tab) -> Application Settings (section) -> Configuration (button), such as: .cgi to: <perl install directory>\perl.exe %s %s .pl to: <perl install directory>\perl.exe %s %s GET,HEAD,POST Change the path to Perl to match your install, of course.

3.6.2. Additional Windows Tips

From Andrew Pearson: "You can make Bugzilla work with Personal Web Server for Windows 98 and higher, as well as for IIS 4.0. Microsoft has information available at http://support.microsoft.com/support/kb/articles/Q231/9/98.ASP Basically you need to add two String Keys in the registry at the following location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ScriptMap The keys should be called ".pl" and ".cgi", and both should have a value something like: c:/perl/bin/perl.exe "%s" "%s" The KB article only talks about .pl, but it goes into more detail and provides a perl test script.

"Brian" had this to add, about upgrading to Bugzilla 2.12 from previous versions: Hi - I am updating bugzilla to 2.12 so I can tell you what I did (after I deleted the current dir and copied the files in). In checksetup.pl, I did the following... my $webservergid = getgrnam($my_webservergroup); to my $webservergid = 'Administrators' I then ran checksetup.pl I removed all the encrypt() Example 3-4. Removing encrypt() for Windows NT installations Replace this: SendSQL("SELECT encrypt(" . SqlQuote($enteredpwd) . ", " . SqlQuote(substr($realcryptpwd, 0, 2)) . ")"); my $enteredcryptpwd = FetchOneColumn(); with this: my $enteredcryptpwd = $enteredpwd in cgi.pl. I renamed processmail to processmail.pl I altered the sendmail statements to windmail: open SENDMAIL, "|\"C:/General/Web/tools/Windmail 4.0 Beta/windmail\" -t > mail.log"; The quotes around the dir is for the spaces. mail.log is for the output

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 (without .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.

4.2.1. Creating the Default User

When you first run checksetup.pl after installing Bugzilla, it will prompt you for the administrative username (email address) and password for this "super user". If for some reason you were to delete the "super user" account, re-running checksetup.pl will again prompt you for this username and password.

If you wish to add more administrative users, you must use the MySQL interface. Run "mysql" from the command line, and use these commands ("mysql>" denotes the mysql prompt, not something you should type in): mysql> use bugs; mysql> update profiles set groupset=0x7ffffffffffffff where login_name = "(user's login name)";

4.2.2. Managing Other Users

---

4.2.2.3. Disabling Users

I bet you noticed that big "Disabled Text" entry box available from the "Add New User" screen, when you edit an account? By entering any text in this box and selecting "submit", you have prevented the user from using Bugzilla via the web interface. Your explanation, written in this text box, will be presented to the user the next time she attempts to use the system.

Don't disable your own administrative account, or you will hate life!

4.3.1. Products

Products are the broadest category in Bugzilla, and you should have the least of these. If your company makes computer games, you should have one product per game, and possibly a few special products (website, meetings...)

A Product (formerly called "Program", and still referred to that way in some portions of the source code) controls some very important functions. The number of "votes" available for users to vote for the most important bugs is set per-product, as is the number of votes required to move a bug automatically from the UNCONFIRMED status to the NEW status. One can close a Product for further bug entry and define various Versions available from the Edit product screen.

To create a new product:

1. Select "components" from the yellow footer

   It may seem counterintuitive to click "components" when you want to edit the properties associated with Products. This is one of a long list of things we want in Bugzilla 3.0...

2. Select the "Add" link to the right of "Add a new product".

3. Enter the name of the product and a description. The Description field is free-form.

Don't worry about the "Closed for bug entry", "Maximum Votes per person", "Maximum votes a person can put on a single bug", "Number of votes a bug in this Product needs to automatically get out of the UNCOMFIRMED state", and "Version" options yet. We'll cover those in a few moments.

4.3.2. Components

Components are subsections of a Product.

To create a new Component:

1. Select the "Edit components" link from the "Edit product" page

2. Select the "Add" link to the right of the "Add a new component" text on the "Select Component" page.

3. Fill out the "Component" field, a short "Description", and the "Initial Owner". The Component and Description fields are free-form; the "Initial Owner" field must be that of a user ID already existing in the database. If the initial owner does not exist, Bugzilla will refuse to create the component.

   Is your "Default Owner" a user who is not yet in the database? No problem. Select the "Log out" link on the footer of the page. Select the "New Account" link on the footer of the "Relogin" page Type in the email address of the default owner you want to create in the "E-mail address" field, and her full name in the "Real name" field, then select the "Submit Query" button. Now select "Log in" again, type in your login information, and you can modify the product to use the Default Owner information you require.

4. Either Edit more components or return to the Bugzilla Query Page. To return to the Product you were editing, you must select the Components link as before.

4.3.3. Versions

Versions are the revisions of the product, such as "Flinders 3.1", "Flinders 95", and "Flinders 2000". Using Versions helps you isolate code changes and are an aid in reporting.

To create and edit Versions:

1. From the "Edit product" screen, select "Edit Versions"

2. You will notice that the product already has the default version "undefined". If your product doesn't use version numbers, you may want to leave this as it is or edit it so that it is "---". You can then go back to the edit versions page and add new versions to your product.

   Otherwise, click the "Add" button to the right of the "Add a new version" text.

3. Enter the name of the Version. This can be free-form characters up to the limit of the text box. Then select the "Add" button.

4. At this point you can select "Edit" to edit more Versions, or return to the "Query" page, from which you can navigate back to the product through the "components" link at the foot of the Query page.

4.3.4. Milestones

Milestones are "targets" that you plan to get a bug fixed by. For example, you have a bug that you plan to fix for your 3.0 release, it would be assigned the milestone of 3.0. Or, you have a bug that you plan to fix for 2.8, this would have a milestone of 2.8.

Milestone options will only appear for a Product if you turned the "usetargetmilestone" field in the "Edit Parameters" screen "On".

To create new Milestones, set Default Milestones, and set Milestone URL:

1. Select "edit milestones"

2. Select "Add" to the right of the "Add a new milestone" text

3. Enter the name of the Milestone in the "Milestone" field. You can optionally set the "Sortkey", which is a positive or negative number (-255 to 255) that defines where in the list this particular milestone appears. Select "Add".

   Example 4-4. Using SortKey with Target Milestone

   Let's say you create a target milestone called "Release 1.0", with Sortkey set to "0". Later, you realize that you will have a public beta, called "Beta1". You can create a Milestone called "Beta1", with a Sortkey of "-1" in order to ensure people will see the Target Milestone of "Beta1" earlier on the list than "Release 1.0"

4. If you want to add more milestones, select the "Edit" link. If you don't, well shoot, you have to go back to the "query" page and select "components" again, and make your way back to the Product you were editing.

   This is another in the list of unusual user interface decisions that we'd like to get cleaned up. Shouldn't there be a link to the effect of "edit the Product I was editing when I ended up here"? In any case, clicking "components" in the footer takes you back to the "Select product" screen, from which you can begin editing your product again.

5. From the Edit product screen again (once you've made your way back), enter the URL for a description of what your milestones are for this product in the "Milestone URL" field. It should be of the format "http://www.foo.com/bugzilla/product_milestones.html"

   Some common uses of this field include product descriptions, product roadmaps, and of course a simple description of the meaning of each milestone.

6. If you're using Target Milestones, the "Default Milestone" field must have some kind of entry. If you really don't care if people set coherent Target Milestones, simply leave this at the default, "---". However, controlling and regularly updating the Default Milestone field is a powerful tool when reporting the status of projects.

   Select the "Update" button when you are done.

4.3.5. Voting

The concept of "voting" is a poorly understood, yet powerful feature for the management of open-source projects. Each user is assigned so many Votes per product, which they can freely reassign (or assign multiple votes to a single bug). This allows developers to gauge user need for a particular enhancement or bugfix. By allowing bugs with a certain number of votes to automatically move from "UNCONFIRMED" to "NEW", users of the bug system can help high-priority bugs garner attention so they don't sit for a long time awaiting triage.

The daunting challenge of Votes is deciding where you draw the line for a "vocal majority". If you only have a user base of 100 users, setting a low threshold for bugs to move from UNCONFIRMED to NEW makes sense. As the Bugzilla user base expands, however, these thresholds must be re-evaluated. You should gauge whether this feature is worth the time and close monitoring involved, and perhaps forego implementation until you have a critical mass of users who demand it.

To modify Voting settings:

1. Navigate to the "Edit product" screen for the Product you wish to modify

2. Set "Maximum Votes per person" to your calculated value. Setting this field to "0" disables voting.

3. Set "Maximum Votes a person can put on a single bug" to your calculated value. It should probably be some number lower than the "Maximum votes per person". Setting this field to "0" disables voting, but leaves the voting options open to the user. This is confusing.

4. Set "Number of votes a bug in this product needs to automatically get out of the UNCONFIRMED state" to your calculated number. Setting this field to "0" disables the automatic move of bugs from UNCONFIRMED to NEW. Some people advocate leaving this at "0", but of what use are Votes if your Bugzilla user base is unable to affect which bugs appear on Development radar?

   You should probably set this number to higher than a small coalition of Bugzilla users can influence it. Most sites use this as a "referendum" mechanism -- if users are able to vote a bug out of UNCONFIRMED, it is a really bad bug!

5. Once you have adjusted the values to your preference, select the "Update" button.

4.3.6. Groups and Group Security

Groups can be very useful in bugzilla, because they allow users to isolate bugs or products that should only be seen by certain people. Groups can also be a complicated minefield of interdependencies and weirdness if mismanaged.

Groups in Bugzilla are a complicated beast that evolved out of very simple user permission bitmasks, apparently itself derived from common concepts in UNIX access controls. A "bitmask" is a fixed-length number whose value can describe one, and only one, set of states. For instance, UNIX file permissions are assigned bitmask values: "execute" has a value of 1, "write" has a value of 2, and "read" has a value of 4. Add them together, and a file can be read, written to, and executed if it has a bitmask of "7". (This is a simplified example -- anybody who knows UNIX security knows there is much more to it than this. Please bear with me for the purpose of this note.) The only way a bitmask scheme can work is by doubling the bit count for each value. Thus if UNIX wanted to offer another file permission, the next would have to be a value of 8, then the next 16, the next 32, etc. Similarly, Bugzilla offers a bitmask to define group permissions, with an internal limit of 64. Several are already occupied by built-in permissions. The way around this limitation is to avoid assigning groups to products if you have many products, avoid bloating of group lists, and religiously prune irrelevant groups. In reality, most installations of Bugzilla support far fewer than 64 groups, so this limitation has not hit for most sites, but it is on the table to be revised for Bugzilla 3.0 because it interferes with the security schemes of some administrators.

To enable Generic Group Security ("usebuggroups"):

1. Turn "On" "usebuggroups" in the "Edit Parameters" screen.

2. You will generally have no groups set up. Select the "groups" link in the footer.

3. Take a moment to understand the instructions on the "Edit Groups" screen. Once you feel confident you understand what is expected of you, select the "Add Group" link.

4. Fill out the "New Name" (remember, no spaces!), "New Description", and "New User RegExp" fields. "New User RegExp" allows you to automatically place all users who fulfill the Regular Expression into the new group.

   Example 4-6. Creating a New Group

   I created a group called DefaultGroup with a description of "This is simply a group to play with", and a New User RegExp of ".*@mydomain.tld". This new group automatically includes all Bugzilla users with "@mydomain.tld" at the end of their user id. When I finished, my new group was assigned bit #128.

   When you have finished, select the Add button.

To enable Product-Based Group Security (usebuggroupsentry):

Don't forget that you only have 64 groups masks available, total, for your installation of Bugzilla! If you plan on having more than 50 products in your individual Bugzilla installation, and require group security for your products, you should consider either running multiple Bugzillas or using Generic Group Security instead of Product-Based ("usebuggroupsentry") Group Security.

1. Turn "On" "usebuggroups" and "usebuggroupsentry" in the "Edit Parameters" screen.

   "usebuggroupsentry" has the capacity to prevent the administrative user from directly altering bugs because of conflicting group permissions. If you plan on using "usebuggroupsentry", you should plan on restricting administrative account usage to administrative duties only. In other words, manage bugs with an unpriveleged user account, and manage users, groups, Products, etc. with the administrative account.

2. You will generally have no Groups set up, unless you enabled "usebuggroupsentry" prior to creating any Products. To create "Generic Group Security" groups, follow the instructions given above. To create Product-Based Group security, simply follow the instructions for creating a new Product. If you need to add users to these new groups as you create them, you will find the option to add them to the group available under the "Edit User" screens.