Frustrating attempts to install RT3.8 from RPM

Hello, I have been struggling with attempts to install RT3.8 via RPMs.

I know it is perfectly possible to install RT3.8 using the BP install
scripts and docs, but I’d prefer to do it through yum for system
sustainability, ease of updates and upgrades, etc.

These instructions show how to set up a local repo and install RT from a
bundle, but for version 3.6.

*Installing RT 3.6.6 on Redhat Enterprise 5.x (using yum to install
from a bundle)*
http://wiki.bestpractical.com/view/Rhel5InstallGuide

(keep this link, because it is hard to find and all of the sometimes
contradictory RT docs look the same)

However there is a similar bundle for 3.8.7, so maybe that would work.

According to the install doc, we install a host of services first:

[root@testbench1]# yum -y update

[root@testbench1]# yum -y install httpd

[root@testbench1]# yum -y install mysql mysql-server sendmail-cf

Start these services:

[root@testbench1]# service mysqld start
Starting MySQL: [ OK ]
[root@testbench1]# service httpd start
Starting httpd: [ OK ]
[root@testbench1]# chkconfig httpd on
[root@testbench1]# chkconfig mysqld on

The docs call for downloading this bundle:

http://www.jwhite3.com/files/rt/rt-3.6.6-bundle.tar.gz

but we are going to be downloading the 3.8.7 bundle

[root@testbench1]# cd
[root@testbench1]# pwd
/root
[root@testbench1]# mkdir rt3
[root@testbench1]# cd rt3
[root@testbench1]# wget http://www.jwhite3.com/files/rt/rt_3.8.7_bundle.zip
–2010-10-29 16:18:39-- http://www.jwhite3.com/files/rt/rt_3.8.7_bundle.zip
Resolving www.jwhite3.com http://www.jwhite3.com… 97.74.144.177
Connecting to www.jwhite3.com|97.74.144.177|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 38577186 (37M) [application/zip]
Saving to: `rt_3.8.7_bundle.zip’

100%[============================================>] 38,577,186 4.87M/s in 7.8s

2010-10-29 16:18:47 (4.72 MB/s) - `rt_3.8.7_bundle.zip’ saved [38577186/38577186]

Unpack:

[root@testbench1]# unzip rt_3.8.7_bundle.zip
Archive: rt_3.8.7_bundle.zip
inflating: install.sh
inflating: Modules.tar.gz
inflating: rt-3.8.7.tar.gz
inflating: rt.repo
inflating: rt_repo.tar.gz

set up yum repo file:

[root@testbench1]# ls
install.sh rt_3.8.7_bundle.zip rt.repo
Modules.tar.gz rt-3.8.7.tar.gz rt_repo.tar.gz

[root@testbench1]# cp rt.repo /etc/yum.repos.d/

[root@testbench1]# vi /etc/yum.repos.d/rt.repo

[rt-387-local]
name=Request Tracker - $basearch
baseurl=file://opt/rt_repo/$basearch/
enabled=1
gpgcheck=0

[rt-387-noarch-local]
name=Request Tracker - noarch
baseurl=file://opt/rt_repo/noarch/
enabled=1
gpgcheck=0

Unpack the distro part and move it over to /opt where the yum file
expected it:

[root@testbench1]# tar xfz rt_repo.tar.gz

[root@testbench1]# mv rt_repo /opt
[root@testbench1]# ls /opt/rt_repo/
i386 noarch x86_64

Okay, let’s see if that works:

[root@testbench1]# yum clean all
Loaded plugins: rhnplugin, security
Cleaning up Everything

[root@testbench1]# yum list rt3
Loaded plugins: rhnplugin, security
adobe-linux-i386 | 951 B 00:00
adobe-linux-i386/primary | 12 kB 00:00
adobe-linux-i386 18/18
rhel-i386-server-5 | 1.4 kB 00:00
rhel-i386-server-5/primary | 3.0 MB 00:00
rhel-i386-server-5 7696/7696
rhel-i386-server-vt-5 | 1.4 kB 00:00
rhel-i386-server-vt-5/primary | 41 kB 00:00
rhel-i386-server-vt-5 198/198
rhn-tools-rhel-i386-server-5 | 1.3 kB 00:00
rhn-tools-rhel-i386-server-5/primary | 38 kB 00:00
rhn-tools-rhel-i386-server-5 457/457
file://opt/rt_repo/i386/repodata/repomd.xml: http://opt/rt_repo/i386/repodata/repomd.xml: [Errno 5] OSError: [Errno 2] No such file or directory: ‘/rt_repo/i386/repodata/repomd.xml’
Trying other mirror.
Error: Cannot retrieve repository metadata (repomd.xml) for repository: rt-387-local. Please verify its path and try again

