4.2. 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 4.5.4.
The plan for this section is to eventually document the specifics of how to lock down permissions on individual web servers.
4.2.1. Apache httpd
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 are allowed to override Apache's normal access permissions or else important password information may be exposed to the Internet.
You need to configure Apache to run .cgi files outside the cgi-bin directory. Open your httpd.conf file and 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
|
You should modify the <DirectoryIndex> parameter for the Apache virtual host running your Bugzilla installation to allow index.cgi as the index page for a directory, as well as the usual index.html, index.htm, and so forth.
 | For more information on Apache and its directives, see the glossary entry on Apache. |
4.2.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 4.5.4.
4.2.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. |