Random logouts in RT 3.8.2

Hi,

We are having a problem with our freshly installed RT 3.8.2 under Suse
Linux ES 10.
The setup ran fine, the queues and tickets made for testing were accessable.

Now we try to get our old database from 3.6.1 into the new instance of RT.
The dump imports into mysql 5.0.26 and the update-script works without
error-messages.

But when clicking any ticket via the quick search field, the
user-account gets logged out. This didn’t happen before with the fresh
database, but only now after importing the dumpfile.

This problem didn’t occur under RT 3.6.1 with the old database.

I think, this is cookie-related, since just before the accounts get
logged out, a new cookie gets placed in the browser. When I log back
into RT, I get the page displayed, that I requested before.

When using the normal search field to directly enter the ticket number
or clicking via “My Day”, the ticket gets displayed correctly and no
random logout happens.

Thank you for your help,

Tobi

Try changing the “Type” for “a_session” under sessions to longblob

Hossein

Tobias Ramin wrote:

Hi,

We are having a problem with our freshly installed RT 3.8.2 under Suse
Linux ES 10.
The setup ran fine, the queues and tickets made for testing were accessable.

Now we try to get our old database from 3.6.1 into the new instance of RT.
The dump imports into mysql 5.0.26 and the update-script works without
error-messages.

But when clicking any ticket via the quick search field, the
user-account gets logged out. This didn’t happen before with the fresh
database, but only now after importing the dumpfile.

This problem didn’t occur under RT 3.6.1 with the old database.

I think, this is cookie-related, since just before the accounts get
logged out, a new cookie gets placed in the browser. When I log back
into RT, I get the page displayed, that I requested before.

When using the normal search field to directly enter the ticket number
or clicking via “My Day”, the ticket gets displayed correctly and no
random logout happens.

Thank you for your help,

Tobi


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

_____ _____ _____ _ _ _ _ ____ Hossein Rafighi
|_ || _ \ | || | | || _/ || __|TRIUMF, 4004 Wesbrook Mall
| | | |
| ) | | | | | || || |__ Vancouver BC, Canada, V6T 2A3
| | | _ / | | | _/ || _/ || |Voice: (604) 222-1047
| | | | \ \ | | | || | | || | Fax: (604) 222-1074
|| || _|
_| _/ || |||_| Website: http://www.triumf.ca

Try changing the “Type” for “a_session” under sessions to longblob

If this is the problem and he doesn’t follow the instructions in
UPGRADING.mysql,
he will run into worse problems.

It is better to recommend that people do the full upgrade rather than
just
fixing sessions

-kevin

Now we try to get our old database from 3.6.1 into the new instance of RT.
The dump imports into mysql 5.0.26 and the update-script works without
error-messages.

Once again: when you ran “upgrade-mysql-schema.pl”, it did not actually
upgrade the mysql schema. That script generates queries that you must
capture to a file, and then run THAT file to actually upgrade the schema.

– ============================
Tom Lahti
BIT Statement LLC

(425)251-0833 x 117
http://www.bitstatement.net/
– ============================

Thank you very much, that did the trick!
I should have read the UPGRADING.mysql more carefully…

Best regards,

Tobi

Tom Lahti schrieb: