Bugzilla

From HerzbubeWiki

Jump to: navigation, search

Contents

Debian packages

The following Debian packages need to be installed 

bugzilla3
libnet-ldap-perl (for LDAP authentication)


References


Configuration

Web server setup

Normal configuration

Add the following section to my /etc/apache2/conf.d/pelargir.conf: 

<Directory /usr/share/bugzilla3/web/>
  Options +ExecCGI
  AddHandler cgi-script .cgi
</Directory>

If Bugzilla is used outside a Virtual Host configuration, the following configuration should probably be used. This is untested, though. 

<Directory /usr/share/bugzilla3/web/>
  Allow from all
</Directory>
Alias /bugzilla3/ /usr/share/bugzilla3/web/


Virtual Host configuration

Bugzilla can be made to live in its own Virtual Host, although it's not very straightforward (at least to me). The intention is that both CGI scripts and regular web content should live at the root of the vhost, i.e.

  • We want to access /index.cgi (regular setup: /cgi-bin/bugzilla3/index.cgi)
  • Which in turn is supposed to produce HTML that refers to paths like /skins (regular setup: /bugzilla3/skins)


The problem lies in the separation of the CGI scripts (/usr/lib/cgi-bin/bugzilla) and the regular web content (/usr/share/bugzilla3/web) on the file system level. The effect of this separation is that it's not enough to set the DocumentRoot, and maybe throw in an alias or two. Instead we will have to resort to a bit of black magic URL rewriting...


This is the vhost configuration: 

# --------------------------------------------------------------------------------
# bugs.herzbube.ch
# --------------------------------------------------------------------------------
<VirtualHost *:80>
  ServerName bugs.herzbube.ch
  ServerAdmin webmaster@herzbube.ch
  ErrorLog /var/log/apache2/herzbube.ch/error.log
  CustomLog /var/log/apache2/herzbube.ch/access.log combined
  
  # Allow access to DocumentRoot, but only in the context of this vhost
  <Directory /usr/share/bugzilla3/web/>
    Allow from all
  </Directory>

  # Makes regular web content live in the vhost root (e.g. /skins)
  DocumentRoot /usr/share/bugzilla3/web

  # This environment variable is used by Bugzilla to generate paths to
  # regular web content. Defaults to "/bugzilla3" if not set. The default
  # is hardcoded in /usr/share/perl5/Bugzilla/Constants.pm (look for lines
  # that set "debian_webpath").
  #
  # Note: This is Debian specific and quite undocumented!
  <IfModule mod_env.c>
    SetEnv X_BUGZILLA_WEBPATH "/"
  </IfModule>

  <IfModule mod_rewrite.c>
    RewriteEngine On
    # Replace the HTML redirect file index.html. The redirect will cause the web
    # client to issue another request, which will then trigger the next rule.
    RewriteRule ^/$ /index.cgi [R,L]
    # And now the real thing: A request for something that ends with ".cgi" is
    # transparently rewritten, i.e. the web client does not see what's going on
    # behind the scenes. This is necessary because the CGI scripts, for some
    # reason, try to refer to the location
    #   /cgi-bin/bugzilla3
    # even though they actually live in the vhost root. CGI execution probably
    # works because somewhere else files in /cgi-bin have been marked as CGI
    # scripts.
    #
    # Note: The "PT" flag is required to make this rewrite rule work in
    # conjunction with the alias (defined somewhere else) that maps
    # /usr/lib/cgi-bin to /cgi-bin to /cgi-bin. For details read the Apache docs
    # for mod_rewrite.
    RewriteRule ^/cgi-bin/bugzilla3/(.*)$ /$1 [PT]
  </IfModule>
</VirtualHost>
  
