Upgrade to 4.01 MySQL questoin

RT Users
#1

My apologies for a silly post but I’m getting confused…

I am migrating from 3.8.4 to 4.01. I have a new server with 4.01 installed
and mostly set up how I want. I have pulled my database dumps into the new
instance, performed the steps in UPGRADING.mysql and run the script
/opt/rt4/sbin/rt-setup-database --prompt-for-dba-password --action upgrade

I’ve missed something and I’m sure I saw it when reading the docs but now
can’t figure out what I missed. After tweaking my set up I’ve tried
restoring from last nights 3.8.4 instance mysqldump and I have to manually
set the passwords in MySQL to log in as the RT user. For example:*
UPDATE Users SET Password=md5(‘password’) WHERE Name=‘user’;*

This lets the user log in - but only once, after a logout the user cannot
again log in. I believe there was a change in the hash used for passwords
and that there is a script I need to run to fix this but I cannot for the
life of me find this again.

Am I on the right track and what can I tell you to help figure out what I
missed?

Please and thanks.

Paul O’Rorke

#2

I am migrating from 3.8.4 to 4.01. I have a new server with 4.01 installed and mostly set up
how I want. I have pulled my database dumps into the new instance, performed the steps in
UPGRADING.mysql and run the script
/opt/rt4/sbin/rt-setup-database --prompt-for-dba-password --action upgrade

I’ve missed something and I’m sure I saw it when reading the docs but now can’t figure out
what I missed. After tweaking my set up I’ve tried restoring from last nights 3.8.4 instance
mysqldump and I have to manually set the passwords in MySQL to log in as the RT user. For
example:
UPDATE Users SET Password=md5(‘password’) WHERE Name=‘user’;

This lets the user log in - but only once, after a logout the user cannot again log in. I
believe there was a change in the hash used for passwords and that there is a script I need to
run to fix this but I cannot for the life of me find this again.

Am I on the right track and what can I tell you to help figure out what I missed?

It appears you didn’t successfully complete the
/opt/rt4/sbin/rt-setup-database --prompt-for-dba-password --action upgrade
step, since it will change the size of your Users.Password field (among lots
of other changes). There is also a script to rehash your user
passwords which was included in our security updates and is documented
in docs/UPGRADING-3.8, but this bug is more likely to be related to an
incomplete database upgrade.

-kevin

#3

Thaks Kevin,

I missed that in the output. Most of it seems OK up until the part where it
processesd 3.9.2 and 3.9.3.:

