Install on CentOS, best current instructions

Hi,

With all the dependencies there are a number of pitfalls, and a number of
different instructions. I bought the book, which is not completely current
anymore. I don’t know what might have changed.

What/where are the best instructions to follow to do the install?

Also, I prefer to stick to a RH (rpm) based distro. Right now I’m using CentOS
for the install. Any thoughts on this?

PERL is certainly omnipresent in RT and a lot of mods are used. Which is the
best set of instructions for this distro.

My production arch is likely to be i386 with 2G RAM and about 5 techs. Of
course SQL loves RAM as does PERL, I’d love to hear some notes on the arch.

Steve

With all the dependencies there are a number of pitfalls, and a number of
different instructions. I bought the book, which is not completely current
anymore. I don’t know what might have changed.

What/where are the best instructions to follow to do the install?
The README that comes with the distribution.

Install from source, with a non-system perl.

CPAN/CPANPLUS is your friend, and it will handle dependencies just fine.

Installation is trivial unless you have SELinux enabled, and even then it’s not
too hard to figure out what strictures need to be loosened from logs,
list archives
and the wiki.
Cambridge Energy Alliance: Save money. Save the planet.

Install from source, with a non-system perl.

Why non-system perl, Jerrad? I’ve never had a problem with it (that I
know of), but have I just been lucky?

My only RPM-related problem is having to reinstall a current version of
Sys::Syslog after every yum update (anyone know why that happens?)

Why non-system perl, Jerrad? I’ve never had a problem with it (that I know
of), but have I just been lucky?

My only RPM-related problem is having to reinstall a current version of
Sys::Syslog after every yum update (anyone know why that happens?)

Precisely. RedHat is bad at not clobbering newer versions of modules
(RPM has the ability to run prep scripts, which could check to see that
the version being replaced is not newer than the package to be installed).

You encounter this, and on Centos 4 I encounter File::Temp occasionally
being downgraded to an incompatible version.

Precisely. RedHat is bad at not clobbering newer versions
of modules
(RPM has the ability to run prep scripts, which could check
to see that
the version being replaced is not newer than the package to
be installed).

You encounter this, and on Centos 4 I encounter File::Temp
occasionally
being downgraded to an incompatible version.

I recently installed RT 3.8.8 on CentOS 5.4, 64bit.

There were a few extra steps I had to do in order for the ‘make fixdeps’ to succeed:

yum install gd

yum install gd-devel

Get the graphviz repo file.

cp graphviz-rhel.repo /etc/yum.repos.d/

yum install graphviz

There is also this, which is a bit overkill, but you can skip the “Active Directory 2003 & Exchange 2007” headache, and only do the RT part. :slight_smile:

http://wiki.bestpractical.com/view/CentOS5InstallPlusSome

There is also this, which is a bit overkill, but you can skip the “Active
Directory 2003 & Exchange 2007” headache, and only do the RT part. :slight_smile:

Fortunately I’m windows free so I don’t need to mess with those “headache’s”.

These replies are interesting however.

Steve Szmidt
Call Center Service Group, LC
http://callcentersg.com
727-330-9491 opt 5

If you can follow this thread, here some very specific instructions I typed
out once upon a time:

http://www.gossamer-threads.com/lists/rt/users/85040?search_string=5.3;#85040

Instead of mod-perl or Apache FastCGI, the instructions call for using
mod_fcgid which is part of the standard RHEL repo.

James MoseleyOn Fri, Aug 6, 2010 at 1:00 PM, Steve Szmidt sszmidt@callcentersg.comwrote:

Hi,

With all the dependencies there are a number of pitfalls, and a number of
different instructions. I bought the book, which is not completely current
anymore. I don’t know what might have changed.

What/where are the best instructions to follow to do the install?

Also, I prefer to stick to a RH (rpm) based distro. Right now I’m using
CentOS
for the install. Any thoughts on this?

PERL is certainly omnipresent in RT and a lot of mods are used. Which is
the
best set of instructions for this distro.

My production arch is likely to be i386 with 2G RAM and about 5 techs. Of
course SQL loves RAM as does PERL, I’d love to hear some notes on the arch.

Steve

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Why non-system perl, Jerrad? I’ve never had a problem with it (that I know
of), but have I just been lucky?

My only RPM-related problem is having to reinstall a current version of
Sys::Syslog after every yum update (anyone know why that happens?)