No clue what this means. I checked the yum locations. I checked the
xml metadata. Couldn’t see where this bad path was coming from.

Any suggestions for resolving this?

If I can’t resolve this, I will just forget about RT3.8 and stick with
RT3.6 of which there is a well-behaved RPM already in the EPEL repo.

Wes

Hello, I have been struggling with attempts to install RT3.8 via RPMs.

I know it is perfectly possible to install RT3.8 using the BP install
scripts and docs, but I’d prefer to do it through yum for system
sustainability, ease of updates and upgrades, etc.

If I can’t resolve this, I will just forget about RT3.8 and stick with
RT3.6 of which there is a well-behaved RPM already in the EPEL repo.

Wes

I’m currently going through a RT move from freebsd to rhel5 (long story,
would rather stay with freebsd but don’t have a choice here) and have
found all kinds of annoying difficulties with yum (or, rather, the
packages available.) When I realized that I was trying to stick with yum
for ease of upgrades when yum was preventing me from easily keeping up
to date, life got a lot easier.

In the end I just let cpan install what it could and used yum for the
things that gave me trouble in cpan. Using RT’s configure and make
targets is a lot easier and much more maintainable than having to roll
my own rpm just to do it the yum way.

Being stuck with an old version of the software in the name of easy
upgrades didn’t make sense to me.

Cheers,
Paul

Paul, sounds like you aren’t a long term fan of Fedora, RHEL, or CentOS,
so I’m guessing yum feels like an inconvenience to you, especially when
it seems to be getting in the way of your desired install.

I’ve been a sysadmin for 20 years and I’ve never been a fan of the make
‘n’ break style of system administration. There is no way I could
manage a score of machines, many with subtly different hardware, if I
had to build every package the old way. As it is, I can spend a few
hours monthly updating the OS and all installed software on all of our
machines, with a simple “yum -y update”

In my opinion, package managers like apt-get and yum are some of the
best things to happen to OS in a very long time. Having installs
tracked and managed by package managers keeps complicated OSs and their
installed software up-to-date, eases system administration (especially
as the server to sysadmin ratio increases), increases scalability,
increases sysadmin efficiency, and creates standards for software
manufacturers.

If as a conservative sysadmin you prefer to operate well-back from the
bleeding edge anyway, the small trade-off in control is a small price to
pay.

It is hardly the package manager’s fault if a software manufacturer such
as Best Practical and its user community fail to create a package for
the latest software. Compare that to software whose RPMs are kept
relatively up-to-date.

WesOn 11/2/2010 3:49 PM, Paul wrote:

On 11/02/2010 02:19 PM, Wes Modes wrote:

Hello, I have been struggling with attempts to install RT3.8 via RPMs.

I know it is perfectly possible to install RT3.8 using the BP install
scripts and docs, but I’d prefer to do it through yum for system
sustainability, ease of updates and upgrades, etc.

If I can’t resolve this, I will just forget about RT3.8 and stick with
RT3.6 of which there is a well-behaved RPM already in the EPEL repo.

Wes

I’m currently going through a RT move from freebsd to rhel5 (long story,
would rather stay with freebsd but don’t have a choice here) and have
found all kinds of annoying difficulties with yum (or, rather, the
packages available.) When I realized that I was trying to stick with yum
for ease of upgrades when yum was preventing me from easily keeping up
to date, life got a lot easier.

In the end I just let cpan install what it could and used yum for the
things that gave me trouble in cpan. Using RT’s configure and make
targets is a lot easier and much more maintainable than having to roll
my own rpm just to do it the yum way.

Being stuck with an old version of the software in the name of easy
upgrades didn’t make sense to me.

Cheers,
Paul

Agreed. This is why I spent a week with cpan2rpm and built packages for both
openSuSE (which we’re transitioning to) and CentOS.On 3/11/10 11:21 AM, “Wes Modes” wmodes@ucsc.edu wrote:

Paul, sounds like you aren’t a long term fan of Fedora, RHEL, or CentOS,
so I’m guessing yum feels like an inconvenience to you, especially when
it seems to be getting in the way of your desired install.

I’ve been a sysadmin for 20 years and I’ve never been a fan of the make
‘n’ break style of system administration. There is no way I could
manage a score of machines, many with subtly different hardware, if I
had to build every package the old way. As it is, I can spend a few
hours monthly updating the OS and all installed software on all of our
machines, with a simple “yum -y update”

In my opinion, package managers like apt-get and yum are some of the
best things to happen to OS in a very long time. Having installs
tracked and managed by package managers keeps complicated OSs and their
installed software up-to-date, eases system administration (especially
as the server to sysadmin ratio increases), increases scalability,
increases sysadmin efficiency, and creates standards for software
manufacturers.

If as a conservative sysadmin you prefer to operate well-back from the
bleeding edge anyway, the small trade-off in control is a small price to
pay.

It is hardly the package manager’s fault if a software manufacturer such
as Best Practical and its user community fail to create a package for
the latest software. Compare that to software whose RPMs are kept
relatively up-to-date.

Wes

On 11/2/2010 3:49 PM, Paul wrote:

On 11/02/2010 02:19 PM, Wes Modes wrote:

Hello, I have been struggling with attempts to install RT3.8 via RPMs.

I know it is perfectly possible to install RT3.8 using the BP install
scripts and docs, but I’d prefer to do it through yum for system
sustainability, ease of updates and upgrades, etc.

If I can’t resolve this, I will just forget about RT3.8 and stick with
RT3.6 of which there is a well-behaved RPM already in the EPEL repo.

Wes

I’m currently going through a RT move from freebsd to rhel5 (long story,
would rather stay with freebsd but don’t have a choice here) and have
found all kinds of annoying difficulties with yum (or, rather, the
packages available.) When I realized that I was trying to stick with yum
for ease of upgrades when yum was preventing me from easily keeping up
to date, life got a lot easier.

In the end I just let cpan install what it could and used yum for the
things that gave me trouble in cpan. Using RT’s configure and make
targets is a lot easier and much more maintainable than having to roll
my own rpm just to do it the yum way.

Being stuck with an old version of the software in the name of easy
upgrades didn’t make sense to me.

Cheers,
Paul

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

A few questions about your openSuSE packages. Are you using the
devel:languages:/perl repository for your perl dependencies? Would you
be willing to make your rpms available or at least the .spec?

Darin Perusich
Email: Darin.Perusich@ctg.com
Office: 716-888-3690
Cell: 716-807-4589

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-
bounces@lists.bestpractical.com] On Behalf Of Gary Greene
Sent: Wednesday, November 03, 2010 2:52 PM
To: Wes Modes; rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Frustrating attempts to install RT3.8 from RPM

Agreed. This is why I spent a week with cpan2rpm and built packages
for
both
openSuSE (which we’re transitioning to) and CentOS.

Paul, sounds like you aren’t a long term fan of Fedora, RHEL, or
CentOS,
so I’m guessing yum feels like an inconvenience to you, especially
when
it seems to be getting in the way of your desired install.

I’ve been a sysadmin for 20 years and I’ve never been a fan of the
make
‘n’ break style of system administration. There is no way I could
manage a score of machines, many with subtly different hardware, if
I
had to build every package the old way. As it is, I can spend a few
hours monthly updating the OS and all installed software on all of
our
machines, with a simple “yum -y update”

In my opinion, package managers like apt-get and yum are some of the
best things to happen to OS in a very long time. Having installs
tracked and managed by package managers keeps complicated OSs and
their
installed software up-to-date, eases system administration
(especially
as the server to sysadmin ratio increases), increases scalability,
increases sysadmin efficiency, and creates standards for software
manufacturers.

If as a conservative sysadmin you prefer to operate well-back from
the
bleeding edge anyway, the small trade-off in control is a small
price
to
pay.

It is hardly the package manager’s fault if a software manufacturer
such
as Best Practical and its user community fail to create a package
for
the latest software. Compare that to software whose RPMs are kept
relatively up-to-date.

Wes

Hello, I have been struggling with attempts to install RT3.8 via
RPMs.

I know it is perfectly possible to install RT3.8 using the BP
install
scripts and docs, but I’d prefer to do it through yum for system
sustainability, ease of updates and upgrades, etc.

