RHEL5 Install Multiple Instances of Tomcat using only RPMs
 

Hi all,

We would like to be able to deploy multiple instances of Tomcat on our servers.

However, the standard RedHat RPM is not "relocatable" which means it can't be installed in a different directory, so using --prefix does not work.

However - I've tried using --relocate which works to a certain degree but falls over when you try and install a 2nd instance of tomcat in another separate directory as RPM complains quite rightly that it is already installed...

This is my dilemma. We want to use RPMs as we want to be able to patch the tomcats easily during our scheduled patching processes. But we also want to be able to deploy multiple instances of Tomcats using RPMs to accommodate this without resorting to manual binary installations which you can't update using up2date...

So my question is - taking the RPMs and the installation issues out of the equation:

Is it possible to install multiple instances of Tomcat and have them be "updateable" during the up2date patching/update process?

Many thanks in advance,

BinkyBong

Doesn't sound to me like anything a standard solution could offer. Besides if you install it multiple times you'll still have clashes with defaults like SysV initscripts. However, if you have a dev box and testbed it would be *dead easy* to create consistently named packages like say tomcat_instance01, tomcat_instance02, tomcat_instance03 that install in default locations and without tainting other installs by rebuilding just one tomcat .src.rpm and making use of the %{name} tag is .spec files. Of course for updates (from your own repo) you should wash, rinse and repeat.

Hi unSpawn,

The problem we have is that we have *lots* of Red Hat boxes, all of varying architectures, some 32bit, some 64bit, different CPUs etc...

We have binary installs of Tomcat all over the place which is a nightmare to maintain, so a relocatable RPM solution that's updateable would be an ideal solution when it comes to our quarterly patching of servers.

I'm in the process of contacting RedHat via our suppliers but it's taking a *long* time as I have to go through several levels of people just to raise this query :(

Multiple tomcat installs are not an uncommon configuration for most organisations and I'm suprised there's not more info on google about this :( Lots of info about installing multiple instances using binary packages but none on using RPM installs :(

Many thanks for the response, just need to find a way of doing this without resorting back to binary installs...

Cheers,

andy

...using one .src.rpm that's just down to using %arch 'n stuff where necessary in the build process. And build processes can be automated.


I think it's unlikely relocation will solve it.

Hi unSpawn,

Please excuse the n00b nature of the question ... but I am new to all of this - how would I automate the build process for multiple architectures? Is there any decent documentation, tutorials etc that can help?

With all the extra management overhead involved in building from source RPMs I'm beginning to wonder whether if going down this route is a such a good idea after all...

There must be some instances out there where Enterprise users have multiple instances of Tomcat and need to keep them (easily) "updateable"...

Thanks for all your replies so far

Cheers,

BinkyBong

Then tell me how you would compare that to "all the extra management overhead involved" building from source and your earlier "easy update" requirements?

Apologies for not replying earlier, I've been on holiday.

I'll define "Extra management overhead":

1. downloading latest source RPMs
2. changing flags for different CPU architectures
3. changing the flags to make the RPMs relocatable
4. manually deploying separate instances of the RPM to different folders
5. doing this every quarter across several machines, different architectures, different geographical locations

This is what I mean by "Extra management overhead".

Definition of "easy update":

1. use up2date

If you think you can fully automate the "extra management overhead" then I'm more than happy to hear from you for I am a mere beginner in the administration of enterprise Red Hat installations.

I've posted in good faith asking for advice on this particular issue and if I've inadvertently offended you, please accepted my humblest apologies as I'm sensing some annoyance in your replies.

Best Regards

Binky