Converter issue on convert from RT2 to RT3, expanded

{First off, I apologize for the dupe – the first message got
attached to another thread, and I never even saw it on the list}

I’m working with the converter tool to migrate my database from RT2
to RT3. We’re finally getting off our old RT2 system, and trying to
get things rolling on RT3.

The two machines are actually two different systems. I assume this
shouldn’t be a problem, as I just run the RT2-to-dumpfile on the old
machine, and the dumpfile-to-RT3 on the new one.

Using the instructions in the README, I have the rt2-to-dumpfile
piece setup. It starts to run, but I get this:

Can’t write to ‘!!RT_LOG_PATH!!/rt.log.4925.0’: No such file or
directory at /usr/share/perl5/Log/Dispatch/File.pm line 69.

Questions:

  1. The fact that the data lives on two different machines shouldn’t
    be a problem, right? Just want to confirm this assumption, and
    verify it’s not the cause of my current (or future) woes.

  2. What’s causing the error I’m seeing, and how do I diagnose?
    Nothing I do seems to reveal what is going on here. Where should I
    be looking for diagnostic data? Any ideas what’s causing this?

Thanks!

Dave

{First off, I apologize for the dupe – the first message got
attached to another thread, and I never even saw it on the list}

I’m working with the converter tool to migrate my database from RT2
to RT3. We’re finally getting off our old RT2 system, and trying to
get things rolling on RT3.

The two machines are actually two different systems. I assume this
shouldn’t be a problem, as I just run the RT2-to-dumpfile on the old
machine, and the dumpfile-to-RT3 on the new one.

Using the instructions in the README, I have the rt2-to-dumpfile
piece setup. It starts to run, but I get this:

Can’t write to ‘!!RT_LOG_PATH!!/rt.log.4925.0’: No such file or
directory at /usr/share/perl5/Log/Dispatch/File.pm line 69.

Questions:

  1. The fact that the data lives on two different machines shouldn’t
    be a problem, right? Just want to confirm this assumption, and
    verify it’s not the cause of my current (or future) woes.
    AFAIK it’s not a problem. dump on old machine and import on new.
  1. What’s causing the error I’m seeing, and how do I diagnose?
    Nothing I do seems to reveal what is going on here. Where should I
    be looking for diagnostic data? Any ideas what’s causing this?
    Is that copy of error? or you substituted that “!!RT_LOG_PATH!!”? I
    think script or RT tries to create log file and write somethings, but
    couldn’t do that because of permissions or may be base dir doesn’t
    exists. I don’t know how logging is implemented in RT-2.0

Thanks!

Dave


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

We’re hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html

Best regards, Ruslan.

That was the actual error. Discovered that the problem was that the
script was pointing to the wrong location.

What is the maximum size people have used with the exporter? We have
some 80000 tickets (spam has been a problem), and we’re seeing a
very, very slow conversion.

DaveOn Mar 22, 2006, at 9:43 AM, Ruslan Zakirov wrote:

On 3/22/06, Dave Sobel dave@evolvetech.com wrote:

{First off, I apologize for the dupe – the first message got
attached to another thread, and I never even saw it on the list}

I’m working with the converter tool to migrate my database from RT2
to RT3. We’re finally getting off our old RT2 system, and trying to
get things rolling on RT3.

The two machines are actually two different systems. I assume this
shouldn’t be a problem, as I just run the RT2-to-dumpfile on the old
machine, and the dumpfile-to-RT3 on the new one.

Using the instructions in the README, I have the rt2-to-dumpfile
piece setup. It starts to run, but I get this:

Can’t write to ‘!!RT_LOG_PATH!!/rt.log.4925.0’: No such file or
directory at /usr/share/perl5/Log/Dispatch/File.pm line 69.

Questions:

  1. The fact that the data lives on two different machines shouldn’t
    be a problem, right? Just want to confirm this assumption, and
    verify it’s not the cause of my current (or future) woes.
    AFAIK it’s not a problem. dump on old machine and import on new.
  1. What’s causing the error I’m seeing, and how do I diagnose?
    Nothing I do seems to reveal what is going on here. Where should I
    be looking for diagnostic data? Any ideas what’s causing this?
    Is that copy of error? or you substituted that “!!RT_LOG_PATH!!”? I
    think script or RT tries to create log file and write somethings, but
    couldn’t do that because of permissions or may be base dir doesn’t
    exists. I don’t know how logging is implemented in RT-2.0

Thanks!

Dave


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

We’re hiring! Come hack Perl for Best Practical: http://
bestpractical.com/about/jobs.html


Best regards, Ruslan.

That was the actual error. Discovered that the problem was that the
script was pointing to the wrong location.

What is the maximum size people have used with the exporter? We have
some 80000 tickets (spam has been a problem), and we’re seeing a
very, very slow conversion.

I’ve done a 400,000 ticket conversion in about 36 hours. It would have
been about 24 if I’d been monitoring the import and seen that an
additional index on cachedgroupmembers was needed for the queries done
by the migration tool.

Jesse Vincent wrote:> On Sat, Mar 25, 2006 at 04:41:42PM -0500, Dave Sobel wrote:

That was the actual error. Discovered that the problem was that the
script was pointing to the wrong location.

What is the maximum size people have used with the exporter? We have
some 80000 tickets (spam has been a problem), and we’re seeing a
very, very slow conversion.

I’ve done a 400,000 ticket conversion in about 36 hours. It would have
been about 24 if I’d been monitoring the import and seen that an
additional index on cachedgroupmembers was needed for the queries done
by the migration tool.

It took me about 14 hours to do ~ 33,000 tickets on a quad P3 700
machine with 2GB RAM.

Tom

Here’s my current problem on this.

The machine this is running on is OLD – very old. We have about
80,000 tickets. It took 4 days to do 55,000 tickets, and the
conversion crashed.

Is it possible to run this conversion on another machine? Would I
install RT2 on a box, and then run the conversion there? What parts
are required for the conversion tool – could I do both parts on the
new box?

DaveOn Mar 27, 2006, at 10:33 AM, Tom Lichti wrote:

Jesse Vincent wrote:

On Sat, Mar 25, 2006 at 04:41:42PM -0500, Dave Sobel wrote:

That was the actual error. Discovered that the problem was that
the script was pointing to the wrong location.

What is the maximum size people have used with the exporter? We
have some 80000 tickets (spam has been a problem), and we’re
seeing a very, very slow conversion.

I’ve done a 400,000 ticket conversion in about 36 hours. It would
have
been about 24 if I’d been monitoring the import and seen that an
additional index on cachedgroupmembers was needed for the queries
done
by the migration tool.

It took me about 14 hours to do ~ 33,000 tickets on a quad P3 700
machine with 2GB RAM.

Tom

Citando Dave Sobel dave@evolvetech.com:

Here’s my current problem on this.

The machine this is running on is OLD – very old. We have about
80,000 tickets. It took 4 days to do 55,000 tickets, and the
conversion crashed.

Is it possible to run this conversion on another machine? Would I
install RT2 on a box, and then run the conversion there? What parts
are required for the conversion tool – could I do both parts on the
new box?

If rt-2.0-to-dumpfile is taking too long on that old machine, I think you
should try to dump the SQL database to a faster machine and also copy your old
RT instalation over. Probably the best way is to dump the DB and then also copy
all system binaries to the new machine to ensure that old RT still works ok.
If the old system does not boot on the newer hardware you can try to just copy
the binaries and libraries and run it all inside a chroot jail on the faster
system.

Hope this helps

Regards

Claudio Martins