Mod_perl2 compatibility

Can someone clarify the current state of mod_perl2 + Apache 2.x
compatibility for RT 3.4?

It would be nice if this information was stated unambiguously in the
installation guides.

Right now here is the information in the installation guide (search
this page for ‘BIG WARNING’):

http://wiki.bestpractical.com/index.cgi?ManualInstallation

Also, here are the references to the original messages referencing
the problems:

http://lists.bestpractical.com/pipermail/rt-users/2005-May/031215.html
http://lists.bestpractical.com/pipermail/rt-users/2005-April/030477.html

At 08:53 AM 6/26/2005, Chris Meyer wrote:

Can someone clarify the current state of mod_perl2 + Apache 2.x
compatibility for RT 3.4?

Here’s the text of from the Apache section of the README:

mod_perl 2.0 isn’t quite ready for prime_time just yet;
We strongly recommend that you use Apache 1.3 or FastCGI.

It would be nice if this information was stated unambiguously in the
installation guides.

Jesse has said several times that he welcomes suggestions on wording
that would be less ambiguous than that.

Michael

Michael S. Liebman m-liebman@northwestern.edu
http://msl521.freeshell.org/
“I have vision and the rest of the world wears bifocals.”
-Paul Newman in “Butch Cassidy & the Sundance Kid”

Chris Meyer wrote:

Can someone clarify the current state of mod_perl2 + Apache 2.x
compatibility for RT 3.4?

It would be nice if this information was stated unambiguously in the
installation guides.

What’s ambiguous about it as it stands?

Right now here is the information in the installation guide (search
this page for ‘BIG WARNING’):

Request Tracker Wiki

That says the same thing that README tells you – mod_perl2 is not
recommended. Or at least that’s how I read it. If someone thinks it’s
unclear and can provide better wording, please have a go…

Phil Homewood wrote:

Chris Meyer wrote:

Can someone clarify the current state of mod_perl2 + Apache 2.x
compatibility for RT 3.4?

It would be nice if this information was stated unambiguously in the
installation guides.

What’s ambiguous about it as it stands?

Right now here is the information in the installation guide (search
this page for ‘BIG WARNING’):

Request Tracker Wiki

That says the same thing that README tells you – mod_perl2 is not
recommended. Or at least that’s how I read it. If someone thinks it’s
unclear and can provide better wording, please have a go…

The problem is (IMO) on layer 8 (user).
People (probably, sometimes) think:
“What? MP2 not ‘supported’? WTF, MP1 is soo old and only for wimps - who
uses a version-1 when a version-2 is available? I’ll try anyway and have
the mailinglist-people help me fix it.”
At least, that’s what I thought (minus the thing about pestering the ML

  • I usually know when it’s my fault).
    Until very recently, it seemed to work pretty well. “Recentyl” being
    pre-3.4.2 …
    Similar things could probably said about people struggling with various
    PERL-odities of their Linux-distributions, though the recommendations
    (or warnings) are even less explicit.
    But the things is: there’s really no “bullet-proof” way to install RT.
    While I never have problems installing it on FreeBSD (I’m quite often
    tempted to suggest learning FreeBSD instead of wrestling for hours with
    whatever the poor soul is trying to use at that moment), someone with
    less insight might just completely hose his system. The same goes for
    _insert_your_fine_distro_here .

That said, an entry like…:
“Q: Will MP2 work for me?”
“A: If you have to ask, it’s probably not”

…might push those uncertain users over the line to MP1 :wink:

Perhaps the wording is so vague as not to discriminate anybody?

cheers,
Rainer

Chris Meyer wrote:

Can someone clarify the current state of mod_perl2 + Apache 2.x
compatibility for RT 3.4?
It would be nice if this information was stated unambiguously in the
installation guides.

Hi Chris,

We have been running rt ( differing version ) with mod_perl2 now for
nearly 3 years.
Never had a problem, however it is slow.
But we did it because it worked and it was easy.

