Help... moved RT and now lost message bodies!

The following relates to rt 1.0.7.

I have to move RT from machine A to B… I did a fresh install and then
overwrote the new mysql database with the original… And I’ve now lost
access to the message bodies…

I’ve also copied the old transactions… Help… users are screaming at
me…

T�o de Hesselle, | Diplomacy is about surviving until
Unix Systems Administrator | the next century. Politics is
| about surviving until Friday
University of Technology, Sydney | afternoon. – Yes, Minister

I have to move RT from machine A to B… I did a fresh install and then
overwrote the new mysql database with the original… And I’ve now lost
access to the message bodies…

I’ve also copied the old transactions… Help… users are screaming at
me…

When I moved from one machine to another, I did a mysqldump out, built
the new RT 1.07 install, then piped in the dump file after excising the
bits that create tables and whatnot. It worked like a dream.

That probably doesn’t help you very much, but it was how I went about
the process.

Karel P Kerezman - IS Admin, Entercom Portland - http://zero.kgon.com
Can’t dial 911 because he can’t find ‘11’ on the phone.
From the Canonical Fulldeckisms List: http://www.herbison.com/canon

| I’ve also copied the old transactions… Help… users are screaming at
| me…
±–>8

Are they in the same place relative to the RT base directory?
Does etc/config.pm have the same location listed?
Does the web server have read (and write) permissions on the transactions
directory and its contents?

brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
electrical and computer engineering KF8NH
carnegie mellon university [“better check the oblivious first” -ke6sls]

“Brandon S. Allbery KF8NH” wrote:

±----
| I’ve also copied the old transactions… Help… users are screaming at
| me…
±–>8

Are they in the same place relative to the RT base directory?
Does etc/config.pm have the same location listed?

Yes. I’ve also made a symlink, so the old full path would still work.

Does the web server have read (and write) permissions on the transactions
directory and its contents?

Yes. And then to be double sure, I did:

cd /usr/local/rt1/transactions

chmod -R 777 .
chown -R rt:rt .

Oddly, some of them appear to be working now… in some cases one out of 5
transactions are appearing, whilst the others (in the same ticket!) are
not.

There doesn’t seem to be a correlation between tickets before the move and
tickets after the move, which makes it all the more frustrating.

T�o de Hesselle, | Diplomacy is about surviving until
Unix Systems Administrator | the next century. Politics is
| about surviving until Friday
University of Technology, Sydney | afternoon. – Yes, Minister

| Oddly, some of them appear to be working now… in some cases one out of 5
| transactions are appearing, whilst the others (in the same ticket!) are
| not.
|
| There doesn’t seem to be a correlation between tickets before the move and
| tickets after the move, which makes it all the more frustrating.
±–>8

That sounds like whatever you did to transfer the database generated new
autoincrement sequence numbers — which would pretty well break things
because the ones in each_req and transactions are what tie everything
together.

I’d re-dump the old RT installation with mysqldump and reload it.

brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
electrical and computer engineering KF8NH
carnegie mellon university [“better check the oblivious first” -ke6sls]

“Brandon S. Allbery KF8NH” wrote:

±----
| Oddly, some of them appear to be working now… in some cases one out of 5
| transactions are appearing, whilst the others (in the same ticket!) are
| not.
|
| There doesn’t seem to be a correlation between tickets before the move and
| tickets after the move, which makes it all the more frustrating.
±–>8

You might think so, but new requests are being generated with the expected
serial numbers, and the new files are being created in the proper place
within the transaction heirachy… it’s just that they (the message
bodies) aren’t showing up on the webpage.

Does RT Log anywhere apart from the apache erorr log (which has nothing
interesting in it)?

T�o de Hesselle, | Diplomacy is about surviving until
Unix Systems Administrator | the next century. Politics is
| about surviving until Friday
University of Technology, Sydney | afternoon. – Yes, Minister

| You might think so, but new requests are being generated with the expected
| serial numbers, and the new files are being created in the proper place
| within the transaction heirachy… it’s just that they (the message
| bodies) aren’t showing up on the webpage.
±–>8

Weird. Make sure the webserver is actually running as user rt, maybe?

| Does RT Log anywhere apart from the apache erorr log (which has nothing
| interesting in it)?
±–>8

Not by default; I installed Log::Stderr and added an invocation of it in
rtmux.pl in our copy.

brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
electrical and computer engineering KF8NH
carnegie mellon university [“better check the oblivious first” -ke6sls]

Teo de Hesselle wrote:

The following relates to rt 1.0.7.

I have to move RT from machine A to B… I did a fresh install and then
overwrote the new mysql database with the original… And I’ve now lost
access to the message bodies…

I’ve also copied the old transactions… Help… users are screaming at
me…

More exciting information:

I shut the rt interface down, so I can play without affecting the users.

Now… I copied mysql/var/rt to mysql/var/rt-broke

then went into mysql and did a DROP DATABASE rt;

Next… moved /usr/local/rt1 to usr/local/rt1-broke

Changed the uid from 42 to 60001, to match the previous system it was
installed on.

“make install” from source.

The new database behaves exactly the same as the old… though I tried
creating/commenting from the web interface, and that works fine (the text
is displayed)… otherwise, the text is gone.

Now… there is no trace of the ‘old’ data on the system whatsoever… but
the behavior is still there.

Any ideas?

T�o de Hesselle, | Diplomacy is about surviving until
Unix Systems Administrator | the next century. Politics is
| about surviving until Friday
University of Technology, Sydney | afternoon. – Yes, Minister

You might think so, but new requests are being generated with the expected
serial numbers, and the new files are being created in the proper place
within the transaction heirachy… it’s just that they (the message
bodies) aren’t showing up on the webpage.

