Help -- weird problems with RT data migration

heya,

I have a problem which the users list is unlikely to be able to

help with.

We have an RT 3.0.2 installation on Redhat Linux 7.3, and we are

trying to migrate it up to 3.0.6 – which, due to perl 5.8.0
requirement, kinda sorta entails an OS upgrade. Yes, we could
custom-build, but we are trying to make do with stock OS installations,
as it makes things much easier.

So. I build an RHL 9 system, and stuck RT 3.0.5 onto it (so yes,

Mason is running under Apache2 and mod_perl2; it’s running fine). So
far, so good. Now we are trying to migrate the data from the old
installation, so that we could use the RHL9 system as a temporary
stand-in during the OS upgrade on the primary RT server.

So I played around a bit, and discovered that I can migrate the

data pretty safely, as long as I don’t copy over the contents of the
‘sessions’ and ‘ACLs’ tables (does anyone know why ACL table can’t
be copied, BTW).

One problem, though -- when I click on 'home' and then click on

the queue, much of the time, I get an error message (attached). Now if
Go make a new search and build it up to be equivalent (given queue, new
or open status), then I can go back to Home and click on that queue, and
it will display correctly.

I thought it may be a session caching issue, so I tried clearing

out the session cache, and re-doing the login/queue access; but there
was no rhyme or reason. Sometimes clearing out the sessions table causes
the next queue view to fail, and sometimes it doesn’t. This happens with
a clean database as well – whether it’s before or after I migrated the
data, it makes no difference.

Unfortunately, there are some further complicating factors,

namely, the RTFM installation. i don’t think it should be interfering,
but it could be.

I realize that this ends up being a very loaded question, with

multiplicity of factors potentially interacting, but I am hoping that
someone here knows what the problem is that causes certain searches to
fail under certain conditions. To recount, the questionable factors are:

  1. Apache2 + mod_perl2

  2. RTFM

    Does anyone have any ideas? please?..

| Victor Danilchenko | Students nowadays, complaining they only get |
| danilche@cs.umass.edu | 10MBs of disk space! In my day we were lucky |
| CSCF | 5-4231 | if we had one file, and that was /dev/null. |

error.html (13.5 KB)

heya,

I have a problem which the users list is unlikely to be able to
help with.

Wrong. It’s been discussed on the users list repeatedly. And a solution
has even been posted. You need to upgrade Storable to the latest version
from CPAN.

We have an RT 3.0.2 installation on Redhat Linux 7.3, and we are
trying to migrate it up to 3.0.6 – which, due to perl 5.8.0
requirement, kinda sorta entails an OS upgrade. Yes, we could
custom-build, but we are trying to make do with stock OS installations,
as it makes things much easier.

So. I build an RHL 9 system, and stuck RT 3.0.5 onto it (so yes,
Mason is running under Apache2 and mod_perl2; it’s running fine). So
far, so good. Now we are trying to migrate the data from the old
installation, so that we could use the RHL9 system as a temporary
stand-in during the OS upgrade on the primary RT server.

So I played around a bit, and discovered that I can migrate the
data pretty safely, as long as I don’t copy over the contents of the
‘sessions’ and ‘ACLs’ tables (does anyone know why ACL table can’t
be copied, BTW).

One problem, though – when I click on ‘home’ and then click on
the queue, much of the time, I get an error message (attached). Now if
Go make a new search and build it up to be equivalent (given queue, new
or open status), then I can go back to Home and click on that queue, and
it will display correctly.

I thought it may be a session caching issue, so I tried clearing
out the session cache, and re-doing the login/queue access; but there
was no rhyme or reason. Sometimes clearing out the sessions table causes
the next queue view to fail, and sometimes it doesn’t. This happens with
a clean database as well – whether it’s before or after I migrated the
data, it makes no difference.

Unfortunately, there are some further complicating factors,
namely, the RTFM installation. i don’t think it should be interfering,
but it could be.

I realize that this ends up being a very loaded question, with
multiplicity of factors potentially interacting, but I am hoping that
someone here knows what the problem is that causes certain searches to
fail under certain conditions. To recount, the questionable factors are:

  1. Apache2 + mod_perl2
  2. RTFM

Does anyone have any ideas? please?..


| Victor Danilchenko | Students nowadays, complaining they only get |
| danilche@cs.umass.edu | 10MBs of disk space! In my day we were lucky |
| CSCF | 5-4231 | if we had one file, and that was /dev/null. |

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

heya,

I have a problem which the users list is unlikely to be able to
help with.

Wrong. It’s been discussed on the users list repeatedly. And a solution
has even been posted. You need to upgrade Storable to the latest version
from CPAN.

While I am highly embarrassed about not having searched for the

answer properly, I am also highly happy with the fact that a potential
show-stopper turned out to have such a simple solution. Thank you very
much – and sorry – in the same breath.

As an aside, have there been thoughts of creating a generalized

infrastructure to permit automatically tagging new tickets with custom
fields’ values? We have had such a need (to tag an incoming ticket with
a ‘research group’ field of its requestor), and I have solved it by
writing a combination of a simple query in the ticket creation code (so
I had to customize the source, alas), and a pre-processing filter that
gets called from .procmailrc.
I was wondering if there were thoughts of making a
general-purpose solution for this sort of problem; and if there were, I
would be happy to contribute whatever I have done towards that cause.

| Victor Danilchenko | Students nowadays, complaining they only get |
| danilche@cs.umass.edu | 10MBs of disk space! In my day we were lucky |
| CSCF | 5-4231 | if we had one file, and that was /dev/null. |