We’ve made multiple attempts to install RT on a Cloud server (Centos 5.5) hosted at Rackspace with no success. Our plan is two fold: move our current installation from our own internal server to the hosted one, and also upgrade from 3.6.3 to the latest stable version in the process.
Any ideas on the process in broad strokes or step-by-step would be greatly appreciated.
Ben McLendon
I.T. Director
Barnes Healthcare Services
We’ve made multiple attempts to install RT on a Cloud server (Centos 5.5) hosted at Rackspace with no success. Our plan is two fold: move our current installation from our own internal server to the hosted one, and also upgrade from 3.6.3 to the latest stable version in the process.
Any ideas on the process in broad strokes or step-by-step would be greatly appreciated.
It would be useful if you could give some idea of where you fell down
so that we can provide some specific pointers. In general, the plan
would be like something like:
You’d want to test that whole migration cycle before trying it for real,
ensuring that you don’t accidentally send out mail to real users whilst
doing that stage of testing.
This assumes that no local modifications have been made to the old
system.
Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford
signature.asc (197 Bytes)
Ben,
In over 40 years in this business, I can hoestly say that the best way to
implement any plan is to “keep it simple”. My advice is to upgrade first,
make sure it is working the way you expect and THEN try moving it.
Otherwise, you run the VERY REAL RISK of complicating the problems and
causes. You’ll spend 3 times as much time trying to figure whether the cause
of a problem is the cloud server or the install.
Good Luck! I’d love to hear the success story.
Kenn
LBNLOn Tue, Jul 27, 2010 at 7:56 AM, Ben McLendon benm@barneshc.com wrote:
We’ve made multiple attempts to install RT on a Cloud server (Centos 5.5)
hosted at Rackspace with no success. Our plan is two fold: move our current
installation from our own internal server to the hosted one, and also
upgrade from 3.6.3 to the latest stable version in the process.Any ideas on the process in broad strokes or step-by-step would be greatly
appreciated.Ben McLendon
I.T. Director
Barnes Healthcare ServicesDiscover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Good news!
Using the procedure located HEREhttp://www.ptitov.net/2008/07/request-tracker-installation-o.html I was successful in getting a bare install of RT 3.8.8 up and running on the Rackspace CloudServer.
Doing a bit of testing/tweaking now… I’ll get a image of the build so far and then try the data migration.
-=BEN=-On Jul 27, 2010, at 11:05 AM, Dominic Hargreaves wrote:
On Tue, Jul 27, 2010 at 09:56:28AM -0500, Ben McLendon wrote:
We’ve made multiple attempts to install RT on a Cloud server (Centos 5.5) hosted at Rackspace with no success. Our plan is two fold: move our current installation from our own internal server to the hosted one, and also upgrade from 3.6.3 to the latest stable version in the process.
Any ideas on the process in broad strokes or step-by-step would be greatly appreciated.
It would be useful if you could give some idea of where you fell down
so that we can provide some specific pointers. In general, the plan
would be like something like:
You’d want to test that whole migration cycle before trying it for real,
ensuring that you don’t accidentally send out mail to real users whilst
doing that stage of testing.
This assumes that no local modifications have been made to the old
system.
Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford
As Dominic and Kenneth pointed out, the planning should be simple but
carefully crafted.
Basically, having a new RT server installation, configured, tested and
running and a DB dump / restore will do the trick.
I only missed tips regarding special attention to the DNS / MX part of the
solution.
As you will be changing RT servers, it is important to include the MX
changes in the appropriate steps of the plan, both for testing and also for
entering in production. You may receive mail that can open new tickets
during testing, and you will have extra work to fix the mess or else opt -
if you can - to loose/ignore those tickets.
[]'s,
Alex
As Dominic and Kenneth pointed out, the planning should be simple but
carefully crafted.
Basically, having a new RT server installation, configured, tested and
running and a DB dump / restore will do the trick.
I only missed tips regarding special attention to the DNS / MX part of the
solution.
As you will be changing RT servers, it is important to include the MX
changes in the appropriate steps of the plan, both for testing and also for
entering in production. You may receive mail that can open new tickets
during testing, and you will have extra work to fix the mess or else opt -
if you can - to loose/ignore those tickets.
with qmail we have it setup like this
#cat ~alias/.qmail-help
|/opt/rt3/bin/rt-mailgate --queue help --action correspond --url
https://rt.example.net 2>/dev/null || exit 111
so its a temporary failure signal to the sender’s relay/smtp server.
that means the mail won’t be lost, it will re-attempt at a later time
automatically
this will allow you to keep the RT down for long time.
's,
AlexDiscover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?