I’m in the middle of configuring an RT 3.4.5 system on Gentoo and
everything is running beautifully except for one thing - the
organisation string is stuck as “example.com”. E.g. “RT for example.com”
on the front screen.
This is my 2nd shot at setting up RT on this same box, the first time
was RT 3.4.3 and the organisation string was fine but the general
functioning of RT wasn’t.
I followed the install HOWTO for Gentoo both times, except for the fact
that the 3.4.5 install was an upgrade (using webapp-config) from the
previous 3.4.3 system.
As recommended I copied RT_Config.pm to RT_SiteConfig.pm, made my
changes to both $rtname and $Organization (plus a few other things, like
timezone). The changes to RT_SiteConfig.pm were made immediately after
install.
Since having this trouble I’ve tried doing a full uninstall using
webapp-config, dropping the database and recreating, then reinstalling
via webapp-config. I also tried editing RT_Config.pm directly and it
didn’t help. In case it matters, this install is in a vhost environment
and I’m running the FastCGI Apache2 config.
If anyone has any ideas of anything I can check I’d be most grateful.
I’ve double checked everything I’m aware of and am still scratching my head.
I’m in the middle of configuring an RT 3.4.5 system
on Gentoo and
everything is running beautifully except for one
thing - the
organisation string is stuck as “example.com”. E.g.
“RT for example.com”
on the front screen.
This is my 2nd shot at setting up RT on this same
box, the first time
was RT 3.4.3 and the organisation string was fine
but the general
functioning of RT wasn’t.
I followed the install HOWTO for Gentoo both times,
except for the fact
that the 3.4.5 install was an upgrade (using
webapp-config) from the
previous 3.4.3 system.
As recommended I copied RT_Config.pm to
RT_SiteConfig.pm, made my
changes to both $rtname and $Organization (plus a
few other things, like
timezone). The changes to RT_SiteConfig.pm were made
immediately after
install.
Since having this trouble I’ve tried doing a full
uninstall using
webapp-config, dropping the database and recreating,
then reinstalling
via webapp-config. I also tried editing RT_Config.pm
directly and it
didn’t help. In case it matters, this install is in
a vhost environment
and I’m running the FastCGI Apache2 config.
If anyone has any ideas of anything I can check I’d
be most grateful.
I’ve double checked everything I’m aware of and am
still scratching my head.
I’m in the middle of configuring an RT 3.4.5 system on Gentoo and
everything is running beautifully except for one thing - the
organisation string is stuck as “example.com”. E.g. “RT for example.com”
on the front screen.
If anyone has any ideas of anything I can check I’d be most grateful.
I’ve double checked everything I’m aware of and am still scratching my
head.
/etc/init.d/apache2 stop
rm -rf /var/www//rt-3.4.5/var/mason_data/
/etc/init.d/apache2 start
You’re possibly seeing the mason cache at works; clear it, then restart
apache, which will restart your fcgi handlers for rt.
While you’re modding your RT instance, you may want to temporarily set the
devel mode, so that the mason cache is turned off, and so that any changes you
do to the templates will be seen immediately w/o an apache restart. Be sure
to unset the flag again when your ready to put in production, because devel
mode is extremely inefficient.
You’re possibly seeing the mason cache at works; clear it, then restart
apache, which will restart your fcgi handlers for rt.
Thanks to everyone that responded - I’ve now got it working, but not in
an ideal manner.
Corey - your suggestion really helped in finding what was going on. I
checked the mason_data directories and did as you suggested in my vhost
location, no joy. I then checked in the central webapp-config repository
(/usr/share/webapps/rt/3.4.5/hostroot/rt-3.4.5/var/mason_data) and found
that apache2 was actually using this location for the mason cache!
From there I found that it was also using the RT_Config.pm file from
this location too. Changing this copy of RT_Config.pm, clearing mason
cache and restarting apache solved my issue.
So now I’m not sure if there is something wrong with the Gentoo ebuild
of 3.4.5 or if this is somehow a local issue. The vhost/webapp-config
stuff certainly isn’t working correctly on my box.
Has anyone else seen this behaviour with 3.4.5 on Gentoo? Any
suggestions of how to tackle this also appreciated
> Corey - your suggestion really helped in finding what was going on. I
> checked the mason_data directories and did as you suggested in my vhost
> location, no joy. I then checked in the central webapp-config repository
> (/usr/share/webapps/rt/3.4.5/hostroot/rt-3.4.5/var/mason_data) and found
> that apache2 was actually using *this* location for the mason cache!
>
> From there I found that it was also using the RT_Config.pm file from
> this location too. Changing this copy of RT_Config.pm, clearing mason
> cache and restarting apache solved my issue.
>
Quite possibly a bug either in the rt ebuild, or in webapp-config.
I recently had run into this very same issue, but figured it was something I
had done wrong in the install or due to the fact that I had ‘ported’ the
3.4.5 ebuild to use the 3.5.7 release of RT.
I’ll see if I can reproduce this again using the 3.4.5 ebuild.
The whole point of webapp-config is to ensure that you can have multiple
separate instances of the app in question running; so if the /usr/share/ base
is being used rather than the /var/www/ base, then something’s definitely
amiss.
cd /usr/share/webapps/rt/3.4.5/hostroot/rt-3.4.5
grep -R webapps
cd /var/www//rt-3.4.5
grep -R webapps
… I’m guessing that even in your /var/www//rt-3.4.5 dir, everything
is pointing to /usr/share/webapps/rt/3.4.5/hostroot/rt-3.4.5; that stuff should be pointing, of course, to /var/www/
I don’t yet know whether this is a bug in the ebuild, or in webapp-config.
I’ll check things out a little deeper then send a bug report to the proper
channels.
In the mean time, you could edit things properly within
your /var/www//rt-3.4.5 dirs.
Cheers,
CoreyOn Friday February 17 2006 4:00 pm, Corey wrote:
On Friday February 17 2006 2:19 am, Matt Robinson wrote:
Corey - your suggestion really helped in finding what was going on. I
checked the mason_data directories and did as you suggested in my vhost
location, no joy. I then checked in the central webapp-config repository
(/usr/share/webapps/rt/3.4.5/hostroot/rt-3.4.5/var/mason_data) and found
that apache2 was actually using this location for the mason cache!
From there I found that it was also using the RT_Config.pm file from
this location too. Changing this copy of RT_Config.pm, clearing mason
cache and restarting apache solved my issue.
Quite possibly a bug either in the rt ebuild, or in webapp-config.
I recently had run into this very same issue, but figured it was something
I had done wrong in the install or due to the fact that I had ‘ported’ the
3.4.5 ebuild to use the 3.5.7 release of RT.
I’ll see if I can reproduce this again using the 3.4.5 ebuild.
The whole point of webapp-config is to ensure that you can have multiple
separate instances of the app in question running; so if the /usr/share/
base is being used rather than the /var/www/ base, then something’s
definitely amiss.
> So now I'm not sure if there is something wrong with the Gentoo ebuild
> of 3.4.5 or if this is somehow a local issue. The vhost/webapp-config
> stuff certainly isn't working correctly on my box.
>
Ok, found the bugger!
Before you run the “webapp-config -I -h myrt -d rt rt 3.4.5” command, as per
the GentooInstallGuide, first do the following:
PN=rt; PVR=3.4.5; export PN PVR
The problem is in the ‘reconfig’ script that the rt ebuild provides. It uses
two environment variables that aren’t actually set when you run the
webapp-config. Since they’re not set, a very crucial bit of final
processing/configuration gets skipped - which is the cause of the problem
you’re seeing:
the
/var/www//rt-//.pm’s
end up with config variables that point to
/usr/share/webapps/rt//hostroot/rt-//.pm’s
I’ll send a patch to the rt ebuild maintainer.
Until then, you can get things working correctly by doing the following:
remove current (broken) rt instance
webapp-config -C -h -d rt rt 3.4.5
set the env vars that the reconfig script wants
PN=rt; PVR=3.4.5; export PN PVR
install the new rt instance
webapp-config -I -h -d rt rt 3.4.5
now create/edit the …/etc/RT_SiteConfig.pm as you would normally,
