Re: [rt-users] Migration Prep

[Jim Berry]

Similarly at our site:   We observed issues (not just RT) when Apache was 
started before the Postgres server was ready.   During certain testing, it 
might be necessary to manually restart Apache.

Jim

-Original Message-
From: rt-users-boun...@lists.bestpractical.com 
[mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Thomas Sibley
Sent: Friday, August 09, 2013 3:46 PM
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Migration Prep

On 08/09/2013 06:36 AM, Paul O'Rorke wrote:
> When I look at syslog I see the following during startup:
>
>
> Aug  9 08:28:04 rt4 RT: DBI
> connect('dbname=rtdb;host=localhost','rtuser',...) failed: Can't
> connect to local MySQL server through socket
> '/var/run/mysqld/mysqld.sock' (2) at 
> /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105.
> (/usr/local/share/perl/5.14.2/Carp.pm:102)
> Aug  9 08:28:05 rt4 RT: DBI
> connect('dbname=rtdb;host=localhost','rtuser',...) failed: Can't
> connect to local MySQL server through socket
> '/var/run/mysqld/mysqld.sock' (2) at 
> /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105.
> (/usr/local/share/perl/5.14.2/Carp.pm:102)
> Aug  9 08:28:08 rt4 mysqld_safe: Starting mysqld daemon with databases
> from /var/lib/mysql

Just by looking at the log timestamps, your system is pretty clearly set to 
start Apache (or whatever is serving RT) before mysql.  This isn't RT's fault, 
but simply the wrong startup ordering for your system.  You should change it so 
Apache/your webserver depends on mysql being started first.  How to do so 
depends on your distribution.

Re: [rt-users] Migration Prep

[paul]

Thanks Thomas

Setting Apache to start after mysql seems to have done the trick.


Sent from my GT-I9305T on the Telstra 4G network

 Original message 
From: Thomas Sibley  
Date:  
To: rt-users@lists.bestpractical.com 
Subject: Re: [rt-users] Migration Prep 
 
On 08/09/2013 06:36 AM, Paul O'Rorke wrote:
> When I look at syslog I see the following during startup:
> 
> 
> Aug  9 08:28:04 rt4 RT: DBI
> connect('dbname=rtdb;host=localhost','rtuser',...) failed: Can't connect
> to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
> at /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105.
> (/usr/local/share/perl/5.14.2/Carp.pm:102)
> Aug  9 08:28:05 rt4 RT: DBI
> connect('dbname=rtdb;host=localhost','rtuser',...) failed: Can't connect
> to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
> at /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105.
> (/usr/local/share/perl/5.14.2/Carp.pm:102)
> Aug  9 08:28:08 rt4 mysqld_safe: Starting mysqld daemon with databases
> from /var/lib/mysql

Just by looking at the log timestamps, your system is pretty clearly set
to start Apache (or whatever is serving RT) before mysql.  This isn't
RT's fault, but simply the wrong startup ordering for your system.  You
should change it so Apache/your webserver depends on mysql being started
first.  How to do so depends on your distribution.

Re: [rt-users] Migration Prep

[Thomas Sibley]

On 08/09/2013 06:36 AM, Paul O'Rorke wrote:
> When I look at syslog I see the following during startup:
> 
> 
> Aug  9 08:28:04 rt4 RT: DBI
> connect('dbname=rtdb;host=localhost','rtuser',...) failed: Can't connect
> to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
> at /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105.
> (/usr/local/share/perl/5.14.2/Carp.pm:102)
> Aug  9 08:28:05 rt4 RT: DBI
> connect('dbname=rtdb;host=localhost','rtuser',...) failed: Can't connect
> to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
> at /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105.
> (/usr/local/share/perl/5.14.2/Carp.pm:102)
> Aug  9 08:28:08 rt4 mysqld_safe: Starting mysqld daemon with databases
> from /var/lib/mysql

Just by looking at the log timestamps, your system is pretty clearly set
to start Apache (or whatever is serving RT) before mysql.  This isn't
RT's fault, but simply the wrong startup ordering for your system.  You
should change it so Apache/your webserver depends on mysql being started
first.  How to do so depends on your distribution.

Re: [rt-users] Migration Prep

[Paul O'Rorke]

A little more information.

If I run through the setup screens that are presented because RT thinks 
there is no initialised database I get my new RT with the theme and logo 
etc but it flips between that and again going to the login screen.  Of 
course this overwrites my RT_SiteConfig.pm but I'm at a loss to 
understand why this is not persistent.  It keeps connecting to MySQL 
then not.


Is there anything else I can provide that would help troubleshoot this?

*Paul O’Rorke*
Tracker Software Products
p...@tracker-software.com 

Re: [rt-users] Migration Prep

[Paul O'Rorke]

When I look at syslog I see the following during startup:


Aug  9 08:28:03 rt4 acpid: starting up with netlink and the input layer
Aug  9 08:28:03 rt4 acpid: 1 rule loaded
Aug  9 08:28:03 rt4 acpid: waiting for events: event logging is off
Aug  9 08:28:04 rt4 RT: DBI 
connect('dbname=rtdb;host=localhost','rtuser',...) failed: Can't connect 
to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) 
at /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105. 
(/usr/local/share/perl/5.14.2/Carp.pm:102)
Aug  9 08:28:05 rt4 RT: DBI 
connect('dbname=rtdb;host=localhost','rtuser',...) failed: Can't connect 
to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) 
at /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105. 
(/usr/local/share/perl/5.14.2/Carp.pm:102)

Aug  9 08:28:08 rt4 /usr/sbin/cron[2152]: (CRON) INFO (pidfile fd = 3)
Aug  9 08:28:08 rt4 /usr/sbin/cron[2172]: (CRON) STARTUP (fork ok)
Aug  9 08:28:08 rt4 /usr/sbin/cron[2172]: (CRON) INFO (Running @reboot jobs)
Aug  9 08:28:08 rt4 mysqld_safe: Starting mysqld daemon with databases 
from /var/lib/mysql
Aug  9 08:28:08 rt4 mysqld: 130809  8:28:08 [Note] Plugin 'FEDERATED' is 
disabled.
Aug  9 08:28:08 rt4 mysqld: 130809  8:28:08 InnoDB: The InnoDB memory 
heap is disabled
Aug  9 08:28:08 rt4 mysqld: 130809  8:28:08 InnoDB: Mutexes and rw_locks 
use GCC atomic builtins
Aug  9 08:28:08 rt4 mysqld: 130809  8:28:08 InnoDB: Compressed tables 
use zlib 1.2.7

Aug  9 08:28:08 rt4 mysqld: 130809  8:28:08 InnoDB: Using Linux native AIO
Aug  9 08:28:08 rt4 mysqld: 130809  8:28:08 InnoDB: Initializing buffer 
pool, size = 128.0M
Aug  9 08:28:08 rt4 mysqld: 130809  8:28:08 InnoDB: Completed 
initialization of buffer pool
Aug  9 08:28:08 rt4 RT: DBI 
connect('dbname=rtdb;host=localhost','rtuser',...) failed: Can't connect 
to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) 
at /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105. 
(/usr/local/share/perl/5.14.2/Carp.pm:102)
Aug  9 08:28:08 rt4 mysqld: 130809  8:28:08 InnoDB: highest supported 
file format is Barracuda.
Aug  9 08:28:08 rt4 RT: DBI 
connect('dbname=rtdb;host=localhost','rtuser',...) failed: Can't connect 
to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) 
at /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105. 
(/usr/local/share/perl/5.14.2/Carp.pm:102)
Aug  9 08:28:09 rt4 mysqld: 130809  8:28:09  InnoDB: Waiting for the 
background threads to start
Aug  9 08:28:10 rt4 mysqld: 130809  8:28:10 InnoDB: 5.5.31 started; log 
sequence number 2602152497
Aug  9 08:28:10 rt4 mysqld: 130809  8:28:10 [Note] Server hostname 
(bind-address): '127.0.0.1'; port: 3306
Aug  9 08:28:10 rt4 mysqld: 130809  8:28:10 [Note]   - '127.0.0.1' 
resolves to '127.0.0.1';
Aug  9 08:28:10 rt4 mysqld: 130809  8:28:10 [Note] Server socket created 
on IP: '127.0.0.1'.
Aug  9 08:28:10 rt4 mysqld: 130809  8:28:10 [Note] Event Scheduler: 
Loaded 0 events
Aug  9 08:28:10 rt4 mysqld: 130809  8:28:10 [Note] /usr/sbin/mysqld: 
ready for connections.
Aug  9 08:28:10 rt4 mysqld: Version: '5.5.31-0+wheezy1' socket: 
'/var/run/mysqld/mysqld.sock'  port: 3306  (Debian)
Aug  9 08:28:10 rt4 /etc/mysql/debian-start[2704]: Upgrading MySQL 
tables if necessary.
Aug  9 08:28:10 rt4 /etc/mysql/debian-start[2708]: 
/usr/bin/mysql_upgrade: the '--basedir' option is always ignored


