Hello,
I am thinking of migrating an RT instance from a machine running RT
3.8.1 to a machine running 3.6, but I’m not sure if this is even
possible? Is it possible to move the MySQL DBs straight across from 3.8
to 3.6 without any issues? If there are any tweaks to be done, are they
major?
I am trying to use a Redhat machine which only has the official EPEL RT
packages which are currently only at 3.6.
If I can’t move the DBs across, is there perhaps a way I can perform a
default install on 3.6, then export / import the old (3.8) data in?
Thanks for any insight,
Khusro
I am thinking of migrating an RT instance from a machine running RT
3.8.1 to a machine running 3.6, but I’m not sure if this is even
possible? Is it possible to move the MySQL DBs straight across from
3.8 to 3.6 without any issues? If there are any tweaks to be done,
are they major?
There are some pretty major schema differences, in particular
encodings. I can’t recommend against this enough.
I am trying to use a Redhat machine which only has the official EPEL
RT packages which are currently only at 3.6.
If I can’t move the DBs across, is there perhaps a way I can perform
a default install on 3.6, then export / import the old (3.8) data
in?
Not really
-kevin
RedHat is god, ftw!On 12/13/10 10:59, Kevin Falcone wrote:
On Mon, Dec 13, 2010 at 01:50:44PM +0000, Khusro Jaleel wrote:
I am thinking of migrating an RT instance from a machine running RT
3.8.1 to a machine running 3.6, but I’m not sure if this is even
possible? Is it possible to move the MySQL DBs straight across from
3.8 to 3.6 without any issues? If there are any tweaks to be done,
are they major?
There are some pretty major schema differences, in particular
encodings. I can’t recommend against this enough.
I am trying to use a Redhat machine which only has the official EPEL
RT packages which are currently only at 3.6.
If I can’t move the DBs across, is there perhaps a way I can perform
a default install on 3.6, then export / import the old (3.8) data
in?
Not really
-kevin
I don’t understand people’s desire to use 3rd party RT packages. You’re
then at the mercy of the packager, and it makes it harder to fix
problems and apply upgrades when new RT releases come out.
It’s better to learn the internals of RT and deal with its
idiosyncrasies than to use a package you find somewhere. They’re almost
always extremely outdated, and require quite a bit of configuration. My
RT setup has enough customizations that I keep track of separately that
fighting with someone’s RPM package would end up costing me far more
time that it’d save.
Don’t get me wrong, I’d LOVE LOVE *LOVE it if Best Practical
official had RPMs available and would use them in a heartbeat, it would
make my life easier, and make me a happier person as well as make RT
easier to maintain, but 3rd party RPMs are annoying. Don’t use them,
just install RT per the instructions.
3.8 is such an improvement over 3.6 if anyone made me go back I’d be
very cranky about it.On 12/13/10 10:06 AM, Jacob Ritorto wrote:
RedHat is god, ftw!
On 12/13/10 10:59, Kevin Falcone wrote:
On Mon, Dec 13, 2010 at 01:50:44PM +0000, Khusro Jaleel wrote:
I am thinking of migrating an RT instance from a machine running RT
3.8.1 to a machine running 3.6, but I’m not sure if this is even
possible? Is it possible to move the MySQL DBs straight across from
3.8 to 3.6 without any issues? If there are any tweaks to be done,
are they major?
There are some pretty major schema differences, in particular
encodings. I can’t recommend against this enough.
I am trying to use a Redhat machine which only has the official EPEL
RT packages which are currently only at 3.6.
If I can’t move the DBs across, is there perhaps a way I can perform
a default install on 3.6, then export / import the old (3.8) data
in?
Not really
-kevin
John Arends
jarends@illinois.edu
Network Analyst
College of ACES ITCS
University of Illinois at Urbana-Champaign
I don’t understand people’s desire to use 3rd party RT packages.
You’re then at the mercy of the packager, and it makes it harder to
fix problems and apply upgrades when new RT releases come out.
It’s better to learn the internals of RT and deal with its
idiosyncrasies than to use a package you find somewhere. They’re
almost always extremely outdated, and require quite a bit of
configuration. My RT setup has enough customizations that I keep track
of separately that fighting with someone’s RPM package would end up
costing me far more time that it’d save.
Don’t get me wrong, I’d LOVE LOVE *LOVE it if Best Practical
official had RPMs available and would use them in a heartbeat, it
would make my life easier, and make me a happier person as well as
make RT easier to maintain, but 3rd party RPMs are annoying. Don’t use
them, just install RT per the instructions.
3.8 is such an improvement over 3.6 if anyone made me go back I’d be
very cranky about it.
I’m stuck between a rock and a hard place, then. The Redhat people are
telling me to avoid CPAN like the plague, and most people [1] seem to
have accomplished the install on CentOS systems using a combination of
packages + CPAN, which is something else that is NOT recommended to do.
I wish Best Practical did come up with their own packages, especially
for Redhat, it would make things so much easier.
[1] - http://requesttracker.wikia.com/wiki/CentOS5InstallPlusSome
CPAN makes me cranky, but trying to package all the perl modules as RPMs
makes me crankier. It’s like wrapping one packaging system around
another one, and fighting with both of them.
The reality is, every time RHEL updates perl, RT will break. I solve
this by having an identical test system. I apply the updates, see what
breaks, and then reinstall the perl modules in question using CPAN.
Once I figure this out, I do the same process on the production RT
system during a maintenance window. It actually works out pretty well
now that I am used to this, but it is less than ideal.
RHEL is a major platform, and I’d love it if BestPractical supported it
in some official way so we don’t have these kinds of problems we have to
work around.
Still, I love RT and praise it to anyone who will listen.On 12/13/10 11:04 AM, Khusro Jaleel wrote:
I’m stuck between a rock and a hard place, then. The Redhat people are
telling me to avoid CPAN like the plague, and most people [1] seem to
have accomplished the install on CentOS systems using a combination of
packages + CPAN, which is something else that is NOT recommended to do.
I wish Best Practical did come up with their own packages, especially
for Redhat, it would make things so much easier.
[1] - http://requesttracker.wikia.com/wiki/CentOS5InstallPlusSome
CPAN makes me cranky, but trying to package all the perl modules as RPMs
makes me crankier. It’s like wrapping one packaging system around another
one, and fighting with both of them.
The reality is, every time RHEL updates perl, RT will break. I solve this
by having an identical test system. I apply the updates, see what breaks,
and then reinstall the perl modules in question using CPAN.
Once I figure this out, I do the same process on the production RT system
during a maintenance window. It actually works out pretty well now that I
am used to this, but it is less than ideal.
RHEL is a major platform, and I’d love it if BestPractical supported it in
some official way so we don’t have these kinds of problems we have to work
around.
Still, I love RT and praise it to anyone who will listen.
I’m stuck between a rock and a hard place, then. The Redhat people are
telling me to avoid CPAN like the plague, and most people [1] seem to
have accomplished the install on CentOS systems using a combination of
packages + CPAN, which is something else that is NOT recommended to do.
I wish Best Practical did come up with their own packages, especially
for Redhat, it would make things so much easier.
[1] - http://requesttracker.wikia.com/wiki/CentOS5InstallPlusSome
It is probably better to remove perl from the list of packages
that are automatically updated and apply those manually, if they
are needed.
Cheers,
Ken
RHEL is a major platform, and I’d love it if BestPractical supported
it in some official way so we don’t have these kinds of problems we
have to work around.
I try pretty hard not to push the commercial side of the business on the
mailing lists, but BPS is a business and we tend to spend our time on
things that are most likely to benefit the folks who keep a roof over
our heads and food on the table. We tend to spend the most effort on
the things that our customers use and need. The best way to help us have
the resources to focus on official RPMs is to buy a support contract.
Best,
Jesse
CPAN makes me cranky, but trying to package all the perl modules as RPMs
makes me crankier. It’s like wrapping one packaging system around
another
one, and fighting with both of them.
I’ve done this quite successfully. I’ve got RH distributed perl + packages plus those that I’ve manually packaged for RT to operate correctly living side by side.
The reality is, every time RHEL updates perl, RT will break. I solve
this
by having an identical test system. I apply the updates, see what
breaks,
and then reinstall the perl modules in question using CPAN.
I’ve not had a RH update break my RT system in over a year, and that was because one of my packages was badly done.
You just have to figure out which packages are conflicting badly (CGI, Encode and File::Temp for instance) and make sure it’s using vendor_perl instead of site_perl installation locations and sometimes relocate some man pages to avoid conflicts.
I am used to this, but it is less than ideal.
RHEL is a major platform, and I’d love it if BestPractical supported it
in some official way so we don’t have these kinds of problems we have to
work around.
Still, I love RT and praise it to anyone who will listen.
Agreed 
Stuart
CPAN makes me cranky, but trying to package all the perl modules as RPMs
makes me crankier. It’s like wrapping one packaging system around
another one, and fighting with both of them.
This is why I use cpan2rpm every time.
The reality is, every time RHEL updates perl, RT will break. I solve
this by having an identical test system. I apply the updates, see what
breaks, and then reinstall the perl modules in question using CPAN.
This ALSO can be avoided, if you know how to package your cpan2rpm packages
in site instead of vendor locations. This allows that NONE of the issues
that are endemic of RHEL’s busted Perl packaging to cause long term
headaches for me.
Once I figure this out, I do the same process on the production RT
system during a maintenance window. It actually works out pretty well
now that I am used to this, but it is less than ideal.
RHEL is a major platform, and I’d love it if BestPractical supported it
in some official way so we don’t have these kinds of problems we have to
work around.
Still, I love RT and praise it to anyone who will listen.
I’m stuck between a rock and a hard place, then. The Redhat people are
telling me to avoid CPAN like the plague, and most people [1] seem to
have accomplished the install on CentOS systems using a combination of
packages + CPAN, which is something else that is NOT recommended to do.
I wish Best Practical did come up with their own packages, especially
for Redhat, it would make things so much easier.
[1] - http://requesttracker.wikia.com/wiki/CentOS5InstallPlusSome
Gary L. Greene, Jr.
IT Operations
Minerva Networks, Inc.
Cell: (650) 704-6633
Office: (408) 240-1239
CPAN makes me cranky, but trying to package all the perl modules as RPMs
makes me crankier. It’s like wrapping one packaging system around
another one, and fighting with both of them.
This is why I use cpan2rpm every time.
The reality is, every time RHEL updates perl, RT will break. I solve
this by having an identical test system. I apply the updates, see what
breaks, and then reinstall the perl modules in question using CPAN.
This ALSO can be avoided, if you know how to package your cpan2rpm packages
in site instead of vendor locations. This allows that NONE of the issues
that are endemic of RHEL’s busted Perl packaging to cause long term
headaches for me.
Do you know of a guide that explains how to do this?
I’ve been working on one for SuSE on the wiki. I’m still a little behind on
getting it all done.On 13/12/10 4:14 PM, “John Arends” jarends@illinois.edu wrote:
On Dec 13, 2010, at 6:06 PM, Gary Greene wrote:
On 13/12/10 9:43 AM, “John Arends” jarends@illinois.edu wrote:
CPAN makes me cranky, but trying to package all the perl modules as RPMs
makes me crankier. It’s like wrapping one packaging system around
another one, and fighting with both of them.
This is why I use cpan2rpm every time.
The reality is, every time RHEL updates perl, RT will break. I solve
this by having an identical test system. I apply the updates, see what
breaks, and then reinstall the perl modules in question using CPAN.
This ALSO can be avoided, if you know how to package your cpan2rpm packages
in site instead of vendor locations. This allows that NONE of the issues
that are endemic of RHEL’s busted Perl packaging to cause long term
headaches for me.
Do you know of a guide that explains how to do this?
Gary L. Greene, Jr.
IT Operations
Minerva Networks, Inc.
Cell: (650) 704-6633
Office: (408) 240-1239
The OpenSuSE build service has a lot of good information about using the
Build Service for packaging perl modules, see
openSUSE:Packaging Perl - openSUSE Wiki and
http://old-en.opensuse.org/Packaging/Perl. The can easily be adopted for
building locally.
All the perl packages needed for a default RT installation are available
in the perl development language repo,
/repositories/devel:/languages:/perl - openSUSE Download. I ran
into missing packages for RTIR but was able to build rpms for them using
the above information. Additionally, I imported them into my personal
repository with the goal of having them included in the perl repo but
ran into a couple minor issues which I haven’t had time to address. This
are build service glitches I’m not sure how to overcome and have nothing
to do with the packages themselves.
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 John Arends
Sent: Monday, December 13, 2010 7:14 PM
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Possible to downgrade DB from 3.8 to 3.6?
CPAN makes me cranky, but trying to package all the perl modules as
RPMs
makes me crankier. It’s like wrapping one packaging system around
another one, and fighting with both of them.
This is why I use cpan2rpm every time.
The reality is, every time RHEL updates perl, RT will break. I
solve
this by having an identical test system. I apply the updates, see
what
breaks, and then reinstall the perl modules in question using CPAN.
This ALSO can be avoided, if you know how to package your cpan2rpm
packages
in site instead of vendor locations. This allows that NONE of the
issues
that are endemic of RHEL’s busted Perl packaging to cause long term
headaches for me.
Do you know of a guide that explains how to do this?
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.