Precisely. RedHat is bad at not clobbering newer versions of modules
(RPM has the ability to run prep scripts, which could check to see that
the version being replaced is not newer than the package to be installed).

You encounter this, and on Centos 4 I encounter File::Temp occasionally
being downgraded to an incompatible version.

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

This is why I normally build the needed Perl module RPMs to live in
site_perl instead of vendor_perl, and then epoch them to 1000000 so RH can’t
clobber my changes. The problem overall is that CPAN doesn’t tie into RPM.
Using only the prep scripts like that would break the RPM dependency chain
which isn’t based off what’s on the file system, but rather it’s concept of
"capabilities" which are only defined in the RPM DB from the metadata
provided in RPM.

Gary L. Greene, Jr.
IT Operations
Minerva Networks, Inc.
Cell: (650) 704-6633
Phone: (408) 240-1239

Howard Jones wrote:> On 06/08/2010 19:09, Jerrad Pierce wrote:

Install from source, with a non-system perl.

Why non-system perl, Jerrad? I’ve never had a problem with it (that I
know of), but have I just been lucky?

My only RPM-related problem is having to reinstall a current version of
Sys::Syslog after every yum update (anyone know why that happens?)

You are over writing files supplied by the perl package.

$ rpm -q --whatprovides 'perl(Sys::Syslog)'
perl-5.8.8-32.el5_5.1

When the perl package gets updated, RPM compares the checksums of the
installed files to those in the new package, detects the checksums don’t
match, and installs the files from the new package over the existing ones.

This is correct behavior and the only sane way a package manager can
operate.

Furthermore if you run a verify over your file system errors will be
reported since the files installed do not match the checksums from the
RPM, so you’ve made your system unverifiable. Probably not a great
tragedy, but something you should avoid unless you have a very
persuasive argument.

It’s trivial to avoid this if you use RPM. You can either roll your own
spec file or use cpanspec to do the heavy lifting for you. I use cpanspec.

1: install the cpanspec package (on your development box eh)

2: cpanspec Sys::Syslog

3: edit perl-Sys-Syslog.spec as below

4: rpmbuild -ba --define "_sourcedir pwd" --define "_builddir pwd"
–define "_srcrpmdir pwd" --define "_rpmdir pwd" perl-Sys-Syslog.spec

5: install the RPM where required, or setup a yum repo

All the --defines aren’t strictly required, but it forces rpmbuild to
use the current directory and that’s generally where I want the RPMs to
end up.

spec file edits

%build

add INSTALLVENDORMAN3DIR

%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS"
INSTALLVENDORMAN3DIR=/usr/local/share/man/man3

%files
%defattr(-,root,root,-)
%doc Changes README README.win32
%{perl_vendorarch}/auto/*
%{perl_vendorarch}/Sys*

change man path

/usr/local/share/man/man3/*

end spec file edits

Since vendor is searched before core, the new module gets found first.
Since the files are on a different path to the ones in the perl package
they won’t get affected when perl updates.

If you are having a clash in vendor, use site instead, which is even
earlier in the perl path.

Easy!

Cheers, Jeff.

Jeff Fearn jfearn@redhat.com
Software Engineer
Engineering Operations
Red Hat, Inc
Freedom … courage … Commitment … ACCOUNTABILITY

Hello,

I have been running and upgrading RT on CentOS (today RT 3.8.7 on CentOS v5.5) for several years. In addition to all the good
advices previously given, I would add, in short : the main (and single !) issue is about non RHEL-compliant Perl modules; up to RT
3.6, it seemed that we had to deal with only one such non-standard module, now there seem to be more. I picked up some from
rpmforge, as I was trying to keep an rpm-administered system if possible, but eventually I dropped this tedious solution, and
finished with :

make testdeps

make fixdeps

(documented in the README from the stock tar.gz downloaded RT archive)

Now, when I am upgrading my OS, I monitor possible perl* updates : whenever I seen one, I am going back immediately to

make testdeps (because I am curious)

make fixdeps (jumping here directly should be sufficient as a quick fix)

So far so good …

Robert GRASSO – System engineer

CEDRAT S.A.
15 Chemin de Malacher - Inovallée - 38246 MEYLAN cedex - FRANCE
Phone: +33 (0)4 76 90 50 45 - Fax: +33 (0)4 56 38 08 30
mailto:robert.grasso@cedrat.com - http://www.cedrat.com