It almost looks like RT is trying to connect before MySQL is loaded.  
Also - I find that the connection intermittently works then fails.  One 
minute I'm looking at my new RT tickets then on a page refresh I am back 
to the RT setup screen because it thinks there is no database configured.


I'm at a loss here and really need to get this new install stable.  Any 
help is appreciated.


Paul O'Rorke
Tracker Software Products Canada Limited



On 08/09/2013 12:54 AM, Paul O'Rorke wrote:

OK - a little premature.

After running for a few hours I rebooted my new RT and get a database 
connect fail.  For some reason it's not trying to use a password in 
DBI connect:


Aug  9 00:33:23 rt4 RT: DBI
connect('dbname=rtdb;host=localhost','rtuser',...) failed: Access
denied for user 'rtuser'@'localhost' (using password: NO) at
/usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line
105. (/usr/local/share/perl/5.14.2/Carp.pm:102)

The database name, user and password are all correct in 
RT_SiteConfig.pm and I can connect using those credentials from a 
shell on that box and can access the right database.


Any suggestions why I'm seeing  (using password: NO) in my logs?  I 
get something similar at startup/shutdown.


regards

*Paul O’Rorke*
Tracker Software Products
p...@tracker-software.com 


On 8/8/2013 9:52 PM, Paul O'Rorke wrote:
Thanks for all the support.  I have a shiny new 4.0.17 ticking away 
nicely.  Very happy.


*Paul O’Rorke*
Tracker Software Products
p...@tracker-software.com 

Re: [rt-users] Migration Prep