Processing 3.9.2
Now inserting data.
[Tue Aug 9 02:42:25 2011] [warning]: DBD::mysql::st execute failed: Unknown
column ‘main.DelegatedBy’ in ‘where clause’ at
/usr/local/share/perl/5.10.1/DBIx/SearchBuilder/Handle.pm line 509, <> line

  1. (/usr/local/share/perl/5.10.1/DBIx/SearchBuilder/Handle.pm:509)
    [Tue Aug 9 02:42:25 2011] [warning]: RT::Handle=HASH(0x31c8f18) couldn’t
    execute the query ‘SELECT main.* FROM ACL main WHERE (main.DelegatedBy >
    ‘0’) AND (main.DelegatedFrom > ‘0’) ’ at
    /usr/local/share/perl/5.10.1/DBIx/SearchBuilder/Handle.pm line 522
    DBIx::SearchBuilder::Handle::SimpleQuery(‘RT::Handle=HASH(0x31c8f18)’,
    ‘SELECT main.* FROM ACL main WHERE (main.DelegatedBy > ‘0’)…’) called
    at /usr/local/share/perl/5.10.1/DBIx/SearchBuilder.pm line 235
    DBIx::SearchBuilder::_DoSearch(‘RT::ACL=HASH(0x5021070)’) called at
    /opt/rt4/sbin/…/lib/RT/SearchBuilder.pm line 320
    RT::SearchBuilder::_DoSearch(‘RT::ACL=HASH(0x5021070)’) called at
    /opt/rt4/sbin/…/lib/RT/ACL.pm line 260
    RT::ACL::_DoSearch(‘RT::ACL=HASH(0x5021070)’) called at
    /usr/local/share/perl/5.10.1/DBIx/SearchBuilder.pm line 503
    DBIx::SearchBuilder::Next(‘RT::ACL=HASH(0x5021070)’) called at
    /opt/rt4/sbin/…/lib/RT/ACL.pm line 225
    RT::ACL::Next(‘RT::ACL=HASH(0x5021070)’) called at
    ./etc/upgrade/3.9.2/content line 19
    RT::Handle::ANON() called at /opt/rt4/sbin/…/lib/RT/Handle.pm line
    767
    eval {…} called at /opt/rt4/sbin/…/lib/RT/Handle.pm line 767
    RT::Handle::InsertData(‘RT::Handle=HASH(0x31c8f18)’,
    ’./etc/upgrade/3.9.2/content’, undef) called at
    /opt/rt4/sbin/rt-setup-database line 292
    main::action_insert(‘prompt-for-dba-password’, 1, ‘datafile’, undef,
    ‘action’, ‘upgrade’, ‘datadir’, ‘./etc/upgrade/3.9.2’, ‘backcompat’, …)
    called at /opt/rt4/sbin/rt-setup-database line 398
    main::action_upgrade(‘prompt-for-dba-password’, 1, ‘action’, ‘upgrade’,
    ‘dba’, ‘root’) called at /opt/rt4/sbin/rt-setup-database line 197
    (/usr/share/perl/5.10/Carp.pm:47)
    [Tue Aug 9 02:42:25 2011] [crit]: _DoSearch is not so successful as it
    still needs redo search, won’t call _BuildHash
    (/opt/rt4/sbin/…/lib/RT/ACL.pm:263)
    Processing 3.9.3
    Now populating database schema.
    [Tue Aug 9 02:42:25 2011] [crit]: DBD::mysql::st execute failed: Can’t DROP
    ’DelegatedBy’; check that column/key exists at
    /opt/rt4/sbin/…/lib/RT/Handle.pm line 517. (/opt/rt4/sbin/…/lib/RT.pm:340)
    DBD::mysql::st execute failed: Can’t DROP ‘DelegatedBy’; check that
    column/key exists at /opt/rt4/sbin/…/lib/RT/Handle.pm line 517.

The complete output is here.:
http://www.paulororke.net/files/rt-setup-database.txt

I see 2 critical errors, need I address the warnings first? I’m not sure
where to go with tis now…

thanks

Paul

I am migrating from 3.8.4 to 4.01. I have a new server with 4.01
installed and mostly set up

how I want. I have pulled my database dumps into the new instance,
performed the steps in

UPGRADING.mysql and run the script
/opt/rt4/sbin/rt-setup-database --prompt-for-dba-password --action
upgrade

I’ve missed something and I’m sure I saw it when reading the docs but
now can’t figure out

what I missed. After tweaking my set up I’ve tried restoring from
last nights 3.8.4 instance

mysqldump and I have to manually set the passwords in MySQL to log in
as the RT user. For

example:
UPDATE Users SET Password=md5(‘password’) WHERE Name=‘user’;

This lets the user log in - but only once, after a logout the user
cannot again log in. I

believe there was a change in the hash used for passwords and that
there is a script I need to

run to fix this but I cannot for the life of me find this again.

Am I on the right track and what can I tell you to help figure out
what I missed?

