Dedicated perl install

Hi all,

I have a web server running Red Hat Enterprise Linux 4, there are a
lot of virtual hosts on it (with PHP and Perl/CGI scripts).

I want to install RT on the server.

Do you recommend to use a dedicated Perl install for RT?
Any cons for that?

I don’t want to affect the other virtual hosts.

Thanks.

We use a specifically crafted Perl install (similar to the one described
in the BestPractical wiki). Encapsulating all of the RT dependencies
separate from the standard RH OS/software just makes my life
significantly easier.

The con is that you need to build and maintain it – but Perl is pretty
stable and you’ll be updating a lot of CPAN packages anyway…

jbw

wolf2k5 wrote:

I have a web server running Red Hat Enterprise Linux 4, there are a
lot of virtual hosts on it (with PHP and Perl/CGI scripts).

I want to install RT on the server.

Do you recommend to use a dedicated Perl install for RT?
Any cons for that?

I don’t want to affect the other virtual hosts.

You could install a different copy, but RHEL4 has a suitable
version and just needs a lot of extra modules that should
not break anything else. The only one you might be concerned
about is HTML::Mason. If you have existing sites using older
versions you should be cautious about updating to the current
one. The RPM’s mentioned at
http://wiki.bestpractical.com/index.cgi?RPMInstall
should work, but since it has to co-exist with other sites
you’ll probably want to run it under fastcgi instead of
mod_perl.

Les Mikesell
les@futuresource.com

The RPM’s mentioned at
Request Tracker Wiki
should work, but since it has to co-exist with other sites
you’ll probably want to run it under fastcgi instead of
mod_perl.

You are right, indeed RHEL4 ships with mod_perl 1.99, while that RT
rpm requires mod_perl 2.0.

I think I’ll go with a dedicated Perl install for RT.

Thanks.

You could install a different copy, but RHEL4 has a suitable
version and just needs a lot of extra modules that should
not break anything else. The only one you might be concerned
about is HTML::Mason.

The other one thing you should be concerned about is RHEL’s updates that
broke weak references in the Perl interpreter, thereby breaking the CPAN
module Tree::Simple, which in turn broke the module DBIx::SearchBuilder,
which in turn broke RT.

For want of a nail, the shoe was lost. For want of a shoe, the horse…well,
you get the idea.

Scott

Scott Courtney | “I don’t mind Microsoft making money. I mind them
scott@4th.com | having a bad operating system.” – Linus Torvalds
http://4th.com/ | (“The Rebel Code,” NY Times, 21 February 1999)
| PGP Public Key at http://4th.com/keys/scott.pubkey

The RPM’s mentioned at
Request Tracker Wiki
should work, but since it has to co-exist with other sites
you’ll probably want to run it under fastcgi instead of
mod_perl.

You are right, indeed RHEL4 ships with mod_perl 1.99, while that RT
rpm requires mod_perl 2.0.

If you don’t have existing mod_perl sites it wouldn’t matter, but
there is a big namespace change that will probably break anything
you might have running now.

I think I’ll go with a dedicated Perl install for RT.

Running under fastcgi would be less drastic.
http://wiki.bestpractical.com/index.cgi?RHEL4InstallGuide
(you could probably use most of the perl module rpms
from the other set instead of the CPAN install).

If you build a custom perl and run mod_perl, you will
also probably have to build a custom httpd and mod_perl
and bind it to a different port or IP address.

Les Mikesell
les@futuresource.com

You could install a different copy, but RHEL4 has a suitable
version and just needs a lot of extra modules that should
not break anything else. The only one you might be concerned
about is HTML::Mason.

The other one thing you should be concerned about is RHEL’s updates that
broke weak references in the Perl interpreter, thereby breaking the CPAN
module Tree::Simple, which in turn broke the module DBIx::SearchBuilder,
which in turn broke RT.

For want of a nail, the shoe was lost. For want of a shoe, the horse…well,
you get the idea.

CPAN is a fairly fragile beast with or without distribution
updates, considering that most of it is interdependent yet managed
independently by different people unaware of concurrent changes.

Les Mikesell
les@futuresource.com

If you build a custom perl and run mod_perl, you will
also probably have to build a custom httpd and mod_perl
and bind it to a different port or IP address.

You are right, I am think I’ll go with a custom Perl build and fastcgi.

Thanks.