[Paul O'Rorke]

OK - a little premature.

After running for a few hours I rebooted my new RT and get a database 
connect fail.  For some reason it's not trying to use a password in DBI 
connect:


   Aug  9 00:33:23 rt4 RT: DBI
   connect('dbname=rtdb;host=localhost','rtuser',...) failed: Access
   denied for user 'rtuser'@'localhost' (using password: NO) at
   /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105.
   (/usr/local/share/perl/5.14.2/Carp.pm:102)

The database name, user and password are all correct in RT_SiteConfig.pm 
and I can connect using those credentials from a shell on that box and 
can access the right database.


Any suggestions why I'm seeing  (using password: NO) in my logs? I get 
something similar at startup/shutdown.


regards

*Paul O’Rorke*
Tracker Software Products
p...@tracker-software.com 


On 8/8/2013 9:52 PM, Paul O'Rorke wrote:
Thanks for all the support.  I have a shiny new 4.0.17 ticking away 
nicely.  Very happy.


*Paul O’Rorke*
Tracker Software Products
p...@tracker-software.com 

Re: [rt-users] Migration Prep

[Paul O'Rorke]

Thanks for all the support.  I have a shiny new 4.0.17 ticking away 
nicely.  Very happy.


*Paul O’Rorke*
Tracker Software Products
p...@tracker-software.com 

Re: [rt-users] Migration Prep

[Paul O'Rorke]

Just a heads up that running the make upgrade-database on an upgrade 
from 3.8.4 to 4.0.17 worked flawlessly once I successfully restored the 
DB from mysqldump.


Thanks for the help and more importantly thanks for fixing that script.

:-)

*Paul O’Rorke*
Tracker Software Products
p...@tracker-software.com 

On 8/2/2013 10:23 AM, Thomas Sibley wrote:

On 08/02/2013 10:04 AM, Kevin Falcone wrote:

On Fri, Aug 02, 2013 at 12:49:47PM -0400, Asif Iqbal wrote:

  Please show a log of your make upgrade-database step

* 3.9.8
* 4.0.1

That's definitely skipping steps.

It should read:
* 3.9.8
* 4.0.0rc2
* 4.0.0rc4
* 4.0.0rc7
* 4.0.1

Paul and Asif, you've helped uncover a regression in RT's upgrade logic
beginning in 4.0.14.  It only affects folks who are upgrading from an RT
3.8.x (or older) install to 4.0.14 or higher.  If you're upgrading from
4.0.0 or higher, you're unaffected.

4.0.17 will be out shortly to correct this regression.  Thanks for your
time spent debugging on the list.

Re: [rt-users] Migration Prep

[Thomas Sibley]

On 08/02/2013 10:04 AM, Kevin Falcone wrote:
> On Fri, Aug 02, 2013 at 12:49:47PM -0400, Asif Iqbal wrote:
>>  Please show a log of your make upgrade-database step
>>
>>* 3.9.8
>>* 4.0.1
> 
> That's definitely skipping steps.
> 
> It should read:
> * 3.9.8
> * 4.0.0rc2
> * 4.0.0rc4
> * 4.0.0rc7
> * 4.0.1

Paul and Asif, you've helped uncover a regression in RT's upgrade logic
beginning in 4.0.14.  It only affects folks who are upgrading from an RT
3.8.x (or older) install to 4.0.14 or higher.  If you're upgrading from
4.0.0 or higher, you're unaffected.

4.0.17 will be out shortly to correct this regression.  Thanks for your
time spent debugging on the list.

Re: [rt-users] Migration Prep

[Asif Iqbal]

On Fri, Aug 2, 2013 at 1:04 PM, Kevin Falcone wrote:

> On Fri, Aug 02, 2013 at 12:49:47PM -0400, Asif Iqbal wrote:
> >  Please show a log of your make upgrade-database step
> >
> >* 3.9.8
> >* 4.0.1
>
> That's definitely skipping steps.
>
> It should read:
> * 3.9.8
> * 4.0.0rc2
> * 4.0.0rc4
> * 4.0.0rc7
> * 4.0.1
>
> What does ls -l etc/upgrade/ in the directory where you're running make
> upgrade-database show?
>
>
~/src/rt-4.0.16$ ls -al etc/upgrade/
...
drwxrwxr-x  2 iqbala iqbala  4096 Jul 29 19:02 3.8.8
drwxrwxr-x  2 iqbala iqbala  4096 Jul 29 19:02 3.8.9
-rwxr-xr--  1 root   root3169 Jul 30 14:37 3.8-branded-queues-extension
-rwxrwxr-x  1 iqbala iqbala  3179 Jul 29 19:02
3.8-branded-queues-extension.in
-rwxr-xr--  1 root   root3203 Jul 30 14:37 3.8-ical-extension
-rw-rw-r--  1 iqbala iqbala  3213 Jul 29 19:02 3.8-ical-extension.in
drwxrwxr-x  2 iqbala iqbala  4096 Jul 29 19:02 3.9.1
drwxrwxr-x  2 iqbala iqbala  4096 Jul 29 19:02 3.9.2
drwxrwxr-x  2 iqbala iqbala  4096 Jul 29 19:02 3.9.3
drwxrwxr-x  2 iqbala iqbala  4096 Jul 29 19:02 3.9.5
drwxrwxr-x  2 iqbala iqbala  4096 Jul 29 19:02 3.9.6
drwxrwxr-x  2 iqbala iqbala  4096 Jul 29 19:02 3.9.7
drwxrwxr-x  2 iqbala iqbala  4096 Jul 29 19:02 3.9.8
drwxrwxr-x  2 iqbala iqbala  4096 Jul 29 19:02 4.0.0rc2
drwxrwxr-x  2 iqbala iqbala  4096 Jul 29 19:02 4.0.0rc4
drwxrwxr-x  2 iqbala iqbala  4096 Jul 29 19:02 4.0.0rc7
drwxrwxr-x  2 iqbala iqbala  4096 Jul 29 19:02 4.0.1
drwxrwxr-x  2 iqbala iqbala  4096 Jul 29 19:02 4.0.12
drwxrwxr-x  2 iqbala iqbala  4096 Jul 29 19:02 4.0.13
drwxrwxr-x  2 iqbala iqbala  4096 Jul 29 19:02 4.0.3
drwxrwxr-x  2 iqbala iqbala  4096 Jul 29 19:02 4.0.4
drwxrwxr-x  2 iqbala iqbala  4096 Jul 29 19:02 4.0.6
drwxrwxr-x  2 iqbala iqbala  4096 Jul 29 19:02 4.0.9




> ls -l etc/upgrade/4.0.0rc*/ would also be interesting.
>
> ~/src/rt-4.0.16$ ls -al etc/upgrade/4.0.0rc*
etc/upgrade/4.0.0rc2:
total 12
drwxrwxr-x  2 iqbala iqbala 4096 Jul 29 19:02 .
drwxrwxr-x 43 iqbala iqbala 4096 Jul 30 17:31 ..
-rw-rw-r--  1 iqbala iqbala  193 Jul 29 19:02 schema.mysql

etc/upgrade/4.0.0rc4:
total 20
drwxrwxr-x  2 iqbala iqbala 4096 Jul 29 19:02 .
drwxrwxr-x 43 iqbala iqbala 4096 Jul 30 17:31 ..
-rw-rw-r--  1 iqbala iqbala   48 Jul 29 19:02 schema.mysql
-rw-rw-r--  1 iqbala iqbala   49 Jul 29 19:02 schema.Oracle
-rw-rw-r--  1 iqbala iqbala   52 Jul 29 19:02 schema.Pg

etc/upgrade/4.0.0rc7:
total 12
drwxrwxr-x  2 iqbala iqbala 4096 Jul 29 19:02 .
drwxrwxr-x 43 iqbala iqbala 4096 Jul 30 17:31 ..
-rw-rw-r--  1 iqbala iqbala  630 Jul 29 19:02 content

~/src/rt-4.0.16$ cat etc/upgrade/4.0.0rc2/schema.mysql

DROP TABLE IF EXISTS sessions;

CREATE TABLE sessions (
id char(32) NOT NULL,
a_session LONGBLOB,
LastUpdated TIMESTAMP,
PRIMARY KEY (id)
) ENGINE=InnoDB CHARACTER SET ascii;

I am not sure why it is skipping then. Could it be because of the RTFM
errors? I do not use them and not planning to either.



-- 
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Re: [rt-users] Migration Prep

[Paul O'Rorke]

Thanks again Kevin,

OK - I'll roll back and run the upgrade again from 3.8.4.

Do you have logs of the upgrade?

How do I enable/check logging for that?

*Paul O'Rorke*
Tracker Software Products
p...@tracker-software.com 


On 8/2/2013 7:48 AM, Kevin Falcone wrote:

On Thu, Aug 01, 2013 at 12:40:44PM -0700, Paul O'Rorke wrote:

I don't remember skipping any errors during make upgrade-database.  Here 
are the table
descriptions you asked for.  As you can see the Classes, Topics, Articles 
tables do exist.

Do you have logs of the upgrade?


Hopefully you will be able to tell what I need to do to my DB to fix this...

Really- you need to do another test upgrade and figure out what fails.
While I can tell you how to fix Users, I wouldn't trust that other
parts of the upgrade didn't fail.

Re: [rt-users] Migration Prep

[Kevin Falcone]

On Fri, Aug 02, 2013 at 12:49:47PM -0400, Asif Iqbal wrote:
>  Please show a log of your make upgrade-database step
> 
>* 3.9.8
>* 4.0.1

That's definitely skipping steps.

It should read:
* 3.9.8
* 4.0.0rc2
* 4.0.0rc4
* 4.0.0rc7
* 4.0.1

What does ls -l etc/upgrade/ in the directory where you're running make
upgrade-database show?

ls -l etc/upgrade/4.0.0rc*/ would also be interesting.

-kevin


pgpityBl0dLTl.pgp
Description: PGP signature

Re: [rt-users] Migration Prep

[Asif Iqbal]

On Fri, Aug 2, 2013 at 11:32 AM, Kevin Falcone wrote:

> >I just did my test upgrade from rt 3.8.2 / mysql 5.0.75 to rt 4.0.16
> / mysql 5.5.32
> >but session table still showing myisam.
> >$ mysql -e 'use rt4; show create table sessions'
> >| sessions | CREATE TABLE `sessions` (
> >`id` varbinary(32) NOT NULL DEFAULT '',
> >`a_session` longblob,
> >`LastUpdated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE
> CURRENT_TIMESTAMP,
> >PRIMARY KEY (`id`)
> >) ENGINE=MyISAM DEFAULT CHARSET=utf8 |
> >I guess I can just ALTER the session table now?
>
> Please show a log of your make upgrade-database step
>
> One of the steps explicitly drops and recreates the sessions table.


~/src/rt-4.0.16# make upgrade-database
/usr/bin/perl -I/opt/rt4/local/lib -I/opt/rt4/lib sbin/rt-setup-database
--action upgrade --prompt-for-dba-password
In order to create or update your RT database, this script needs to connect
to your  mysql instance on localhost (port '') as root
Please specify that user's database password below. If the user has no
database
password, just press return.

Password:
Working with:
Type: mysql
Host: localhost
Port:
Name: rt4
User: rt_user
DBA: root
Enter RT version you're upgrading from: 3.8.2

Going to apply following upgrades:
* 3.8.3
* 3.8.4
* 3.8.6
* 3.8.8
* 3.8.9
* 3.9.1
* 3.9.2
* 3.9.3
* 3.9.5
* 3.9.6
* 3.9.7
* 3.9.8
* 4.0.1
* 4.0.3
* 4.0.4
* 4.0.6
* 4.0.9
* 4.0.12
* 4.0.13

Enter RT version if you want to stop upgrade at some point,
  or leave it blank if you want apply above upgrades:

IT'S VERY IMPORTANT TO BACK UP BEFORE THIS STEP

Proceed [y/N]:y
Processing 3.8.3
Now inserting data.
Processing 3.8.4
Now inserting data.
Processing 3.8.6
Now inserting data.
Processing 3.8.8
Now inserting data.
[Fri Aug  2 16:42:55 2013] [warning]: Couldn't set SortOrder: That is
already the current value (./etc/upgrade/3.8.8/content:32)
[Fri Aug  2 16:42:55 2013] [warning]: Couldn't set SortOrder: That is
already the current value (./etc/upgrade/3.8.8/content:32)
Processing 3.8.9
Now inserting data.
[Fri Aug  2 16:42:58 2013] [warning]: Use of uninitialized value in string
eq at /home/iqbala/src/rt-4.0.16/sbin/../lib/RT/Template.pm line 652, <>
line 1. (/home/iqbala/src/rt-4.0.16/sbin/../lib/RT/Template.pm:652)
[Fri Aug  2 16:42:58 2013] [warning]: Use of uninitialized value in string
eq at /home/iqbala/src/rt-4.0.16/sbin/../lib/RT/Template.pm line 652, <>
line 1. (/home/iqbala/src/rt-4.0.16/sbin/../lib/RT/Template.pm:652)
[Fri Aug  2 16:42:58 2013] [warning]: Use of uninitialized value in string
eq at /home/iqbala/src/rt-4.0.16/sbin/../lib/RT/Template.pm line 652, <>
line 1. (/home/iqbala/src/rt-4.0.16/sbin/../lib/RT/Template.pm:652)
Processing 3.9.1
Now inserting data.
[Fri Aug  2 16:43:03 2013] [warning]: Unable to grant ExecuteCode on
principal 685493: NSI already has that right
(./etc/upgrade/3.9.1/content:63)
Processing 3.9.2
Now inserting data.
Processing 3.9.3
Now populating database schema.
Processing 3.9.5
Now populating database schema.
Processing 3.9.6
Now populating database schema.
Processing 3.9.7
Now populating database schema.
Now inserting data.
Processing 3.9.8
Now populating database schema.
Now inserting data.
[Fri Aug  2 16:46:20 2013] [error]: You appear to be upgrading from RTFM
2.0 - We don't support upgrading this old of an RTFM yet
(./etc/upgrade/3.9.8/content:11)
[Fri Aug  2 16:46:20 2013] [error]: We found RTFM tables in your database.
 Checking for content. (./etc/upgrade/3.9.8/content:14)
[Fri Aug  2 16:46:20 2013] [error]: You appear to have RTFM Articles.  You
can upgrade using the etc/upgrade/upgrade-articles script.  Read more about
it in docs/UPGRADING-4.0 (./etc/upgrade/3.9.8/content:20)
Processing 4.0.1
Now inserting data.
Processing 4.0.3
Now inserting data.
Processing 4.0.4
Now inserting data.
Processing 4.0.6
Now populating database schema.
Now inserting data.
Processing 4.0.9
Now inserting data.
Processing 4.0.12
Now populating database schema.
Processing 4.0.13
Now populating database schema.
Done.
root@newwebrt:~/src/rt-4.0.16#


-- 
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Re: [rt-users] Migration Prep

[Kevin Falcone]

On Fri, Aug 02, 2013 at 11:21:24AM -0400, Asif Iqbal wrote:
>On Fri, Aug 2, 2013 at 10:48 AM, Kevin Falcone 
> <[1]falc...@bestpractical.com> wrote:
> 
>  You can look at 'show create table sessions' which should be innodb
>  not myisam and look at your Attributes table, which should have a
>  LONGBLOB for Content.
> 
>I just did my test upgrade from rt 3.8.2 / mysql 5.0.75 to rt 4.0.16 / 
> mysql 5.5.32
>but session table still showing myisam.
>$ mysql -e 'use rt4; show create table sessions'
>| sessions | CREATE TABLE `sessions` (
>`id` varbinary(32) NOT NULL DEFAULT '',
>`a_session` longblob,
>`LastUpdated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE 
> CURRENT_TIMESTAMP,
>PRIMARY KEY (`id`)
>) ENGINE=MyISAM DEFAULT CHARSET=utf8 |
>I guess I can just ALTER the session table now?

Please show a log of your make upgrade-database step

One of the steps explicitly drops and recreates the sessions table.

-kevin


pgpKmzGNJ98Sj.pgp
Description: PGP signature

Re: [rt-users] Migration Prep

[Asif Iqbal]

On Fri, Aug 2, 2013 at 10:48 AM, Kevin Falcone wrote:

> You can look at 'show create table sessions' which should be innodb
> not myisam and look at your Attributes table, which should have a
> LONGBLOB for Content.
>

I just did my test upgrade from rt 3.8.2 / mysql 5.0.75 to rt 4.0.16 /
mysql 5.5.32
but session table still showing myisam.

$ mysql -e 'use rt4; show create table sessions'
| sessions | CREATE TABLE `sessions` (
  `id` varbinary(32) NOT NULL DEFAULT '',
  `a_session` longblob,
  `LastUpdated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE
CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 |

I guess I can just ALTER the session table now?





-- 
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Re: [rt-users] Migration Prep

[Kevin Falcone]

On Thu, Aug 01, 2013 at 12:40:44PM -0700, Paul O'Rorke wrote:
>I don't remember skipping any errors during make upgrade-database.  Here 
> are the table
>descriptions you asked for.  As you can see the Classes, Topics, Articles 
> tables do exist.

Do you have logs of the upgrade?

>Hopefully you will be able to tell what I need to do to my DB to fix 
> this...

Really- you need to do another test upgrade and figure out what fails.
While I can tell you how to fix Users, I wouldn't trust that other
parts of the upgrade didn't fail.

>mysql> describe ACL;
>mysql> describe Groups;
>mysql> describe GroupMembers;
>mysql> describe CustomFieldValues;
>mysql> describe Tickets;
>mysql> describe CustomFields;
>mysql> describe Queues;
>mysql> show tables;

These all look correct.  That shows that you at least ran upgrades
through 3.9.7, but the User change for Password that you're missing
was 4.0.0rc4.  Did you stop anywhere or let it run everything through
4.0.16?

You can look at 'show create table sessions' which should be innodb
not myisam and look at your Attributes table, which should have a
LONGBLOB for Content.

While I've seen errors that reset the Password field to the wrong size
on 3.6 -> 4.0 upgrades, those don't apply to a 3.8 -> 4.0 upgrade.

At this point, I'd rerun a database upgrade, paying close attention to
what steps run and watching the screen and the mysql error logs for
errors.

-kevin


pgpUZiiu6z98l.pgp
Description: PGP signature

Re: [rt-users] Migration Prep

[Kevin Falcone]

On Wed, Jul 31, 2013 at 12:31:26PM -0700, Paul O'Rorke wrote:
>OK - I thought that make upgrade-database covered those - it suggested it 
> was doing all those
>incremental updates.  It asked from which version I was update from/to and 
> showed each step as
>doing something.  What is it's purpose then?
> 
>Do I have to still do each one manually from 3.8.4 then?

make upgrade-database runs all of the steps.
The database you're showing clearly did not have at least one of the
steps run on it.

Did you skip past any errors?

You can also show the 'desc TABLE' for:
ACL
Groups
GroupMembers
CustomFieldValues
Tickets
CustomFields
Queues
and check for the existence of the Classes, Topics, Articles tables.

Your desc Users showed that at least one part of the Users table
upgrade (adding the AuthToken field) was run.  Now the challenge is
figuring out what steps did not run.

-kevin

>Paul O'Rorke
> 
>On 07/31/2013 11:59 AM, Kevin Falcone wrote:
> 
>  On Wed, Jul 31, 2013 at 10:24:29AM -0700, Paul O'Rorke wrote:
> 
>Password: !sha512!8MzDJesb8kr4UHIA!784B/mzwvLcUEEa
> `Password` varbinary(40) DEFAULT NULL,
> 
>  These are 3.8 versions of that table, not 4.0 versions.
>  Did you run all of the database upgrade steps?  This was step 4.0.0rc4.
>  There are many other schema changes.
> 


pgpkavUplp0qw.pgp
Description: PGP signature

Re: [rt-users] Migration Prep

[Paul O'Rorke]

OK - I thought that *make upgrade-database* covered those - it suggested 
it was doing all those incremental updates.  It asked from which version 
I was update from/to and showed each step as doing something.  What is 
it's purpose then?


Do I have to still do each one manually from 3.8.4 then?


Paul O'Rorke

On 07/31/2013 11:59 AM, Kevin Falcone wrote:

On Wed, Jul 31, 2013 at 10:24:29AM -0700, Paul O'Rorke wrote:

   Password: !sha512!8MzDJesb8kr4UHIA!784B/mzwvLcUEEa
`Password` varbinary(40) DEFAULT NULL,

These are 3.8 versions of that table, not 4.0 versions.
Did you run all of the database upgrade steps?  This was step 4.0.0rc4.
There are many other schema changes.

This will absolutely prevent you from logging in.

-kevin

Re: [rt-users] Migration Prep

[Kevin Falcone]

On Wed, Jul 31, 2013 at 10:24:29AM -0700, Paul O'Rorke wrote:
>   Password: !sha512!8MzDJesb8kr4UHIA!784B/mzwvLcUEEa
>`Password` varbinary(40) DEFAULT NULL,

These are 3.8 versions of that table, not 4.0 versions.
Did you run all of the database upgrade steps?  This was step 4.0.0rc4.
There are many other schema changes.

This will absolutely prevent you from logging in.

-kevin


pgpAXyy0_i37k.pgp
Description: PGP signature

Re: [rt-users] Migration Prep

[Paul O'Rorke]

Thanks again Kevin,

so I did try what's on that page you sent me to:

   perl -I/opt/rt4/local/lib -I/opt/rt4/lib \
-MRT -MRT::User \
-e'RT::LoadConfig();RT::Init(); my $u =
   RT::User->new($RT::SystemUser); $u->Load("root");
   $u->SetPassword("secret")'

returned to a prompt with no messages and the hash displayed in MySQL 
changed so I'm thinking it worked:


   mysql> SELECT * FROM Users WHERE Name='root'\G;
   *** 1. row ***
   id: 12
 Name: root
 Password: !sha512!8MzDJesb8kr4UHIA!784B/mzwvLcUEEa
 Comments: SuperUser
Signature: NULL
 EmailAddress: root@localhost
  FreeformContactInfo: NULL
 Organization: NULL
 RealName: Enoch Root
 NickName: NULL
 Lang: NULL
EmailEncoding: NULL
  WebEncoding: NULL
   ExternalContactInfoId: NULL
ContactInfoSystem: NULL
   ExternalAuthId: NULL
   AuthSystem: NULL
Gecos: root
HomePhone: NULL
WorkPhone: NULL
  MobilePhone: NULL
   PagerPhone: NULL
 Address1: NULL
 Address2: NULL
 City: NULL
State: NULL
  Zip: NULL
  Country: NULL
 Timezone: NULL
   PGPKey: NULL
  Creator: 1
  Created: 2010-03-19 21:41:50
LastUpdatedBy: 1
  LastUpdated: 2013-07-31 17:14:02
AuthToken: e4b79ac4754841d8
   1 row in set (0.00 sec)

I still cannot login using root:secret.  Here is mysql> show create 
table Users;


   mysql> show create table Users;
   
+---+--+
   | Table | Create Table |
   
+---+--+
   | Users | CREATE TAB

Re: [rt-users] Migration Prep

[Paul O'Rorke]

Sorry to keep bugging this list,

can anyone tell me why I can't set the password in MySQL with the UPDATE 
statement below?  I have upgraded from 3.8.4 to 4.0.14 and run the 
password updater.  MySQL was at 5.1  so I didn't need to do the MySQL 
update stuff as far as my reading shows.


Is there something wrong with my query or is there something that RT is 
doing such that the passwords are perhaps hashed differently?


I'd so love to get past this final hurdle and be able to make tickets 
again...


Is there perhaps some further info that I should supply that I have not 
to help understand this?


Regards

Paul O'Rorke
Tracker Software Products Canada Limited

p...@tracker-software.com 
tracker-software.com 



On 07/30/2013 03:17 PM, Paul O'Rorke wrote:

Thanks for that Kevin,

not the first time - a silly little mistake had me scratching my 
head.  I had in my Apache config a rewrite rule for /rt and had the 
wrong value in RT_Siteconfig for Set($WebPath, '');


So I now get my logon screen but cannot log in.

I did run the password updater:

root@rt4:/opt/rt4# perl /opt/rt4/etc/upgrade/vulnerable-passwords
--fix
Upgrading 16 users...
Done.

I am assuming that I can't just UPDATE the passwords in MySQL because 
of the hashing?  I tried without success:


mysql> UPDATE rtdb.Users SET Password=PASSWORD('') WHERE
Name='jamie';
Query OK, 1 row affected, 1 warning (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 1

I guess I have missed something in these upgrade README files. I do 
appreciate your help.  Now that I've the Apache thing sorted I'm 
feeling like on the home stretch - if only I can sort these passwords 
out.  Is there another related script I missed perhaps?


Sincerely

Paul O'Rorke
Tracker Software Products Canada Limited

p...@tracker-software.com 
tracker-software.com 

Tel: +1 (250) 324 1621
Fax: +1 (250) 324 1623

Re: [rt-users] Migration Prep

[Kevin Falcone]

On Tue, Jul 30, 2013 at 03:17:11PM -0700, Paul O'Rorke wrote:
>I am assuming that I can't just UPDATE the passwords in MySQL because of 
> the hashing?  I tried
>without success:
> 
>  mysql> UPDATE rtdb.Users SET Password=PASSWORD('') WHERE 
> Name='jamie';
>  Query OK, 1 row affected, 1 warning (0.01 sec)
>  Rows matched: 1  Changed: 1  Warnings: 1

The jamie user will definitely not be able to log in after this.
That puts a MySQL password hash into RT, which is *not* expecting
that.

>I guess I have missed something in these upgrade README files.  I do 
> appreciate your help.
>Now that I've the Apache thing sorted I'm feeling like on the home stretch 
> - if only I can
>sort these passwords out.  Is there another related script I missed 
> perhaps?

You can safely use the techniques here.  RT should update the md5 one
for you and if you change rt3 for rt4 in the perl code, it will
generate a proper password the first time out.

http://requesttracker.wikia.com/wiki/RecoverRootPassword

However, this does bring up a question.  Show us
show create table Users;

-kevin


pgpchyKjkgIMc.pgp
Description: PGP signature

Re: [rt-users] Migration Prep

[Paul O'Rorke]

Thanks for that Kevin,

not the first time - a silly little mistake had me scratching my head.  
I had in my Apache config a rewrite rule for /rt and had the wrong value 
in RT_Siteconfig for Set($WebPath, '');


So I now get my logon screen but cannot log in.

I did run the password updater:

   root@rt4:/opt/rt4# perl /opt/rt4/etc/upgrade/vulnerable-passwords --fix
   Upgrading 16 users...
   Done.

I am assuming that I can't just UPDATE the passwords in MySQL because of 
the hashing?  I tried without success:


   mysql> UPDATE rtdb.Users SET Password=PASSWORD('') WHERE
   Name='jamie';
   Query OK, 1 row affected, 1 warning (0.01 sec)
   Rows matched: 1  Changed: 1  Warnings: 1

I guess I have missed something in these upgrade README files.  I do 
appreciate your help.  Now that I've the Apache thing sorted I'm feeling 
like on the home stretch - if only I can sort these passwords out.  Is 
there another related script I missed perhaps?


Sincerely

Paul O'Rorke
Tracker Software Products Canada Limited

p...@tracker-software.com 
tracker-software.com 

Tel: +1 (250) 324 1621
Fax: +1 (250) 324 1623



PLEASE NOTE : - If you are sending files for us to look at or assist with
these must ALWAYS be wrapped in either a ZIP/RAR or 7z FILE
or they will be removed by our Firewall/Virus management software.



**Certified by Microsoft**
"Works with Vista"
PDF-XChange & SDK, Image-XChange SDK,
PDF-Tools & SDK, TIFF-XChange & SDK.

Support:
http://docu-track.com/support/ 
or
http://www.tracker-software.com/forum/index.php 




Download latest Releases
http://www.tracker-software.com/downloads/ 


On 07/30/2013 07:42 AM, Kevin Falcone wrote:

On Mon, Jul 29, 2013 at 02:30:35PM -0700, Paul O'Rorke wrote:

In the meanwhile I am finding that after running make upgrade-database 
(took me through all
the upgrades from 3.8.4 to 4.0.15) and then trying to set up Apache again 
I'm running into a
loop on the login page.  If I run Apache I don't get a login page at all.  
If I stop Apache
and start

Are you running your 3.8 Apache config or a new 4.0 config.
We can't help debug that problem without seeing error logs or a
config.


  /opt/rt4/sbin/rt-server

then I get:

You don't say what you did to cause this.  Load the login page?
Attempt to log in?  There are clearly a few actions mixed in there.

Also - did you run the password updater, either as a security fix back
in 3.8 or more recently as part of the upgrade?
http://bestpractical.com/docs/rt/latest/UPGRADING-3.8.html

-kevin


Reason: your browser did not supply a Referrer header
(/opt/rt4/sbin/../lib/RT/Interface/Web.pm:397)
[Mon Jul 29 21:25:46 2013] [notice]: Marking original destination as having 
side-effects
before redirecting for login.
Request: /rt/NoAuth/Login.html?next=d820f5cbf943dfe116cbee257b840411
Reason: your browser did not supply a Referrer header
(/opt/rt4/sbin/../lib/RT/Interface/Web.pm:397)
[Mon Jul 29 21:26:00 2013] [error]: FAILED LOGIN for root from 192.168.0.254
(/opt/rt4/sbin/../lib/RT/Interface/Web.pm:753)
[Mon Jul 29 21:26:12 2013] [error]: FAILED LOGIN for rtuser from 
192.168.0.254
(/opt/rt4/sbin/../lib/RT/Interface/Web.pm:753)
I'm assuming I've not actually managed to get my database upgraded properly 
as I'm very
confident of the credentials used (tried others as well that worked in 
3.8.4).  After running
make upgrade-database do I still need to do the individual upgrades in each 
of the README
files for the various updates or does make upgrade-database effectively do 
the same?

Re: [rt-users] Migration Prep

[Kevin Falcone]

On Mon, Jul 29, 2013 at 02:30:35PM -0700, Paul O'Rorke wrote:
>In the meanwhile I am finding that after running make upgrade-database 
> (took me through all
>the upgrades from 3.8.4 to 4.0.15) and then trying to set up Apache again 
> I'm running into a
>loop on the login page.  If I run Apache I don't get a login page at all.  
> If I stop Apache
>and start

Are you running your 3.8 Apache config or a new 4.0 config.
We can't help debug that problem without seeing error logs or a
config.

>  /opt/rt4/sbin/rt-server
> 
>then I get:

You don't say what you did to cause this.  Load the login page?
Attempt to log in?  There are clearly a few actions mixed in there.

Also - did you run the password updater, either as a security fix back
in 3.8 or more recently as part of the upgrade?
http://bestpractical.com/docs/rt/latest/UPGRADING-3.8.html

-kevin

>Reason: your browser did not supply a Referrer header
>(/opt/rt4/sbin/../lib/RT/Interface/Web.pm:397)
>[Mon Jul 29 21:25:46 2013] [notice]: Marking original destination as 
> having side-effects
>before redirecting for login.
>Request: /rt/NoAuth/Login.html?next=d820f5cbf943dfe116cbee257b840411
>Reason: your browser did not supply a Referrer header
>(/opt/rt4/sbin/../lib/RT/Interface/Web.pm:397)
>[Mon Jul 29 21:26:00 2013] [error]: FAILED LOGIN for root from 
> 192.168.0.254
>(/opt/rt4/sbin/../lib/RT/Interface/Web.pm:753)
>[Mon Jul 29 21:26:12 2013] [error]: FAILED LOGIN for rtuser from 
> 192.168.0.254
>(/opt/rt4/sbin/../lib/RT/Interface/Web.pm:753)
>I'm assuming I've not actually managed to get my database upgraded 
> properly as I'm very
>confident of the credentials used (tried others as well that worked in 
> 3.8.4).  After running
>make upgrade-database do I still need to do the individual upgrades in 
> each of the README
>files for the various updates or does make upgrade-database effectively do 
> the same?


pgpj8Bq937o77.pgp
Description: PGP signature

Re: [rt-users] Migration Prep

[Paul O'Rorke]

I guess I should add that although I cannot log into RT through the WEB 
I can confirm that both root and rtuser can access mysql locally via the 
command line.  I guess however that although the users that RT runs as 
can access MySQL that does not mean that the users defined in there are 
working...



*Paul O'Rorke*
Tracker Software Products
p...@tracker-software.com 

On 7/29/2013 2:30 PM, Paul O'Rorke wrote:

Thanks Kevin,

I'm going through that right now.  I must admit I'm a little confused 
by the whole LifeCycle thing.  I'm going through 
http://bestpractical.com/docs/rt/4.0/customizing/lifecycles.html now 
to see if I can swing this.


In the meanwhile I am finding that after running *make 
upgrade-database* (took me through all the upgrades from 3.8.4 to 
4.0.15) and then trying to set up Apache again I'm running into a loop 
on the login page.  If I run Apache I don't get a login page at all.  
If I stop Apache and start

/opt/rt4/sbin/rt-server
then I get:

Reason: your browser did not supply a Referrer header 
(/opt/rt4/sbin/../lib/RT/Interface/Web.pm:397)
[Mon Jul 29 21:25:46 2013] [notice]: Marking original destination as 
having side-effects before redirecting for login.

Request: /rt/NoAuth/Login.html?next=d820f5cbf943dfe116cbee257b840411
Reason: your browser did not supply a Referrer header 
(/opt/rt4/sbin/../lib/RT/Interface/Web.pm:397)
[Mon Jul 29 21:26:00 2013] [error]: FAILED LOGIN for root from 
192.168.0.254 (/opt/rt4/sbin/../lib/RT/Interface/Web.pm:753)
[Mon Jul 29 21:26:12 2013] [error]: FAILED LOGIN for rtuser from 
192.168.0.254 (/opt/rt4/sbin/../lib/RT/Interface/Web.pm:753)


I'm assuming I've not actually managed to get my database upgraded 
properly as I'm very confident of the credentials used (tried others 
as well that worked in 3.8.4).  After running *make upgrade-database* 
do I still need to do the individual upgrades in each of the README 
files for the various updates or does *make upgrade-database* 
effectively do the same?


Thanks


*Paul O'Rorke*
Tracker Software Products
p...@tracker-software.com 


On 7/26/2013 5:53 AM, Kevin Falcone wrote:

On Thu, Jul 25, 2013 at 01:47:07PM -0700, Paul O'Rorke wrote:

I meant the README Docs in the installer archive mostly.

My concern with the migration is that I used custom statuses for queues and 
I have to now use
the LifeCycle set up.  I wasn't sure how the DB restore would go because I 
imagine I'm going
to have different fields in my database than what 4.0.18 expects.  Anyway - 
installing 4.0.14
on my new server now and will get back I'm sure if I run into any 
troubles...

To start, just port your custom statuses to LifeCycles.  That should
be as easy as adding them to the active and inactive lists and
defining some transitions.

Once you're migrated, you can deal with tweaking them to be more
complicated.

-kevin

Re: [rt-users] Migration Prep

[Paul O'Rorke]

Thanks Kevin,

I'm going through that right now.  I must admit I'm a little confused by 
the whole LifeCycle thing.  I'm going through 
http://bestpractical.com/docs/rt/4.0/customizing/lifecycles.html now to 
see if I can swing this.


In the meanwhile I am finding that after running *make upgrade-database* 
(took me through all the upgrades from 3.8.4 to 4.0.15) and then trying 
to set up Apache again I'm running into a loop on the login page.  If I 
run Apache I don't get a login page at all.  If I stop Apache and start


/opt/rt4/sbin/rt-server

then I get:

Reason: your browser did not supply a Referrer header 
(/opt/rt4/sbin/../lib/RT/Interface/Web.pm:397)
[Mon Jul 29 21:25:46 2013] [notice]: Marking original destination as 
having side-effects before redirecting for login.

Request: /rt/NoAuth/Login.html?next=d820f5cbf943dfe116cbee257b840411
Reason: your browser did not supply a Referrer header 
(/opt/rt4/sbin/../lib/RT/Interface/Web.pm:397)
[Mon Jul 29 21:26:00 2013] [error]: FAILED LOGIN for root from 
192.168.0.254 (/opt/rt4/sbin/../lib/RT/Interface/Web.pm:753)
[Mon Jul 29 21:26:12 2013] [error]: FAILED LOGIN for rtuser from 
192.168.0.254 (/opt/rt4/sbin/../lib/RT/Interface/Web.pm:753)


I'm assuming I've not actually managed to get my database upgraded 
properly as I'm very confident of the credentials used (tried others as 
well that worked in 3.8.4).  After running *make upgrade-database* do I 
still need to do the individual upgrades in each of the README files for 
the various updates or does *make upgrade-database* effectively do the same?


Thanks


*Paul O'Rorke*
Tracker Software Products
p...@tracker-software.com 


On 7/26/2013 5:53 AM, Kevin Falcone wrote:

On Thu, Jul 25, 2013 at 01:47:07PM -0700, Paul O'Rorke wrote:

I meant the README Docs in the installer archive mostly.

My concern with the migration is that I used custom statuses for queues and 
I have to now use
the LifeCycle set up.  I wasn't sure how the DB restore would go because I 
imagine I'm going
to have different fields in my database than what 4.0.18 expects.  Anyway - 
installing 4.0.14
on my new server now and will get back I'm sure if I run into any 
troubles...

To start, just port your custom statuses to LifeCycles.  That should
be as easy as adding them to the active and inactive lists and
defining some transitions.

Once you're migrated, you can deal with tweaking them to be more
complicated.

-kevin

Re: [rt-users] Migration Prep

[Kevin Falcone]

On Thu, Jul 25, 2013 at 01:47:07PM -0700, Paul O'Rorke wrote:
>I meant the README Docs in the installer archive mostly.
> 
>My concern with the migration is that I used custom statuses for queues 
> and I have to now use
>the LifeCycle set up.  I wasn't sure how the DB restore would go because I 
> imagine I'm going
>to have different fields in my database than what 4.0.18 expects.  Anyway 
> - installing 4.0.14
>on my new server now and will get back I'm sure if I run into any 
> troubles...

To start, just port your custom statuses to LifeCycles.  That should
be as easy as adding them to the active and inactive lists and
defining some transitions.

Once you're migrated, you can deal with tweaking them to be more
complicated.

-kevin


pgpWlwow9Jvs6.pgp
Description: PGP signature

Re: [rt-users] Migration Prep

[Craig Ringer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/26/2013 12:32 AM, Kevin Falcone wrote:
> On Wed, Jul 24, 2013 at 08:36:43PM -0700, Paul O'Rorke wrote:
>> From what I've read it seems that the best approach might be to:
>> 
>> 1. make a clone of the existing RT, 2. upgrade it to 4.0.13 3. do
>> a mysqldump on the upgraded clone 4. restore the dump on the new
>> server.
> 
> Since you have a new server, upgrading should be easy, if
> something fails, you just start again on the new server.  You're
> not in any way touching production until the final cutover.
> 
> I always:
> 
> Install RT 4.0.14 on the new server mysqldump the old server import
> on the new server run make upgrade-database test turn off the old
> server do a final dump, import, upgrade go forth and rejoice.

I just followed much the same process (with 4.0.15 and PostgreSQL),
except that I used replication (Londiste) to narrow the outage window,
streaming changes from the old to the new server until the moment of
switch-over.

I also used rinetd to redirect traffic from the old server to the new
one, so there'd be no visible outage to people whose DNS hadn't caught
up to the A record change yet. This was necessary because the DNS host
used is unfortunately not able to lower the TTL.

You can do the same thing for mail handling if your RT server receives
mail by direct SMTP, or you can change rt-mailgate in /etc/aliases to
remote-deliver over http directly to the new server and set the Apache
security rules to allow it.

With a little effort you can keep the outage window down to less than
a minute.

- -- 
 Craig Ringer   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJR8f3iAAoJELBXNkqjr+S21hwH/jK0kIt2jZrRWDwhut+5tygJ
HbP7oS+ulzZI+MtrSehmkKPn5E/wa6v+XIgCCsBSU8dG7bXlk60k0IrICW/W1sQ8
dawmw/agyKolj30/OPz2Ac+86uePLYMkEzDKuWlsEASIK/JFM9yOPH9T/m5fYrin
xb0IFZJV3wPBfteuWH3mFxkrH/Od4G5nEKAlc22WXOz8vJZti24qW6Nn3/D5M1c3
uJPAe9/AeJznxiaTIjCfQEx/IWrwb1w35c9EIMfA9PedhCAzzV95ng1y3l5+NJal
gRpV4WeD9A05vjtq9CsuGt3MZHDgv6LI9MQi6nCU5t8CQ6Eel+afD9kxkKR7f4A=
=kmnO
-END PGP SIGNATURE-

Re: [rt-users] Migration Prep

[Paul O'Rorke]

Thanks for that Kevin,

I meant the README Docs in the installer archive mostly.

My concern with the migration is that I used custom statuses for queues 
and I have to now use the LifeCycle set up.  I wasn't sure how the DB 
restore would go because I imagine I'm going to have different fields in 
my database than what 4.0.18 expects.  Anyway - installing 4.0.14 on my 
new server now and will get back I'm sure if I run into any troubles...


regards

*Paul O'Rorke*
Tracker Software Products
p...@tracker-software.com 


On 7/25/2013 9:32 AM, Kevin Falcone wrote:

On Wed, Jul 24, 2013 at 08:36:43PM -0700, Paul O'Rorke wrote:

From what I've read it seems that the best approach might be to:

 1. make a clone of the existing RT,
 2. upgrade it to 4.0.13
 3. do a mysqldump on the upgraded clone
 4. restore the dump on the new server.

Since you have a new server, upgrading should be easy, if something
fails, you just start again on the new server.  You're not in any way
touching production until the final cutover.

I always:

Install RT 4.0.14 on the new server
mysqldump the old server
import on the new server
run make upgrade-database
test
turn off the old server
do a final dump, import, upgrade
go forth and rejoice.


It's the details of step 4 I'm concerned about.  If I set up the database 
on the new server
and restore it from the dump do I then use make upgrade on the new server?  
I don't understand
what the right process would be to make sure the new server has mailgate, 
users etc and can
accept the dump.

You have to copy things like cron jobs and your mailgate config.
I don't understand what you mean by 'users etc and can accept the
dump'?

If you want to create a very empty DB on the rt4 host, run

/opt/rt4/sbin/rt-setup-databas --action create,acl
then restore your dump

You don't say what docs you've reviewed, but I frequently recommend to
the list our upgrading and README rather than any third party guides
as well as this quite old but still surprisingly relevant blog post I
wrote.

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

-kevin

Re: [rt-users] Migration Prep

[Kevin Falcone]

On Wed, Jul 24, 2013 at 08:36:43PM -0700, Paul O'Rorke wrote:
>From what I've read it seems that the best approach might be to:
> 
> 1. make a clone of the existing RT,
> 2. upgrade it to 4.0.13
> 3. do a mysqldump on the upgraded clone
> 4. restore the dump on the new server.

Since you have a new server, upgrading should be easy, if something
fails, you just start again on the new server.  You're not in any way
touching production until the final cutover.

I always:

Install RT 4.0.14 on the new server
mysqldump the old server
import on the new server
run make upgrade-database
test
turn off the old server
do a final dump, import, upgrade
go forth and rejoice.

>It's the details of step 4 I'm concerned about.  If I set up the database 
> on the new server
>and restore it from the dump do I then use make upgrade on the new server? 
>  I don't understand
>what the right process would be to make sure the new server has mailgate, 
> users etc and can
>accept the dump.

You have to copy things like cron jobs and your mailgate config.
I don't understand what you mean by 'users etc and can accept the
dump'?

If you want to create a very empty DB on the rt4 host, run

/opt/rt4/sbin/rt-setup-databas --action create,acl
then restore your dump

You don't say what docs you've reviewed, but I frequently recommend to
the list our upgrading and README rather than any third party guides
as well as this quite old but still surprisingly relevant blog post I
wrote.

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

-kevin


pgpj_Rck084ds.pgp
Description: PGP signature