465887 - X_BUGZILLA_SITE: Support multipe virtual hosts of bugzilla at the same system

Status: UNCONFIRMED

(Bugzilla :: Bugzilla-General, enhancement)

Description

[Raphael Bossek]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.0.3) Gecko/2008092816 Firefox/2.0.0.11 (Debian-3.0.3-3)
Build Identifier: 3.2.0rc2

How to set several VirtualHosts with this package
------------------------------------------------------------------------------

  If you want to provide several virtual hosts of Bugzilla, you can achieve that
  goal easily thanks to your Apache configuration.

  You will need to enable the Apache mod_env module first:
    
    # a2enmod env

  Then, you have to prepare a configuration directory for your virtual
  host. The simpliest way is to copy the one the package created:
  `/etc/bugzilla3'. 
  Name this new configuration directory like that:
  `/etc/bugzilla3/sites/host' where `host' is the name of your virtual host.

  You have now to add a virtual host section in your Apache configuraiton file. 
  This can be achieved in different ways, depending on the kind of VirtualHost
  you want.

  This package comes with two virtual host examples, located under
  `/usr/share/doc/bugzilla3/examples/'.

  If you want a vritualhost that uses the same static files as the orginal
  package, just use the example: `vh-basic.conf'.

  If you'd rather have different static files for the virtual host, you can
  use the other example: `vh-custom-static.conf'.

  As you can see in those examples, two environment variables are provided for
  fitting your needs:
    - X_BUGZILLA_SITE which is the name of the virtual host, it is used to find
      wich configuration directory to use: `/etc/bugzilla3/sites/X_BUGZILLA_SITE'.
    - X_BUGZILLA_WEBPATH wich is the prefix to prepend to every static files in
      the templates.

  When you are ok with the apache configuration, you can restart it and
  test your virtual host.

  If you want to have specific templates for a given virtual host, that's also
  possible, just copy `/var/lib/bugzilla3/template' to
  `/var/lib/bugzilla3/template-X_BUGZILLA_SITE' and apply your changes there.
  Take care to preserve permissions when you copy the files.
  
  At this time, you can set a different database for each virtual host,
  customize templates for another or even share the same database... Everything
  is possible with few effort.

  Even though each bugzilla site will be updated with checksetup.pl, the params
  file won't be updated. The only params file that is updated during the
  postinst phase is the standard one: `/etc/bugzilla3/params'.

  Thanks to Yann Dirson for the mod_env idea.


Reproducible: Always

Comment 1

[Raphael Bossek]

Attachment: 10_constants.sh

Wrapper script to apply the 10_constants.pm implementation in the current source code without the need of a patch.

Comment 2

[Raphael Bossek]

Attachment: 10_constants.pm

Contains the wrapper arround bz_locations() which support virtual hosts X_BUGZILLA_SITE. Within the function the original bz_locations() function will be called which was renamed to bz_locations_nondebian() by the 10_constants.sh script.

Comment 3

[Max Kanat-Alexander]

What does this have to do with the WebService? And how is this different from the existing PROJECT environment variable?

Comment 4

[Raphael Bossek]

Attachment: 10_config.sh

Script to apply the modifications from 10_config.pm without the need of a patch.

Comment 5

[Raphael Bossek]

Attachment: 10_config.pm

Wrap read_param_file() and write_param_file() so /etc/bugzilla3 is used as directory.

Comment 6

[Raphael Bossek]

(In reply to comment #3)
> What does this have to do with the WebService? And how is this different from
> the existing PROJECT environment variable?

For me one X_BUGZILLA_SITE may have multiple independent PROJECTS.

Comment 7

[Max Kanat-Alexander]

Well, this seems to totally duplicate the PROJECT environment variable, except that it re-uses the same params file for each site.

Comment 8

[Frédéric Buclin]

If each localconfig.foo file has the same data, and each data/foo/params file differs only by the content of urlbase and sslbase (to match each VH), you don't need anything else to use several VHs with one installation, right? This would make this bug WFM, IMHO.