Multi-instance patch

RT Developers
1

Hi there,

I’ve been trying (somewhat unsuccessfully) to get RT going with the
multiple instance patch that I found on the Wiki, firstly against 3.4.1
(this is on debian sarge), then on 3.4.2 which the patch was actually
written for.

Has anyone had any success with this patch, or does anyone know who
submitted it? Also are there any plans to implement something similar
into the main code tree?

Regards,
Oliver Hookins
Anchor Systems

2

Hi there,

I’ve been trying (somewhat unsuccessfully) to get RT going with the
multiple instance patch that I found on the Wiki, firstly against 3.4.1
(this is on debian sarge), then on 3.4.2 which the patch was actually
written for.

Has anyone had any success with this patch, or does anyone know who
submitted it? Also are there any plans to implement something similar
into the main code tree?

I did the original Multiple Instances wiki page, but someone else
appears to have replaced my patch (probably with something better.)
By quick glance, it looks pretty similar to what I have. I’m
currently running 3.4.2, and have used multiple instances since about 3.0.8.

In practice, when I upgrade, I’ve just compared my current files with the
original, and changed the new code by hand, since the changes were pretty
small.

I’m not sure that helps. You haven’t described your symptoms; I don’t know
if the problem is the patch, or perhaps some misconfiguration in apache.
As to merging this into the main code tree, that’s up to Jesse.

 Bob Goldstein
3

Not sure if this got through the other day…

Stephen Joyce wrote:

Oliver,

I am successfully using the multi-instance patch on 3.4.2. It’s great!
What sort of trouble did you have applying the patch?

No real trouble applying the patch (although I had to re-jig it as you
did for it to work). I actually ended up applying it to the source
packages from debian and rebuilding debs from it.

The problems I’m having is actually during use. I have set up two users
with databases, and the following in their home directories:

~user/etc/request-tracker3.4/RT_SiteConfig.pm
~user/usr/share/request-tracker3.4/libexec/mason_handler.fcgi (which is
a link to the system mason_handler.fcgi file).

Then I have virtual hosts in apache set up with different domain names
etc, aliases to direct to the mason handler, and the following line:

FastCgiServer
/home/user/usr/share/request-tracker3.4/libexec/mason_handler.fcgi
-initial-env RT_INSTANCE_PATH=/home/user/

