[Rt-devel] Multi-instance patch

Bob Goldstein bobg at uic.edu
Tue Dec 20 10:20:20 EST 2005

>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):
>>>-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 
>> 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:



     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?)


>and later on after the =cut:
>     my $RT_INSTANCE_PATH = $args{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_S
>> (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.
>Oliver Hookins
>Anchor Systems
>Rt-devel mailing list
>Rt-devel at lists.bestpractical.com

More information about the Rt-devel mailing list