Two domains, one RT?

Darren_Nickerson3 · February 18, 2002, 4:14pm

Folks,

I’d like to setup RT for two projects I support - www.hylafax.org and
www.tpc.int. I normally host everything from these two domains on one server,
and so I’m wondering how practical it’s going to be to have two separate RT
installations running on the same box.

Are there any alternatives to installing RT twice, in

/usr/local/rt2-hylafax/
/usr/local/rt2-tpc/

complete with two separate databases?

Thanks!

-Darren

Darrin_Walton · February 18, 2002, 4:28pm

What you could do is sym-link most of the directories, and just maintain
unique config.pm files.

As for the databases, you’re going to have to run two databases, but not
have to run two different database servers.

In the config.pm, just specific one database as ‘rt2-hylafax’ and the
second as ‘rt2-tpc’ and create both databases, etc.

-darrin

Vivek_Khera · February 18, 2002, 4:39pm

“DW” == Darrin Walton darrinw@nixc.net writes:

DW> What you could do is sym-link most of the directories, and just maintain
DW> unique config.pm files.

You can only do this if you do not run under mod_perl. Mod_perl
shares everything, and the first config.pm to get loaded will stay in
effect. You need to use fast_cgi for this.

Darrin_Walton · February 18, 2002, 4:54pm

|+ DW> What you could do is sym-link most of the directories, and just maintain
|+ DW> unique config.pm files.
|+
|+ You can only do this if you do not run under mod_perl. Mod_perl
|+ shares everything, and the first config.pm to get loaded will stay in
|+ effect. You need to use fast_cgi for this.

mod_perl shares everything, yes. But if you are running two different
instances of Apache, then this should be fine. I do it here.

-darrin

Darren_Nickerson3 · February 18, 2002, 5:11pm

Darrin> |+ DW> What you could do is sym-link most of the directories, and
Darrin> |+ DW> just maintain unique config.pm files.
Darrin> |+
Darrin> |+ You can only do this if you do not run under mod_perl. Mod_perl
Darrin> |+ shares everything, and the first config.pm to get loaded will stay
Darrin> |+ in effect. You need to use fast_cgi for this.

Darrin> mod_perl shares everything, yes. But if you are running two
Darrin> different instances of Apache, then this should be fine. I do it
Darrin> here.

ugh

I’m only running one apache, using NameVirtualHosting.

<VirtualHost ###.###.##.###>
ServerName support.tpc.int
ServerAdmin tpcadmin@info.tpc.int
ErrorLog logs/support.tpc.int-error_log
TransferLog logs/support.tpc.int-access_log
DocumentRoot /usr/local/rt2/WebRT/html
PerlModule Apache::DBI
PerlRequire /usr/local/rt2/bin/webmux.pl

SetHandler perl-script
PerlHandler RT::Mason

My knowledge of mod-perl is weak . . . if I install two instances of RT
(avoiding symlinking for now) can I even make THAT work?

Thanks for the replies thus far.

-d

Bruce_Campbell · February 18, 2002, 5:20pm

I’d like to setup RT for two projects I support - www.hylafax.org and
www.tpc.int. I normally host everything from these two domains on one server,
and so I’m wondering how practical it’s going to be to have two separate RT
installations running on the same box.

Your first option should be:

Can I run the same RT2 installation, and just have different queue
names (with corresponding changes to the submission address) ?

Note that in such a setup, you will share the same ticket number space
(not really a problem, but the tag ($rtname) will be the same in both
cases. If you want a different tag for each queue, you can hack the code,
or effectively have two seperate installations.)

Are there any alternatives to installing RT twice, in

/usr/local/rt2-hylafax/
/usr/local/rt2-tpc/

complete with two separate databases?

If you want to run seperate RT2 databases, then I’d suggest installing RT2
into /usr/local/rt2, then create two seperate config files, as per:

/usr/local/rt2/etc/tpc/config.pm
/usr/local/rt2/etc/hylafax/config.pm

You then need to create two seperate Virtualhost directives, changing
/usr/local/rt2/etc to /usr/local/rt2/etc/{tpc,hylafax} as appropriate.
Finally, create /usr/local/rt2/bin/{tpc,hylafax}-webmux.pl from
/usr/local/rt2/bin/webmux.pl, changing the lib directories within as
appropriate.

Repeat the excercise for /usr/local/rt2/bin/rt-mailgate. Presto - two
installations sharing the RT libraries. Or you could just symlink away

Regards,

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B                      Operations

Darren_Nickerson3 · February 24, 2002, 5:27pm

Bruce> On Mon, 18 Feb 2002, Darren Nickerson wrote:

+> I’d like to setup RT for two projects I support - www.hylafax.org and
+> www.tpc.int. I normally host everything from these two domains on one server,
+> and so I’m wondering how practical it’s going to be to have two separate RT
+> installations running on the same box.

