3.5. Installation General Notes
3.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.
That file 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.
3.5.2. Upgrading From Previous Versions
The developers of Bugzilla are constantly adding new tables, columns and fields. You'll get SQL errors if you just update the code. The strategy to update is to simply always run the checksetup.pl script whenever you upgrade your installation of Bugzilla. If you want to see what has changed, you can read the comments in that file, starting from the end.
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.
3.5.3. .htaccess files and security
To enhance the security of your Bugzilla installation, Bugzilla will generate .htaccess files which the Apache webserver can use to restrict access to the bugzilla data files. The checksetup script will generate the .htaccess files.
 | 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. |
If you are using Internet Information Server or other web server which does not observe .htaccess conventions, you can disable their creation by editing localconfig and setting the $create_htaccess variable to 0.
3.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.
3.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# cd $BUGZILLA_HOME; for i in `ls *.cgi`; \ do cat $i | sed 's/Content-type\: text\/html/Content-Type: text\/html\; charset=ISO-8859-1/' >$i.tmp; \ mv $i.tmp $i; done |
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".
3.5.6. UNIX Installation Instructions History
This document was originally adapted from the Bonsai installation instructions by Terry Weissman <terry@mozilla.org>.
The February 25, 1999 re-write of this page was done by Ry4an Brase <ry4an@ry4an.org>, with some edits by Terry Weissman, Bryce Nesbitt, Martin Pool, & Dan Mosedale (But don't send bug reports to them; report them using bugzilla, at http://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla ).
This document was heavily modified again Wednesday, March 07 2001 to reflect changes for Bugzilla 2.12 release by Matthew P. Barnson. The securing MySQL section should be changed to become standard procedure for Bugzilla installations.
Finally, the README in its entirety was marked up in SGML and included into the Guide on April 24, 2001 by Matt Barnson. Since that time, it's undergone extensive modification as Bugzilla grew.
Comments from people using this Guide for the first time are particularly welcome.