From 78e29c8900fa96d67163a34a0c02c7cecb31b55f Mon Sep 17 00:00:00 2001 From: "jake%bugzilla.org" <> Date: Wed, 23 Apr 2003 09:04:01 +0000 Subject: The source files for the Bugzilla Guide have long been using the XML version of DocBook but still residing in the sgml/ directory with an extension of .sgml. In an effort to maintain CVS history, the raw files were copied on the CVS server to the xml/ directory and renamed to have .xml for the extension; any checkins before this one did have the .sgml extension. --- docs/sgml/installation.sgml | 1615 ------------------------------------------- 1 file changed, 1615 deletions(-) delete mode 100644 docs/sgml/installation.sgml (limited to 'docs/sgml/installation.sgml') diff --git a/docs/sgml/installation.sgml b/docs/sgml/installation.sgml deleted file mode 100644 index b9fee2cc8..000000000 --- a/docs/sgml/installation.sgml +++ /dev/null @@ -1,1615 +0,0 @@ - - - Installation - -
- Step-by-step Install - -
- Introduction - - Bugzilla has been successfully installed under Solaris, Linux, - and Win32. Win32 is not yet officially supported, but many people - have got it working fine. - Please see - - for further advice on getting Bugzilla to work on Microsoft - Windows. - -
- -
- Package List - - - If you are running the very most recent - version of Perl and MySQL (both the executables and development - libraries) on your system, you can skip these manual installation - steps for the Perl modules by using Bundle::Bugzilla; see - . - - - - The software packages necessary for the proper running of - Bugzilla (with download links) are: - - - - - - MySQL database server - (&min-mysql-ver; or greater) - - - - - - Perl - (&min-perl-ver;, 5.6.1 is recommended if you wish to - use Bundle::Bugzilla) - - - - - Perl Modules (minimum version): - - - - - Template - (v&min-template-ver;) - - - - - - - File::Temp - (&min-file-temp-ver;) (Prerequisite for Template) - - - - - - AppConfig - - (&min-appconfig-ver;) - - - - - - Text::Wrap - (&min-text-wrap-ver;) - - - - - - File::Spec - - (&min-file-spec-ver;) - - - - - - Data::Dumper - - (&min-data-dumper-ver;) - - - - - - DBD::mysql - - (&min-dbd-mysql-ver;) - - - - - - DBI - (&min-dbi-ver;) - - - - - - Date::Parse - - (&min-date-format-ver;) - - - - - - CGI - - (&min-cgi-ver;) - - - - - and, optionally: - - - - GD - (&min-gd-ver;) for bug charting - - - - - - GD::Graph - (&min-gd-graph-ver;) for bug charting - - - - - - GD::Text::Align - (&min-gd-text-align-ver;) for bug charting - - - - - - Chart::Base - - (&min-chart-base-ver;) for bug charting - - - - - - XML::Parser - (&min-xml-parser-ver;) for the XML interface - - - - - - MIME::Parser - (&min-mime-parser-ver;) for the email interface - - - - - - - - - - The web server of your choice. - Apache - is highly recommended. - - - - - - - - It is a good idea, while installing Bugzilla, to ensure that there - is some kind of firewall between you and the rest of the Internet, - because your machine may be insecure for periods during the install. - Many - installation steps require an active Internet connection to complete, - but you must take care to ensure that at no point is your machine - vulnerable to an attack. - - - -
- -
- MySQL - - Visit the MySQL homepage at - www.mysql.com - to grab and install the latest stable release of the server. - - - - Many of the binary - versions of MySQL store their data files in - /var. - On some Unix systems, this is part of a smaller root partition, - and may not have room for your bug database. You can set the data - directory as an option to configure - if you build MySQL from source yourself. - - - If you install from something other than an RPM or Debian - package, you will need to add mysqld - to your init scripts so the server daemon will come back up whenever - your machine reboots. Further discussion of UNIX init sequences are - beyond the scope of this guide. - - - Change your init script to start - mysqld - with the ability to accept large packets. By default, - mysqld - only accepts packets up to 64K long. This limits the size of - attachments you may put on bugs. If you add - - to the command that starts - mysqld - (or safe_mysqld), - then you will be able to have attachments up to about 1 megabyte. - There is a Bugzilla parameter for maximum attachment size; - you should configure it to match the value you choose here. - - If you plan on running Bugzilla and MySQL on the same machine, - consider using the - - option in the init script. This enhances security by preventing - network access to MySQL. - -
- -
- Perl - - Any machine that doesn't have Perl on it is a sad machine indeed. - Perl can be got in source form from - perl.com for the rare - *nix systems which don't have it. - Although Bugzilla runs with perl &min-perl-ver;, - it's a good idea to be up to the very latest version - if you can when running Bugzilla. As of this writing, that is Perl - version &newest-perl-ver;. - - - - You can skip the following Perl module installation steps by - installing - Bundle::Bugzilla - - from - CPAN, - which installs all required modules for you. - - - - bash# - - perl -MCPAN -e 'install "Bundle::Bugzilla"' - - - - Bundle::Bugzilla doesn't include GD, Chart::Base, or - MIME::Parser, which are not essential to a basic Bugzilla install. If - installing this bundle fails, you should install each module - individually to isolate the problem. - -
- -
- Perl Modules - - - All Perl modules can be found on the - Comprehensive Perl - Archive Network (CPAN). The - CPAN servers have a real tendency to bog down, so please use mirrors. - - - Quality, general Perl module installation instructions can be - found on the CPAN website, but the easy thing to do is to just use the - CPAN shell which does all the hard work for you. - To use the CPAN shell to install a module: - - - - - bash# - perl -MCPAN -e 'install "<modulename>"' - - - - - To do it the hard way: - - - Untar the module tarball -- it should create its own - directory - - CD to the directory just created, and enter the following - commands: - - - - - bash# - - perl Makefile.PL - - - - - - - - bash# - - make - - - - - - - - bash# - - make test - - - - - - - - bash# - - make install - - - - - - - - Many people complain that Perl modules will not install for - them. Most times, the error messages complain that they are missing a - file in - @INC. - Virtually every time, this error is due to permissions being set too - restrictively for you to compile Perl modules or not having the - necessary Perl development libraries installed on your system. - Consult your local UNIX systems administrator for help solving these - permissions issues; if you - are - the local UNIX sysadmin, please consult the newsgroup/mailing list - for further assistance or hire someone to help you out. - - - -
- DBI - - The DBI module is a generic Perl module used the - MySQL-related modules. As long as your Perl installation was done - correctly the DBI module should be a breeze. It's a mixed Perl/C - module, but Perl's MakeMaker system simplifies the C compilation - greatly. -
- -
- Data::Dumper - - The Data::Dumper module provides data structure persistence for - Perl (similar to Java's serialization). It comes with later - sub-releases of Perl 5.004, but a re-installation just to be sure it's - available won't hurt anything. -
- -
- MySQL-related modules - - The Perl/MySQL interface requires a few mutually-dependent Perl - modules. These modules are grouped together into the the - Msql-Mysql-modules package. - - The MakeMaker process will ask you a few questions about the - desired compilation target and your MySQL installation. For most of the - questions the provided default will be adequate, but when asked if your - desired target is the MySQL or mSQL packages, you should - select the MySQL related ones. Later you will be asked if you wish to - provide backwards compatibility with the older MySQL packages; you - should answer YES to this question. The default is NO. - - A host of 'localhost' should be fine and a testing user of 'test' - with a null password should find itself with sufficient access to run - tests on the 'test' database which MySQL created upon installation. - -
- -
- TimeDate modules - - Many of the more common date/time/calendar related Perl modules - have been grouped into a bundle similar to the MySQL modules bundle. - This bundle is stored on the CPAN under the name TimeDate. - The component module we're most interested in is the Date::Format - module, but installing all of them is probably a good idea anyway. - -
- -
- GD (optional) - - The GD library was written by Thomas Boutell a long while ago to - programatically generate images in C. Since then it's become the - defacto standard for programmatic image construction. The Perl bindings - to it found in the GD library are used on millions of web pages to - generate graphs on the fly. That's what Bugzilla will be using it for - so you must install it if you want any of the graphing to work. - - - The Perl GD library requires some other libraries that may or - may not be installed on your system, including - libpng - and - libgd. - The full requirements are listed in the Perl GD library README. - If compiling GD fails, it's probably because you're - missing a required library. - -
- -
- Chart::Base (optional) - - The Chart module provides Bugzilla with on-the-fly charting - abilities. It can be installed in the usual fashion after it has been - fetched from CPAN. - Note that earlier versions that 0.99c used GIFs, which are no longer - supported by the latest versions of GD. -
- -
- Template Toolkit - - When you install Template Toolkit, you'll get asked various - questions about features to enable. The defaults are fine, except - that it is recommended you use the high speed XS Stash of the Template - Toolkit, in order to achieve best performance. - -
- - -
- -
- HTTP Server - - You have freedom of choice here, pretty much any web server that - is capable of running CGI - scripts will work. has more information about - configuring web servers to work with Bugzilla. - - - - We strongly recommend Apache as the web server to use. The - Bugzilla Guide installation instructions, in general, assume you are - using Apache. If you have got Bugzilla working using another webserver, - please share your experiences with us. - - -
- -
- Bugzilla - - You should untar the Bugzilla files into a directory that you're - willing to make writable by the default web server user (probably - nobody). - You may decide to put the files in the main web space for your - web server or perhaps in - /usr/local - with a symbolic link in the web space that points to the Bugzilla - directory. - - - If you symlink the bugzilla directory into your Apache's HTML - hierarchy, you may receive - Forbidden - errors unless you add the - FollowSymLinks - directive to the <Directory> entry for the HTML root - in httpd.conf. - - - Once all the files are in a web accessible directory, make that - directory writable by your webserver's user. This is a temporary step - until you run the post-install - checksetup.pl - script, which locks down your installation. -
- -
- Setting Up the MySQL Database - - After you've gotten all the software installed and working you're - ready to start preparing the database for its life as the back end to - a high quality bug tracker. - - First, you'll want to fix MySQL permissions to allow access from - Bugzilla. For the purpose of this Installation section, the Bugzilla - username will be - bugs, and will have minimal permissions. - - - Begin by giving the MySQL root user a password. MySQL passwords are limited - to 16 characters. - - - - bash# - - mysql -u root mysql - - - - - - mysql> - - UPDATE user SET Password=PASSWORD('<new_password'>) - WHERE user='root'; - - - - - - mysql> - - FLUSH PRIVILEGES; - - - - - From this point on, if you need to access MySQL as the MySQL root user, - you will need to use - mysql -u root -p - - and enter <new_password>. Remember that MySQL user names have - nothing to do with Unix user names (login names). - - Next, we use an SQL GRANT command to create a - bugs - - user, and grant sufficient permissions for checksetup.pl, which we'll - use later, to work its magic. This also restricts the - bugs - user to operations within a database called - bugs, and only allows the account to connect from - localhost. - Modify it to reflect your setup if you will be connecting from - another machine or as a different user. - - Remember to set <bugs_password> to some unique password. - - - - mysql> - - GRANT SELECT,INSERT,UPDATE,DELETE,INDEX, - ALTER,CREATE,DROP,REFERENCES ON bugs.* TO bugs@localhost - IDENTIFIED BY '<bugs_password>'; - - - - - - mysql> - - FLUSH PRIVILEGES; - - - - - - - If you are using MySQL 4, the bugs user also needs to be granted - the LOCK TABLES and CREATE TEMPORARY TABLES permissions. - - -
- -
- - <filename>checksetup.pl</filename> - - - Next, run the magic checksetup.pl script. (Many thanks to - Holger Schurig - for writing this script!) - This script is designed to make sure your MySQL database and other - configuration options are consistent with the Bugzilla CGI files. - It will make sure Bugzilla files and directories have reasonable - permissions, set up the - data - directory, and create all the MySQL tables. - - - - bash# - - ./checksetup.pl - - - - - The first time you run it, it will create a file called - localconfig. - - This file contains a variety of settings you may need to tweak - including how Bugzilla should connect to the MySQL database. - - The connection settings include: - - - server's host: just use - localhost - if the MySQL server is local - - - - database name: - bugs - if you're following these directions - - - - MySQL username: - bugs - if you're following these directions - - - - Password for the - bugs - MySQL account; (<bugs_password>) above - - - - - Once you are happy with the settings, - su to the user - your web server runs as, and re-run - checksetup.pl. (Note: on some security-conscious - systems, you may need to change the login shell for the webserver - account before you can do this.) - On this second run, it will create the database and an administrator - account for which you will be prompted to provide information. - - - The checksetup.pl script is designed so that you can run it at - any time without causing harm. You should run it after any upgrade to - Bugzilla. - -
- -
- Configuring Bugzilla - - You should run through the parameters on the Edit Parameters page - (link in the footer) and set them all to appropriate values. - They key parameters are documented in . - -
-
- -
- Optional Additional Configuration - -
- Dependency Charts - - As well as the text-based dependency graphs, Bugzilla also - supports dependency graphing, using a package called 'dot'. - Exactly how this works is controlled by the 'webdotbase' parameter, - which can have one of three values: - - - - - - - A complete file path to the command 'dot' (part of - GraphViz) - will generate the graphs locally - - - - - A URL prefix pointing to an installation of the webdot package will - generate the graphs remotely - - - - - A blank value will disable dependency graphing. - - - - - - So, to get this working, install - GraphViz. If you - do that, you need to - enable - server-side image maps in Apache. - Alternatively, you could set up a webdot server, or use the AT&T - public webdot server (the - default for the webdotbase param). Note that AT&T's server won't work - if Bugzilla is only accessible using HARTS. - -
- -
- Bug Graphs - - As long as you installed the GD and Graph::Base Perl modules you - might as well turn on the nifty Bugzilla bug reporting graphs. - - Add a cron entry like this to run - collectstats.pl - daily at 5 after midnight: - - - - bash# - - crontab -e - - - - - 5 0 * * * cd <your-bugzilla-directory> ; - ./collectstats.pl - - - - - After two days have passed you'll be able to view bug graphs from - the Bug Reports page. -
- -
- The Whining Cron - - By now you have a fully functional Bugzilla, but what good are - bugs if they're not annoying? To help make those bugs more annoying you - can set up Bugzilla's automatic whining system to complain at engineers - which leave their bugs in the NEW state without triaging them. - - - This can be done by - adding the following command as a daily crontab entry (for help on that - see that crontab man page): - - - - cd <your-bugzilla-directory> ; - ./whineatnews.pl - - - - - - - Depending on your system, crontab may have several manpages. - The following command should lead you to the most useful page for - this purpose: - -man 5 crontab - - - -
- -
- LDAP Authentication - - - This information on using the LDAP - authentication options with Bugzilla is old, and the authors do - not know of anyone who has tested it. Approach with caution. - - - - - - The existing authentication - scheme for Bugzilla uses email addresses as the primary user ID, and a - password to authenticate that user. All places within Bugzilla where - you need to deal with user ID (e.g assigning a bug) use the email - address. The LDAP authentication builds on top of this scheme, rather - than replacing it. The initial log in is done with a username and - password for the LDAP directory. This then fetches the email address - from LDAP and authenticates seamlessly in the standard Bugzilla - authentication scheme using this email address. If an account for this - address already exists in your Bugzilla system, it will log in to that - account. If no account for that email address exists, one is created at - the time of login. (In this case, Bugzilla will attempt to use the - "displayName" or "cn" attribute to determine the user's full name.) - After authentication, all other user-related tasks are still handled by - email address, not LDAP username. You still assign bugs by email - address, query on users by email address, etc. - - - Using LDAP for Bugzilla authentication requires the - Mozilla::LDAP (aka PerLDAP) Perl module. The - Mozilla::LDAP module in turn requires Netscape's Directory SDK for C. - After you have installed the SDK, then install the PerLDAP module. - Mozilla::LDAP and the Directory SDK for C are both - available for - download from mozilla.org. - - - - Set the Param 'useLDAP' to "On" **only** if you will be using an LDAP - directory for - authentication. Be very careful when setting up this parameter; if you - set LDAP authentication, but do not have a valid LDAP directory set up, - you will not be able to log back in to Bugzilla once you log out. (If - this happens, you can get back in by manually editing the data/params - file, and setting useLDAP back to 0.) - - - If using LDAP, you must set the - three additional parameters: Set LDAPserver to the name (and optionally - port) of your LDAP server. If no port is specified, it defaults to the - default port of 389. (e.g "ldap.mycompany.com" or - "ldap.mycompany.com:1234") Set LDAPBaseDN to the base DN for searching - for users in your LDAP directory. (e.g. "ou=People,o=MyCompany") uids - must be unique under the DN specified here. Set LDAPmailattribute to - the name of the attribute in your LDAP directory which contains the - primary email address. On most directory servers available, this is - "mail", but you may need to change this. - - - You can also try using - OpenLDAP with Bugzilla, using any of a number of administration - tools. You should apply the patch attached this bug: - - http://bugzilla.mozilla.org/show_bug.cgi?id=158630, then set - the following object classes for your users: - - - objectClass: person - objectClass: organizationalPerson - objectClass: inetOrgPerson - objectClass: top - objectClass: posixAccount - objectClass: shadowAccount - - - Please note that this patch has not yet been - accepted by the Bugzilla team, and so you may need to do some - manual tweaking. That said, it looks like Net::LDAP is probably - the way to go in the future. - -
- -
- - 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# perl -pi -e "s/Content-Type\: text\/html/Content-Type\: text\/html\; charset=ISO-8859-1/i" *.cgi *.pl - - - - 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. - - - Using <meta> tags to set the charset is not - recommended, as there's a bug in Netscape 4.x which causes pages - marked up in this way to load twice. See - bug - 126266 for more information including progress toward making - bugzilla charset aware by default. - - -
- -
- - <filename>directoryindex</filename> for the Bugzilla default page. - - - 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. -
- -
- - Bugzilla and <filename>mod_perl</filename> - - Bugzilla is unsupported under mod_perl. Effort is underway - to make it work cleanly in a mod_perl environment, but it is - slow going. - -
- -
- - <filename>mod_throttle</filename> - - 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. -
-
- -
- OS Specific Installation Notes - - Many aspects of the Bugzilla installation can be affected by the - the operating system you choose to install it on. Sometimes it can be made - easier and others more difficult. This section will attempt to help you - understand both the difficulties of running on specific operating systems - and the utilities available to make it easier. - - - If you have anything to add or notes for an operating system not - covered, please file a bug in &bzg-bugs;. - - -
- Microsoft Windows - - Making Bugzilla work on windows is still a very painful processes. - The Bugzilla Team is working to make it easier, but that goal is not - considered a top priority. If you wish to run Bugzilla, we still - recommend doing so on a Unix based system such as GNU/Linux. As of this - writing, all members of the Bugzilla team and all known large installations - run on Unix based systems. - - - If after hearing all that, you have enough pain tolerance to attempt - installing Bugzilla on Win32, here are some pointers. - - - -
- Win32 Perl - - Perl for Windows can be obtained from ActiveState. You should be - able to find a compiled binary at http://aspn.activestate.com/ASPN/Downloads/ActivePerl/. - -
- -
- Perl Modules on Win32 - - Bugzilla on Windows requires the same perl modules found in - . The main difference is that - windows uses ppm instead of CPAN. - - - -C:\perl> ppm <module name> - - - - The above syntax should work for all modules with the exception - of Template Toolkit. The Template Toolkit website - suggests using the instructions on OpenInteract's website. - - - - - A complete list of modules that can be installed using ppm can - be found at http://www.activestate.com/PPMPackages/5.6plus. - - -
- -
- Code changes required to run on win32 - - Unfortunately, Bugzilla still doesn't run "out of the box" on - Windows. There is work in progress to make this easier, but until that - happens code will have to be modified. This section is an attempt to - list the required changes. It is an attempt to be all inclusive, but - there may be other changes required. If you find something is missing, - please file a bug in &bzg-bugs;. - - -
- Changes to <filename>checksetup.pl</filename> - - In checksetup.pl, the line reading: - - -my $mysql_binaries = `which mysql`; - - to - -my $mysql_binaries = "D:\\mysql\\bin\\mysql"; - - - And you'll also need to change: - - -my $webservergid = getgrnam($my_webservergroup) - - to - -my $webservergid = '8' - -
- -
- -
- Serving the web pages - - As is the case on Unix based systems, any web server should be - able to handle Bugzilla; however, the Bugzilla Team still recommends - Apache whenever asked. No matter what web server you choose, be sure - to pay attention to the security notes in . - More information on configuring specific web servers can be found in - . - - - - If using Apache on windows, you can set the ScriptInterpreterSource - directive in your Apache config, if you don't do this, you'll have - to modify the first line of every script to contain your path to - perl instead of /usr/bin/perl. - - - -
- -
- -
- <productname>Mac OS X</productname> - - - There are a lot of common libraries and utilities out there that - Apple did not include with Mac OS X, but which run perfectly well on it. - The GD library, which Bugzilla needs to do bug graphs, is one of - these. - - The easiest way to get a lot of these is with a program called - Fink, which is similar in nature to the CPAN installer, but installs - common GNU utilities. Fink is available from - . - - Follow the instructions for setting up Fink. Once it's installed, - you'll want to run the following as root: - fink install gd - - - It will prompt you for a number of dependencies, type 'y' and hit - enter to install all of the dependencies. Then watch it work. - - To prevent creating conflicts with the software that Apple installs - by default, Fink creates its own directory tree at /sw where it installs - most of the software that it installs. This means your libraries and - headers for libgd will be at /sw/lib and /sw/include instead of /usr/lib - and /usr/local/include. Because of these changed locations for the - libraries, the Perl GD module will not install directly via CPAN, because it - looks for the specific paths instead of getting them from your - environment. But there's a way around that :-) - - Instead of typing - install GD - at the - cpan> - prompt, type - look GD. - This should go through the motions of downloading the latest version of - the GD module, then it will open a shell and drop you into the build - directory. Apply this patch - to the Makefile.PL file (save the - patch into a file and use the command - patch < patchfile.) - - - Then, run these commands to finish the installation of the GD - module: - - - perl Makefile.PL - - - - make - - - - make test - - - - make install - - - And don't forget to run - exit - - to get back to CPAN. - - - -
- -
- Linux-Mandrake 8.0 - - Linux-Mandrake 8.0 includes every required and optional library - for Bugzilla. The easiest way to install them is by using the - urpmi utility. If you follow these commands, you - should have everything you need for Bugzilla, and - ./checksetup.pl should not complain about any - missing libraries. You may already have some of these installed. - - - -bash# urpmi perl-mysql -bash# urpmi perl-chart -bash# urpmi perl-gd -bash# urpmi perl-MailTools -bash# urpmi apache-modules - - - - for Bugzilla e-mail integration - - - -
- -
- -
- 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 - . - - - The plan for this section is to eventually document the specifics of how to lock - down permissions on individual web servers. - - -
- Apache <productname>httpd</productname> - - 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 - 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 - 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 . - - - - - <filename>.htaccess</filename> files for Apache - - $BUGZILLA_HOME/.htaccess - - deny from all - - - allow from all - - ]]> - - - $BUGZILLA_HOME/data/.htaccess - - allow from all - - ]]> - - - $BUGZILLA_HOME/data/webdot - - Allow from 192.20.225.10 - Deny from all - - -# Allow access by a local copy of 'dot' to .png, .gif, .jpg, and -# .map files - - Allow from all - - -# 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 - - - - - -
- -
- Microsoft <productname>Internet Information Services</productname> - - 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 . - - -
- -
- 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 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. - - -
-
- -
- Troubleshooting - - This section gives solutions to common Bugzilla installation - problems. - - -
- Bundle::Bugzilla makes me upgrade to Perl 5.6.1 - - - Try executing perl -MCPAN -e 'install CPAN' - and then continuing. - - - - Certain older versions of the CPAN toolset were somewhat naive about how - to upgrade Perl modules. When a couple of modules got rolled into the core - Perl distribution for 5.6.1, CPAN thought that the best way to get those - modules up to date was to haul down the Perl distribution itself and - build it. Needless to say, this has caused headaches for just about - everybody. Upgrading to a newer version of CPAN with the - commandline above should fix things. - -
- - -
- DBD::Sponge::db prepare failed - - - The following error message may appear due to a bug in DBD::mysql - (over which the Bugzilla team have no control): - - - - - - To fix this, go to - <path-to-perl>/lib/DBD/sponge.pm - in your Perl installation and replace - - -{'NUM_OF_FIELDS'}) { - $numFields = $attribs->{'NUM_OF_FIELDS'}; - } elsif ($attribs->{'NAME'}) { - $numFields = @{$attribs->{NAME}}; -]]> - - - by - - -{'NUM_OF_FIELDS'}) { - $numFields = $attribs->{'NUM_OF_FIELDS'}; - } elsif ($attribs->{'NAMES'}) { - $numFields = @{$attribs->{NAMES}}; -]]> - - - (note the S added to NAME.) - -
- -
- cannot chdir(/var/spool/mqueue) - - If you are installing Bugzilla on SuSE Linux, or some other - distributions with - paranoid - security options, it is possible that the checksetup.pl script may fail - with the error: - - - - - This is because your - /var/spool/mqueue - directory has a mode of - drwx------. Type - chmod 755 - /var/spool/mqueue - - as root to fix this problem. - -
- -
- Your vendor has not defined Fcntl macro O_NOINHERIT - - This is caused by a bug in the version of - File::Temp that is distributed with perl - 5.6.0. Many minor variations of this error have been reported. Examples - can be found in . - - -
- Other File::Temp error messages - - -Your vendor has not defined Fcntl macro O_NOINHERIT, used -at /usr/lib/perl5/site_perl/5.6.0/File/Temp.pm line 208. - -Your vendor has not defined Fcntl macro O_EXLOCK, used -at /usr/lib/perl5/site_perl/5.6.0/File/Temp.pm line 210. - -Your vendor has not defined Fcntl macro O_TEMPORARY, used -at /usr/lib/perl5/site_perl/5.6.0/File/Temp.pm line 233. - -
- - Numerous people have reported that upgrading to version 5.6.1 - or higher solved the problem for them. A less involved fix is to apply - the patch in . The patch is also - available as a patch file. - - -
- Patch for File::Temp in Perl 5.6.0 - - -
-
-
- - - - -- cgit v1.2.3-24-g4f1b