Is it just imported messages which aren’t displaying, or are new messages affected too? If so, before reimporting anything, recreate the new database as per a fresh install, and check that it works okay without any imported messages.

Does RT Log anywhere apart from the apache erorr log (which has nothing
interesting in it)?
Not that I know of. Logging has never been a strong suit.

Feargal Reilly,
Systems Administrator,
The CIA.

Jesse wrote:

is the timezone on the two systems set the same?

Yes. Both are set to TZ=Australia/NSW in /etc/default/init (it’s solaris).

However as I’ve found that I can’t get a default frelling install to
happen, I longer think this is an import problem… how I failed to notice
before, I don’t know…

T�o de Hesselle, | Diplomacy is about surviving until
Unix Systems Administrator | the next century. Politics is
| about surviving until Friday
University of Technology, Sydney | afternoon. – Yes, Minister

Jesse wrote:

is the timezone on the two systems set the same?

Okay… you’ve obviously been here before… when I use the web, it
creates it using yesterday’s date, and displays fine. If i move Jul/6/* to
Jul/5/*, they display fine also.

Now I just have to work out where this incorrect timezone info is coming
from…

What is the difference in the method used by the web and the mailgate?

T�o de Hesselle, | Diplomacy is about surviving until
Unix Systems Administrator | the next century. Politics is
| about surviving until Friday
University of Technology, Sydney | afternoon. – Yes, Minister

They’re different users and may have different default environments.
This is one of the larger design screwups in RT 1.0.xOn Fri, Jul 06, 2001 at 12:35:00PM +1000, Teo de Hesselle wrote:

Jesse wrote:

is the timezone on the two systems set the same?

Okay… you’ve obviously been here before… when I use the web, it
creates it using yesterday’s date, and displays fine. If i move Jul/6/* to
Jul/5/*, they display fine also.

Now I just have to work out where this incorrect timezone info is coming
from…

What is the difference in the method used by the web and the mailgate?


Téo de Hesselle, | Diplomacy is about surviving until
Unix Systems Administrator | the next century. Politics is
| about surviving until Friday
University of Technology, Sydney | afternoon. – Yes, Minister

jesse reed vincent – root@eruditorum.orgjesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90

that’s security the same way that asking for directions to topeka and
being told that a seal is a mammal is informative
-robin@apocalypse.org

Read the readme. It tells you that you’ll probably have to install Apache::DBI
by hand.On Sun, Jul 08, 2001 at 01:09:22PM +0200, Leuchter, Lars wrote:

Hi,

After re-installint RT to a complete different box as the original one
appeared to be a nightmare,
I get the following error when starting apache:

Syntax error on line 980 of /usr/local/apache/conf/httpd.conf:
Can’t locate Apache/DBI.pm in @INC (@INC contains:
/usr/local/lib/perl5/5.6.1

fixdeps and testdeps went fine, the following perl modules are installed
properly however:

DBIx::SearchBuilder https://10.20.31.245/cpan/edit_mod.cgi?idx=35
0.39
DBIx::DataSource https://10.20.31.245/cpan/edit_mod.cgi?idx=34
0.02
DBI https://10.20.31.245/cpan/edit_mod.cgi?idx=33 1.18
Digest::MD5 https://10.20.31.245/cpan/edit_mod.cgi?idx=32 2.13
RT https://10.20.31.245/cpan/edit_mod.cgi?idx=31 !!RT_VERSION!!
Apache::Session https://10.20.31.245/cpan/edit_mod.cgi?idx=28
1.53
mod_perl https://10.20.31.245/cpan/edit_mod.cgi?idx=27 1.25
Msql-Mysql-modules https://10.20.31.245/cpan/edit_mod.cgi?idx=22
1.2216
Data::ShowTable https://10.20.31.245/cpan/edit_mod.cgi?idx=21 3.3

Log::Dispatch https://10.20.31.245/cpan/edit_mod.cgi?idx=20 1.79
Text::Template https://10.20.31.245/cpan/edit_mod.cgi?idx=19 1.31
Text::Wrapper https://10.20.31.245/cpan/edit_mod.cgi?idx=18 1.000
Tie::IxHash https://10.20.31.245/cpan/edit_mod.cgi?idx=17 1.21
MIME-tools https://10.20.31.245/cpan/edit_mod.cgi?idx=16 5.411
IO-stringy https://10.20.31.245/cpan/edit_mod.cgi?idx=15 1.220
MIME::Base64 https://10.20.31.245/cpan/edit_mod.cgi?idx=14 2.12
Mail https://10.20.31.245/cpan/edit_mod.cgi?idx=13 1.15
TimeDate https://10.20.31.245/cpan/edit_mod.cgi?idx=12 1.10
MD5 https://10.20.31.245/cpan/edit_mod.cgi?idx=11 2.02
Storable https://10.20.31.245/cpan/edit_mod.cgi?idx=9 1.012
HTML::Mason https://10.20.31.245/cpan/edit_mod.cgi?idx=8 1.03
Params::Validate https://10.20.31.245/cpan/edit_mod.cgi?idx=7
0.04
Net https://10.20.31.245/cpan/edit_mod.cgi?idx=6 1.07
MLDBM https://10.20.31.245/cpan/edit_mod.cgi?idx=5 2.00
HTML::Parser https://10.20.31.245/cpan/edit_mod.cgi?idx=4 3.25
HTML::Tagset https://10.20.31.245/cpan/edit_mod.cgi?idx=3 3.03

Any ideas ?

Lars

jesse reed vincent – root@eruditorum.orgjesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90

“Bother,” said Pooh, “Eeyore, ready two photon torpedoes and lock
phasers on the Heffalump, Piglet, meet me in transporter room three”