However, the system running RT has been upgraded to FC4 and RT is
currently broken. ( even after all rt-test-dependancies )
We get the error:
[error] Can’t locate Apache2.pm in @INC in the httpd log even though
perl-Apache::DBI is installed and mod_perl2
We were running RT 3.2.2. ( and earlier versions ) on Fedora Core 2
The upgrade ( fresh install ) to FC4 has been fine for everything except RT

Now that it is broken, I have to put some effort into fixing it.
I will take the advice of the good people here and try FastCGI ( they
really do seem to feel strongly that mod_perl2 should be avoided )
I have kept a posting to the list from March ready for this time, here
it is in full… (hope this helps)

The post is from Wiliam Harrison harrison@itrd.gov

PS> I don’t post very often so can I just say a BIG thanks to Jesse and
crew. RT Rocks!

Well, thanks to hard work and effort from others, this procedure has been verified to work across at least three installations of RHEL 4. If you think it would be of value, I’m happy to add it to the wiki.

Installation procedure follows…

-William

Installing RT on RHEL 4 with FastCGI and MySQL:

Start with a standard install of RHEL, then upgrade / up2date / whatever to get latest versions of installed packages. Then make sure you have the following packages as well:
httpd-devel
mysql
mysqlclient10
mysql-server
mysql-devel
gcc

Install FastCGI…
wget http://www.fastcgi.com/dist/mod_fastcgi-2.4.2.tar.gz
gunzip mod_fastcgi-2.4.2.tar.gz
tar -xvf mod_fastcgi-2.4.2.tar
cd mod_fastcgi-2.4.2
cp Makefile.AP2 Makefile
edit Makefile:
###Modify for location of apache 2 installation:
top_dir = /etc/httpd
make
make install
edit /etc/httpd/conf/httpd.conf
###Add line to load FastCGI module:
LoadModule fastcgi_module modules/mod_fastcgi.so

FastCGI wants to have a place to put its logs, and permission to do so:

mkdir /etc/httpd/logs/fastcgi
mkdir /etc/httpd/logs/fastcgi/dynamic
chown apache:apache /etc/httpd/logs/fastcgi
chown apache:apache /etc/httpd/logs/fastcgi/dynamic

service httpd start

Check Apache logs to make sure fastcgi started

less /var/log/httpd/error_log
### Should see no lines with [error] referencing FastCGI
### Should see one line indicating a [notice] and the pid of FastCGI
  ### [Mon Mar 14 9:16:57 2005] [notice] FastCGI: process manager initialized (pid 3478)

Turn on MySQL server, Apache server, set MySQL root password…
chkconfig httpd on
chkconfig mysqld on
service mysqld start
mysqladmin -u root password newpass

Set up CPAN initially…
perl -MCPAN -e shell

RT Pre-Install…

RT requires its own group, so let’s add it now lest we forget:

groupadd rt

RT gets initiated by apache, so add apache to the rt group:

edit /etc/group
### Change the line:
### rt:x:501:
### to read:
### rt:x:501:apache

Disable selinux (or make sure it is disabled):

 edit /etc/selinux/config
 ### Change the line:
 ### SELINUX=enforcing
 ### or
 ### SELINUX=permissive
 ### to read:
 ### SELINUX=disabled

Change permissions on /etc/httpd/logs from within

 cd /etc/htttpd/logs
 chmod 755 .

Install RT…
wget http://download.bestpractical.com/pub/rt/release/rt-3.4.1.tar.gz
gunzip rt.tar.gz
tar -xvf rt.tar
cd rt-3.4.1/

Set up the makefile for us with the proper settings:

./configure --with-web-user=apache --with-web-group=apache --with-mysql --with-fastcgi

Show us what’s missing and what’s not:

perl sbin/rt-test-dependencies --with-mysql --with-fastcgi --verbose

Try to install what’s missing for us through CPAN:

perl sbin/rt-test-dependencies --with-mysql --with-fastcgi --install

Test again and only show us the MISSING items this time:

perl sbin/rt-test-dependencies --with-mysql --with-fastcgi --verbose | grep MISSING

MIME::Entity won’t install without MIME::Base64, so install that first:

perl -MCPAN -e 'install MIME::Base64'

Now install MIME::Entity:

perl -MCPAN -e 'install MIME::Entity'

Try to install anything else missing for us:

perl sbin/rt-test-dependencies --with-mysql --with-fastcgi --install

Test again and make sure nothing is MISSING:

perl sbin/rt-test-dependencies --with-mysql --with-fastcgi --verbose | grep MISSING

Assuming everything is present and it’s a go, install and intialize database…

make install
make initialize-database

Make a copy of the dist config file to edit:

cp /opt/rt3/etc/RT_Config.pm /opt/rt3/etc/RT_SiteConfig.pm

Edit your RT config file for your purposes:

edit /opt/rt3/etc/RT_SiteConfig.pm
### Change the line:
### Set($WebBaseURL , "http://RT::WebBaseURL.not.configured:80");
### to read:
### Set($WebBaseURL , "http://your.ip.address:80");
### Change the line:
### Set($WebPath , "");
### to read:
### Set($WebPath , "/rt");

Edit your Apache config file as well:

edit /etc/httpd/conf/httpd.conf
###  NameVirtualHost *:80
###  <VirtualHost *:80>
###    ServerAdmin root
###    DocumentRoot /var/www/html/
###    # Adding the following for RT (the ticket tracker)
###    AddHandler fastcgi-script fcgi
###    <Directory "/opt/rt3/share/html">
###      Options FollowSymLinks ExecCGI
###      AllowOverride None
###    </Directory>
###    # Pass through requests to display images
###    Alias /NoAuth/images/ /opt/rt3/share/html/NoAuth/images/
###  </VirtualHost>
###  FastCgiServer /opt/rt3/bin/mason_handler.fcgi -idle-timeout 120
###  ScriptAlias /rt /opt/rt3/bin/mason_handler.fcgi

###Restart Apache:
service httpd stop
service httpd start

I have kept a posting to the list from March ready for this time, here it is
in full… (hope this helps)

The post is from Wiliam Harrison harrison@itrd.gov

PS> I don’t post very often so can I just say a BIG thanks to Jesse and crew.
RT Rocks!

================================================================================

Well, thanks to hard work and effort from others, this procedure has been
verified to work across at least three installations of RHEL 4. If you think
it would be of value, I’m happy to add it to the wiki.

William’s instructions actually were added to the wiki, and I just used
them this past weekend to get an install up and running on RHEL 4. The
instructions are located at:

http://wiki.bestpractical.com/index.cgi?RHEL4InstallGuide

Every step of the instructions went perfectly, with one hitch…

Installation procedure follows…

-William

Snip-snip

Assuming everything is present and it’s a go, install and intialize

database…
make install

Here, William’s directions seem to go awry. He says to follow ‘make
install’ with ‘make initialize-database’, but ‘make install’ finishes by
outputting the following:

     Congratulations. RT has been installed.


     You must now configure RT by editing 

/opt/rt3/etc/RT_SiteConfig.pm.

     (You will definitely need to set RT's database password in
     /opt/rt3/etc/RT_SiteConfig.pm before continuing. Not doing so
could be very dangerous.  Note that you do not have to manually
add a database user or set up a database for RT.  These actions
will be taken care of in the next step.)

     After that, you need to initialize RT's database by running
      'make initialize-database'

I emailed the list about this discrepancy, and got back two responses. One
was from William, who says that the sequence here doesn’t matter, another
was from another RT user who said (as the above warning does) that the
sequence matters very much, since the info in RT_SiteConfig.pm is used in
building the database. Because the second piece of advice, the
instructions output by ‘make install’, and warnings all over the wiki,
docs, and in other installation guides all seem to agree on the importance
of editing RT_SiteConfig.pm first, I went ahead and did the following
first:

Make a copy of the dist config file to edit:

cp /opt/rt3/etc/RT_Config.pm /opt/rt3/etc/RT_SiteConfig.pm

Edit your RT config file for your purposes:

edit /opt/rt3/etc/RT_SiteConfig.pm

Change the line:

Set($WebBaseURL , “http://RT::WebBaseURL.not.configured:80”);

to read:

Set($WebBaseURL , “http://your.ip.address:80”);

Change the line:

Set($WebPath , “”);

to read:

Set($WebPath , “/rt”);

Only then did I

make initialize-database

While William says his instructions work as they stand, and I have no
reason not to believe that, I can’t confirm it either, as I followed the
RT installer’s instructions to edit RT_SiteConfig.pm first. Whether you
follow William’s sequence or the standard RT sequence at this step, I’d
encourage you to work from the wiki instructions, as those have been
updated (with new formatting, if nothing else). Disclaimer: I changed the
wiki instructions to match the procedure I followed after ‘make install’
(nothing more than copy and paste of what was there). It worked for me,
but if you want to follow William’s instructions, you can undo the switch
described in this email. Again, the instructions are at:

http://wiki.bestpractical.com/index.cgi?RHEL4InstallGuide

Good luck!

-Chris Allison
Brandeis University CS Dept.
Systems Operations Guru
chris@cs.brandeis.edu
http://www.cs.brandeis.edu/~guru/

Ian Ward wrote:

Chris Meyer wrote:

Can someone clarify the current state of mod_perl2 + Apache 2.x
compatibility for RT 3.4?
It would be nice if this information was stated unambiguously in the
installation guides.

Hi Chris,

We have been running rt ( differing version ) with mod_perl2 now for
nearly 3 years.
Please, clarify what exactly mod_perl version is!!! You can’t run MP2
for years, because MP2 is available only for month or two.
You can run development version 1.99_XX that is DEVELOPMENT branch.

If you use MP1.99_XX or MP2.X then you are in situation: “I know what
I’m doing! I subscribed to the mod_perl mailing list and follow all
major changes. And if something goes wrong while perl/mod_perl update I
know where to go and this is not RT mailing list.”

Never had a problem, however it is slow.
Last versions of the MP2.X and 1.99_XX as fast as latest FastCGI versions.
MP1 is slower then FCGI by ~10% this was tested for simple operations
like browsing HomePage with ab tool in RT 3.0.X.

Christopher Allison wrote:

I have kept a posting to the list from March ready for this time, here
it is in full… (hope this helps)

The post is from Wiliam Harrison harrison@itrd.gov

PS> I don’t post very often so can I just say a BIG thanks to Jesse
and crew. RT Rocks!

================================================================================

Well, thanks to hard work and effort from others, this procedure has
been verified to work across at least three installations of RHEL 4.
If you think it would be of value, I’m happy to add it to the wiki.

William’s instructions actually were added to the wiki, and I just used
them this past weekend to get an install up and running on RHEL 4. The
instructions are located at:

http://wiki.bestpractical.com/index.cgi?RHEL4InstallGuide

Every step of the instructions went perfectly, with one hitch…

Installation procedure follows…
-William

Snip-snip

Assuming everything is present and it’s a go, install and

intialize database…
make install

Here, William’s directions seem to go awry. He says to follow ‘make
install’ with ‘make initialize-database’, but ‘make install’ finishes by
outputting the following:

    Congratulations. RT has been installed.


    You must now configure RT by editing /opt/rt3/etc/RT_SiteConfig.pm.

    (You will definitely need to set RT's database password in
    /opt/rt3/etc/RT_SiteConfig.pm before continuing. Not doing so
could be very dangerous.  Note that you do not have to manually
add a database user or set up a database for RT.  These actions
will be taken care of in the next step.)

    After that, you need to initialize RT's database by running
     'make initialize-database'

I emailed the list about this discrepancy, and got back two responses.
One was from William, who says that the sequence here doesn’t matter,
another was from another RT user who said (as the above warning does)
that the sequence matters very much, since the info in RT_SiteConfig.pm
is used in building the database. Because the second piece of advice,
the instructions output by ‘make install’, and warnings all over the
wiki, docs, and in other installation guides all seem to agree on the
importance of editing RT_SiteConfig.pm first, I went ahead and did the
following first:

Make a copy of the dist config file to edit:

cp /opt/rt3/etc/RT_Config.pm /opt/rt3/etc/RT_SiteConfig.pm

Edit your RT config file for your purposes:

edit /opt/rt3/etc/RT_SiteConfig.pm

Change the line:

Set($WebBaseURL , “http://RT::WebBaseURL.not.configured:80”);

to read:

Set($WebBaseURL , “http://your.ip.address:80”);

Change the line:

Set($WebPath , “”);

to read:

Set($WebPath , “/rt”);

Only then did I

make initialize-database

While William says his instructions work as they stand, and I have no
reason not to believe that, I can’t confirm it either, as I followed the
RT installer’s instructions to edit RT_SiteConfig.pm first. Whether you
follow William’s sequence or the standard RT sequence at this step, I’d
encourage you to work from the wiki instructions, as those have been
updated (with new formatting, if nothing else). Disclaimer: I changed
the wiki instructions to match the procedure I followed after ‘make
install’ (nothing more than copy and paste of what was there). It worked
for me, but if you want to follow William’s instructions, you can undo
the switch described in this email. Again, the instructions are at:

http://wiki.bestpractical.com/index.cgi?RHEL4InstallGuide

William and other are right from thier points of view and wrong at the
same time.
Main thing you HAVE TO do before you init your RT DB is set up password
of the RT database user. RT code base uses one user account to connect
its DB, by default it’s ‘rt_user’ with password ‘rt_pass’. You WANT
change default values before you init RT DB in other case you have local
RT security hole and anybody with local system login can access RT data
with this credentials via DB console program.

You can use ./configure arguments --with-db-rt-user and
–with-db-rt-pass to setup it, then you don’t need to change config
file, because RT_Config.pm would be filled with your new values instead
of the defaults.
Second way is change your config before you run ‘make initialize-database’.
If you allready has DB initilized then you should read your DB docs to
find way to change user name and/or password.

So both variants of the installation are right from the “smallest number
of commands” point of view, but wrong from the “secure RT data” point.

Please, apply some changes to instalation guides. IMHO easiest way is
configure script options.

Best regards, Ruslan.

Main thing you HAVE TO do before you init your RT DB is set up password
of the RT database user.

Snip-snip

You can use ./configure arguments --with-db-rt-user and
–with-db-rt-pass to setup it, then you don’t need to change config
file, because RT_Config.pm would be filled with your new values instead
of the defaults.

Snip-snip

Please, apply some changes to instalation guides. IMHO easiest way is
configure script options.

Ruslan,

Let me make sure I understand you. You're saying to do
	'make install'
	'./configure arguments --with-db-rt-user --with-db-rt-pass'

then
‘make initialize-database’

and then edit RT_SiteConfig.pm? Or are you suggesting a different
sequence? While you can wait to edit RT_SiteConfig.pm with your method,
don’t you have to edit it eventually anyway? Does this save time, or
simply put off a complex step? The RHEL4 install guide is located at:

http://wiki.bestpractical.com/index.cgi?RHEL4InstallGuide

and you can edit it directly yourself if you like at:

http://wiki.bestpractical.com/index.cgi?action=edit; 

page_name=RHEL4InstallGuide

Thanks for the input, hope I got your instructions down right,

-Chris Allison
Brandeis University CS Dept.
Systems Operations Guru
chris@cs.brandeis.edu
http://www.cs.brandeis.edu/~guru/

Christopher Allison wrote:

Main thing you HAVE TO do before you init your RT DB is set up password
of the RT database user.

Snip-snip

You can use ./configure arguments --with-db-rt-user and
–with-db-rt-pass to setup it, then you don’t need to change config
file, because RT_Config.pm would be filled with your new values instead
of the defaults.

Snip-snip

Please, apply some changes to instalation guides. IMHO easiest way is
configure script options.

Ruslan,

Let me make sure I understand you. You're saying to do
    'make install'
    './configure arguments --with-db-rt-user --with-db-rt-pass'

no-no. You should run configure script only once. Running it second time
after make install doesn’t make sence because this script prepare
files for installation. This this should be something like:
‘./configure arguments --with-db-rt-user our_secret_rt_db_user
–with-db-rt-pass our_secret_rt_db_pass’
‘make install’
then
‘make initialize-database’

then
‘make initialize-database’

Let’s clarify that I talk only about how things work and want to NOTE
that you have to change default values of the $DatabaseUser and
$DatabasePassword before you run make initialize-database. That’s why
RT suggest you change RT config just after make install. You can
change this options by adding additional arguments when running
configure script or setting this RT options before you run make initialize-database.
So if you don’t use ‘–with-db-rt-user our_secret_rt_db_user
–with-db-rt-pass our_secret_rt_db_pass’ when run configure script then
you have to change your RT config just after make install in other
case you should run custom SQL queries to change credentials RT uses
when connect to the DB. But if you use described configure options you
can run make initialize-database before you change RT config file.

and then edit RT_SiteConfig.pm? Or are you suggesting a different
sequence? While you can wait to edit RT_SiteConfig.pm with your method,
For wiki InstallationGuide I suggest use configure options I described
and change RT config file after make install and before make initialize-database to be compliant with what make install says.

don’t you have to edit it eventually anyway? Does this save time, or
You almost always have to change RT config file options, because you
can’t set all default values with configure script.

simply put off a complex step? The RHEL4 install guide is located at:
This makes your installation more SECURE!!!

http://wiki.bestpractical.com/index.cgi?RHEL4InstallGuide

and you can edit it directly yourself if you like at:
Yeah, I do know that I can edit it :slight_smile:

Ruslan U. Zakirov wrote:

Christopher Allison wrote:

Main thing you HAVE TO do before you init your RT DB is set up password
of the RT database user.

Snip-snip

You can use ./configure arguments --with-db-rt-user and
–with-db-rt-pass to setup it, then you don’t need to change config
file, because RT_Config.pm would be filled with your new values instead
of the defaults.

Snip-snip

Please, apply some changes to instalation guides. IMHO easiest way is
configure script options.
After I think a little bit more about this I change my mind.
Easiest way and right thing to do is change RT_SiteConfig.pm just after
you done make install and set $DatabaseUser and $DatabasePassword in
it manually. This will save from accident password losses while RT
update/upgrade.

I’ve updated wiki page
http://wiki.bestpractical.com/index.cgi?RHEL4InstallGuide

Also you don’t want to cp RT_Config.pm RT_SiteConfig.pm because if
some default values will change in new RT versions to more correct
values then you wouldn’t get this changes while update/upgrade.

Ruslan U. Zakirov wrote:

Ian Ward wrote:

We have been running rt ( differing version ) with mod_perl2 now for
nearly 3 years.

Please, clarify what exactly mod_perl version is!!! You can’t run MP2
for years, because MP2 is available only for month or two.
You can run development version 1.99_XX that is DEVELOPMENT branch.

If you use MP1.99_XX or MP2.X then you are in situation: “I know what
I’m doing! I subscribed to the mod_perl mailing list and follow all
major changes. And if something goes wrong while perl/mod_perl update I
know where to go and this is not RT mailing list.”

Never had a problem, however it is slow.

Last versions of the MP2.X and 1.99_XX as fast as latest FastCGI versions.
MP1 is slower then FCGI by ~10% this was tested for simple operations
like browsing HomePage with ab tool in RT 3.0.X.

OK, I’m sorry I used such a sweeping statement. After I sent it I
thought maybe it wasn’t the best thing to say as it just adds to the
confusion.

We started using RT around 2.0.X on RedHat 7.X which of course was
mod_perl1 and apache 1.3.X

RedHat 9 came out and we installed that and battled with the mod_perl
known as mod_perl2 but was really mod_perl_1.99 ( I think, hey it was a
long time ago! )

Since then gone to 3.0.11 on RedHat ES3 ( which ended up a dead end as
well )
RedHat seem to refuse to update the Perl in their distributions which
eventually blocks your progress with RT
We could not get RT past 3.0.12 ( I seem to recall )
Then went on to Fedora Core2 , RT 3.2.2 with mod_perl2 ( errr 1.99 ) and
custom built Mysql 4

So here I am at Fedora Core 4 , Our RT broke, ( and I am no mod_perl
expert ) so, based on advise here (backed up with your statement ) I
have decided to go with FastCGI using the RedHat ES4 howto as a basis.

It is now working except that the RT instance runs under /rt instead of
the root of the server.
I’d like to get it finished off and I will document it but I am not that
good with Apache directives either!
( I am good at somethings, dammed if I can remember though )

regards, Ian

Ian Ward wrote:

Ruslan U. Zakirov wrote:

Ian Ward wrote:

We have been running rt ( differing version ) with mod_perl2 now for
nearly 3 years.

Please, clarify what exactly mod_perl version is!!! You can’t run MP2
for years, because MP2 is available only for month or two.
You can run development version 1.99_XX that is DEVELOPMENT branch.

If you use MP1.99_XX or MP2.X then you are in situation: “I know what
I’m doing! I subscribed to the mod_perl mailing list and follow all
major changes. And if something goes wrong while perl/mod_perl update I
know where to go and this is not RT mailing list.”

Never had a problem, however it is slow.

Last versions of the MP2.X and 1.99_XX as fast as latest FastCGI
versions.
MP1 is slower then FCGI by ~10% this was tested for simple operations
like browsing HomePage with ab tool in RT 3.0.X.

OK, I’m sorry I used such a sweeping statement. After I sent it I
thought maybe it wasn’t the best thing to say as it just adds to the
confusion.

We started using RT around 2.0.X on RedHat 7.X which of course was
mod_perl1 and apache 1.3.X

RedHat 9 came out and we installed that and battled with the mod_perl
known as mod_perl2 but was really mod_perl_1.99 ( I think, hey it was a
long time ago! )

Since then gone to 3.0.11 on RedHat ES3 ( which ended up a dead end as
well )
RedHat seem to refuse to update the Perl in their distributions which
eventually blocks your progress with RT
We could not get RT past 3.0.12 ( I seem to recall )
Then went on to Fedora Core2 , RT 3.2.2 with mod_perl2 ( errr 1.99 ) and
custom built Mysql 4

So here I am at Fedora Core 4 , Our RT broke, ( and I am no mod_perl
expert ) so, based on advise here (backed up with your statement ) I
have decided to go with FastCGI using the RedHat ES4 howto as a basis.

It is now working except that the RT instance runs under /rt instead of
the root of the server.
I’d like to get it finished off and I will document it but I am not that
good with Apache directives either!
( I am good at somethings, dammed if I can remember though )
Request Tracker Wiki
AFAICS you just need to change ScriptAlias in httpd.conf and set $Web*
config options to get of /rt.
May be script alias line should look like:
ScriptAlias / /opt/rt3/bin/mason_handler.fcgi/

RedHat seem to refuse to update the Perl in their distributions which
eventually blocks your progress with RT

In general, RH doesn’t change the version numbers on apps within their
own distributions, but they back in some of the updates.

So here I am at Fedora Core 4 , Our RT broke, ( and I am no mod_perl
expert ) so, based on advise here (backed up with your statement ) I
have decided to go with FastCGI using the RedHat ES4 howto as a basis.

You might like Centos4.x which should be a closer match for RHEL4 but
free: http://www.centos.org/.

Les Mikesell
les@futuresource.com