# --------------------------------------------------------------------------------
# SSL Hosts
# --------------------------------------------------------------------------------
<IfModule mod_ssl.c>
  <VirtualHost *:443>
    ServerName bugs.herzbube.ch
    ServerAdmin webmaster@herzbube.ch
    ErrorLog /var/log/apache2/herzbube.ch/error.log
    CustomLog /var/log/apache2/herzbube.ch/access.log combined

    <Directory /usr/share/bugzilla3/web/>
      Allow from all
    </Directory>
    DocumentRoot /usr/share/bugzilla3/web
    <IfModule mod_env.c>
      SetEnv X_BUGZILLA_WEBPATH "/"
    </IfModule>
    <IfModule mod_rewrite.c>
      RewriteEngine On
      RewriteRule ^/$ /index.cgi [R,L]
      RewriteRule ^/cgi-bin/bugzilla3/(.*)$ /$1 [PT]
    </IfModule>

    SSLEngine on
    SSLCertificateFile    /etc/ssl/certs/herzbube.ch.crt
    SSLCertificateKeyFile /etc/ssl/private/herzbube.ch.key.unsecure
    SSLCertificateChainFile /etc/ssl/certs/cacert.org.certchain
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
  </VirtualHost>
</IfModule>


Additional changes and notes:

  • Access to the DocumentRoot is allowed in the context of the vhost only. The corresponding global directives therefore need to be removed from pelargir.conf
  • If Bugzilla lives in its own vhost, the alias "/bugzilla3" is not required and should be removed. A prerequisite for this is setting the (Debian-specific) environment variable X_BUGZILLA_WEBPATH.
  • The following settings on Bugzilla's administration pages need to be changed:
    • urlbase
    • sslbase
    • cookiepath
  • Bugzilla thoughtfully provides a robots.txt in /usr/share/bugzilla3/web/robots.txt


MySQL setup

Starting with package bugzilla3, the MySQL database is managed through dbconfig-common.


Script setup

dpkg should do it for you, but if it doesn't you must run 

/usr/share/bugzilla3/lib/checksetup.pl

manually to fill the database.


Web browser setup

Go to 

http://pelargir/cgi-bin/bugzilla3/editparams.cgi

and change the following things:

  • required settings
  • user authentication
    • user_verify_class = LDAP
  • bug fields
    • usetargetmilestone = on
    • usevotes = off
    • defaultpriority = p3
  • LDAP
    • LDAPserver = localhost
    • LDAPbinddn = cn=readonly-users,ou=users,dc=herzbube,dc=ch:<secret>
    • LDAPBaseDN = ou=users,dc=herzbube,dc=ch
    • LDAPmailattribute = bugzillaEmail (default is "mail")

After parameters have been set up

  • Add products & components (e.g. product "AceXpander", components "GUI", "unace communication")

Some notes:

  • See section about LDAP below for details about how the login procedure works
  • New users are automatically part of the groups canconfirm and editbugs because these groups have ".*" as the so-called "User RegExp" (i.e. all users match)
  • New users therefore automatically inherit the appropriate rights from these groups


LDAP

Login procedure

In LDAP mode, when a user tries to login, Bugzilla does the following:

  • User has entered a user name and a password on the login form
  • Bugzilla binds to the directory using the LDAPbinddn parameter (or it binds anonymously if the parameter is not set, but my directory does not allow this)
  • After the initial bind, Bugzilla tries to match the user name entered on the login form to an LDAP entry
  • The LDAP entry to match is searched below LDAPBaseDN
  • To match, an entry must have an attribute named LDAPuidattribute whose value is equal to the user name
  • If a matching entry (M) is found, Bugzilla now tries to bind a second time
  • It uses the matching entry (M) to bind, in conjunction with the password entered on the login form
  • If successful, this constitutes a successful login
  • Bugzilla now tries to extract an email address that it should use as the user name for all of the subsequent actions during this session
  • The email address is extracted from the attribute named LDAPmailattribute within the matching entry (M)


Schema customizations to support Bugzilla

Originally, my LDAP entries below ou=users were simple entries with a structural object class "organizationalRole" and an auxiliary object class "simpleSecurityObject". These two object classes did not support either the "uid" or any "mail" attribute.

Solution for "uid":

  • LDAPuidattribute could have been set to "cn"
  • Or even better, LDAP entries could have been augmented with the additional auxiliary object class "uidObject"

Solution for "mail":

  • Create a new auxiliary object class "bugzillaAccount"
  • Add attribute "bugzillaEmail" to this class and set LDAPmailattribute to this attribute name


Actual LDAP configuration

Is done via web browser in editparams.cgi. Details are listed in the corresponding section further up.


Upgrade

2.20 -> 2.22

After updating in aptitude, the 

checksetup.pl

script must be run manually. On my system, it tells me that at least version 1.67 of perl Module Mail::Mailer is required, but that I have only 1.62. Since the module cannot be installed through aptitude I have to manually install it with 

