Why I am recommending 3.6 over 3.8 to my boss

RT Users
1

Dear Boss:

I strongly recommend going with the 3.6 version of RT. The install takes a few minutes, and it otherwise meets all the requirements of our project. Migration of old queues is simple. There is cost savings in the near and long-term.

There is no rpm of RT3.8 that works for RHEL (32 or 64 bit) and none seem to be forthcoming. Someday perhaps someone will put one together, but it doesn’t look like anytime soon.

I CAN do a manual install of RT3.8 using the Best Practical install scripts. It is not terribly hard. However, the long-term costs of this are large. The install scripts put all the binaries, configuration files, and libraries in the wrong places for RHEL/CentOS, and working outside the package manager means files could be clobbered at any time. On the other hand, the rpms for RT3.6 use the package manager and 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. The non-standard install using the scripts creates recurring costs in the future as the system is significantly more difficult to update and harder to maintain, like by a factor of 50 (five minutes compared to 4 hours).

Additionally, the cost of migration of old content from 3.6 to 3.8 is unknown.

Again, I will install either RT3.6 or RT3.8 but I need you to understand
and acknowledge the costs of the choice.

Wes

Thanks to Gary Greene for the info about his latest centos rpm build.

2

Migration from 3.6 to 3.8 is a non-issue. It is easy, and not even worth
considering as a problem. It isn’t any more difficult to move from 3.6
to 3.8 as it is to move from 3.6.x to 3.6.y.

We were stuck on the RPM issue for a while, but I stopped caring. I
don’t trust the RPMs produced for 3.6 since they’re not from Best
Practical and their quality is unknown.

The real issue is managing all the CPAN modules, not maintaining RT.

Usually updating RHEL’s Perl breaks RT, but it is easy to fix if you
have a test system you perform all the upgrades on first.

There are too many features that we use in 3.8.x to make sticking to 3.6
make any sense.On 11/4/10 4:01 PM, Wes Modes wrote:

Dear Boss:

I strongly recommend going with the 3.6 version of RT. The install takes a few minutes, and it otherwise meets all the requirements of our project. Migration of old queues is simple. There is cost savings in the near and long-term.

There is no rpm of RT3.8 that works for RHEL (32 or 64 bit) and none seem to be forthcoming. Someday perhaps someone will put one together, but it doesn’t look like anytime soon.

I CAN do a manual install of RT3.8 using the Best Practical install scripts. It is not terribly hard. However, the long-term costs of this are large. The install scripts put all the binaries, configuration files, and libraries in the wrong places for RHEL/CentOS, and working outside the package manager means files could be clobbered at any time. On the other hand, the rpms for RT3.6 use the package manager and 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. The non-standard install using the scripts creates recurring costs in the future as the system is significantly more difficult to update and harder to maintain, like by a factor of 50 (five minutes compared to 4 hours).

Additionally, the cost of migration of old content from 3.6 to 3.8 is unknown.

Again, I will install either RT3.6 or RT3.8 but I need you to understand
and acknowledge the costs of the choice.

Wes

Thanks to Gary Greene for the info about his latest centos rpm build.

John Arends
jarends@illinois.edu
Network Analyst
College of ACES ITCS
University of Illinois at Urbana-Champaign

3

Hello,

I have recently installed RT 3.8.7 on CentOS 5 (main RHEL clone), after several previous upgrades. The rpm you mention did not fit
our requirements.

This is my own opinion : as you increase your Unix/Linux/RedHat skills, you will feel less concerned by such issues.

BTW : the Best Practical installation scripts install RT in /opt, which is a standard location for extra software, according to the
Filesystem Hierarchy Standard
http://www.pathname.com/fhs/

http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES

So their decision of installing RT in /opt is pretty compliant.

Besides, to me, maintaining the non-RedHat Perl modules is quite straightforward, using the Best Practical :

make testeps

make fixdeps

and of course, there is a slight burden, each time perl is updated by yum, I must install Scalar::Util from CPAN by hand again -
this has been painful the first time, now I am warned and it does not cost anything more on upgrades.

Regards
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

4

This is my own opinion : as you increase your Unix/Linux/RedHat skills, you will feel less concerned by such issues.

As you increase the number of systems you need to manage, you will feel more concerned by such issues.

A good package manager to manage all of your software is essential to configuration management on a large scale. We even go so far as to make internal packages of our own software to deploy to the servers – nothing is manually done, except for the one-off office server which does the file/mail serving.

