RT upgrade failing!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Has anybody ever successfully upgraded an RT installation acrosse
multiple versions?

I have a failing hard drive on the machine that is running our current
RT installation. I have new hardware on which I am trying to get it
installed. Our old installation is running on FC1. Because our new
machine has SATA drives I need a much newer kernel for this hardware. My
problem is that the RT upgrade path appears to be broken. My original
version is RT 3.0.7_01 and that version requires sperl which is not
required under the new version (3.4.2). As you may know, unless I want
to do a customized perl build on rhel4 there is no sperl. So when I try
to upgrade from 3.0.7_01 to 3.4.2 it wants me to do a series of database
upgrades involving the schemas, acls, and some data inserts.
Theoretically these updates should move my existing database from
version 3.0.7_01 to 3.1.0 to 3.1.15 to 3.1.17 to 3.3.0 to 3.3.11 which
is where it seems to stop.

This all breaks down pretty early though because at 3.1.15 there is no
upgrade schema for postgres and no ACL’s update either. The bottom line
here is that it seems there is NO viable upgrade path to get from
3.0.7_01 to 3.4.2.

Does anybody have any clues for me?


Chuck Mead csm@redhat.com
Instructor II (and resident Postfix bigot), GLS
Disclaimer: “It’s Thursday and my name is Locutus of B0rk!”
Addendum: “Bwahahaha! Fire up the orbital mind-control lasers!”

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFCk5SjZfy0juH51WsRAgssAJ0WAeaAbzaa78iFex8CQtrlz16MQACbBZWM
NeA0ykJv2LgF0vekbmpnZA0=
=+0+c
-----END PGP SIGNATURE-----

My
problem is that the RT upgrade path appears to be broken. My original
version is RT 3.0.7_01 and that version requires sperl which is not
required under the new version (3.4.2). As you may know, unless I want
to do a customized perl build on rhel4 there is no sperl. So when I try
to upgrade from 3.0.7_01 to 3.4.2 it wants me to do a series of database
upgrades involving the schemas, acls, and some data inserts.
Theoretically these updates should move my existing database from
version 3.0.7_01 to 3.1.0 to 3.1.15 to 3.1.17 to 3.3.0 to 3.3.11 which
is where it seems to stop.

Which is right, because there hasn’t been a schema change since 3.3.11

This all breaks down pretty early though because at 3.1.15 there is no
upgrade schema for postgres and no ACL’s update either. The bottom line
here is that it seems there is NO viable upgrade path to get from
3.0.7_01 to 3.4.2.

RT 3.4.2 shouldn’t throw errors if there was nothing to do for a given
database for a specific upgrade. Did you try to upgrade all the way and
have it fail? I’ve done the upgrades, not just in house but for a number
of customers.

Jesse

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jesse Vincent wrote:

My
problem is that the RT upgrade path appears to be broken. My original
version is RT 3.0.7_01 and that version requires sperl which is not
required under the new version (3.4.2). As you may know, unless I want
to do a customized perl build on rhel4 there is no sperl. So when I try
to upgrade from 3.0.7_01 to 3.4.2 it wants me to do a series of database
upgrades involving the schemas, acls, and some data inserts.
Theoretically these updates should move my existing database from
version 3.0.7_01 to 3.1.0 to 3.1.15 to 3.1.17 to 3.3.0 to 3.3.11 which
is where it seems to stop.

Which is right, because there hasn’t been a schema change since 3.3.11

This all breaks down pretty early though because at 3.1.15 there is no
upgrade schema for postgres and no ACL’s update either. The bottom line
here is that it seems there is NO viable upgrade path to get from
3.0.7_01 to 3.4.2.

RT 3.4.2 shouldn’t throw errors if there was nothing to do for a given
database for a specific upgrade. Did you try to upgrade all the way and
have it fail? I’ve done the upgrades, not just in house but for a number
of customers.

Yes… I ran this:

//begin code
#!/bin/bash

