General Installation Notes

The Bugzilla Guide
Prev | Chapter 4. Installation | Next

# 4.5. General Installation Notes

## 4.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.

`versioncache` 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.

## 4.5.2. Upgrading From Previous Versions

A plain Bugzilla is fairly easy to upgrade from one version to a newer one. However, things get a bit more complicated if you've made changes to Bugzilla's code. In this case, you may have to re-make or reapply those changes. It is recommended that you take a backup of your database and your entire Bugzilla installation before attempting an upgrade. You can upgrade a 'clean' installation by untarring a new tarball over the old installation. If you are upgrading from 2.12 or later, you can type `cvs -z3 update` , and resolve conflicts if there are any.

Because the developers of Bugzilla are constantly adding new tables, columns and fields, you'll probably get SQL errors if you just update the code and attempt to use Bugzilla. Always run the `checksetup.pl` script whenever you upgrade your installation.

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.

## 4.5.3. `.htaccess` files and security

To enhance the security of your Bugzilla installation, Bugzilla's `checksetup.pl` script will generate `.htaccess` files which the Apache webserver can use to restrict access to the bugzilla data files. These .htaccess files will not work with Apache 1.2.x - but this has security holes, so you shouldn't be using it anyway.

| 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 (IIS) or another web server which does not observe `.htaccess` conventions, you can disable their creation by editing `localconfig` and setting the `$create_htaccess` variable to `0`.

## 4.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.

## 4.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# perl -pi -e "s/Content-Type\: text\/html/Content-Type\: text\/html\; charset=ISO-8859-1/i" *.cgi *.pl

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

Prev | Home | Next
Mac OS X Installation Notes | Up | Troubleshooting