Bruce> Your first option should be:

Bruce> Can I run the same RT2 installation, and just have different queue
Bruce> names (with corresponding changes to the submission address) ?

Bruce> Note that in such a setup, you will share the same ticket number space
Bruce> (not really a problem, but the tag ($rtname) will be the same in both
Bruce> cases. If you want a different tag for each queue, you can hack the code,
Bruce> or effectively have two seperate installations.)

+> Are there any alternatives to installing RT twice, in

+> /usr/local/rt2-hylafax/
+> /usr/local/rt2-tpc/

+> complete with two separate databases?

Bruce> If you want to run seperate RT2 databases, then I’d suggest installing RT2
Bruce> into /usr/local/rt2, then create two seperate config files, as per:

Bruce> /usr/local/rt2/etc/tpc/config.pm
Bruce> /usr/local/rt2/etc/hylafax/config.pm

Bruce> You then need to create two seperate Virtualhost directives, changing
Bruce> /usr/local/rt2/etc to /usr/local/rt2/etc/{tpc,hylafax} as appropriate.
Bruce> Finally, create /usr/local/rt2/bin/{tpc,hylafax}-webmux.pl from
Bruce> /usr/local/rt2/bin/webmux.pl, changing the lib directories within as
Bruce> appropriate.

Bruce> Repeat the excercise for /usr/local/rt2/bin/rt-mailgate. Presto - two
Bruce> installations sharing the RT libraries. Or you could just symlink away

Well, I finally had a chance to take a crack at this. It occurred to me that
I might like to upgrade/customize the RT installations separately, and so it
made sense not to co-mingle the components at all. I installed two completely
independent RT installations, in:

/usr/local/rt2-tpc

and
/usr/local/rt2-hyla

Here’s apache’s two VirtualHost containers:

<VirtualHost 216.152.199.8>
ServerName support.tpc.int
ServerAdmin tpcadmin@tpc.int
ErrorLog logs/support.tpc.int-error_log
CustomLog logs/support.tpc.int-access_log common
DocumentRoot /usr/local/rt2-tpc/WebRT/html
PerlModule Apache::DBI
PerlFreshRestart On
PerlRequire /usr/local/rt2-tpc/bin/webmux.pl

SetHandler perl-script
PerlHandler RT::Mason

<VirtualHost 216.152.199.8>
ServerName support.hylafax.org
ServerAdmin webmaster@hylafax.org
ErrorLog logs/support.hylafax.org-error_log
CustomLog logs/support.hylafax.org-access_log common
DocumentRoot /var/www/vhosts/support.hylafax.org/html
<Directory “/var/www/vhosts/support.hylafax.org/html”>
Options None
AllowOverride None
Order allow,deny
Allow from all

PerlModule Apache::DBI
PerlFreshRestart On
PerlRequire /usr/local/rt2-hyla/bin/webmux.pl
Alias /rt/ /usr/local/rt2-hyla/WebRT/html/
<Location /rt>
SetHandler perl-script
PerlHandler RT::Mason

apachestl configtest reports:

[root@polaris rt-2-0-11]# apachectl configtest
Subroutine SetContentType redefined at /usr/local/rt2-hyla/bin/webmux.pl line 88.
Subroutine CGIObject redefined at /usr/local/rt2-hyla/bin/webmux.pl line 93.
Subroutine handler redefined at /usr/local/rt2-hyla/bin/webmux.pl line 122.
Syntax OK

which is a bit worrying, but apparently non-fatal.

Sadly, when this config is activated in apache only the first virtual host container gives a functional RT. The second one gives:

==> /var/log/httpd/support.hylafax.org-error_log <==
[Sun Feb 24 08:21:27 2002] [warn] [Mason] Cannot resolve file to component: /usr/local/rt2-hyla/WebRT/html/index.html (is file outside component root?)

Reversing the order of the VirtualHost containers does not help - again the second one fails with:

==> /var/log/httpd/support.hylafax.org-error_log <==
[Sun Feb 24 08:24:15 2002] [warn] [Mason] Cannot resolve file to component: /usr/local/rt2-hyla/WebRT/html/index.html (is file outside component root?)

Am I missing something obvious, or is it going to be impossible to run RT2 from two different VirtualHosts which don’t share a common DocumentRoot?

-Darren

Bruce_Campbell · February 25, 2002, 11:28am

Bruce> Repeat the excercise for /usr/local/rt2/bin/rt-mailgate. Presto - two
Bruce> installations sharing the RT libraries. Or you could just symlink away

Well, I finally had a chance to take a crack at this. It occurred to me that
I might like to upgrade/customize the RT installations separately, and so it
made sense not to co-mingle the components at all. I installed two completely
independent RT installations, in:

/usr/local/rt2-tpc
and
/usr/local/rt2-hyla

