RT.pm with multiple instances and FastCGI

RT Developers
1

I am trying to get NameVirtualHosts going with multiple instances of
RT3.07. I took the advice in the archives of this list and am using
FastCGI.

I have created two of everything, leaving the default installation and
adding another domain alongside:

/etc/request-tracker3
/etc/request-tracker3-mydomain

/usr/share/request-tracker3
/usr/share/request-tracker3-mydomain

I successfully populated the database by running rt-setup-database
having first switched the /etc directories. The source to
rt-setup-database talks about specifying the directory on the
commandline but it doesn’t work. That should have given me a clue about
what was going to happen :slight_smile:

I cannot get the second instance to be recognised. So I temporarily
remove /etc/request-tracker3 and sure enough, Apache chokes. The error
is:

Can’t locate /etc/request-tracker3/RT_Config.pm in @INC (@INC contains: /usr/local/share/request-tracker3/lib /usr/share/perl5 /etc/perl /usr/local/lib/perl/5.8.0 /usr/local/share/perl/5.8.0 /usr/lib/perl5 /usr/lib/perl/5.8.0 /usr/share/perl/5.8.0 /usr/local/lib/site_perl .)
at /usr/share/perl5/RT.pm line 108.

What? Hardcoded? Yep, because in /usr/share/perl5/RT.pm I find:

$BasePath = ‘/usr/share/request-tracker3’;
$EtcPath = ‘/etc/request-tracker3’;
$VarPath = ‘/var/cache/request-tracker3’;
$LocalPath = ‘/usr/local/share/request-tracker3’;
$LocalEtcPath = ‘/usr/local/share/request-tracker3/etc’;
$LocalLexiconPath = ‘/usr/local/share/request-tracker3/po’;

So I copied RT.pm to RT-mydomain.pm and edited the webmux for mydomain to say
“Use RT-mydomain;”. For testing I renamed RT.pm. But it seems to still be
included somewhere.

Apache says:

Can’t locate RT.pm in @INC (@INC contains: /usr/local/share/request-tracker3/lib /usr/share/perl5 /etc/perl /usr/local/lib/perl/5.8.0 /usr/local/share/perl/5.8.0 /usr/lib/perl5 /usr/lib/perl/5.8.0 /usr/share/perl/5.8.0 /usr/local/lib/site_perl .) at /usr/share/request-tracker3-daemonlinux/libexec/webmux.pl line 50.

This will be coming from webmux (from the fcgi handler in /etc/request-tracker3-mydomain).

Any ideas?

Dan Shearer
dan@shearer.org

2

Dan Shearer wrote:

What? Hardcoded? Yep, because in /usr/share/perl5/RT.pm I find:

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

You’ll need to “./configure” RT with a different directory/layout
for each of the instances.

3

Dan Shearer wrote:

What? Hardcoded? Yep, because in /usr/share/perl5/RT.pm I find:

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

You’ll need to “./configure” RT with a different directory/layout
for each of the instances.

Thanks!

Fine, I seem to recall something about a goal for 3.0 was to make this
stuff cleaner. Never mind, I can do that.

In my case I’m using the Debian package. I wonder how hard it will be to
continue to use it, only doing a local build. I’ll give it a go.

Dan Shearer
dan@shearer.org

4

I am trying to get NameVirtualHosts going with multiple instances of
RT3.07. I took the advice in the archives of this list and am using
FastCGI.

I have created two of everything, leaving the default installation and
adding another domain alongside:

Phil Homewood pointed out I need to ./configure to put each instance in
its own directory hierachy. I thought this was to be fixed from RT2
(shows how little I watch this list :slight_smile: and it is rather messy to say
the least. Then there is upgrading, keeping in tune with your OS’s
package management etc etc. No thanks :slight_smile: I now have what seems so far
to be a better solution. Someone here will probably disillusion me!

The details that follow are specific to Debian. However the technique
could work in a very similar way for FreeBSD and other systems depending
how the packager has built his package.

Goal

Take the source for a given version of the RT3 Debian package and make
the minimum number of changes required to create an identical Debian
package that installs into a different directory hierachy.

Implementation

mkdir /usr/src/rt ; cd /usr/src/rt
apt-get source request-tracker3
cd request-tracker3-3.0.6
fakeroot dpkg-buildpackage
perl -e “s/request-tracker3/request-tracker3-testing/g;” -pi.bak
$(find . -type f)

this find command should really have some exceptions to it.

fakeroot dpkg-buildpackage

This should produce two files:

request-tracker3-testing_3.0.6-2_all.deb
request-tracker3_3.0.6-2_all.deb

Now you can install them both. The second deb will want to overwrite
some files of the first, but that won’t matter because they are
identical.

dpkg -i request-tracker3_3.0.6-2_all.deb
dpkg -i --force-overwrite request-tracker3-testing_3.0.6-2_all.deb

Caveats

1. If the .debs aren't completely identical (ie they come from
the same source deb) then you will probably destroy things. Plan
to upgrade all your instances at once.

2. Such a global find/replace simply shouldn't work. So far
it looks like it does, but I'm sure there will be something
broken. The reason it works so well is that the name 
"request-tracker3" is specific to the Debian package.

Corollary

Don’t run multiple instances on one OS, RT is just not made for it. Far
better to run instances in their own little sandbox, for example inside
User Mode Linux.

Dan Shearer
dan@shearer.org

5

Dan Shearer wrote:

What? Hardcoded? Yep, because in /usr/share/perl5/RT.pm I find:

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

You’ll need to “./configure” RT with a different directory/layout
for each of the instances.

I got multiple instances working yesterday without needing to
re-run configure. I had to patch RT.pm, webmux.pm and
rt-setup-database, but the changes are minimal and don’t
affect normal operation. They just allow specifying
the directory tree and path at run time, rather than build time.
But the build time values are the defaults.

I’ll submit the patches to Jesse in a few days, once I run
some more tests just to be sure I haven’t made any gross errors.

This will allow me to install multiple versions of RT
(e.g. 3.0.6 and 3.0.7) in different directories, and have
lots of instances (each with its own mysql database on the same server),
so that 10 departments could each have an instance. Each instance
provides its own directory tree; each tree must have its
own RT_SiteConfig.pm, but may also have its own local files
for overlays and callbacks.

The idea is to use fastcgi, one server for each RT instance.
And the association of fastcgi server with RT instance is
governed solely by the apache config.

  bobg
6

Fine, I seem to recall something about a goal for 3.0 was to make this
stuff cleaner. Never mind, I can do that.

I’m pretty sure it is a lot cleaner. I think the only place that
paths are still burned in are in the files in the bin/ directory, and
then it’s only very few. (if you ignore the tests)

Oh, and RT.pm

-R