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 moments, 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 the Bugzilla user experience. 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 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, let's visit the query page. landfill.tequilarista.org/bugzilla-tip/query.cgi

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 "Bugzilla". Select this entry.

4. Did you notice that some of the boxes to the right changed when you selected "Bugzilla"? 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's Bugzilla Components

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

   Administration, Administration of a bugzilla installation, including editcomponents.cgi, editgroups.cgi, editkeywords.cgi, editparams.cgi, editproducts.cgi, editusers.cgi, editversions.cgi, and sanitycheck.cgi.

   Bugzilla-General, Anything that doesn't fit in the other components, or spans multiple components.

   Creating/Changing Bugs, Creating, changing, and viewing bugs. enter_bug.cgi, post_bug.cgi, show_bug.cgi and process_bug.cgi.

   Documentation, The bugzilla documentation, including anything in the docs/ directory and The Bugzilla Guide (This document :)

   Email, Anything to do with email sent by Bugzilla. processmail

   Installation, The installation process of Bugzilla. This includes checksetup.pl and whatever else it evolves into.

   Query/Buglist, Anything to do with searching for bugs and viewing the buglists. query.cgi and buglist.cgi

   Reporting/Charting, Getting reports from Bugzilla. reports.cgi and duplicates.cgi

   User Accounts, Anything about managing a user account from the user's perspective. userprefs.cgi, saved queries, creating accounts, changing passwords, logging in, etc.

   User Interface, General issues having to do with the user interface cosmetics (not functionality) including cosmetic issues, HTML templates, etc.

   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 are done.

2.4.2. Email Settings

---

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.

Linux-Mandrake 8.0, the author's test system, includes every required and optional library for Bugzilla. The easiest way to install them is by using the urpmi utility. If you follow these commands, you should have everything you need for Bugzilla, and checksetup.pl should not complain about any missing libraries. You may already have some of these installed. bash# urpmi perl-mysql bash# urpmi perl-chart bash# urpmi perl-gd bash# urpmi perl-MailTools (for Bugzilla email integration) bash# urpmi apache-modules

3.2.3. Installing MySQL Database

Visit MySQL homepage at www.mysql.com and grab the latest stable release of the server. Many of the binary versions of MySQL store their data files in /var which is often 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 install from source or non-package (RPM, deb, etc.) binaries you need to add mysqld to your init scripts so the server daemon will come back up whenever your machine reboots. Further discussion of UNIX init sequences are beyond the scope of this guide.

You should have your init script start mysqld with the ability to accept large packets. By default, mysqld only accepts packets up to 64K long. This limits the size of attachments you may put on bugs. If you add -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 can be found in Appendix B.

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 (see Appendix B) 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 (see link: Appendix B). 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 the defacto standard for programatic image construction. The Perl bindings to it found in the GD library are used on millions of web pages to generate graphs on the fly. That's what bugzilla will be using it for so you must install it if you want any of the graphing to work.

Actually bugzilla uses the Graph module which relies on GD itself. Isn't that always the way with object-oriented programming? At any rate, you can find the GD library on CPAN in Appendix 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.

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, linked in Appendix B. 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.

I strongly recommend Apache as the web server to use. The Bugzilla Guide installation instructions, in general, assume you are using Apache. As more users use different webservers and send me information on the peculiarities of installing using their favorite webserver, I will provide notes for them.

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 into which you intend to put the bugzilla .html and .cgi files.

Users of newer versions of Apache will generally find both of the above lines will be in the httpd.conf file, rather than srm.conf or access.conf.

There are important files and directories that should not be a served by the HTTP server. These are most files in 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 on how to do this for Apache. I appreciate notes on how to get this same functionality using other webservers.

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, 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. 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, or use The setperl.csh Utility, found in Useful Patches and Utilities for Bugzilla. I suggest using the symlink approach for future release compatability.

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 should 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 will have a nearly empty Bugzilla database and a newly-created localconfig file in your Bugzilla root directory.

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.

The default .htaccess file may not provide adequate access restrictions, depending on your web server configuration. Be sure to check the <Directory> entries for your Bugzilla directory so that the .htaccess file is allowed to override web server defaults. For instance, let's assume your installation of Bugzilla is installed to /usr/local/bugzilla. You should have this <Directory> entry in your httpd.conf file:

<Directory /usr/local/bugzilla/> Options +FollowSymLinks +Indexes +Includes +ExecCGI AllowOverride All </Directory>

The important part above is "AllowOverride All". Without that, the .htaccess file created by checksetup.pl will not have sufficient permissions to protect your Bugzilla installation.

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. mod_throttle and Security

It is possible for a user, by mistake or on purpose, to access the database many times in a row which can result in very slow access speeds for other users. If your Bugzilla installation is experiencing this problem , you may install the Apache module mod_throttle which can limit connections by ip-address. You may download this module at http://www.snert.com/Software/Throttle/. Follow the instructions to install into your Apache install. This module only functions with the Apache web server!. You may use the ThrottleClientIP command provided by this module to accomplish this goal. See the Module Instructions for more information.