It appears you didn’t successfully complete the
/opt/rt4/sbin/rt-setup-database --prompt-for-dba-password --action
upgrade
step, since it will change the size of your Users.Password field (among
lots

#4

[Tue Aug 9 02:42:25 2011] [warning]: DBD::mysql::st execute failed: Unknown column
’main.DelegatedBy’ in ‘where clause’ at

This implies that you have a partially upgraded database, since this
column is deleted in 3.9.3

Are you sure you’re starting from a fully-clean restore of your 3.8.4
dump? You want to ensure that no existing tables are in your DB.

-kevin

#5

no - actually I’m not. I guess I have to change my plan.

I had thought to import the data - spend some time setting up 4.01 as I
wanted then update the DB by running the import again. I guess this is not
such a good idea. I’m thinking then that I’ll have to make careful note of
the set up changes and do it all in one ‘fell swoop’…

Unless there is a way to update my imported and ‘patched’ 4.01 DB with a
3.8.4 dump just to get the most recent changes.

Does what I’m trying to do make sense?

Thanks for the excellent help thus far btw.

PauloOn Tue, Aug 9, 2011 at 2:16 PM, Kevin Falcone falcone@bestpractical.comwrote:

On Tue, Aug 09, 2011 at 12:27:03PM -0700, Paul O’Rorke wrote:

[Tue Aug 9 02:42:25 2011] [warning]: DBD::mysql::st execute failed:
Unknown column
’main.DelegatedBy’ in ‘where clause’ at

This implies that you have a partially upgraded database, since this
column is deleted in 3.9.3

Are you sure you’re starting from a fully-clean restore of your 3.8.4
dump? You want to ensure that no existing tables are in your DB.

-kevin

RT Training Sessions (http://bestpractical.com/services/training.html)

  • Chicago, IL, USA — September 26 & 27, 2011
  • San Francisco, CA, USA — October 18 & 19, 2011
  • Washington DC, USA — October 31 & November 1, 2011
  • Melbourne VIC, Australia — November 28 & 29, 2011
  • Barcelona, Spain — November 28 & 29, 2011
#6

no - actually I’m not. I guess I have to change my plan.

I had thought to import the data - spend some time setting up 4.01 as I wanted then update the
DB by running the import again. I guess this is not such a good idea. I’m thinking then that
I’ll have to make careful note of the set up changes and do it all in one ‘fell swoop’…

I’m curious how you were going to ‘run the import again’ to pick up
the 3.8.4 data, especially considering the numerous schema changes.

Unless there is a way to update my imported and ‘patched’ 4.01 DB with a 3.8.4 dump just to
get the most recent changes.

Does what I’m trying to do make sense?

You can’t just somehow apply the new data in your 3.8.4 database to
your 4.0.1 database and rerun part of the upgrader.

You’ll need to document your upgrade process and run it in one
process.

-kevin

#7

aaah - well then that’s what I must do. Thanks for the help. I’ll let you
know how that goes.

regardsOn Tue, Aug 9, 2011 at 5:14 PM, Kevin Falcone falcone@bestpractical.comwrote:

On Tue, Aug 09, 2011 at 02:56:52PM -0700, Paul O’Rorke wrote:

no - actually I’m not. I guess I have to change my plan.

I had thought to import the data - spend some time setting up 4.01 as
I wanted then update the
DB by running the import again. I guess this is not such a good idea.
I’m thinking then that
I’ll have to make careful note of the set up changes and do it all in
one ‘fell swoop’…

I’m curious how you were going to ‘run the import again’ to pick up
the 3.8.4 data, especially considering the numerous schema changes.

Unless there is a way to update my imported and ‘patched’ 4.01 DB with
a 3.8.4 dump just to
get the most recent changes.

Does what I’m trying to do make sense?

You can’t just somehow apply the new data in your 3.8.4 database to
your 4.0.1 database and rerun part of the upgrader.

You’ll need to document your upgrade process and run it in one
process.

-kevin

RT Training Sessions (http://bestpractical.com/services/training.html)

  • Chicago, IL, USA — September 26 & 27, 2011
  • San Francisco, CA, USA — October 18 & 19, 2011
  • Washington DC, USA — October 31 & November 1, 2011
  • Melbourne VIC, Australia — November 28 & 29, 2011
  • Barcelona, Spain — November 28 & 29, 2011