If I can’t resolve this, I will just forget about RT3.8 and stick
with
RT3.6 of which there is a well-behaved RPM already in the EPEL
repo.

Wes

I’m currently going through a RT move from freebsd to rhel5 (long
story,
would rather stay with freebsd but don’t have a choice here) and
have
found all kinds of annoying difficulties with yum (or, rather, the
packages available.) When I realized that I was trying to stick
with
yum
for ease of upgrades when yum was preventing me from easily keeping
up
to date, life got a lot easier.

In the end I just let cpan install what it could and used yum for
the
things that gave me trouble in cpan. Using RT’s configure and make
targets is a lot easier and much more maintainable than having to
roll
my own rpm just to do it the yum way.

Being stuck with an old version of the software in the name of easy
upgrades didn’t make sense to me.

Cheers,
Paul


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

The information transmitted is intended only for the person or entity to which
it is addressed and may contain confidential and/or privileged material. Any
review, retransmission, dissemination or other use of, or taking of any action
in reliance upon, this information by persons or entities other than the
intended recipient is prohibited. If you are not the intended recipient of this
message, please contact the sender and delete this material from this computer.

I presume that is CentOS5. That would make me very happy as CentOS RPMs
should work for RHEL.

One thing I adore about well-built packages is that things are placed in
the right location for the OS. For instance, the RT3 rpms put all the
config files in /etc, all the perl modules in the perl modules dir, and
the various tools in /usr/bin and /usr/sbin.

Is yours built that way, or does it keep to the Best Practical distro
locations?

i guess this means that no one has a solution to the problem I observed
with the rpm bundle I did find, ya?

WesOn 11/3/2010 11:52 AM, Gary Greene wrote:

Agreed. This is why I spent a week with cpan2rpm and built packages for both
openSuSE (which we’re transitioning to) and CentOS.

On 3/11/10 11:21 AM, “Wes Modes” wmodes@ucsc.edu wrote:

Paul, sounds like you aren’t a long term fan of Fedora, RHEL, or CentOS,
so I’m guessing yum feels like an inconvenience to you, especially when
it seems to be getting in the way of your desired install.

I’ve been a sysadmin for 20 years and I’ve never been a fan of the make
‘n’ break style of system administration. There is no way I could
manage a score of machines, many with subtly different hardware, if I
had to build every package the old way. As it is, I can spend a few
hours monthly updating the OS and all installed software on all of our
machines, with a simple “yum -y update”

In my opinion, package managers like apt-get and yum are some of the
best things to happen to OS in a very long time. Having installs
tracked and managed by package managers keeps complicated OSs and their
installed software up-to-date, eases system administration (especially
as the server to sysadmin ratio increases), increases scalability,
increases sysadmin efficiency, and creates standards for software
manufacturers.

If as a conservative sysadmin you prefer to operate well-back from the
bleeding edge anyway, the small trade-off in control is a small price to
pay.

It is hardly the package manager’s fault if a software manufacturer such
as Best Practical and its user community fail to create a package for
the latest software. Compare that to software whose RPMs are kept
relatively up-to-date.

Wes

On 11/2/2010 3:49 PM, Paul wrote:

On 11/02/2010 02:19 PM, Wes Modes wrote:

Hello, I have been struggling with attempts to install RT3.8 via RPMs.

I know it is perfectly possible to install RT3.8 using the BP install
scripts and docs, but I’d prefer to do it through yum for system
sustainability, ease of updates and upgrades, etc.

If I can’t resolve this, I will just forget about RT3.8 and stick with
RT3.6 of which there is a well-behaved RPM already in the EPEL repo.

Wes

I’m currently going through a RT move from freebsd to rhel5 (long story,
would rather stay with freebsd but don’t have a choice here) and have
found all kinds of annoying difficulties with yum (or, rather, the
packages available.) When I realized that I was trying to stick with yum
for ease of upgrades when yum was preventing me from easily keeping up
to date, life got a lot easier.

In the end I just let cpan install what it could and used yum for the
things that gave me trouble in cpan. Using RT’s configure and make
targets is a lot easier and much more maintainable than having to roll
my own rpm just to do it the yum way.

Being stuck with an old version of the software in the name of easy
upgrades didn’t make sense to me.

Cheers,
Paul