for i in 3.1.0 3.1.15 3.1.17 3.3.0 3.3.11

do
echo $i
/opt/rt3/sbin/rt-setup-database --dba postgres --action schema --datadir
etc/upgrade/$i

/opt/rt3/sbin/rt-setup-database --dba postgres --action acl --datadir
etc/upgrade/$i

/opt/rt3/sbin/rt-setup-database --dba postgres --action insert --datadir
etc/upgrade/$i

done
//end code

After running that and getting errors splatted all over the place it
fails to run and the apache logs are reporting that there is no users
database.


Chuck Mead csm@redhat.com
Instructor II (and resident Postfix bigot), GLS
Disclaimer: “It’s Thursday and my name is Locutus of B0rk!”
Addendum: “Bwahahaha! Fire up the orbital mind-control lasers!”

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFCk6/SZfy0juH51WsRAuAIAKCdikIR2NTNVMQLrBVBjq6OvvVp6gCgoCQK
LDbW3JRHgNx8/NwZsljNhbA=
=MUzA
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am trying to use rt-3-0-7_01 straight up now on a rhel4 machine with
fastcgi. I am getting the dreaded “You’re almost there!” message.

Here is my config:

LoadModule fastcgi_module modules/mod_fastcgi.so

NameVirtualHost 172.16.62.89:80

<VirtualHost 172.16.62.89:80>
ServerAdmin root@glsrt.gls.redhat.com
ServerName glsrt.gls.redhat.com
DocumentRoot /var/www/html
AddDefaultCharset UTF-8
AddHandler fastcgi-script fcgi
<Directory “/opt/rt3/share/html”>
Options FollowSymLinks ExecCGI
AllowOverride None

#Pass through requests to for noauth
Alias /NoAuth/ /opt/rt3/share/html/NoAuth/

FastCgiIpcDir /tmp
FastCgiServer /opt/rt3/bin/mason_handler.fcgi -idle-timeout 120 -processes 4
ScriptAlias / /opt/rt3/bin/mason_handler.fcgi/

The error_log says:

[Tue May 24 18:39:25 2005] [notice] suEXEC mechanism enabled (wrapper:
/usr/sbin/suexec)
[Tue May 24 18:39:25 2005] [notice] Digest: generating secret for digest
authentication …
[Tue May 24 18:39:25 2005] [notice] Digest: done
[Tue May 24 18:39:25 2005] [notice] LDAP: Built with OpenLDAP LDAP SDK
[Tue May 24 18:39:25 2005] [notice] LDAP: SSL support unavailable
[Tue May 24 18:39:25 2005] [notice] FastCGI: process manager initialized
(pid 7896)
[Tue May 24 18:39:25 2005] [warn] FastCGI: server
“/opt/rt3/bin/mason_handler.fcgi” started (pid 7897)
[Tue May 24 18:39:25 2005] [notice] mod_python: Creating 4 session
mutexes based on 256 max processes and 0 max threads.
[Tue May 24 18:39:25 2005] [notice] Apache/2.0.52 (Red Hat) configured

  • – resuming normal operations
    [Tue May 24 18:39:26 2005] [warn] FastCGI: server
    “/opt/rt3/bin/mason_handler.fcgi” started (pid 7907)
    [Tue May 24 18:39:27 2005] [warn] FastCGI: server
    “/opt/rt3/bin/mason_handler.fcgi” started (pid 7911)
    [Tue May 24 18:39:28 2005] [warn] FastCGI: server
    “/opt/rt3/bin/mason_handler.fcgi” started (pid 7914)

I have been working on this for so long now I am starting to think there
is no forest… there are only trees. Do you see anything glaringly
wrong here?


Chuck Mead csm@redhat.com
Instructor II (and resident Postfix bigot), GLS
Disclaimer: “It’s Thursday and my name is Locutus of B0rk!”
Addendum: “Bwahahaha! Fire up the orbital mind-control lasers!”

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFCk6/0Zfy0juH51WsRAl4aAJ9WjjO7p/PRkBq2937Dg+HG32c1zwCfadtI
FxS5wmuPyR0/dokmnc+5Pvw=
=62oA
-----END PGP SIGNATURE-----