3.5.5. Preventing untrusted Bugzilla content from executing malicious Javascript code

It is possible for a Bugzilla to execute malicious Javascript code. Due to internationalization concerns, we are unable to incorporate the code changes necessary to fulfill the CERT advisory requirements mentioned in http://www.cet.org/tech_tips/malicious_code_mitigation.html/#3. Executing the following code snippet from a UNIX command shell will rectify the problem if your Bugzilla installation is intended for an English-speaking audience. As always, be sure your Bugzilla installation has a good backup before making changes, and I recommend you understand what the script is doing before executing it.

bash# cd $BUGZILLA_HOME; for i in `ls *.cgi`; \ do cat $i | sed 's/Content-type\: text\/html/Content-Type: text\/html\; charset=ISO-8859-1/' >$i.tmp; \ mv $i.tmp $i; done

All this one-liner command does is search for all instances of "Content-type: text/html" and replaces it with "Content-Type: text/html; charset=ISO-8859-1". This specification prevents possible Javascript attacks on the browser, and is suggested for all English-speaking sites. For non-english-speaking Bugzilla sites, I suggest changing "ISO-8859-1", above, to "UTF-8".

3.5.6. 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?product=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 Bugzilla Installation 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 strong troubleshooting abilities, a high tolerance for pain, and moderate perl skills. 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 Appendix A.

If you are using IIS or Personal Web Server, 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.

If attempting to run Bugzilla 2.12 or older, you will need to remove encrypt() calls from the Perl source. This is not necessary for Bugzilla 2.13 and later, which includes the current release, Bugzilla 2.14. Example 3-4. Removing encrypt() for Windows NT Bugzilla version 2.12 or earlier Replace this: SendSQL("SELECT encrypt(" . SqlQuote($enteredpwd) . ", " . SQLQuote(substr($realcryptpwd, 0, 2)) . ")"); my $enteredcryptpwd = FetchOneColumn(); with this: my $enteredcryptpwd = $enteredpwd in cgi.pl.

3.6.3. Bugzilla LDAP Integration

What follows is some late-breaking information on using the LDAP authentication options with Bugzilla. The author has not tested these (nor even formatted this section!) so please contribute feedback to the newsgroup.

Mozilla::LDAP module

The Mozilla::LDAP module allows you to use LDAP for authentication to
the Bugzilla system.  This module is not required if you are not using
LDAP.

Mozilla::LDAP (aka PerLDAP) is available for download from
http://www.mozilla.org/directory.

NOTE: The Mozilla::LDAP module requires Netscape's Directory SDK.
Follow the link for "Directory SDK for C" on that same page to
download the SDK first.  After you have installed this SDK, then
install the PerLDAP module.
----------------------------------------------------------------------

Post-Installation Checklist
----------------------------------------------------------------------
Set useLDAP to "On" **only** if you will be using an LDAP directory
for authentication.  Be very careful when setting up this parameter;
if you set LDAP authentication, but do not have a valid LDAP directory
set up, you will not be able to log back in to Bugzilla once you log
out.  (If this happens, you can get back in by manually editing the
data/params file, and setting useLDAP back to 0.)

If using LDAP, you must set the three additional parameters:

Set LDAPserver to the name (and optionally port) of your LDAP server.
If no port is specified, it defaults to the default port of 389.  (e.g
"ldap.mycompany.com" or "ldap.mycompany.com:1234")

Set LDAPBaseDN to the base DN for searching for users in your LDAP
directory.  (e.g. "ou=People,o=MyCompany")  uids must be unique under
the DN specified here.

Set LDAPmailattribute to the name of the attribute in your LDAP
directory which contains the primary email address.  On most directory
servers available, this is "mail", but you may need to change this.
----------------------------------------------------------------------

(Not sure where this bit should go, but it's important that it be in
there somewhere...)
----------------------------------------------------------------------
Using LDAP authentication for Bugzilla:

The existing authentication scheme for Bugzilla uses email addresses
as the primary user ID, and a password to authenticate that user.  All
places within Bugzilla where you need to deal with user ID (e.g
assigning a bug) use the email address.

The LDAP authentication builds on top of this scheme, rather than
replacing it.  The initial log in is done with a username and password
for the LDAP directory.  This then fetches the email address from LDAP
and authenticates seamlessly in the standard Bugzilla authentication
scheme using this email address.  If an account for this address
already exists in your Bugzilla system, it will log in to that
account.  If no account for that email address exists, one is created
at the time of login.  (In this case, Bugzilla will attempt to use the
"displayName" or "cn" attribute to determine the user's full name.)

After authentication, all other user-related tasks are still handled
by email address, not LDAP username.  You still assign bugs by email
address, query on users by email address, etc.
----------------------------------------------------------------------
      

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)"; Yes, that is fourteen "f"'s. A whole lot of f-ing going on if you want to create a new administator.

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! At this time, "Disabled Text" does not prevent a user from using the email interface. If you have the email interface enabled, they can still continue to submit bugs and comments that way. We need a patch to fix this.

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.

You may find this example illustrative for how bug groups work.