HTTP Server Configuration

The Bugzilla Guide - 2.17.5 Development Release
Prev | Chapter 4. Installation | Next

# 4.4. HTTP Server Configuration

The Bugzilla Team recommends Apache when using Bugzilla, however, any web server that can be configured to run CGI scripts should be able to handle Bugzilla. No matter what web server you choose, but especially if you choose something other than Apache, you should be sure to read Section 5.6.4.

The plan for this section is to eventually document the specifics of how to lock down permissions on individual web servers.

## 4.4.1. Apache httpd

As mentioned above, the Bugzilla Team recommends Apache for use with Bugzilla. You will have to make sure that Apache is properly configured to run the Bugzilla CGI scripts. You also need to make sure that the `.htaccess` files created by ./checksetup.pl (shown in Example 4-2 for the curious) are allowed to override Apache's normal access permissions or else important password information may be exposed to the Internet.

Many Apache installations are not configured to run scripts anywhere but in the `cgi-bin` directory; however, we recommend that Bugzilla not be installed in the `cgi-bin`, otherwise the static files such as images and JavaScript will not work correctly. To allow scripts to run in the normal web space, the following changes should be made to your `httpd.conf` file.

To allow files with a .cgi extension to be run, make sure the following line exists and is uncommented:

    AddHandler cgi-script .cgi

To allow `.htaccess` files to override permissions and .cgi files to run in the Bugzilla directory, make sure the following two lines are in a `Directory` directive that applies to the Bugzilla directory on your system (either the Bugzilla directory or one of its parents).

    Options +ExecCGI
    AllowOverride Limit

| For more information on Apache and its directives, see the glossary entry on Apache.

Example 4-2. `.htaccess` files for Apache

`$BUGZILLA_HOME/.htaccess`

    # don't allow people to retrieve non-cgi executable files or our private data
    <FilesMatch ^(.*\.pl|.*localconfig.*|runtests.sh)$>
      deny from all
    </FilesMatch>
    <FilesMatch ^(localconfig.js|localconfig.rdf)$>
      allow from all
    </FilesMatch>

`$BUGZILLA_HOME/data/.htaccess`

    # nothing in this directory is retrievable unless overriden by an .htaccess
    # in a subdirectory; the only exception is duplicates.rdf, which is used by
    # duplicates.xul and must be loadable over the web
    deny from all
    <Files duplicates.rdf>
      allow from all
    </Files>

`$BUGZILLA_HOME/data/webdot`

    # Restrict access to .dot files to the public webdot server at research.att.com
    # if research.att.com ever changed their IP, or if you use a different
    # webdot server, you'll need to edit this
    <FilesMatch ^[0-9]+\.dot$>
      Allow from 192.20.225.10
      Deny from all
    </FilesMatch>

    # Allow access by a local copy of 'dot' to .png, .gif, .jpg, and
    # .map files
    <FilesMatch ^[0-9]+\.(png|gif|jpg|map)$>
      Allow from all
    </FilesMatch>

    # And no directory listings, either.
    Deny from all

`$BUGZILLA_HOME/Bugzilla/.htaccess`

    # nothing in this directory is retrievable unless overriden by an .htaccess
    # in a subdirectory
    deny from all

`$BUGZILLA_HOME/template/.htaccess`

    # nothing in this directory is retrievable unless overriden by an .htaccess
    # in a subdirectory
    deny from all

## 4.4.2. Microsoft Internet Information Services

If you need, or for some reason even want, to use Microsoft's Internet Information Services or Personal Web Server you should be able to. You will need to configure them to know how to run CGI scripts, however. This is described in Microsoft Knowledge Base article Q245225 for Internet Information Services and Q231998 for Personal Web Server.

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

## 4.4.3. AOL Server

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

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

Because AOL Server doesn't support `.htaccess` files, you'll have to create a TCL script. You should create an `aolserver/modules/tcl/filter.tcl` file (the filename shouldn't matter) with the following contents (change `/bugzilla/` to the web-based path to your Bugzilla installation):

    ns_register_filter preauth GET /bugzilla/localconfig filter_deny
    ns_register_filter preauth GET /bugzilla/localconfig~ filter_deny
    ns_register_filter preauth GET /bugzilla/\#localconfig\# filter_deny
    ns_register_filter preauth GET /bugzilla/*.pl filter_deny
    ns_register_filter preauth GET /bugzilla/syncshadowdb filter_deny
    ns_register_filter preauth GET /bugzilla/runtests.sh filter_deny
    ns_register_filter preauth GET /bugzilla/data/* filter_deny
    ns_register_filter preauth GET /bugzilla/template/* filter_deny

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

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

| If you are using webdot from research.att.com (the default configuration for the `webdotbase` paramater), you will need to allow access to `data/webdot/*.dot` for the reasearch.att.com machine. If you are using a local installation of GraphViz, you will need to allow everybody to access `*.png`, `*.gif`, `*.jpg`, and `*.map` in the `data/webdot` directory.

Prev | Home | Next
OS Specific Installation Notes | Up | Troubleshooting