Yes… I ran this:

And what was the output from the scripts? What exact errors are you
seeing?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jesse Vincent wrote:

Yes… I ran this:

And what was the output from the scripts? What exact errors are you
seeing?

After running that and getting errors splatted all over the place it
fails to run and the apache logs are reporting that there is no users
database.

First things first… (once my current effort is working properly I will
attempt to do an upgrade to 3.4.2)

I am working at getting a working install of rt-3-0-7_01.

I sent the config up for this a while ago… it IS working with the
database from the original host pulled in via “psql -f dump.db”.

There are a couple of problems though…

  1. When I click logout I get the following error in the browser:

(Note: I have to freeze the browser with the escape key to see this as
it passes quite quickly otherwise)

The URL showing is: http://glsrt.gls.redhat.com/NoAuth/Logout.html

The main window of the browser shows:

%# BEGIN LICENSE BLOCK %# %# Copyright (c) 1996-2003 Jesse Vincent %# %#
(Except where explictly superceded by other copyright notices) %# %#
This work is made available to you under the terms of Version 2 of %#
the GNU General Public License. A copy of that license should have %#
been provided with this software, but in any event can be snarfed %#
from www.gnu.org. %# %# This work is distributed in the hope that it
will be useful, but %# WITHOUT ANY WARRANTY; without even the implied
warranty of %# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
the GNU %# General Public License for more details. %# %# Unless
otherwise specified, all modifications, corrections or %# extensions to
this work which alter its source code become the %# property of Best
Practical Solutions, LLC when submitted for %# inclusion in the work. %#
%# %# END LICENSE BLOCK

<&|/l&>You have been logged out of RT.

<&|/l&>You’re welcome to login again <%PERL> if (defined %session) {
tied(%session)->delete; } $m->abort(); <%ARGS> $URL => $RT::WebPath.“/”

After this screen the browser settles to this URL:

http://glsrt.gls.redhat.com/NoAuth/<%$URL%>

And text in the browser window that says:

Bad Request

Your browser sent a request that this server could not understand.

  1. When I click the “Home” link from the left hand side I get the
    dreaded “You’re almost there!” message.

Both of these errors occur in spite of the fact that RT is actually
working otherwise… I can manipulate data in the interface etc.

Here is my current apache configuration:

NameVirtualHost 172.16.62.89:80

<VirtualHost 172.16.62.89:80>
ServerAdmin root@glsrt.gls.redhat.com
ServerName glsrt.gls.redhat.com
DocumentRoot /var/www/html/
AddDefaultCharset UTF-8
AddHandler fastcgi-script fcgi
<Directory “/opt/rt3/share/html”>
Options FollowSymLinks ExecCGI
AllowOverride None

#Pass through requests for noauth
<Location /NoAuth/images >
SetHandler default-handler

Alias /NoAuth/ /opt/rt3/share/html/NoAuth/
ScriptAlias / /opt/rt3/bin/mason_handler.fcgi/
DirectoryIndex index.html

FastCgiIpcDir /tmp
FastCgiServer /opt/rt3/bin/mason_handler.fcgi -idle-timeout 120 -processes 6

This is setup with fastcgi as you can see and I have no idea what to do
to fix these problems.


Chuck Mead csm@redhat.com
Instructor II (and resident Postfix bigot), GLS
Disclaimer: “It’s Thursday and my name is Locutus of B0rk!”
Addendum: “Bwahahaha! Fire up the orbital mind-control lasers!”

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFCk9CwZfy0juH51WsRAtjnAJ9cAHBzKZklkb0mWYdDku5VUHuNlgCfQRpD
EtBlngTw8H+wqq6EpVD6Z6E=
=yC51
-----END PGP SIGNATURE-----