However it seems to be ignoring this environment variable. It accepts
the default settings in RT.pm and thus tries to use a system-wide
configuration (which doesn’t exist). If I edit RT.pm and manually
specify the location of the SITE_CONFIG_FILE as one of the user’s
RT_SiteConfig.pm files, it will work, but only for that user (regardless
of which virtual host is served up.

Any ideas?

Regards,
Oliver Hookins
Anchor Systems

4

Oliver,

I replied directly to you; if you didn’t get the reply, I’ve included it
again below. Also cc’ing the list, as maybe someone else has some helpful
suggestions too.Date: Thu, 15 Dec 2005 01:07:36 -0500 (EST)
From: Stephen Joyce stephen@physics.unc.edu
To: Oliver Hookins oliver.hookins@anchor.com.au
Subject: Re: [Rt-devel] Multi-instance patch

Oliver,

I’m running both instances on the same virtual host, but I don’t see any
reason it shouldn’t work in differing hosts via redirection (but I do think
the lines below must not appear inside a spec.

Your problem may be that RT_INSTANCE_PATH needs to point to a full
instance. So, for me, when I set RT_INSTANCE_PATH=/var/rt3_purchasing the
config that gets used is /var/rt3_purchasing/etc/RT_SiteConfig.pm. Notice
that RT fills in the “/etc/” part of the path automatically.
$ ls /var/rt3_purchasing/
etc lib local var
$ ls /var/rt3_purchasing/etc
RT_Config.pm RT_SiteConfig.pm

The other difference I see is the absence of a trailing / in my
RT_INSTANCE_PATH specifications; not sure if that’s significant or not…

Here are the relevant lines of my httpd.conf (b/c I’m sure word-wrap will
screw them up, there are 8 lines total):

FastCgiServer /usr/rt3/rt3-3.4-compat/rt3/bin/mason_handler_purchasing.fcgi
-initial-env RT_INSTANCE_PATH=/var/rt3_purchasing
ScriptAlias /purchasing
/usr/rt3/rt3-3.4-compat/rt3/bin/mason_handler_purchasing.fcgi
FastCgiServer /usr/rt3/rt3-3.4-compat/rt3/bin/mason_handler_panic.fcgi
-initial-env RT_INSTANCE_PATH=/var/rt3_panic
ScriptAlias /panic
/usr/rt3/rt3-3.4-compat/rt3/bin/mason_handler_panic.fcgi

Other than those minor differences, it looks like your setup should work.
If not, are you sure the patch applied cleanly? Is anything being logged
(either in messages or in the apache logs) that looks suspicious (perl
errors, permission problems, etc)?

Best, Stephen
Stephen Joyce
Systems Administrator P A N I C
Physics & Astronomy Department Physics & Astronomy
University of North Carolina at Chapel Hill Network Infrastructure
voice: (919) 962-7214 and Computing
fax: (919) 962-0480 http://www.panic.unc.edu

MacOS X: Because making Unix user friendly was easier than debugging Windows.

5

Stephen Joyce wrote:

Oliver,

I replied directly to you; if you didn’t get the reply, I’ve included it
again below. Also cc’ing the list, as maybe someone else has some helpful
suggestions too.

Date: Thu, 15 Dec 2005 01:07:36 -0500 (EST)
From: Stephen Joyce stephen@physics.unc.edu
To: Oliver Hookins oliver.hookins@anchor.com.au
Subject: Re: [Rt-devel] Multi-instance patch

Oliver,

I’m running both instances on the same virtual host, but I don’t see any
reason it shouldn’t work in differing hosts via redirection (but I do think
the lines below must not appear inside a spec.

Your problem may be that RT_INSTANCE_PATH needs to point to a full
instance. So, for me, when I set RT_INSTANCE_PATH=/var/rt3_purchasing the
config that gets used is /var/rt3_purchasing/etc/RT_SiteConfig.pm. Notice
that RT fills in the “/etc/” part of the path automatically.
$ ls /var/rt3_purchasing/
etc lib local var
$ ls /var/rt3_purchasing/etc
RT_Config.pm RT_SiteConfig.pm

OK so I have instead (outside of the virtualhost tags):
FastCgiServer
/home/testguy/usr/share/request-tracker3.4/libexec/mason_handler.fcgi
-initial-env RT_INSTANCE_PATH=/home/testguy

I am using /home/USERNAME for all of my separate instances. Using this,
I get a 500 internal server error from the webpage, and the following in
the apache error log:

Can’t locate /etc/request-tracker3.4/RT_SiteConfig.pm in @INC (@INC
contains: /usr/local/share/request-tracker3.4/lib
/usr/share/request-tracker3.4/lib /etc/perl /usr/local/lib/perl/5.8.4
/usr/local/share/perl/5.8.4 /usr/lib/perl5 /usr/share/perl5
/usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at
/usr/share/request-tracker3.4/lib/RT.pm line 176.
BEGIN failed–compilation aborted at
/usr/share/request-tracker3.4/libexec/webmux.pl line 85.
Compilation failed in require at
/home/testguy/usr/share/request-tracker3.4/libexec/mason_handler.fcgi
line 52.
[Tue Dec 20 13:22:15 2005] [warn] FastCGI: server
“/home/testguy/usr/share/request-tracker3.4/libexec/mason_handler.fcgi”
(pid 11810) terminated by calling exit with status ‘13’
[Tue Dec 20 13:22:15 2005] [warn] FastCGI: server
“/home/testguy/usr/share/request-tracker3.4/libexec/mason_handler.fcgi”
has failed to remain running for 30 seconds given 3 attempts, its
restart interval has been backed off to 600 seconds

Here are the relevant lines of my httpd.conf (b/c I’m sure word-wrap will
screw them up, there are 8 lines total):

Mine are a little different but I believe the problem is earlier than
the script aliases.

Other than those minor differences, it looks like your setup should work.
If not, are you sure the patch applied cleanly? Is anything being logged
(either in messages or in the apache logs) that looks suspicious (perl
errors, permission problems, etc)?

See the above. I am 99% certain the patch was applied properly. I
checked out the modified files (RT.pm, webmux.pl, rt-setup-database) and
the installed files all appear to have the correct contents as far as
the patch goes. The problem appears to be that something is not grabbing
the environment variables properly, but I’m not sure how to proceed from
there.

Regards,
Oliver Hookins
Anchor Systems

6

Your problem may be that RT_INSTANCE_PATH needs to point to a full
instance. So, for me, when I set RT_INSTANCE_PATH=/var/rt3_purchasing the
config that gets used is /var/rt3_purchasing/etc/RT_SiteConfig.pm. Notice
that RT fills in the “/etc/” part of the path automatically.
$ ls /var/rt3_purchasing/
etc lib local var
$ ls /var/rt3_purchasing/etc
RT_Config.pm RT_SiteConfig.pm

OK so I have instead (outside of the virtualhost tags):
FastCgiServer
/home/testguy/usr/share/request-tracker3.4/libexec/mason_handler.fcgi
-initial-env RT_INSTANCE_PATH=/home/testguy

I am using /home/USERNAME for all of my separate instances. Using this,
I get a 500 internal server error from the webpage, and the following in
the apache error log:

Can’t locate /etc/request-tracker3.4/RT_SiteConfig.pm in @INC (@INC
contains: /usr/local/share/request-tracker3.4/lib
/usr/share/request-tracker3.4/lib /etc/perl /usr/local/lib/perl/5.8.4
/usr/local/share/perl/5.8.4 /usr/lib/perl5 /usr/share/perl5
/usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at
/usr/share/request-tracker3.4/lib/RT.pm line 176.
BEGIN failed–compilation aborted at
/usr/share/request-tracker3.4/libexec/webmux.pl line 85.
Compilation failed in require at
/home/testguy/usr/share/request-tracker3.4/libexec/mason_handler.fcgi

That seems a little odd to me. Just checking, but take a look
at RT.pm. Near the top, you should see something like this:

$SITE_CONFIG_FILE = “/usr/share/request-tracker3.4/etc/request-tracker3.4/RT_SiteConfig.pm”;

$BasePath = ‘/usr/share/request-tracker3.4’;

Later on, this code from the patch:

if ($RT_INSTANCE_PATH) {
    foreach my $vref (@variables) {
        $$vref =~ s/^\Q$BasePath\E/$RT_INSTANCE_PATH/;
    }
}

should turn $SITE_CONFIG_FILE into /home/testguy/etc/request-tracker3.4/RT_SiteConfig.pm

(I’m guessing at your directory structure, so this may not be exactly right for you.)

Yet your error message doesn’t say anything about this file, it leaves
off the /home/testguy part.

If I were debugging this, I’d add some logging or print statements
to verify the changes in all the variables in the above loop,
and to verify that $RT_INSTANCE_PATH is set correctly,
since it seems to me, you are already in trouble by the time
you leave the RT::import() routine.

bobg

7

Bob Goldstein wrote:

Your problem may be that RT_INSTANCE_PATH needs to point to a full
instance. So, for me, when I set RT_INSTANCE_PATH=/var/rt3_purchasing the
config that gets used is /var/rt3_purchasing/etc/RT_SiteConfig.pm. Notice
that RT fills in the “/etc/” part of the path automatically.
$ ls /var/rt3_purchasing/
etc lib local var
$ ls /var/rt3_purchasing/etc
RT_Config.pm RT_SiteConfig.pm

OK so I have instead (outside of the virtualhost tags):
FastCgiServer
/home/testguy/usr/share/request-tracker3.4/libexec/mason_handler.fcgi
-initial-env RT_INSTANCE_PATH=/home/testguy

I am using /home/USERNAME for all of my separate instances. Using this,
I get a 500 internal server error from the webpage, and the following in
the apache error log:

Can’t locate /etc/request-tracker3.4/RT_SiteConfig.pm in @INC (@INC
contains: /usr/local/share/request-tracker3.4/lib
/usr/share/request-tracker3.4/lib /etc/perl /usr/local/lib/perl/5.8.4
/usr/local/share/perl/5.8.4 /usr/lib/perl5 /usr/share/perl5
/usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at
/usr/share/request-tracker3.4/lib/RT.pm line 176.
BEGIN failed–compilation aborted at
/usr/share/request-tracker3.4/libexec/webmux.pl line 85.
Compilation failed in require at
/home/testguy/usr/share/request-tracker3.4/libexec/mason_handler.fcgi

That seems a little odd to me. Just checking, but take a look
at RT.pm. Near the top, you should see something like this:

This is what I have:

$VERSION = ‘3.4.1’;
$CORE_CONFIG_FILE = “/etc/request-tracker3.4/RT_Config.pm”;
$SITE_CONFIG_FILE = “/etc/request-tracker3.4/RT_SiteConfig.pm”;

$BasePath = ‘/usr/share/request-tracker3.4’;

and later on after the =cut:

…
my $RT_INSTANCE_PATH = $args{RT_INSTANCE_PATH} ||
$ENV{RT_INSTANCE_PATH};
if ($RT_INSTANCE_PATH) {
foreach my $vref (@variables) {
$$vref =~ s/^\Q$BasePath\E/$RT_INSTANCE_PATH/;
}
}
foreach my $vref (@variables) {
$$vref = $args{$vref} if defined ( $args{$vref} );
}

use strict ‘refs’;
}

should turn $SITE_CONFIG_FILE into /home/testguy/etc/request-tracker3.4/RT_SiteConfig.pm

(I’m guessing at your directory structure, so this may not be exactly right for you.)

Yet your error message doesn’t say anything about this file, it leaves
off the /home/testguy part.

Yeah… this is the core problem.

If I were debugging this, I’d add some logging or print statements
to verify the changes in all the variables in the above loop,
and to verify that $RT_INSTANCE_PATH is set correctly,
since it seems to me, you are already in trouble by the time
you leave the RT::import() routine.

I’m not very good with Perl, so if you can suggest some debugging
methods I’ll try to use them.

Regards,
Oliver Hookins
Anchor Systems

8

Bob Goldstein wrote:

Your problem may be that RT_INSTANCE_PATH needs to point to a full
instance. So, for me, when I set RT_INSTANCE_PATH=/var/rt3_purchasing the
config that gets used is /var/rt3_purchasing/etc/RT_SiteConfig.pm. Notice
that RT fills in the “/etc/” part of the path automatically.
$ ls /var/rt3_purchasing/
etc lib local var
$ ls /var/rt3_purchasing/etc
RT_Config.pm RT_SiteConfig.pm

OK so I have instead (outside of the virtualhost tags):
FastCgiServer
/home/testguy/usr/share/request-tracker3.4/libexec/mason_handler.fcgi
-initial-env RT_INSTANCE_PATH=/home/testguy

I am using /home/USERNAME for all of my separate instances. Using this,
I get a 500 internal server error from the webpage, and the following in
the apache error log:

Can’t locate /etc/request-tracker3.4/RT_SiteConfig.pm in @INC (@INC
contains: /usr/local/share/request-tracker3.4/lib
/usr/share/request-tracker3.4/lib /etc/perl /usr/local/lib/perl/5.8.4
/usr/local/share/perl/5.8.4 /usr/lib/perl5 /usr/share/perl5
/usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at
/usr/share/request-tracker3.4/lib/RT.pm line 176.
BEGIN failed–compilation aborted at
/usr/share/request-tracker3.4/libexec/webmux.pl line 85.
Compilation failed in require at
/home/testguy/usr/share/request-tracker3.4/libexec/mason_handler.fcgi

That seems a little odd to me. Just checking, but take a look
at RT.pm. Near the top, you should see something like this:

This is what I have:

$VERSION = ‘3.4.1’;
$CORE_CONFIG_FILE = “/etc/request-tracker3.4/RT_Config.pm”;
$SITE_CONFIG_FILE = “/etc/request-tracker3.4/RT_SiteConfig.pm”;

$BasePath = ‘/usr/share/request-tracker3.4’;

 Hmm, that's a problem right there.
 Your native $SITE_CONFIG_FILE string does not
 begin with $BasePath.  Mine does, and the loop
 below uses this fact to munge $SITE_CONFIG_FILE

 I don't know much about 'configure' internals,
 but from 'configure', I see this:

 sysconfdir='${prefix}/etc'

  ...
 RT_PATH=${exp_prefix}
  ...
 CONFIG_FILE_PATH=${exp_sysconfdir}


 So I'm guessing when you ran 'configure', you
 set sysconfdir separately from prefix.  Unfortunately,
 the patch code isn't smart enough to cope with this.

 Basically, the patch code assumes you used only 'prefix',
 and it replaces that strign with RT_INSTANCE_PATH
 in selective places.  E.g. so that the config file
 can be outsider of the original prefix, on a per-instance basis,
 while leaving the rest of the codebase alone.

 I don't have enough time to change that patch now.
 Would it be a major problem to reinstall?  (Assuming
 my diagnosis is correct, of course?)

    bobg
9

Bob Goldstein wrote:

And my RT.pm for each instance has
$VERSION = ‘3.4.2’;
$CORE_CONFIG_FILE = “/var/rt3_panic/etc/RT_Config.pm”;
$SITE_CONFIG_FILE = “/var/rt3_panic/etc/RT_SiteConfig.pm”;

$BasePath = ‘/var/rt3’;

So the default RT path is /var/rt3, and /var/rt3_panic is one of my
instances.

That already seems different than what I have. I have only
one version of RT.pm, not one per instance. That’s the whole
point of RT_INSTANCE_PATH, for RT.pm to essentially
reconfigure itself, on the fly, per instance invoked.

So in my case, I have:

$SITE_CONFIG_FILE = “/usr/local/rt/3.4.2/etc/RT_SiteConfig.pm”;
$BasePath = ‘/usr/local/rt/3.4.2’;

Because I did a normal install into /usr/local/rt/3.4.2/

Then later, this loop will munge the value of $SITE_CONFIG_FILE:
if ($RT_INSTANCE_PATH) {
foreach my $vref (@variables) {
$$vref =~ s/^\Q$BasePath\E/$RT_INSTANCE_PATH/;
}
}

so that by the time it is used, $SITE_CONFIG_FILE
will have the value “/some/instance/etc/RT_SiteConfig.pm”;

Sorry for the delay, have been busy with work and holidays.

What you wrote above makes sense… so it will only match the regex if
$SITE_CONFIG_FILE starts with the value of $BasePath? I’ll give that a try.

Basically the build process I followed was:

  • Download sarge source package for RT 3.4 (which is actually 3.4.1)
  • Rework the patch from the wiki to apply cleanly to the debian source
    package
  • Insert the patch as a dpatch to the package
  • Rebuild the package with dpkg-buildpackage

So my installation should be identical to the standard debian
installation from the package, but with the multi-user stuff applied.

Regards,
Oliver Hookins
Anchor Systems

10

Bob Goldstein wrote:

And my RT.pm for each instance has
$VERSION = ‘3.4.2’;
$CORE_CONFIG_FILE = “/var/rt3_panic/etc/RT_Config.pm”;
$SITE_CONFIG_FILE = “/var/rt3_panic/etc/RT_SiteConfig.pm”;

$BasePath = ‘/var/rt3’;

So the default RT path is /var/rt3, and /var/rt3_panic is one of my
instances.

That already seems different than what I have. I have only
one version of RT.pm, not one per instance. That’s the whole
point of RT_INSTANCE_PATH, for RT.pm to essentially
reconfigure itself, on the fly, per instance invoked.

So in my case, I have:

$SITE_CONFIG_FILE = “/usr/local/rt/3.4.2/etc/RT_SiteConfig.pm”;
$BasePath = ‘/usr/local/rt/3.4.2’;

Because I did a normal install into /usr/local/rt/3.4.2/

Then later, this loop will munge the value of $SITE_CONFIG_FILE:
if ($RT_INSTANCE_PATH) {
foreach my $vref (@variables) {
$$vref =~ s/^\Q$BasePath\E/$RT_INSTANCE_PATH/;
}
}

so that by the time it is used, $SITE_CONFIG_FILE
will have the value “/some/instance/etc/RT_SiteConfig.pm”;

(assuming that $RT_INSTANCE_PATH = ‘/some/instance’ )

Anyway, I installed like this:

./configure --prefix=/usr/local/rt/3.4.2
–with-db-type=mysql
–with-web-user=nobody
–with-web-group=rt
–with-logfiledir=/var/log/rt

to keep the installation in one single directory tree, governed
by ‘prefix’. If that helps :slight_smile:

bobg

Thanks Bob, changing the $SITE_CONFIG_FILE to include $BasePath has
fixed the problem.

Regards,
Oliver Hookins
Anchor Systems