Re: [rt-users] RT 3.8.0 DB migrate to 4.0.5 - Errors Please help!

2012-06-20 Thread Kevin Falcone
On Wed, Jun 20, 2012 at 03:22:20PM +0300, Rabin Yasharzadehe wrote:
> Did the same thing, i used this guide as a base
> http://www.math.ias.edu/~tarzadon/pages/posts/migrating-rt-3.6.4-to-rt-4.0-88.php
> 
> but it didn't dump and restore the DB, it was big and slow, so i just copy
> the DB files
> from Debian 5 server to a new (Virtual) Debian 6 server and fixed the DB
> (you'll get ERROR 1577 for MySQL)
> 
> ERROR 1577 (HY000) at line 1: Cannot proceed because system tables used by
> > Event Scheduler were found damaged at server start
> 
> 
> You'll need to run this command to fixit
> 
> sudo mysql_upgrade -u root -h localhost -p --verbose --force
> 
> 
> then I created the ALTER SQL-Queries && Upgrade the DB schema
> 
> perl /opt/rt/rt-4.0.5/etc/upgrade/upgrade-mysql-schema.pl rt3-database
> > dbuser dbpassword  > /opt/rt/queries.sql
> > mysql -u root -p rt3-database < /opt/rt/queries.sql

This skips the really important 'make upgrade-database' command.
Without it, you will not have a correct RT4 database.

If the UPGRADING documentation that ships with RT is not sufficient,
we've also written up some of the common issues in a blog post a while
back:

http://blog.bestpractical.com/2011/07/upgrading-to-rt-4.html

-kevin


pgpAv9j6zBbFn.pgp
Description: PGP signature


Re: [rt-users] RT 3.8.0 DB migrate to 4.0.5 - Errors Please help!

2012-06-20 Thread Rabin Yasharzadehe
Did the same thing, i used this guide as a base
http://www.math.ias.edu/~tarzadon/pages/posts/migrating-rt-3.6.4-to-rt-4.0-88.php

but it didn't dump and restore the DB, it was big and slow, so i just copy
the DB files
from Debian 5 server to a new (Virtual) Debian 6 server and fixed the DB
(you'll get ERROR 1577 for MySQL)

ERROR 1577 (HY000) at line 1: Cannot proceed because system tables used by
> Event Scheduler were found damaged at server start


You'll need to run this command to fixit

sudo mysql_upgrade -u root -h localhost -p --verbose --force


then I created the ALTER SQL-Queries && Upgrade the DB schema

perl /opt/rt/rt-4.0.5/etc/upgrade/upgrade-mysql-schema.pl rt3-database
> dbuser dbpassword  > /opt/rt/queries.sql
> mysql -u root -p rt3-database < /opt/rt/queries.sql



*---
Rabin Yasharzadehe*



On Tue, Jun 12, 2012 at 9:23 PM, FrankOh  wrote:

>
> OK i've searched all over the Internet and I can't seem to fix the problem.
> Currently in production we have RHEL (kernel 2.6.18-238.9.1.el5) with
> RT3.8.0 installed on mySQL 5.0.77. We want to move RT off of this physical
> box and put it on VM. At the same time upgrade to the latest RT 4.0.5.
>
> What I have done so far:
> - Got a backup of our DB in production using mysqldump
> - Created the brand new environment. Tried two different distros. Debian
> (Squeeze) was by far the easiest using all the tutorials and aptitude.
> Kernel 2.6.32-5-amd64 with RT 4.0.5 and mysql 5.1.61-0+squeeze1. Also
> created a Centos 6.2 (kernel 2.6.32-220.el6.x86_64) environment with RT
> 4.0.5 and mySQL 5.1.61.
> - In both cases, RT 4.0.5 was working without any issues after the initial
> install. Then I deleted the "sample" DB, created a new empty db (rtdb) and
> imported the mySQL dump from production:
>
> "mysql --max_allowed_packet=512M -u root -p rtdb < rt.sql"
>
> After the import was complete, if i had a session open from before.. i can
> actually browse the RT site and see all my old information.. cool. Then I
> did the upgrade using the RT scripts. Since I am not migrating from prior
> 3.8.0 and I am not moving from mySQL 4.0 to 4.1, I do not need to apply the
> mySQL scripts in the README. All i did after this import was:
>
> "rt-setup-database --prompt-for-dba-password --action upgrade"
>
> After a couple prompts ("current version" 3.8.0", etc) it did its upgrade
> process. I didn't get any errors.. however i did get some warnings.
> Something about if you're not using something then don't worry about it.
>
> [Sat Jun  9 20:36:36 2012] [warning]: Going to add [OLD] prefix to all
> templates in approvals queue. If you have never used approvals, you can
> safely delete all the templates with the [OLD] prefix. Leave the new
> Approval templates because you may eventually want to start using
> approvals.
> (./etc/upgrade/3.8.2/content:3)
> [Sat Jun  9 20:37:01 2012] [warning]: IMPORTANT: We're going to delete all
> scrips in Approvals queue and save them in 'rt-approvals-scrips-cxYO' file.
> (./etc/upgrade/3.8.2/content:165)
>
> [Sat Jun  9 20:37:30 2012] [warning]: Couldn't set SortOrder: That is
> already the current value (./etc/upgrade/3.8.8/content:32)
> [Sat Jun  9 20:37:30 2012] [warning]: Couldn't set SortOrder: That is
> already the current value (./etc/upgrade/3.8.8/content:32)
>
> The upgrade finished without a hitch. Now i see 26 tables in my DB (3.8.0,
> there were 21). Now again, i can browse the RT site with my imported data.
>
> Now the error
>
> When i restart the box.. or even restart apache (httpd in Centos and
> apache2
> in Debian).. i get weird errors.
>
> Debian box (Squeeze):
> root@rt-migrate:~# service apache2 restart
> Restarting web server: apache2RT since version 3.8 has new schema for MySQL
> versions after 4.1.0
> Follow instructions in the UPGRADING.mysql file.
>
> [Wed May 30 14:44:45 2012] [warning]:   (in cleanup) Error while loading
> /usr/share/request-tracker4/libexec/rt-server: ModPerl::Util::exit:
> (12)
> exit was called at /usr/share/request-tracker4/libexec/rt-server line 135
> at
> /usr/share/perl5/Plack/Util.pm line 156.
> (/usr/share/request-tracker4/lib/RT.pm:353)
>  ... waiting RT since version 3.8 has new schema for MySQL versions after
> 4.1.0
> Follow instructions in the UPGRADING.mysql file.
>
> [Wed May 30 14:44:48 2012] [warning]:   (in cleanup) Error while loading
> /usr/share/request-tracker4/libexec/rt-server: ModPerl::Util::exit:
> (12)
> exit was called at /usr/share/request-tracker4/libexec/rt-server line 135
> at
> /usr/share/perl5/Plack/Util.pm line 156.
> (/usr/share/request-tracker4/lib/RT.pm:353)
>
> Debian /var/log/apache/error.log
>
> [Wed May 30 14:45:02 2012] [warning]: Subroutine handle_startup_error
> redefined at /usr/share/request-tracker4/libexec/rt-server line 240.
> (/usr/share/request-tracker4/libexec/rt-server:240)
> [Wed May 30 14:45:02 2012] [warning]: Subroutine handle_bind_error
> redefined
> at /usr/share/request-tracker4/libexec/rt-server line 252.
> (/usr/shar

Re: [rt-users] RT 3.8.0 DB migrate to 4.0.5 - Errors Please help!

2012-06-20 Thread Kristian Davies
On Tue, Jun 12, 2012 at 7:23 PM, FrankOh  wrote:
>
> OK i've searched all over the Internet and I can't seem to fix the problem.
> Currently in production we have RHEL (kernel 2.6.18-238.9.1.el5) with
> RT3.8.0 installed on mySQL 5.0.77. We want to move RT off of this physical
> box and put it on VM. At the same time upgrade to the latest RT 4.0.5.

I'm about to go on holiday so I can't respond fully but I went through
a similar process recently and had similar issues.

I treated the DB and the code separate.  Upgraded the database but the
code I installed new and migrated everything to make sure it all
worked.

With the DB I did some test with just the schema so 3.8.0 (mysqldump
-d mydb) to 3.8.11 then 3.8.11 to 4.0.0, then each step
(4.0.1/4.0.2/4.0.3/4.0.4/4.0.5), I was being quite careful :-)   I
then ran a tests with data.  I also ran at stage 4.0.0
etc/upgrade/upgrade-articles, etc/upgrade/vulnerable-passwords --fix,
etc/upgrade/shrink_transactions_table.pl,
etc/upgrade/shrink_cgm_table.pl, at 4.0.1 sbin/rt-validator --fix,
4.0.2 sbin/rt-validator --resolve

Sorry for the dump, but that seemed to work for me on our 11GB DB.

-Kristian


[rt-users] RT 3.8.0 DB migrate to 4.0.5 - Errors Please help!

2012-06-12 Thread FrankOh

OK i've searched all over the Internet and I can't seem to fix the problem.
Currently in production we have RHEL (kernel 2.6.18-238.9.1.el5) with
RT3.8.0 installed on mySQL 5.0.77. We want to move RT off of this physical
box and put it on VM. At the same time upgrade to the latest RT 4.0.5.

What I have done so far:
- Got a backup of our DB in production using mysqldump
- Created the brand new environment. Tried two different distros. Debian
(Squeeze) was by far the easiest using all the tutorials and aptitude.
Kernel 2.6.32-5-amd64 with RT 4.0.5 and mysql 5.1.61-0+squeeze1. Also
created a Centos 6.2 (kernel 2.6.32-220.el6.x86_64) environment with RT
4.0.5 and mySQL 5.1.61. 
- In both cases, RT 4.0.5 was working without any issues after the initial
install. Then I deleted the "sample" DB, created a new empty db (rtdb) and
imported the mySQL dump from production: 

"mysql --max_allowed_packet=512M -u root -p rtdb < rt.sql"

After the import was complete, if i had a session open from before.. i can
actually browse the RT site and see all my old information.. cool. Then I
did the upgrade using the RT scripts. Since I am not migrating from prior
3.8.0 and I am not moving from mySQL 4.0 to 4.1, I do not need to apply the
mySQL scripts in the README. All i did after this import was:

"rt-setup-database --prompt-for-dba-password --action upgrade"

After a couple prompts ("current version" 3.8.0", etc) it did its upgrade
process. I didn't get any errors.. however i did get some warnings.
Something about if you're not using something then don't worry about it.

[Sat Jun  9 20:36:36 2012] [warning]: Going to add [OLD] prefix to all
templates in approvals queue. If you have never used approvals, you can
safely delete all the templates with the [OLD] prefix. Leave the new
Approval templates because you may eventually want to start using approvals.
(./etc/upgrade/3.8.2/content:3)
[Sat Jun  9 20:37:01 2012] [warning]: IMPORTANT: We're going to delete all
scrips in Approvals queue and save them in 'rt-approvals-scrips-cxYO' file.
(./etc/upgrade/3.8.2/content:165)

[Sat Jun  9 20:37:30 2012] [warning]: Couldn't set SortOrder: That is
already the current value (./etc/upgrade/3.8.8/content:32)
[Sat Jun  9 20:37:30 2012] [warning]: Couldn't set SortOrder: That is
already the current value (./etc/upgrade/3.8.8/content:32)

The upgrade finished without a hitch. Now i see 26 tables in my DB (3.8.0,
there were 21). Now again, i can browse the RT site with my imported data. 

Now the error

When i restart the box.. or even restart apache (httpd in Centos and apache2
in Debian).. i get weird errors. 

Debian box (Squeeze):
root@rt-migrate:~# service apache2 restart
Restarting web server: apache2RT since version 3.8 has new schema for MySQL
versions after 4.1.0
Follow instructions in the UPGRADING.mysql file.

[Wed May 30 14:44:45 2012] [warning]:   (in cleanup) Error while loading
/usr/share/request-tracker4/libexec/rt-server: ModPerl::Util::exit: (12)
exit was called at /usr/share/request-tracker4/libexec/rt-server line 135 at
/usr/share/perl5/Plack/Util.pm line 156.
(/usr/share/request-tracker4/lib/RT.pm:353)
 ... waiting RT since version 3.8 has new schema for MySQL versions after
4.1.0
Follow instructions in the UPGRADING.mysql file.

[Wed May 30 14:44:48 2012] [warning]:   (in cleanup) Error while loading
/usr/share/request-tracker4/libexec/rt-server: ModPerl::Util::exit: (12)
exit was called at /usr/share/request-tracker4/libexec/rt-server line 135 at
/usr/share/perl5/Plack/Util.pm line 156.
(/usr/share/request-tracker4/lib/RT.pm:353)

Debian /var/log/apache/error.log

[Wed May 30 14:45:02 2012] [warning]: Subroutine handle_startup_error
redefined at /usr/share/request-tracker4/libexec/rt-server line 240.
(/usr/share/request-tracker4/libexec/rt-server:240)
[Wed May 30 14:45:02 2012] [warning]: Subroutine handle_bind_error redefined
at /usr/share/request-tracker4/libexec/rt-server line 252.
(/usr/share/request-tracker4/libexec/rt-server:252)
RT since version 3.8 has new schema for MySQL versions after 4.1.0
Follow instructions in the UPGRADING.mysql file.

[Wed May 30 07:45:15 2012] [error] [client 10.2.66.131] Error while loading
/usr/share/request-tracker4/libexec/rt-server: ModPerl::Util::exit: (12)
exit was called at /usr/share/request-tracker4/libexec/rt-server line 135 at
/usr/share/perl5/Plack/Util.pm line 156.\n

If i browse to the server: http:///rt I get a 500 Internal Server
error. 

CentOS box 6.2:
Restarting the httpd service doesn't display any errors. Httpd looks like it
started correctly.

Centos /var/log/httpd/error.log
[Sat Jun 09 13:46:41 2012] [notice] Apache/2.2.15 (Unix) DAV/2
mod_fcgid/2.3.7 PHP/5.3.3 mod_ssl/2.2.15 OpenSSL/1.0.0-fips configured --
resuming normal operations
RT since version 3.8 has new schema for MySQL versions after 4.1.0
Follow instructions in the UPGRADING.mysql file.

[Sat Jun 09 13:46:51 2012] [warn] [client x.x.x.x] (104)Connection reset by
peer: mod_fcgid: error