Optional Additional Configuration

The Bugzilla Guide - 2.17.5 Development Release
Prev | Chapter 4. Installation | Next

# 4.2. Optional Additional Configuration

## 4.2.1. 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:

1. A complete file path to the command 'dot' (part of GraphViz) will generate the graphs locally

2. A URL prefix pointing to an installation of the webdot package will generate the graphs remotely

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

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

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

## 4.2.4. LDAP Authentication

| LDAP authentication has been rewritten for the 2.18 release of Bugzilla. It no longer requires the Mozilla::LDAP module and now uses Net::LDAP instead. This rewrite was part of a larger landing that allowed for additional authentication schemes to be easily added (bug 180642). This patch originally landed in 21-Mar-2003 and was included in the 2.17.4 development release.

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.

| Because the Bugzilla account is not created until the first time a user logs in, a user who has not yet logged is unknown to Bugzilla. This means they cannot be used as an assignee or QA contact (default or otherwise), added to any cc list, or any other such operation. One possible workaround is the `bugzilla_ldapsync.rb` script in the `contrib` directory. Another possible solution is fixing bug 201069.

Parameters required to use LDAP Authentication:

loginmethod

  This parameter should be set to "LDAP" only if you will be using an LDAP directory for authentication. If you set this param to "LDAP" but fail to set up the other parameters listed below you will not be able to log back in to Bugzilla one you log out. If this happens to you, you will need to manually edit `data/params` and set loginmethod to "DB".

LDAPserver

  This parameter should be set to the name (and optionally the port) of your LDAP server. If no port is specified, it assumes the default LDAP port of 389.

  Ex. "ldap.company.com" or "ldap.company.com:3268"

LDAPbinddn [Optional]

  Some LDAP servers will not allow an anonymous bind to search the directory. If this is the case with your configuration you should set the LDAPbinddn parameter to the user account Bugzilla should use instead of the anonymous bind.

  Ex. "cn=default,cn=user:password"

LDAPBaseDN

  The LDAPBaseDN parameter should be set to the location in your LDAP tree that you would like to search for e-mail addresses. Your uids should be unique under the DN specified here.

  Ex. "ou=People,o=Company"

LDAPuidattribute

  The LDAPuidattribute parameter should be set to the attribute which contains the unique UID of your users. The value retrieved from this attribute will be used when attempting to bind as the user to confirm their password.

  Ex. "uid"

LDAPmailattribute

  The LDAPmailattribute parameter should be the name of the attribute which contains the e-mail address your users will enter into the Bugzilla login boxes.

  Ex. "mail"

## 4.2.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.cert.org/tech_tips/malicious_code_mitigation.html/#3. Making the change below will fix the problem if your installation is for an English speaking audience.

Telling Bugzilla to output a charset as part of the HTTP header is much easier in version 2.18 and higher (including any cvs pull after 4-May-2003 and development release after 2.17.5) than it was in previous versions. Simply locate the following line in `Bugzilla/CGI.pm`:

        # Make sure that we don't send any charset headers
        $self->charset('');

and change it to:

        # Send all data using the ISO-8859-1 charset
        $self->charset('ISO-8859-1');

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

## 4.2.6. `directoryindex` 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.

## 4.2.7. Bugzilla and `mod_perl`

Bugzilla is unsupported under mod_perl. Effort is underway to make it work cleanly in a mod_perl environment, but it is slow going.

## 4.2.8. `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/mod_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.

Prev | Home | Next
Step-by-step Install | Up | OS Specific Installation Notes