Moved Database, now cannot create sessions

RT Users
1

I’m moving my devel database to a second server and separating it from the
server RT actually runs on. However, after doing so and updating the
RT_SiteConfig.pm I get the following:

error: RT couldn’t store your session.
This may mean that that the directory ‘/usr/local/rt3/var/session_data’ isn’t
writable or a database table is missing or corrupt.

context:
…
86: };
87: undef $cookies{$cookiename};
88: }
89: else {
90: die loc(“RT couldn’t store your session.”) . “\n”
91: . loc(
92: “This may mean that that the directory ‘[_1]’ isn’t writable or a database
table is missing or corrupt.”,
93: $RT::MasonSessionDir
94: )
…
code stack: /usr/local/rt3/local/html/Elements/SetupSessionCookie:90
/usr/local/rt3/share/html/autohandler:120

I’ve verified the permissions and ownership for the directory. What else might
I need to look at?

Keep up with me and what I’m up to: http://theillien.blogspot.com

2

I’m guessing the problem here is that MySQL is trying to write the session data
to this directory. However, with the database now on another server it clearly
doesn’t have access to it. Is this correct?

Keep up with me and what I’m up to: http://theillien.blogspot.com

Mathew Snyder wrote:

3

I figured out that I need to use the session file instead of the database. I
linked the error together with what I found in RT_SiteConfig.pm.

Now I can get the login screen but can’t login. I’m guessing that the remote
database isn’t being located/connected to.

Keep up with me and what I’m up to: http://theillien.blogspot.com

Mathew Snyder wrote:

4

It should actually be the web server process that is trying to write to
the directory, not MySQL, if you’re using Apache::Session::File. Have
you changed the WebSessionClass in your RT_SiteConfig.pm? It should be
trying to save to the MySQL DB, and not /usr/local/rt3/var/session_data,
unless you have changed it.

$WebSessionClass is the class you wish to use for managing Sessions.

It defaults to use your SQL database, but if you are using MySQL 3.x

and

plans to use non-ascii Queue names, uncomment and add this line to

RT_SiteConfig.pm will prevent session corruption.

Set($WebSessionClass , ‘Apache::Session::File’);

If the Set line is still commented out, or not defined in your
RT_SiteConfig.pm, you might want to check the permissions on your
sessions table, and make sure the structure is correct on it.

Jacob Helwig
PC Technician
Busch’s Help Desk
Desk: x35221
Direct: 734-214-8221From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Mathew
Snyder
Sent: Thursday, October 04, 2007 9:05 AM
To: Mathew Snyder
Cc: RT Users
Subject: Re: [rt-users] Moved Database, now cannot create sessions

I’m guessing the problem here is that MySQL is trying to write the
session data
to this directory. However, with the database now on another server it
clearly
doesn’t have access to it. Is this correct?

Keep up with me and what I’m up to: http://theillien.blogspot.com

Mathew Snyder wrote:

I’m moving my devel database to a second server and separating it from
the
server RT actually runs on. However, after doing so and updating the
RT_SiteConfig.pm I get the following:

error: RT couldn’t store your session.
This may mean that that the directory
‘/usr/local/rt3/var/session_data’ isn’t
writable or a database table is missing or corrupt.

context:
…
86: };
87: undef $cookies{$cookiename};
88: }
89: else {
90: die loc(“RT couldn’t store your session.”) . “\n”
91: . loc(
92: “This may mean that that the directory ‘[_1]’ isn’t writable or
a database
table is missing or corrupt.”,
93: $RT::MasonSessionDir
94: )
…
code stack: /usr/local/rt3/local/html/Elements/SetupSessionCookie:90
/usr/local/rt3/share/html/autohandler:120

I’ve verified the permissions and ownership for the directory. What
else might
I need to look at?

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

5

Most likely, RT can’t talk to the database on the remote server. Have you
verified database rights on the remote server? Do you have Selinux enabled
on either server?

James Moseley

         Mathew Snyder                                                 
         <theillien@yahoo.                                             
         com>                                                       To 
         Sent by:                  Mathew Snyder <theillien@yahoo.com> 
         rt-users-bounces@                                          cc 
         lists.bestpractic         RT Users                            
         al.com                    <rt-users@lists.bestpractical.com>  
                                                               Subject 
                                   Re: [rt-users] Moved Database, now  
         10/04/2007 08:10          cannot create sessions              
         AM

I figured out that I need to use the session file instead of the database.
I
linked the error together with what I found in RT_SiteConfig.pm.

Now I can get the login screen but can’t login. I’m guessing that the
remote
database isn’t being located/connected to.

Keep up with me and what I’m up to: http://theillien.blogspot.com

Mathew Snyder wrote:

I’m guessing the problem here is that MySQL is trying to write the
session data
to this directory. However, with the database now on another server it
clearly
doesn’t have access to it. Is this correct?

Keep up with me and what I’m up to: http://theillien.blogspot.com

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

6

Matthew;
It sounds to me you forgot to :

GRANT SELECT,INSERT,CREATE,INDEX,UPDATE,DELETE ON ${RT::DatabaseName}.*
TO ${RT::DatabaseUser}@’${RT::DatabaseRTHost}’ IDENTIFIED BY
’${RT::DatabasePassword}’
;");

Roy

Mathew Snyder wrote:

7

I ran
GRANT ALL ON rt_database.* to ‘rt_user’@‘rt_server’ IDENTIFIED BY ‘rt_password’
when I first migrated it. It didn’t work. I then actually went through the
process of installing RT on the database server in order to utilize make initialize-database. This didn’t work either.

Keep up with me and what I’m up to: http://theillien.blogspot.com

Roy El-Hames wrote:

8

Have you poked a hole for tcp 3306 in the firewall on your new db server?

Mathew Snyder wrote:

9

Well thats your answer Mathew, unless you grant the permissions RT is
not going to work for you…
What errors are you getting when you granting permissions??

Roy

Mathew Snyder wrote:

10

Let me clarify. I ran that query and added the user. However, this did not
make RT work. The query itself did, though.

Keep up with me and what I’m up to: http://theillien.blogspot.com

Roy El-Hames wrote:

11

No need. When installing MySQL via rpm or when installing Red Hat this is
automatically taken care of. But to be sure, I connected to it using the mysql
shell from another host.

Keep up with me and what I’m up to: http://theillien.blogspot.com

Drew Barnes wrote:

12

Ah ok sorry …
When you logged in via sql from another host did you login as the rt
user and the rt password??
Have you got logging enabled on your sql server and debug level logging
on RT? what is in the log files??
Roy

Mathew Snyder wrote:

13

this is the block of error that comes up when trying to connect:

[Thu Oct 4 13:10:21 2007] [warning]: DBD::mysql::st execute failed: SELECT
command denied to user ‘rt_user’@‘rtdev01.company.com’ for table ‘Users’ at
/usr/lib/perl5/vendor_perl/5.8.8/DBIx/SearchBuilder/Handle.pm line 505,
line 3. (/usr/lib/perl5/vendor_perl/5.8.8/DBIx/SearchBuilder/Handle.pm:505)
[Thu Oct 4 13:10:21 2007] [warning]: RT::Handle=HASH(0x8217ce58) couldn’t
execute the query ‘SELECT * FROM Users WHERE Name = ?’ at
/usr/lib/perl5/vendor_perl/5.8.8/DBIx/SearchBuilder/Handle.pm line 518
DBIx::SearchBuilder::Handle::SimpleQuery(‘RT::Handle=HASH(0x8217ce58)’,
‘SELECT * FROM Users WHERE Name = ?’, ‘msnyder’) called at
/usr/lib/perl5/vendor_perl/5.8.8/DBIx/SearchBuilder/Record.pm line 1208

DBIx::SearchBuilder::Record::_LoadFromSQL(‘RT::CurrentUser=HASH(0x82e93408)’,
‘SELECT * FROM Users WHERE Name = ?’, ‘msnyder’) called at
/usr/lib/perl5/vendor_perl/5.8.8/DBIx/SearchBuilder/Record.pm line 1127

DBIx::SearchBuilder::Record::LoadByCols(‘RT::CurrentUser=HASH(0x82e93408)’,
‘Name’, ‘msnyder’) called at
/usr/lib/perl5/vendor_perl/5.8.8/DBIx/SearchBuilder/Record/Cachable.pm line 119

DBIx::SearchBuilder::Record::Cachable::LoadByCols(‘RT::CurrentUser=HASH(0x82e93408)’,
‘Name’, ‘msnyder’) called at /usr/local/rt3/lib/RT/Record.pm line 402
RT::Record::LoadByCols(‘RT::CurrentUser=HASH(0x82e93408)’, ‘Name’,
‘msnyder’) called at
/usr/lib/perl5/vendor_perl/5.8.8/DBIx/SearchBuilder/Record.pm line 1072

DBIx::SearchBuilder::Record::LoadByCol(‘RT::CurrentUser=HASH(0x82e93408)’,
‘Name’, ‘msnyder’) called at /usr/local/rt3/lib/RT/CurrentUser.pm line 287
RT::CurrentUser::Load(‘RT::CurrentUser=HASH(0x82e93408)’, ‘msnyder’)
called at /usr/local/rt3/share/html/autohandler line 245
HTML::Mason::Commands::ANON(‘Error’, ‘Your username or password is
incorrect’, ‘pass’, ‘password’, ‘user’, ‘msnyder’) called at
/usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Component.pm line 135

HTML::Mason::Component::run(‘HTML::Mason::Component::FileBased=HASH(0x819bc5ec)’,
‘Error’, ‘Your username or password is incorrect’, ‘pass’, ‘password’, ‘user’,
‘msnyder’) called at /usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Request.pm line
1246
eval {…} called at
/usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Request.pm line 1245
HTML::Mason::Request::comp(‘undef’, ‘undef’, ‘undef’, ‘Error’, ‘Your
username or password is incorrect’, ‘pass’, ‘password’, ‘user’, ‘msnyder’, …)
called at /usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Request.pm line 459
eval {…} called at
/usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Request.pm line 459
eval {…} called at
/usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Request.pm line 411

HTML::Mason::Request::exec(‘HTML::Mason::Request::ApacheHandler=HASH(0x82e958bc)’)
called at /usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/ApacheHandler.pm line 168

HTML::Mason::Request::ApacheHandler::exec(‘HTML::Mason::Request::ApacheHandler=HASH(0x82e958bc)’)
called at /usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/ApacheHandler.pm line 826

HTML::Mason::ApacheHandler::handle_request(‘HTML::Mason::ApacheHandler=HASH(0x821766f8)’,
‘Apache2::RequestRec=SCALAR(0x82aba4d8)’) called at /usr/local/rt3/bin/webmux.pl
line 125
eval {…} called at /usr/local/rt3/bin/webmux.pl line 125
RT::Mason::handler(‘Apache2::RequestRec=SCALAR(0x82aba4d8)’) called at
-e line 0
eval {…} called at -e line 0 (/usr/lib/perl5/5.8.8/Carp.pm:272)
[Thu Oct 4 13:10:21 2007] [error]: FAILED LOGIN for msnyder from 192.168.4.118
(/usr/local/rt3/share/html/autohandler:251)

This is all that is in /var/log/mysqld.log:
071004 11:19:10 InnoDB: Starting shutdown…
071004 11:19:11 InnoDB: Shutdown completed; log sequence number 5 3271909341
071004 11:19:11 [Note] /usr/libexec/mysqld: Shutdown complete

071004 11:19:11 mysqld ended

071004 11:19:12 mysqld started
071004 11:19:12 InnoDB: Started; log sequence number 5 3271909341
071004 11:19:12 [Warning] Neither --relay-log nor --relay-log-index were used;
so replication may break when this MySQL server acts as a slave and has his
hostname changed!! Please use ‘–relay-log=rtdev02-relay-bin’ to avoid this problem.
071004 11:19:12 [ERROR] Failed to open the relay log
‘./rt-devel-relay-bin.000008’ (relay_log_pos 98)
071004 11:19:12 [ERROR] Could not find target log during relay log initialization
071004 11:19:12 [ERROR] Failed to initialize the master info structure
071004 11:19:12 [Note] /usr/libexec/mysqld: ready for connections.
Version: ‘5.0.22-log’ socket: ‘/var/lib/mysql/mysql.sock’ port: 3306 Source
distribution

Roy El-Hames wrote:

14

I have no idea what happened but I pointed the RT host to the new database
server again and restarted httpd again. This time it seems to have worked.

I wish I knew what I did that fixed it.

Keep up with me and what I’m up to: http://theillien.blogspot.com

Roy El-Hames wrote: