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