As you note later in your message, you have to manually go in and fix up things when you upgrade other parts of your system. This is the job of your package manager. It does not scale to do this by hand.

5

I CAN do a manual install of RT3.8 using the Best Practical install
scripts. It is not terribly hard. However, the long-term costs of this

Hi Wes. One of the biggest problems here is often over-looked. When you
build the app yourself you are taking over management of security updates,
rather than relying on the distro maintainer to do it (but you should
always keep an eye on report of serious vulnerabilities anyway).

are large. The install scripts put all the binaries, configuration
files, and libraries in the wrong places for RHEL/CentOS, and working
outside the package manager means files could be clobbered at any time.

Package manager should completely avoid touching some parts of the file
system including /opt and /usr/local. This is deliberate to avoid exactly
this problem (custom apps being clobbered).

I always try to keep custom modifications to a minimum because of the
increased security overhead. If I have to build a custom app I will
normally try to put it on a dedicated virtual box so that any
customisations I have to do don’t effect other apps (but then I make
extensive use of virtualisation anyway).

Additionally, the cost of migration of old content from 3.6 to 3.8 is unknown.

And check your data throughly after the upgrade. More than once I’ve seen
upgrades appear to go successfully but have problems discovered later -
when it is too late to go back.

Cheers,

Rob

Email: robert@timetraveller.org Linux counter ID #16440
IRC: Solver (OFTC & Freenode)
Web: http://www.practicalsysadmin.com
Contributing member of Software in the Public Interest (http://spi-inc.org/)
Open Source: The revolution that silently changed the world

6

I CAN do a manual install of RT3.8 using the Best Practical install
scripts. It is not terribly hard. However, the long-term costs of
this are large. The install scripts put all the binaries,
configuration files, and libraries in the wrong places for RHEL/CentOS,
and working outside the package manager means files could be clobbered
at any time.

They are never clobbered with:

./configure --prefix=/opt/local

My /opt/local is more complicated, and I have a couple directories like this: ./builds/rt/rt-3.8.8 and ./Sources/rt/rt-3.8.8. In the latter directory I execute

./configure --prefix=/opt/local/builds/rt/rt-3.8

Then I softlink /opt/local/builds/rt/rt-3.8.8 to /opt/local/rt and run a script I wrote which symlinks everything under each subdirectory of /opt/local/builds/rt/rt-3.8.8 to /opt/local/bin, /opt/local/etc, et cetera. I end up with /opt/local/etc/RT_Config.pm → /opt/local/builds/rt/rt-3.8.8/etc/RT_Config.pm

Technically, when I need to migrate a package to a new version, the first steps (unpack and install) will not affect anything and I just change the symlinks and rerun my script. In fact, the reverse course is even easier than normal package managers, since I just restore the original symlinks and I am back to the old configuration.

I only do this for code for production use. I do not do this for any system libraries. Personally I was never comfortable with the idea of my Operating System deciding when to upgrade apache for me.

Currently, for RT, I have perl, postgresql, apache, mod_perl and rt installed this way. I get to use perl-5.12.2 as a bonus. This lets me use “say”, “given/when” and named captures in regular expressions, all new with 5.10.

Josh Narins
Director of Application Development
SeniorBridge
845 Third Ave
7th Floor
New York, NY 10022
Tel: (212) 994-6194
Mobile: (917) 488-6248
Fax: (212) 994-4260
jnarins@seniorbridge.com

SeniorBridge
Managing Complex Chronic Care
http://www.seniorbridge.com

SeniorBridge Statement of Confidentiality: The contents of this email message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. Any dissemination, distribution or copying of this email by an unintended or mistaken recipient is strictly prohibited. In said event, kindly reply to the sender and destroy all entries of this message and any attachments from your system. Thank you.

7

They are never clobbered with:

./configure --prefix=/opt/local

so now you need your own private copy of perl in /opt/local as well… else the package system may clobber your perl modules installed by hand too. It becomes a very tangled web when you have some stuff manually installed and some by packages, were the manual stuff is intermixed with the packages, like CPAN installation of modules.

8

They are never clobbered with:

./configure --prefix=/opt/local

so now you need your own private copy of perl in /opt/local as well… else the package system may clobber your perl modules installed by hand too. It becomes a very tangled web when you have some stuff manually installed and some by packages, were the manual stuff is intermixed with the packages, like CPAN installation of modules.

No, you can use the system perl and put the modules that you/RT needs
in the /opt/local area. We do that for many different packages already
to isolate them from auto-updates of vendor packages.

Cheers,
Ken

9

Wes,

I strongly recommend going with the 3.6 version of RT. The install takes a few minutes, and it otherwise meets all the requirements of our project. Migration of old queues is simple. There is cost savings in the near and long-term.

RT 3.6 is no longer being actively developed and receives only critical security fixes. If 3.6, meets your needs, by all means use it, though we’d not recommend it to a client who was paying for our help or advice at this point.

Please do be careful to ensure that you’re running 3.6.10, as all earlier releases are vulnerable to CVE 2009-3585.

I CAN do a manual install of RT3.8 using the Best Practical install scripts. It is not terribly hard. However, the long-term costs of this are large. The install scripts put all the binaries, configuration files, and libraries in the wrong places for RHEL/CentOS, and working outside the package manager means files could be clobbered at any time.

If you’d like RT to be installed into RedHat FHS locations, you should use

./confiure --enable-layout=RH

On the other hand, the rpms for RT3.6 use the package manager and 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. The non-standard install using the scripts creates recurring costs in the future as the system is significantly more difficult to update and harder to maintain, like by a factor of 50 (five minutes compared to 4 hours).

Indeed, the maintenance burdens of an RPM upgrade for 3.6 are
likely to be small as you’re not going to see any bugfix or feature
releases. Historically, the RPM installs of RT haven’t had much in the
way of cross-major-version upgradability, so if you decide later to come
up to 3.8 to get Dashboards (automated emailed reporting), reasonable
support for mail generated by a modern Exchange server, the refreshed
UI, built in iCal support, several years of bug fixes and performance
improvements or any of the other features in 3.8, it might be rather
more work than if you’d started with 3.8.

I do hear you about wanting a supported RPM.

Best,
Jesse

10

If you’d like RT to be installed into RedHat FHS locations, you should use

./confiure --enable-layout=RH

This is interesting, since I use CentOS (RedHat) and had absolutely no issue installing RT 3.8.8. What does the above option do differently than omitting it?

11

./confiure --enable-layout=RH

This is interesting, since I use CentOS (RedHat) and had absolutely no issue installing RT 3.8.8. What does the above option do differently than omitting it?

Have a look in config.layout in the source directory. It’s an affordance for package builders, mostly. Rather than defaulting to /opt/rt3 with RT’s directory layout, it installs things in a more “RedHatty” layout.

12

I bet Best Practical would produce RPMs for you if you paid them to.On Thu, Nov 4, 2010 at 5:01 PM, Wes Modes wmodes@ucsc.edu wrote:

Dear Boss:

I strongly recommend going with the 3.6 version of RT. The install takes a
few minutes, and it otherwise meets all the requirements of our project.
Migration of old queues is simple. There is cost savings in the near and
long-term.

There is no rpm of RT3.8 that works for RHEL (32 or 64 bit) and none seem
to be forthcoming. Someday perhaps someone will put one together, but it
doesn’t look like anytime soon.

I CAN do a manual install of RT3.8 using the Best Practical install
scripts. It is not terribly hard. However, the long-term costs of this are
large. The install scripts put all the binaries, configuration files, and
libraries in the wrong places for RHEL/CentOS, and working outside the
package manager means files could be clobbered at any time. On the other
hand, the rpms for RT3.6 use the package manager and 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. The non-standard install using the scripts
creates recurring costs in the future as the system is significantly more
difficult to update and harder to maintain, like by a factor of 50 (five
minutes compared to 4 hours).

Additionally, the cost of migration of old content from 3.6 to 3.8 is
unknown.

Again, I will install either RT3.6 or RT3.8 but I need you to understand
and acknowledge the costs of the choice.

Wes

Thanks to Gary Greene for the info about his latest centos rpm build.

13

If you search for “rt 3.8 spec file” you will find some spec files that
do work for fedora and other variants. It wasn’t too difficult to take
one of those and morph it for our custom use.

Biggest issue I had was taking the time to package up perl dependencies
as rpms to store in our repo long term. And after a few dot release
upgrades the work has paid off.

DallasOn Fri, 5 Nov 2010, Todd Chapman wrote:

I bet Best Practical would produce RPMs for you if you paid them to.

On Thu, Nov 4, 2010 at 5:01 PM, Wes Modes wmodes@ucsc.edu wrote:
Dear Boss:

  I strongly recommend going with the 3.6 version of RT.  The install takes a few minutes, and it otherwise meets all the requirements of
  our project.  Migration of old queues is simple.  There is cost savings in the near and long-term.

  There is no rpm of RT3.8 that works for RHEL (32 or 64 bit) and none seem to be forthcoming.  Someday perhaps someone will put one
  together, but it doesn't look like anytime soon.

  I CAN do a manual install of RT3.8 using the Best Practical install scripts.  It is not terribly hard.  However, the long-term costs of
  this are large.  The install scripts put all the binaries, configuration files, and libraries in the wrong places for RHEL/CentOS, and
  working outside the package manager means files could be clobbered at any time.  On the other hand, the rpms for RT3.6 use the package
  manager and 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.  The non-standard install using the scripts creates recurring costs in the future as the system is significantly more difficult
  to update and harder to maintain, like by a factor of 50 (five minutes compared to 4 hours).

  Additionally, the cost of migration of old content from 3.6 to 3.8 is unknown.

  Again, I will install either RT3.6 or RT3.8 but I need you to understand
  and acknowledge the costs of the choice.

  Wes


  Thanks to Gary Greene for the info about his latest centos rpm build.
14

Agreed. One sysadmin managing a score of mission-critical servers and a
half dozen projects does not allow much time for one-offs and special
cases. Over my 25 years of sysadmin experience, I’ve learned that the
most efficient thing I can do as a sysadmin is to allow the package
management system to do much of my work for me.

There are legacy systems I inherited with their spaghetti installations
of all special-case software and manual hack builds and their touchy
interdependencies that I am still afraid to do much more than basic
security updates of the OS.

WesOn 11/5/2010 5:11 AM, Vick Khera wrote:

On Nov 5, 2010, at 5:26 AM, Robert Grasso wrote:

This is my own opinion : as you increase your Unix/Linux/RedHat skills, you will feel less concerned by such issues.
As you increase the number of systems you need to manage, you will feel more concerned by such issues.

A good package manager to manage all of your software is essential to configuration management on a large scale. We even go so far as to make internal packages of our own software to deploy to the servers – nothing is manually done, except for the one-off office server which does the file/mail serving.

As you note later in your message, you have to manually go in and fix up things when you upgrade other parts of your system. This is the job of your package manager. It does not scale to do this by hand.

15

Get yourself a copy of cpan2rpm. It simplifies creating the specs from the
ground up greatly.On 5/11/10 12:49 PM, “Dallas Wisehaupt” dallas@craigslist.org wrote:

If you search for “rt 3.8 spec file” you will find some spec files that
do work for fedora and other variants. It wasn’t too difficult to take
one of those and morph it for our custom use.

Biggest issue I had was taking the time to package up perl dependencies
as rpms to store in our repo long term. And after a few dot release
upgrades the work has paid off.

Dallas

On Fri, 5 Nov 2010, Todd Chapman wrote:

I bet Best Practical would produce RPMs for you if you paid them to.

On Thu, Nov 4, 2010 at 5:01 PM, Wes Modes wmodes@ucsc.edu wrote:
Dear Boss:

  I strongly recommend going with the 3.6 version of RT.  The install

takes a few minutes, and it otherwise meets all the requirements of
our project. Migration of old queues is simple. There is cost savings
in the near and long-term.

  There is no rpm of RT3.8 that works for RHEL (32 or 64 bit) and none

seem to be forthcoming. Someday perhaps someone will put one
together, but it doesn’t look like anytime soon.

  I CAN do a manual install of RT3.8 using the Best Practical install

scripts. It is not terribly hard. However, the long-term costs of
this are large. The install scripts put all the binaries,
configuration files, and libraries in the wrong places for RHEL/CentOS, and
working outside the package manager means files could be clobbered at
any time. On the other hand, the rpms for RT3.6 use the package
manager and 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. The non-standard install using the scripts creates
recurring costs in the future as the system is significantly more difficult
to update and harder to maintain, like by a factor of 50 (five minutes
compared to 4 hours).

  Additionally, the cost of migration of old content from 3.6 to 3.8 is

unknown.

  Again, I will install either RT3.6 or RT3.8 but I need you to

understand
and acknowledge the costs of the choice.

  Wes


  Thanks to Gary Greene for the info about his latest centos rpm build.

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