apachestl configtest reports:

[root@polaris rt-2-0-11]# apachectl configtest
Subroutine SetContentType redefined at /usr/local/rt2-hyla/bin/webmux.pl line 88.
Subroutine CGIObject redefined at /usr/local/rt2-hyla/bin/webmux.pl line 93.
Subroutine handler redefined at /usr/local/rt2-hyla/bin/webmux.pl line 122.
Syntax OK

This is where its going a bit wonky, as mod_perl by default is
apache-wide, not specific to a specific virtual host. I’m finding the
same problems with trying to get RT, RT/FM and my own Mason-based archiver
running on the same apache instance under mod_perl (don’t like fastcgi
).

http://www.weedns.com/apache_tuning/fast_modperl_mini_howto.html has a
couple of suggestions that I’m intending to try at some point.

Am I missing something obvious, or is it going to be impossible to run
RT2 from two different VirtualHosts which don’t share a common
DocumentRoot?

At the moment, without trickery, it looks that way. My previous
suggestion will work for getting mail into multiple RT installations
correctly, but won’t work for running multiple RT installations from the
same apache instance. Seperate Apache instances it looks like

Regards,

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B                      Operations

darren_chamberlain · February 25, 2002, 2:09pm

Quoting Darren Nickerson darren@dazza.org [24 Feb-02 12:31]:

Well, I finally had a chance to take a crack at this. It
occurred to me that I might like to upgrade/customize the RT
installations separately, and so it made sense not to co-mingle
the components at all.

[-- snip --]

Am I missing something obvious, or is it going to be impossible
to run RT2 from two different VirtualHosts which don’t share a
common DocumentRoot?

Under mod_perl 1.x on Apache 1.3.x, it is impossible to have two
modules with the same name that do different things, e.g.,
RT::Mason, which is the package defined to handle Location / in
webmux.pl.

In one of the webmux.pl scripts, change the name of the package
to something other than RT::Mason, for example,
RT::Mason::SiteOne, and modify the entry in httpd.conf to use the
new package name as the PerlHandler for Location /. In this
webmux.pl, change the stuff you want to be different, for
example, component roots. This way, you can share most of the RT
modules, without having namespace clashes.

I can be more specific if this doesn’t make enough sense. In
fact, maybe this should be in RT/FM, since it seems to have
bitten a number of people. The problem is that this is a
mod_perl-ism, and has nothing to do with either RT or
HTML::Mason, per se.

(darren)

If it turns out that there is a God, I don’t think that he’s evil.
But the worst that you can say about him is that basically he’s an
underachiever.
– Woody Allen

Darren_Nickerson3 · February 25, 2002, 4:38pm

darren> Under mod_perl 1.x on Apache 1.3.x, it is impossible to have two
darren> modules with the same name that do different things, e.g.,
darren> RT::Mason, which is the package defined to handle Location / in
darren> webmux.pl.

darren> In one of the webmux.pl scripts, change the name of the package
darren> to something other than RT::Mason, for example,
darren> RT::Mason::SiteOne, and modify the entry in httpd.conf to use the
darren> new package name as the PerlHandler for Location /. In this
darren> webmux.pl, change the stuff you want to be different, for
darren> example, component roots. This way, you can share most of the RT
darren> modules, without having namespace clashes.

Darren,

Thanks for the insight into this problem! I’ve modified the file:

/usr/local/rt2-hyla/bin

to provide:

package RT::Mason::HylaFAX;

And my virtual host containers now look like:

<VirtualHost 216.152.199.8>
ServerName support.tpc.int
ServerAdmin tpcadmin@tpc.int
ErrorLog logs/support.tpc.int-error_log
CustomLog logs/support.tpc.int-access_log common
DocumentRoot /usr/local/rt2-tpc/WebRT/html
PerlModule Apache::DBI
PerlFreshRestart On
PerlRequire /usr/local/rt2-tpc/bin/webmux.pl

SetHandler perl-script
PerlHandler RT::Mason

<VirtualHost 216.152.199.8>
ServerName support.hylafax.org
ServerAdmin webmaster@hylafax.org
ErrorLog logs/support.hylafax.org-error_log
CustomLog logs/support.hylafax.org-access_log common
DocumentRoot /var/www/vhosts/support.hylafax.org/html
<Directory “/var/www/vhosts/support.hylafax.org/html”>
Order allow,deny
Allow from all

PerlModule Apache::DBI
PerlFreshRestart On
PerlRequire /usr/local/rt2-hyla/bin/webmux.pl
Alias /rt/ /usr/local/rt2-hyla/WebRT/html/
<Location /rt>
SetHandler perl-script
PerlHandler RT::Mason::HylaFAX

And I restarted apache with

service httpd stop
service httpd start

But I seem to have the same error:

[Mon Feb 25 07:40:30 2002] [warn] [Mason] Cannot resolve file to component: /usr/local/rt2-hyla/WebRT/html/index.html (is file outside component root?)

I even modified the second virtual host to have only RT in it at the root:

<VirtualHost 216.152.199.8>
ServerName support.hylafax.org
ServerAdmin webmaster@hylafax.org
ErrorLog logs/support.hylafax.org-error_log
CustomLog logs/support.hylafax.org-access_log common
DocumentRoot /usr/local/rt2-hyla/WebRT/html
PerlModule Apache::DBI
PerlFreshRestart On
PerlRequire /usr/local/rt2-hyla/bin/webmux.pl

SetHandler perl-script
PerlHandler RT::Mason::HylaFAX

But still no joy:

[Mon Feb 25 08:34:51 2002] [warn] [Mason] Cannot resolve file to component: /usr/local/rt2-hyla/WebRT/html/index.html (is file outside component root?)

I think I’ll take you up on your offer of explaining this a bit more

-Darren

darren_chamberlain · February 25, 2002, 4:48pm

Quoting Darren Nickerson darren@dazza.org [25 Feb-02 11:40]:

But still no joy:

[Mon Feb 25 08:34:51 2002] [warn] [Mason] Cannot resolve file to component: /usr/local/rt2-hyla/WebRT/html/index.html (is file outside component root?)

Is the file outside of the component root? Can you post your
full httpd.conf and webmux.pl?

(darren)

Why are our days numbered and not, say, lettered?
– Woody Allen

Darren_Nickerson3 · February 25, 2002, 5:42pm

darren> Quoting Darren Nickerson darren@dazza.org [25 Feb-02 11:40]:

+> But still no joy:

+> [Mon Feb 25 08:34:51 2002] [warn] [Mason] Cannot resolve file to
component:
+> /usr/local/rt2-hyla/WebRT/html/index.html (is file outside component
root?)

darren> Is the file outside of the component root? Can you post your
darren> full httpd.conf and webmux.pl?

Thanks for sticking with this thread.

What more do you need from my httpd.conf than the two virtual host containers I
gave you? I can’t really paste the whole thing in . . . I’ve attached
webmux.pl though.

I don’t think anything’s wrong with the setup of this RT instance, since if I
comment out the first virtual host, so the two look like:

#<VirtualHost 216.152.199.8>
#ServerName support.tpc.int
#ServerAdmin tpcadmin@tpc.int
#ErrorLog logs/support.tpc.int-error_log
#CustomLog logs/support.tpc.int-access_log common
#DocumentRoot /usr/local/rt2-tpc/WebRT/html
#PerlModule Apache::DBI
#PerlFreshRestart On
#PerlRequire /usr/local/rt2-tpc/bin/webmux.pl
#

SetHandler perl-script

PerlHandler RT::Mason

#
#

<VirtualHost 216.152.199.8>
ServerName support.hylafax.org
ServerAdmin webmaster@hylafax.org
ErrorLog logs/support.hylafax.org-error_log
CustomLog logs/support.hylafax.org-access_log common
DocumentRoot /usr/local/rt2-hyla/WebRT/html
PerlModule Apache::DBI
PerlFreshRestart On
PerlRequire /usr/local/rt2-hyla/bin/webmux.pl

SetHandler perl-script
PerlHandler RT::Mason::HylaFAX

Then support.hylafax.org works perfectly, loading the RT login screen.

Modifying the PerlHandler namespace does not seem to have made any difference

if both vhosts are loaded, the first one works, and the second generates the
component root error.

-d

webmux.pl (4.39 KB)

Rich_West2 · February 28, 2002, 1:33am

I can safely say that running multiple seperate instances of RT2 on a
single machine with a single instance of Apache is definitely possible
(and done so quite easily, I will add) with mod_fastcgi.

I have been doing the very same thing for some time now…

-Rich

You can only do this if you do not run under mod_perl. Mod_perl
shares everything, and the first config.pm to get loaded will stay in
effect. You need to use fast_cgi for this.

Richard West $14.95 Registrations mailto:rwest@wesmo.com
Wesmo Computer Services .com .net .org .tv .cc http://www.wesmo.com
Full Domain & Web Hosting .BIZ .INFO & MORE!!

Darren_Nickerson3 · March 4, 2002, 5:21am

Rich> I can safely say that running multiple seperate instances of RT2 on a
Rich> single machine with a single instance of Apache is definitely possible
Rich> (and done so quite easily, I will add) with mod_fastcgi.

Rich> I have been doing the very same thing for some time now…

Thanks for the recommendation! Seems I was not going to get very far with
mod_perl.

I finally had time to look at mod_fastcgi this weekend. Once I got past the
problem with the broken images by placing them outside of the RT area and
redefining $WebImagesURL, things seem to be working nicely.

-Darren