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