perl -MCPAN -e 'install "Mail::Mailer"'

Also, the file /etc/bugzilla/params needs to be changed manually:


2.22 -> 3.0

Using dbconfig-common

dpkg asks me whether to use dbconfig-common to manage the MySQL database. Answering yes and also answering the following questions installs a new database "bugzilla3" instead of upgrading the existing database. The following steps are necessary to "point" the dbconfig-common configuration into the right direction for an upgrade:

  • modify the config file to use the old access settings 
/etc/dbconfig-common/bugzilla3.conf
  • change these settings
    • dbc_dbuser = bugzilla (instead of bugzilla3)
    • dbc_dbpass = <secret>
    • dbc_dbname = bugzilla (instead of bugzilla3)
  • run this command 
dpkg-reconfigure bugzilla3
  • provide the following answers to debconf
    • reinstall database = no
    • all other questions = use default values
  • reconfigure runs checksetup.pl which upgrades the old database


Fixing the missing "template" symlink

The installation log contains an error message 

Failed to symlink from ../../../template to /var/lib/bugzilla3/data/template/var/lib/bugzilla3: File exists at /usr/share/perl5/Bugzilla/Template.pm line 919.

Examining the situation I see that the two directories exist and contain similar structure data: 

/var/lib/bugzilla3/template
/var/lib/bugzilla3/data/template/var/lib/bugzilla3/template

Symlinking failed because "someone" created the second directory. From the error message, it looks as if the symlinkg would have been wrong anyway (3 directories up are not enough)... Diff'ing two files reveals that the file in the data directory seems to be a generated file: 

diff /var/lib/bugzilla3/data/template/var/lib/bugzilla3/template/de/default/account/auth/login-small.html.tmpl /var/lib/bugzilla3/template/de/default/account/auth/login-small.html.tmpl

For the moment I don't know what's correct, so I leave the situation as it is - the fact that I did not find any bugs in the Debian bugtracker lets me hope that the installation should work correctly despite the "missing" symlink.


Fix alias in Apache configuration

Change configuration in /etc/apache2/conf.d/pelargir.conf because the package has changed its name from "bugzilla" to "bugzilla3": 

<Directory /usr/share/bugzilla3/web/>
   Allow from all
</Directory>
Alias /bugzilla3/ /usr/share/bugzilla3/web/


Note: Without this change, no skins are displayed. This problem is also described in this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495107


3.0 -> 3.2

The upgrade script asks whether a new version of /etc/bugzilla3/params should be installed. This would overwrite all my settings, so I say "no" here (first saving a copy of the params file that was offered for installation).

Later I check out the differences in detail and change the following things in the web interface (Administration -> Parameters):

  • allowuserdeletion = 0 (was set to 1 previously)
  • docs_urlbase = docs/%lang%/html/ (previously: docs/html/)
  • I also edit the old params file in an editor and clean out settings that are no longer used ("commentonclose" and other similar comment oriented settings; these are now mostly configured on the new workflow configuration pages (Administration -> Bug Status Workflow)).

In addition, I fix the default user preferences (Administration -> Default Preferences)

  • Skin = Dusk (previously: Classic)
  • After changing a bug = Show the updated bug (previously: Show next bug in my list)

Last but not least, I run the sanity check in the web interface (Administration -> Sanity Check).


3.2 -> 3.4

  • The Debian package bugzilla3-3.4.7.0-2 was broken, I had to manually fix the postinst control file. See my Bugzilla entry and the Debian bug I reported
  • In addition, the Apache configuration had to be fixed because this new version of the Bugzilla Debian package no longer uses /cgi-bin/bugzilla3


3.4 -> 3.6

  • The package upgrade coincided with an upgrade of the entire server. I took this opportunity to rename both database and database user from the ancient bugzilla to the more modern bugzilla3.
  • After letting the package create a fresh install, I dropped the new database, re-created it empty, populated it with a backup of the old database, and finally ran an upgrade via 
dpkg-reconfigure bugzilla3
  • I was able to login in immediately afterwards; decided to run a final "Sanity Check", which also did not produce any problems. Probably the first upgrade without any holdup whatsoever
Retrieved from "http://wiki.herzbube.ch/index.php/Bugzilla"
Personal tools
francesca