= The Bugzilla4Intranet Guide - (UNRELEASED) [[about]] == About This Guide [[copyright]] === Copyright Information This document is copyright (c) 2000-2014 by the various Bugzilla and Bugzilla4Intranet contributors who wrote it. [quote] ____ Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in <>. ____ If you have any questions regarding this document, its copyright, or publishing this document in non-electronic form, please contact the Bugzilla Team. [[disclaimer]] === Disclaimer No liability for the contents of this document can be accepted. Follow the instructions herein at your own risk. This document may contain errors and inaccuracies that may damage your system, cause your partner to leave you, your boss to fire you, your cats to pee on your furniture and clothing, and global thermonuclear war. Proceed with caution. Naming of particular products or brands should not be seen as endorsements, with the exception of the term "GNU/Linux". We wholeheartedly endorse the use of GNU/Linux; it is an extremely versatile, stable, and robust operating system that offers an ideal operating environment for Bugzilla. Although the Bugzilla development team has taken great care to ensure that all exploitable bugs have been fixed, security holes surely exist in any piece of code. Great care should be taken both in the installation and usage of this software. The Bugzilla development team members assume no liability for your use of Bugzilla. You have the source code, and are responsible for auditing it yourself to ensure your security needs are met. [[newversions]] === New Versions This is the (UNRELEASED) version of The Bugzilla4Intranet Guide. It is so named to match the current version of Bugzilla4Intranet. The latest version of this guide can always be found at http://github.com/vitalif/bugzilla4intranet/tree/beta/docs/en/asciidoc/Bugzilla-Guide.asciidoc. However, you should read the version which came with the Bugzilla4Intranet release you are using. [[credits]] === Credits The people listed below have made enormous contributions to the creation of this Guide, through their writing, dedicated hacking efforts, numerous e-mail and IRC support sessions, and overall excellent contribution to the Bugzilla community: Matthew P. Barnson pass:[mbarnson@sisna.com]:: for the Herculean task of pulling together the Bugzilla Guide and shepherding it to 2.14. Terry Weissman pass:[terry@mozilla.org]:: for initially writing Bugzilla and creating the README upon which the UNIX installation documentation is largely based. Tara Hernandez pass:[tara@tequilarists.org]:: for keeping Bugzilla development going strong after Terry left mozilla.org and for running landfill. Dave Lawrence pass:[dkl@redhat.com]:: for providing insight into the key differences between Red Hat's customized Bugzilla. Dawn Endico pass:[endico@mozilla.org]:: for being a hacker extraordinaire and putting up with Matthew's incessant questions and arguments on irc.mozilla.org in #mozwebtools Jacob Steenhagen pass:[jake@bugzilla.org]:: for taking over documentation during the 2.17 development period. Dave Miller pass:[justdave@bugzilla.org]:: for taking over as project lead when Tara stepped down and continually pushing for the documentation to be the best it can be. Thanks also go to the following people for significant contributions to this documentation: * Kevin Brannen * Vlad Dascalu * Ben FrantzDale * Eric Hanson * Zach Lipton * Gervase Markham * Andrew Pearson * Joe Robins * Spencer Smith * Ron Teitelbaum * Shane Travis * Martin Wulffeld Also, thanks are due to the members of the link:$$news://news.mozilla.org/mozilla.support.bugzilla$$[mozilla.support.bugzilla] newsgroup (and its predecessor, netscape.public.mozilla.webtools). Without your discussions, insight, suggestions, and patches, this could never have happened. [[conventions]] === Document Conventions This document uses the following conventions: File or directory name:: _filename_ Command to be typed:: _command_ Application name:: application Normal user's prompt under bash shell:: bash$ Root user's prompt under bash shell:: bash# Normal user's prompt under tcsh shell:: tcsh$ Environment variables:: VARIABLE ---- Code example ---- == About Bugzilla and Bugzilla4Intranet Bugzilla is a free bug-tracking system that is developed by the Mozilla community. While it's actively maintained, it contains a lot of legacy and ugly code, and some features that are implemented in a very strange and non-intuitive manner. Bugzilla4Intranet is a highly improved fork of Bugzilla version 3.6.4, which was started just as a customised Bugzilla version used internally in link:http://custis.ru/[CUSTIS] company. CUSTIS is a Russian company that develops custom-built large-scale information systems for banking and trade applications. The amount of changes has quickly become so great and so "fundamental" that starting with 3.6.4, the idea of merging with the upstream was rejected and that's when Bugzilla4Intranet became a separate project. The ideal goal of Bugzilla4Intranet is being Fast and Customisable. Ideally, no behaviour should be hardcoded, no modification of code or templates should be required for customisation or localisation. In this guide, both 'Bugzilla' and 'Bugzilla4Intranet' terms usually refer to Bugzilla4Intranet. If something only applies to the 'original Bugzilla', it is stated separately. [[installing-bugzilla]] == Installing Bugzilla [[installation]] === Installation [NOTE] If you just want to _use_ Bugzilla, you do not need to install it. None of this chapter is relevant to you. Ask your Bugzilla administrator for the URL to access it from your web browser. The Bugzilla server software is usually installed on GNU/Linux or *BSD system. If you are installing on another OS, check <> before you start your installation to see if there are any special instructions. This guide assumes that you have administrative access to the Bugzilla machine. It is also possible to install and run Bugzilla without administrative access, although it is usually harder. [WARNING] The installation process may make your machine insecure for short periods of time. Make sure there is a firewall between you and the Internet. You are strongly recommended to make a backup of your system before installing Bugzilla (and at regular intervals thereafter :-). In outline, the installation proceeds as follows: <> (5.8.1 or above) <> (and optionally <>) <> <> <> <> (Sendmail 8.7 or above, or an MTA that is Sendmail-compatible with at least this version) Configure all of the above. [[install-perl5]] ==== Perl 5 Installed Version Test: ---- perl -v ---- Any machine that doesn't have Perl 5 on it is a sad machine indeed. If you don't have it and your OS doesn't provide official packages, visit http://www.perl.org. Although Bugzilla should run with Perl 5.8.1, it's a good idea to be using the latest stable version. NOTE: Although Windows is not a recommended platform itself, we recommend to use link:http://strawberryperl.com/[Strawberry Perl] on it. Strawberry Perl contains a working GCC compiler toolchain and a package manager that allows to install Perl modules containing native code easily. [[install-database]] ==== Database Engine Bugzilla supports MySQL/MariaDB, PostgreSQL and Oracle as database servers, or SQLite as an embedded SQL database for small or development installations. You only require one of these systems to make use of Bugzilla. [[install-mysql]] ===== MySQL or MariaDB MySQL is a popular free and open-source DBMS; MariaDB is an enhanced community fork of MySQL started when MySQL company has been acquired by Oracle. It's fully compatible with MySQL. Installed Version Test: ---- mysql -V ---- If you don't have it and your OS doesn't provide official packages, visit http://mariadb.org/ or http://www.mysql.com/. Bugzilla is compatible with any MySQL/MariaDB version 4.1.2 or higher, but the best is to use the latest MariaDB version, because it contains more advanced features out-of-the-box. [NOTE] Many of the binary versions of MySQL/MariaDB store their data files in _/var_. On some systems, this is part of a smaller root partition, and may not have room for your bug database. In this case just move existing database files to some other place and change data directory in your _my.cnf_ configuration file. If you install from something other than a packaging/installation system, such as .rpm (Redhat Package), .deb (Debian Package), .exe (Windows Executable), or .msi (Microsoft Installer), make sure the MySQL server is started when the machine boots. [[install-pg]] ===== PostgreSQL Installed Version Test: ---- psql -V ---- If you don't have it and your OS doesn't provide official packages, visit http://www.postgresql.org/. You need PostgreSQL version 8.00.0000 or higher. If you install from something other than a packaging/installation system, such as .rpm (Redhat Package), .deb (Debian Package), .exe (Windows Executable), or .msi (Microsoft Installer), make sure the PostgreSQL server is started when the machine boots. [[install-oracle]] ===== Oracle WARNING: Oracle is not a recommended database for Bugzilla4Intranet. It's a closed-source commercial product, it's harded to administer and it doesn't offer any real advantage over MySQL or PostgreSQL for Bugzilla. Moreover, there are some MySQL-specific features in Bugzilla and most testing is done on MySQL and PostgreSQL installations so while Oracle support should mostly work, it may be more buggy than MySQL or PostgreSQL. Installed Version Test: ---- select * from v$version ---- (you first have to log in into your DB) If you don't have it and your OS doesn't provide official packages, visit http://www.oracle.com/. You need Oracle version 10.02.0 or higher. If you install from something other than a packaging/installation system, such as .rpm (Redhat Package), .deb (Debian Package), .exe (Windows Executable), or .msi (Microsoft Installer), make sure the Oracle server is started when the machine boots. ===== SQLite SQLite is a small and lightweight embedded SQL database library, so it doesn't require separate DBMS server. Due to SQLite's link:$$http://sqlite.org/faq.html#q5$$[concurrency limitations] we recommend SQLite only for small and development Bugzilla installations. No special configuration is required to run Bugzilla on SQLite, besides installing perl `DBD::SQLite` module. The database will be stored in _data/db/$db_name_, where `$db_name` is the database name defined in _localconfig_. [[install-sphinx]] ==== Sphinx Search link:http://sphinxsearch.com[Sphinx Search] is an easy-to-use high-performance full-text search server. It's faster (in some cases *much* faster) and gives better search quality than the full-text search built into any of the databases Bugzilla may use (especially MySQL). Bugzilla4Intranet may use Sphinx for full-text searching. If you want to use it, you must install Sphinx server (any version that supports SphinxQL, that is, at least 2.0.1). Use official packages of your distribution or visit http://sphinxsearch.com/downloads/. After installing Sphinx, you must enable SphinxQL protocol by adding 'listen' directive to the 'searchd' section of your 'sphinx.conf' (usually located in '/etc/sphinxsearch' on GNU/Linux), and configure the index for Bugzilla. Example configuration is (also provided in 'data/sphinx.conf'): ---- index bugs { type = rt path = /var/lib/sphinxsearch/data/bugs rt_field = short_desc rt_field = comments rt_field = comments_private docinfo = extern enable_star = 1 charset_type = utf-8 charset_table = 0..9, A..Z->a..z, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F blend_chars = _, -, &, +, @, $ morphology = stem_enru min_word_len = 2 } searchd { ... listen = /var/run/sphinxsearch/searchd.sock:mysql41 ... } ---- After configuring Sphinx server set '$sphinx_*' variables in your 'localconfig'. For the above case it should look like the following: ---- $sphinx_index = 'bugs'; $sphinx_host = '127.0.0.1'; $sphinx_port = 0; $sphinx_sock = '/var/run/sphinxsearch/searchd.sock'; ---- .Installing Sphinx from source To install Sphinx from source, run the following commands: ---- tar -zxf sphinx-.tar.gz cd sphinx- ./configure --prefix=/usr --sysconfdir=/etc/sphinxsearch --localstatedir=/var --datarootdir=/var/lib/sphinxsearch --enable-id64 --with-libstemmer make clean make -j4 sudo make install ---- [[install-webserver]] ==== Web Server You have several options here: * *Recommended option:* use the pure-perl standalone HTTP server 'HTTPServerSimple.pl' supplied with Bugzilla4Intranet installed behind a fast reverse-proxy like link:http://nginx.org[nginx] or link:http://lighttpd.net/[lighttpd]. * *The simplest way:* Use just 'HTTPServerSimple.pl' without any reverse proxy. It is capable of serving static files, so this setup also works, but it may be less secure to have it point directly to the public network (because it's of course less tested than nginx or lighttpd). Also note that the standalone server doesn't support keepalive so the client will open much more connections which also affects page load speed. * Run Bugzilla inside link:http://httpd.apache.org/[Apache] with link:http://perl.apache.org/[mod_perl]. This setup should result in roughly the same performance, but usually consumes more memory than the standalone server, especially if you have several virtual hosts / web applications in a single Apache instance. Sometimes mod_perl usage also results is very strange bugs that don't show up in the bare Perl. * *The worst:* Run Bugzilla using CGI with any webserver capable of running CGI scripts. This is the worst option because CGI means Perl must re-initialise all Bugzilla modules on every request which usually leads to poor performance. [[install-bzfiles]] ==== Bugzilla4Intranet You can check out Bugzilla4Intranet from one of these Git repositories: * https://github.com/vitalif/bugzilla-4intranet * http://yourcmc.ru/git/summary/bugzilla-4intranet.git Also you can download a release archive from GitHub 'Releases' page: https://github.com/vitalif/bugzilla-4intranet/releases or just from a branch: https://github.com/vitalif/bugzilla-4intranet/archive/beta.zip and extract it in a suitable directory, accessible by the default web server user (in case of Apache, it's usually "httpd", "apache" or "www-data"). [CAUTION] The Bugzilla distribution is NOT designed to be placed in a _cgi-bin_ directory. This includes any directory which is configured using the ScriptAlias directive of Apache. It's not needed (and even _not recommended_) to make Bugzilla files to be writable by your web-server user. Although they _must_ be readable by it and you may even leave them world-readable - that's no problem because _checksetup.pl_ will take care of setting correct permissions to sensitive files and to files that Bugzilla needs to write (mainly _data/_ directory). But you should run _checksetup.pl_ as the user that is a member of the web-server group (or a superuser) so it could change group on these files. [[install-perlmodules]] ==== Perl Modules Bugzilla's installation process is based on a script called _checksetup.pl_. The first thing it checks is whether you have appropriate versions of all the required Perl modules. The aim of this section is to pass this check. When it passes, proceed to <>. To check you have the required modules, run: ---- bash# ./checksetup.pl --check-modules ---- _checksetup.pl_ will print out a list of the required and optional Perl modules, together with the versions (if any) installed on your machine. The list of required modules is reasonably long; however, you may already have several of them installed. The best is to install missing Perl modules system-wise, but this requires root permissions (_su_ or _sudo bash_ to root before proceeding). You may install modules using the following methods: . Using the official packages of your operating system or distribution. It's *almost certain* that not all modules are available as the official packages, at least on GNU/Linux distributions, but you may install the ones that are available with the system package manager. Package manager is usually 'yum' or 'zypper' in RPM-based GNU/Linux distros, 'apt-get' in Debian GNU/Linux-based systems, and 'ppm' (Perl Package Manager) in Windows link:http://www.activestate.com/activeperl[ActivePerl] and link:http://strawberryperl.com/[Strawberry Perl] distributions. Package names vary: * For example, in Debian ImageMagick is 'perlmagick' and most other packages have names similar to 'libxxx-yyyperl' for 'Xxx::Yyy' perl module. * In RPM-based distros, packages are usually named 'perl-Xxx-Yyy'. * In PPM, they're usually just 'Xxx-Yyy'. . Using link:http://cpan.org/[CPAN] shell. In fact, you may install all required modules using CPAN. To install modules using CPAN shell, run `cpan Module1 Module2...` or `perl -MCPAN -eshell Module1 Module2...` command as the root user, where 'Module1', 'Module2' and etc are the required modules. + NOTE: Some of modules (database drivers, GD, ImageMagick and etc) contain native code (C/C++) and require a working compiler toolchain, libraries and their development ('-dev' or '-devel') packages to install. . Using the _install-module.pl_ script. In this case just run `perl install-module.pl ` from the Bugzilla installation directory. It basically invokes CPAN, but it's capable of installing modules to local Bugzilla directory instead of installing them system-wise. . Manually. In this case see <>. [TIP] ==== 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. ==== Here is a complete list of modules and their minimum versions. Some modules have special installation notes, which follow. Required Perl modules: include::../../required-modules.asciidoc[] Optional Perl modules: include::../../optional-modules.asciidoc[] [[install-MTA]] ==== Mail Transfer Agent (MTA) Bugzilla is dependent on the availability of an e-mail system for its user authentication and for other tasks. [NOTE] ==== This is not entirely true. It is possible to completely disable email sending, or to have Bugzilla store email messages in a file instead of sending them. However, this is mainly intended for testing, as disabling or diverting email on a production machine would mean that users could miss important events (such as bug changes or the creation of new accounts). For more information, see the "mail_delivery_method" parameter in <>. ==== On Linux, any Sendmail-compatible MTA (Mail Transfer Agent) will suffice. Sendmail, Postfix, qmail and Exim are examples of common MTAs. Sendmail is the original Unix MTA, but the others are easier to configure, and therefore many people replace Sendmail with Postfix or Exim. They are drop-in replacements, so Bugzilla will not distinguish between them. If you are using Sendmail, version 8.7 or higher is required. If you are using a Sendmail-compatible MTA, it must be congruent with at least version 8.7 of Sendmail. Consult the manual for the specific MTA you choose for detailed installation instructions. Each of these programs will have their own configuration files where you must configure certain parameters to ensure that the mail is delivered properly. They are implemented as services, and you should ensure that the MTA is in the auto-start list of services for the machine. If a simple mail sent with the command-line 'mail' or 'sendmail -t' program succeeds, then Bugzilla should also be fine. [[configuration]] === Configuration [WARNING] ==== Poorly-configured MySQL and Bugzilla installations have given attackers full access to systems in the past. Please take the security parts of these guidelines seriously, even for Bugzilla machines hidden away behind your firewall. Be certain to read <> for some important security tips. ==== [[localconfig]] ==== localconfig You should now run _checksetup.pl_ again, this time without the +--check-modules+ switch. ---- bash ./checksetup.pl ---- This time, _checksetup.pl_ should tell you that all the correct modules are installed and will display a message about, and write out a file called, _localconfig_. This file contains the default settings for a number of Bugzilla parameters. Load this file in your editor. The only values you _need_ to change are database connection details: '$db_driver' :: Name of the database driver you want to use. May be 'mysql', 'pg', 'oracle' or 'sqlite'. '$db_host' :: Hostname or IP address on which the database server runs, usually 'localhost' (ignored by SQLite). '$db_user' and '$db_password' :: Database user and password to connect as (ignored by SQLite). Pick a username and a strong password; you will create this user during the next installation step. '$db_name' :: Name of the database Bugzilla should use (database filename in case of SQLite). In case of MySQL/PostgreSQL you will create this database during the next installation step. + NOTE: In Oracle, '$db_name' should actually be the SID name of your database (e.g. "XE" if you are using Oracle XE). You may need to change the value of '$webservergroup' if your web server does not run in the "apache" group. On Debian, for example, Apache runs in the "www-data" group. If you are going to run Bugzilla on a machine where you do not have root or web-server group access, you will need to leave _webservergroup_ empty, ignoring the warnings that _checksetup.pl_ will subsequently display every time it is run. The other options in the _localconfig_ file are documented by their accompanying comments. [[database-engine]] ==== Database Server This section deals with configuring your database server for use with Bugzilla. Currently, <>, <> and <> are available. SQLite does not require additional configuration. [[database-schema]] ===== Bugzilla Database Schema The Bugzilla database schema is described in 'Bugzilla/DB/Schema.pm' source file. There is the link:$$http://www.ravenbrook.com/project/p4dti/tool/cgi/bugzilla-schema/$$[Ravenbrook] utility which can generate a written description of the schema, but it's now limited to Bugzilla 3.4.2 and surely it doesn't know anything about Bugzilla4Intranet. Nevertheless, its source is available in link:https://github.com/Ravenbrook/bugzilla-schema[this GitHub repository], so you may try to use it by hand on a Bugzilla4Intranet installation. [[mysql]] ===== MySQL [CAUTION] ==== MySQL's default configuration may be insecure. We highly recommend to run _$$mysql_secure_installation$$_ on Linux or the MySQL installer on Windows, and follow the instructions. Important points to note are: . Be sure that the root account has a secure password set. . Do not create an anonymous account, and if it exists, say "yes" to remove it. . If your web server and MySQL server are on the same machine, you should disable the network access. ==== [[mysql-max-allowed-packet]] .Allow many comments By default, MySQL will only allow you to insert things into the database that are smaller than 1MB. But in the case you use MySQL full-text search, Bugzilla combines all comments on a single bug into one field, and the combination of all comments on a single bug could in some cases be larger than 1MB. Original Bugzilla also used to store attachments in the DB, but Bugzilla4Intranet doesn't do it by default, so max_allowed_packet doesn't affect them. To change MySQL's default, you need to edit your MySQL configuration file, which is usually _/etc/my.cnf_ on Linux. We recommend that you allow at least 4MB packets by adding the "max_allowed_packet" parameter to your MySQL configuration in the "[mysqld]" section, like this: ---- [mysqld] # Allow packets up to 4MB max_allowed_packet=4M ---- .Allow small words in full-text indexes By default, words must be at least four characters in length in order to be indexed by MySQL's full-text indexes. This causes a lot of Bugzilla specific words to be missed, including "cc", "ftp" and "uri". MySQL can be configured to index those words by setting the ft_min_word_len param to the minimum size of the words to index. This can be done by modifying the _/etc/my.cnf_ according to the example below: ---- [mysqld] # Allow small words in full-text indexes ft_min_word_len=2 ---- Rebuilding the indexes can be done based on documentation found at link:$$http://www.mysql.com/doc/en/Fulltext_Fine-tuning.html$$[]. [[install-setupdatabase-adduser]] .Add a user to MySQL You need to add a new MySQL user for Bugzilla to use (It's not safe to have Bugzilla use the MySQL root account). You will need the '$db_*' values you set in _localconfig_ in <>. We use an SQL _GRANT_ command to create the '$db_user' user. This also restricts him to operations within a database called '$db_name', and only allows the account to connect from '$db_host' (usually 'localhost'). Modify it to reflect your setup if you will be connecting from another machine or as a different user. Run the _mysql_ command-line client and enter: ---- mysql> GRANT ALL PRIVILEGES ON $db_name.* TO '$db_user'@'$db_host' IDENTIFIED BY '$db_pass'; mysql> FLUSH PRIVILEGES; ---- [[postgresql]] ===== PostgreSQL .Add a User to PostgreSQL You need to add a new user to PostgreSQL for the Bugzilla application to use when accessing the database. The following instructions assume the defaults in __localconfig__; if you changed those, you need to modify the commands appropriately. You will need the '$db_pass' password you set in _localconfig_ in <>. On most systems, to create the user in PostgreSQL, you will need to login as the root user, and then ---- bash# su - postgres ---- As the postgres user, you then need to create a new user: ---- bash$ createuser -U postgres -dRSP $db_user ---- When asked for a password, provide the password which will be set as '$db_pass' in _localconfig_. The created user will not be a superuser (-S) and will not be able to create new users (-R). He will only have the ability to create databases (-d). [NOTE] If your are running PostgreSQL 8.0, you must replace -dRSP by -dAP. .Configure PostgreSQL Now, you will need to edit _$$pg_hba.conf$$_ which is usually located in _/var/lib/pgsql/data/_. In this file, you will need to add a new line to it as follows: ---- host all $db_user 127.0.0.1 255.255.255.255 md5 ---- This means that for TCP/IP (host) connections, allow connections from '127.0.0.1' to 'all' databases on this server from the '$db_user' user, and use password authentication (md5) for that user. Now, you will need to restart PostgreSQL, but you will need to fully stop and start the server rather than just restarting due to the possibility of a change to _postgresql.conf_. [[oracle]] ===== Oracle .Create a New Tablespace You can use the existing tablespace or create a new one for Bugzilla. To create a new tablespace, run the following command: ---- CREATE TABLESPACE bugs DATAFILE '$path_to_datafile' SIZE 500M AUTOEXTEND ON NEXT 30M MAXSIZE UNLIMITED ---- Here, the name of the tablespace is 'bugs', but you can choose another name. '$path_to_datafile' is the path to the file containing your database, for instance _/u01/app/oracle/oradata/XE/bugzilla.dbf_. The initial size of the database file is set in this example to 500 Mb, with an increment of 30 Mb everytime we reach the size limit of the file. .Add a User to Oracle The user name and password must match what you set in _localconfig_ ('$db_user' and '$db_pass', respectively). Here, we assume that the user name is 'bugs' and the tablespace name is the same as above. ---- CREATE USER bugs IDENTIFIED BY "$db_pass" DEFAULT TABLESPACE bugs TEMPORARY TABLESPACE TEMP PROFILE DEFAULT; -- GRANT/REVOKE ROLE PRIVILEGES GRANT CONNECT TO bugs; GRANT RESOURCE TO bugs; -- GRANT/REVOKE SYSTEM PRIVILEGES GRANT UNLIMITED TABLESPACE TO bugs; GRANT EXECUTE ON CTXSYS.CTX_DDL TO bugs; ---- .Configure the Web Server For Oracle database driver to work, you must add ORACLE_HOME and LD_LIBRARY_PATH to your web-server environment variables. For instance, for Apache and Oracle XE installed into '/u01/app/oracle/product/11.2.0/xe', add the following into 'httpd.conf': ---- SetEnv ORACLE_HOME /u01/app/oracle/product/11.2.0/xe SetEnv LD_LIBRARY_PATH /u01/app/oracle/product/11.2.0/xe/lib/ ---- When this is done, restart your web server. ==== checksetup.pl Next, rerun _checksetup.pl_. It reconfirms that all the modules are present, and notices the altered localconfig file, which it assumes you have edited to your satisfaction. It compiles the UI templates, connects to the database using the 'bugs' user you created and the password you defined, and creates the 'bugs' database and the tables therein. After that, it asks for details of an administrator account. Bugzilla can have multiple administrators - you can create more later - but it needs one to start off with. Enter the email address of an administrator, his or her full name, and a suitable Bugzilla password. _checksetup.pl_ will then finish. You may rerun _checksetup.pl_ at any time if you wish. [[http]] ==== Web server Configure your web server according to the instructions in the appropriate section. To check whether your web server is correctly configured, run `perl testserver.pl http://` from the Bugzilla installation directory. It will perform some checks; if OK is displayed for all of them, then your configuration is successful. Regardless of which web server you are using, however, ensure that sensitive information is not remotely available by properly applying the access controls in <>. [[http-standalone]] ===== Standalone server (HTTPServerSimple.pl) NOTE: *HTTPServerSimple.pl is the recommended way to run Bugzilla.* It's a simple pure-perl application that doesn't require an external web server to run. it's fast, it's free of mod_perl-specific bugs, it doesn't require Apache to be installed, and it consumes less memory than mod_perl or CGI-based setups. The fastest and safest way is to use it with a reverse proxy like link:http://nginx.org[nginx] or link:http://lighttpd.net/[lighttpd] so it serves static files and proxies all script requests to 'HTTPServerSimple.pl'. Refer to the official documentation of these servers for information about how to configure them. It's also possible to use the standalone server without a reverse proxy if you don't want to use one. In this case just configure 'HTTPServerSimple.pl' to listen on '0.0.0.0:80'. However this setup does not allow you to use SSL and even HTTP keepalive, and to have a single server for multiple sites or webapplications, because port 80 is occupied by Bugzilla. .How to configure HTTPServerSimple.pl 'HTTPServerSimple.pl' is configured either in the config file or via command line options: perl HTTPServerSimple.pl --