First things first… (once my current effort is working properly I will
attempt to do an upgrade to 3.4.2)

I am working at getting a working install of rt-3-0-7_01.

I’d probably start with 3.0.12, not 3.0.7_01. That’s 5 patch releases
back, two stable release cycles ago.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jesse Vincent wrote:

First things first… (once my current effort is working properly I will
attempt to do an upgrade to 3.4.2)

I am working at getting a working install of rt-3-0-7_01.

I’d probably start with 3.0.12, not 3.0.7_01. That’s 5 patch releases
back, two stable release cycles ago.

Yeah… but guess what version my existing database is?


Chuck Mead csm@redhat.com
Instructor II (and resident Postfix bigot), GLS
Disclaimer: “It’s Thursday and my name is Locutus of B0rk!”
Addendum: “Bwahahaha! Fire up the orbital mind-control lasers!”

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFCk9M5Zfy0juH51WsRAqw6AKCgBrxbv3h/x2a7CGBKp11YDu2NPgCfXVHO
opcL6i7F0N/FuUHqWL0qL1U=
=buge
-----END PGP SIGNATURE-----

I’d probably start with 3.0.12, not 3.0.7_01. That’s 5 patch releases
back, two stable release cycles ago.

Yeah… but guess what version my existing database is?

Within a stable series, the database schema should not change.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chuck Mead wrote:

Jesse Vincent wrote:

First things first… (once my current effort is working properly I will
attempt to do an upgrade to 3.4.2)

I am working at getting a working install of rt-3-0-7_01.

I’d probably start with 3.0.12, not 3.0.7_01. That’s 5 patch releases
back, two stable release cycles ago.

Yeah… but guess what version my existing database is?

Also… #2 from my problem description may be ignored… I cleared my
browsers cache and that problem went away.

Problem #1 is still in effect.


Chuck Mead csm@redhat.com
Instructor II (and resident Postfix bigot), GLS
Disclaimer: “It’s Thursday and my name is Locutus of B0rk!”
Addendum: “Bwahahaha! Fire up the orbital mind-control lasers!”

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFCk9QMZfy0juH51WsRAoH7AKCmOF5muOpbDhR7/s6Ieat1VKGRrACgkX4v
jkXVGoOx1eVV0mtHWpoVTbA=
=348B
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jesse Vincent wrote:

First things first… (once my current effort is working properly I will
attempt to do an upgrade to 3.4.2)

I am working at getting a working install of rt-3-0-7_01.

I’d probably start with 3.0.12, not 3.0.7_01. That’s 5 patch releases
back, two stable release cycles ago.

So can I just do a code upgrade?


Chuck Mead csm@redhat.com
Instructor II (and resident Postfix bigot), GLS
Disclaimer: “It’s Thursday and my name is Locutus of B0rk!”
Addendum: “Bwahahaha! Fire up the orbital mind-control lasers!”

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFCk9QuZfy0juH51WsRAko6AKCUhYOYwScxMVr5UC5AMrBCuIvmgQCfahU/
Fa48AtIcvqG4PUVHUDv8JNE=
=DBmg
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jesse Vincent wrote:

I’d probably start with 3.0.12, not 3.0.7_01. That’s 5 patch releases
back, two stable release cycles ago.

Yeah… but guess what version my existing database is?

Within a stable series, the database schema should not change.

Okay… I am now on 3.0.12.

NB. I still have the error when I click the log out link.

Tomorrow I will start looking at continuing the upgrade cycle.


Chuck Mead csm@redhat.com
Instructor II (and resident Postfix bigot), GLS
Disclaimer: “It’s Thursday and my name is Locutus of B0rk!”
Addendum: “Bwahahaha! Fire up the orbital mind-control lasers!”

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFCk+RmZfy0juH51WsRAg9fAKCJ48prkw8dH8rrA3CQGpHEPn0JGQCgpbhm
qwVtFwCc4O8Z8QCt0MXkJ5M=
=F3+D
-----END PGP SIGNATURE-----