The CentOS ones follow the RH way of directory layout, with the caveat that
I chose to put the other modules that normally get pulled in via cpan in the
perl5 site_lib hierarchy to assure that a rouge update from rpmforge or
upstream CentOS would be able to be installed without odd file conflicts.

The SuSE ones I did slightly differently as I think having the main RT stuff
strewn around /usr a little odd. The CPAN stuff is in the perl5 site_lib
hierarchy as before, but the main HTML/Mason templates/RT only specific
modules/plugins stuff are in /srv/www/htdocs/rt. Configuration stuff is in
/etc/rt and the plugin configuration directory is /etc/rt/local/…

If I were to do over the CentOS ones, I’d likely do the same as I did with
SuSE.On 3/11/10 4:36 PM, “Wes Modes” wmodes@ucsc.edu wrote:

I presume that is CentOS5. That would make me very happy as CentOS RPMs
should work for RHEL.

One thing I adore about well-built packages is that things are placed in
the right location for the OS. For instance, the RT3 rpms put all the
config files in /etc, all the perl modules in the perl modules dir, and
the various tools in /usr/bin and /usr/sbin.

Is yours built that way, or does it keep to the Best Practical distro
locations?

i guess this means that no one has a solution to the problem I observed
with the rpm bundle I did find, ya?

Wes

On 11/3/2010 11:52 AM, Gary Greene wrote:

Agreed. This is why I spent a week with cpan2rpm and built packages for both
openSuSE (which we’re transitioning to) and CentOS.

On 3/11/10 11:21 AM, “Wes Modes” wmodes@ucsc.edu wrote:

Paul, sounds like you aren’t a long term fan of Fedora, RHEL, or CentOS,
so I’m guessing yum feels like an inconvenience to you, especially when
it seems to be getting in the way of your desired install.

I’ve been a sysadmin for 20 years and I’ve never been a fan of the make
‘n’ break style of system administration. There is no way I could
manage a score of machines, many with subtly different hardware, if I
had to build every package the old way. As it is, I can spend a few
hours monthly updating the OS and all installed software on all of our
machines, with a simple “yum -y update”

In my opinion, package managers like apt-get and yum are some of the
best things to happen to OS in a very long time. Having installs
tracked and managed by package managers keeps complicated OSs and their
installed software up-to-date, eases system administration (especially
as the server to sysadmin ratio increases), increases scalability,
increases sysadmin efficiency, and creates standards for software
manufacturers.

If as a conservative sysadmin you prefer to operate well-back from the
bleeding edge anyway, the small trade-off in control is a small price to
pay.

It is hardly the package manager’s fault if a software manufacturer such
as Best Practical and its user community fail to create a package for
the latest software. Compare that to software whose RPMs are kept
relatively up-to-date.

Wes

On 11/2/2010 3:49 PM, Paul wrote:

On 11/02/2010 02:19 PM, Wes Modes wrote:

Hello, I have been struggling with attempts to install RT3.8 via RPMs.

I know it is perfectly possible to install RT3.8 using the BP install
scripts and docs, but I’d prefer to do it through yum for system
sustainability, ease of updates and upgrades, etc.

If I can’t resolve this, I will just forget about RT3.8 and stick with
RT3.6 of which there is a well-behaved RPM already in the EPEL repo.

Wes

I’m currently going through a RT move from freebsd to rhel5 (long story,
would rather stay with freebsd but don’t have a choice here) and have
found all kinds of annoying difficulties with yum (or, rather, the
packages available.) When I realized that I was trying to stick with yum
for ease of upgrades when yum was preventing me from easily keeping up
to date, life got a lot easier.

In the end I just let cpan install what it could and used yum for the
things that gave me trouble in cpan. Using RT’s configure and make
targets is a lot easier and much more maintainable than having to roll
my own rpm just to do it the yum way.

Being stuck with an old version of the software in the name of easy
upgrades didn’t make sense to me.

Cheers,
Paul

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

That is nice to see that you made a well-crafted rpm that you can be
proud of. I wonder what would happen if a later version of RT3 became
available via EPEL. Would it nicely replace the files (maybe moving
stuff to rpmsave’s) or would all hell break loose?

What RT3 version is your centos rpm build?

When and where would your centos rpm be available to play with?

W.On 11/3/2010 4:45 PM, Gary Greene wrote:

The CentOS ones follow the RH way of directory layout, with the caveat that
I chose to put the other modules that normally get pulled in via cpan in the
perl5 site_lib hierarchy to assure that a rouge update from rpmforge or
upstream CentOS would be able to be installed without odd file conflicts.

The SuSE ones I did slightly differently as I think having the main RT stuff
strewn around /usr a little odd. The CPAN stuff is in the perl5 site_lib
hierarchy as before, but the main HTML/Mason templates/RT only specific
modules/plugins stuff are in /srv/www/htdocs/rt. Configuration stuff is in
/etc/rt and the plugin configuration directory is /etc/rt/local/…

If I were to do over the CentOS ones, I’d likely do the same as I did with
SuSE.

On 3/11/10 4:36 PM, “Wes Modes” wmodes@ucsc.edu wrote:

I presume that is CentOS5. That would make me very happy as CentOS RPMs
should work for RHEL.

One thing I adore about well-built packages is that things are placed in
the right location for the OS. For instance, the RT3 rpms put all the
config files in /etc, all the perl modules in the perl modules dir, and
the various tools in /usr/bin and /usr/sbin.

Is yours built that way, or does it keep to the Best Practical distro
locations?

i guess this means that no one has a solution to the problem I observed
with the rpm bundle I did find, ya?

Wes

On 11/3/2010 11:52 AM, Gary Greene wrote:

Agreed. This is why I spent a week with cpan2rpm and built packages for both
openSuSE (which we’re transitioning to) and CentOS.

On 3/11/10 11:21 AM, “Wes Modes” wmodes@ucsc.edu wrote:

Paul, sounds like you aren’t a long term fan of Fedora, RHEL, or CentOS,
so I’m guessing yum feels like an inconvenience to you, especially when
it seems to be getting in the way of your desired install.

I’ve been a sysadmin for 20 years and I’ve never been a fan of the make
‘n’ break style of system administration. There is no way I could
manage a score of machines, many with subtly different hardware, if I
had to build every package the old way. As it is, I can spend a few
hours monthly updating the OS and all installed software on all of our
machines, with a simple “yum -y update”

In my opinion, package managers like apt-get and yum are some of the
best things to happen to OS in a very long time. Having installs
tracked and managed by package managers keeps complicated OSs and their
installed software up-to-date, eases system administration (especially
as the server to sysadmin ratio increases), increases scalability,
increases sysadmin efficiency, and creates standards for software
manufacturers.

If as a conservative sysadmin you prefer to operate well-back from the
bleeding edge anyway, the small trade-off in control is a small price to
pay.

It is hardly the package manager’s fault if a software manufacturer such
as Best Practical and its user community fail to create a package for
the latest software. Compare that to software whose RPMs are kept
relatively up-to-date.

Wes

On 11/2/2010 3:49 PM, Paul wrote:

On 11/02/2010 02:19 PM, Wes Modes wrote:

Hello, I have been struggling with attempts to install RT3.8 via RPMs.

I know it is perfectly possible to install RT3.8 using the BP install
scripts and docs, but I’d prefer to do it through yum for system
sustainability, ease of updates and upgrades, etc.

If I can’t resolve this, I will just forget about RT3.8 and stick with
RT3.6 of which there is a well-behaved RPM already in the EPEL repo.

Wes

I’m currently going through a RT move from freebsd to rhel5 (long story,
would rather stay with freebsd but don’t have a choice here) and have
found all kinds of annoying difficulties with yum (or, rather, the
packages available.) When I realized that I was trying to stick with yum
for ease of upgrades when yum was preventing me from easily keeping up
to date, life got a lot easier.

In the end I just let cpan install what it could and used yum for the
things that gave me trouble in cpan. Using RT’s configure and make
targets is a lot easier and much more maintainable than having to roll
my own rpm just to do it the yum way.

Being stuck with an old version of the software in the name of easy
upgrades didn’t make sense to me.

Cheers,
Paul

The CentOS version is currently 3.8.1, so they’re not really a good fit at
this time. The SuSE ones are 3.8.8. If you’re still interested in them, I
can put them on a server outside my office for download (bandwidth at work
is… lacking.)

Far as I know, the changes in /etc are marked config noreplace, however,
changing them to config save is fairly easy in the srpm.On 3/11/10 5:24 PM, “Wes Modes” wmodes@ucsc.edu wrote:

That is nice to see that you made a well-crafted rpm that you can be
proud of. I wonder what would happen if a later version of RT3 became
available via EPEL. Would it nicely replace the files (maybe moving
stuff to rpmsave’s) or would all hell break loose?

What RT3 version is your centos rpm build?

When and where would your centos rpm be available to play with?

W.

On 11/3/2010 4:45 PM, Gary Greene wrote:

The CentOS ones follow the RH way of directory layout, with the caveat that
I chose to put the other modules that normally get pulled in via cpan in the
perl5 site_lib hierarchy to assure that a rouge update from rpmforge or
upstream CentOS would be able to be installed without odd file conflicts.

The SuSE ones I did slightly differently as I think having the main RT stuff
strewn around /usr a little odd. The CPAN stuff is in the perl5 site_lib
hierarchy as before, but the main HTML/Mason templates/RT only specific
modules/plugins stuff are in /srv/www/htdocs/rt. Configuration stuff is in
/etc/rt and the plugin configuration directory is /etc/rt/local/…

If I were to do over the CentOS ones, I’d likely do the same as I did with
SuSE.

On 3/11/10 4:36 PM, “Wes Modes” wmodes@ucsc.edu wrote:

I presume that is CentOS5. That would make me very happy as CentOS RPMs
should work for RHEL.

One thing I adore about well-built packages is that things are placed in
the right location for the OS. For instance, the RT3 rpms put all the
config files in /etc, all the perl modules in the perl modules dir, and
the various tools in /usr/bin and /usr/sbin.

Is yours built that way, or does it keep to the Best Practical distro
locations?

i guess this means that no one has a solution to the problem I observed
with the rpm bundle I did find, ya?

Wes

On 11/3/2010 11:52 AM, Gary Greene wrote:

Agreed. This is why I spent a week with cpan2rpm and built packages for
both
openSuSE (which we’re transitioning to) and CentOS.

On 3/11/10 11:21 AM, “Wes Modes” wmodes@ucsc.edu wrote:

Paul, sounds like you aren’t a long term fan of Fedora, RHEL, or CentOS,
so I’m guessing yum feels like an inconvenience to you, especially when
it seems to be getting in the way of your desired install.

I’ve been a sysadmin for 20 years and I’ve never been a fan of the make
‘n’ break style of system administration. There is no way I could
manage a score of machines, many with subtly different hardware, if I
had to build every package the old way. As it is, I can spend a few
hours monthly updating the OS and all installed software on all of our
machines, with a simple “yum -y update”

In my opinion, package managers like apt-get and yum are some of the
best things to happen to OS in a very long time. Having installs
tracked and managed by package managers keeps complicated OSs and their
installed software up-to-date, eases system administration (especially
as the server to sysadmin ratio increases), increases scalability,
increases sysadmin efficiency, and creates standards for software
manufacturers.

If as a conservative sysadmin you prefer to operate well-back from the
bleeding edge anyway, the small trade-off in control is a small price to
pay.

It is hardly the package manager’s fault if a software manufacturer such
as Best Practical and its user community fail to create a package for
the latest software. Compare that to software whose RPMs are kept
relatively up-to-date.

Wes

On 11/2/2010 3:49 PM, Paul wrote:

On 11/02/2010 02:19 PM, Wes Modes wrote:

Hello, I have been struggling with attempts to install RT3.8 via RPMs.

I know it is perfectly possible to install RT3.8 using the BP install
scripts and docs, but I’d prefer to do it through yum for system
sustainability, ease of updates and upgrades, etc.

If I can’t resolve this, I will just forget about RT3.8 and stick with
RT3.6 of which there is a well-behaved RPM already in the EPEL repo.

Wes

I’m currently going through a RT move from freebsd to rhel5 (long story,
would rather stay with freebsd but don’t have a choice here) and have
found all kinds of annoying difficulties with yum (or, rather, the
packages available.) When I realized that I was trying to stick with yum
for ease of upgrades when yum was preventing me from easily keeping up
to date, life got a lot easier.

In the end I just let cpan install what it could and used yum for the
things that gave me trouble in cpan. Using RT’s configure and make
targets is a lot easier and much more maintainable than having to roll
my own rpm just to do it the yum way.

Being stuck with an old version of the software in the name of easy
upgrades didn’t make sense to me.

Cheers,
Paul

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