[rt-users] Login/database connectivity

Anthony Sorace rt at anothy.9srv.net
Tue Dec 9 18:53:58 EST 2003


I've now done both an upgrade to 3.0.7_01, as well as a fresh install  
(saving full state frequently along the way, and skipping only the make  
initialize-database step), and the problem persists. I've reinstalled  
all the requisite perl modules (had problems with DBD, but it's in, and  
Apache::Request requires a force install, but I remember that being the  
case last time, too). There's an "RT" package, maintained by Jesse, in  
CPAN, but it's unavailable, and the CPAN web site has no info on it.  
This seems potentially related to the "RT::CurrentUser" stuff hitting  
the database logs (see below).

I'm working from the theory that "RT::CurrentUser" is supposed to pass  
the user name I give the login page to the database (possibly after  
some transformation), and that's not happening.

Also, I'm unable to get rt3 to produce any logging information at all.  
I can make the whole thing fail to run (and return a server error) if I  
change permissions on the directory, and it creates the file, but it  
never puts anything in it, despite having $LogToFile set to 'debug' in  
RT_SiteConfig.pm. Suggestions here?

Begin forwarded message:

> From: Anthony Sorace <rt at anothy.9srv.net>
> Date: December 9, 2003 6:30:04 PM GMT+00:00
> To: rt-users at lists.fsck.com
> Subject: [rt-users] Login/database connectivity
>
> Over the weekend, I updated the Mac OS X server running our RT3  
> instance. The results... were not positive. :-)
>
> Everything *seems* to be working properly... other things that rely on  
> the database function, the web server's running... even mason and  
> mod_perl seem to be working, as we get the login page fine. still,  
> something's amiss: whenever any user, including the superuser, tries  
> to log in, they're immediately presented back with the login page.
>
> I've turned on logging for MySQL (sadly, I don't have pre-upgrade logs  
> to compare to), an found the problem on one level, at least. This is  
> the log for a user "antonio" attempting to log in:
>
> 031209 18:19:16     144 Connect     rt_user at localhost on rt3
>                     144 Query       SELECT  * FROM Users WHERE Name =  
> 'RT_System'
>                     144 Query       SELECT  * FROM Users WHERE Name =  
> 'Nobody'
>                     144 Query       SELECT  
> GET_LOCK('Apache-Session-c159f8d7bbab4b0f9a177b520198df47', 3600)
>                     144 Query       SELECT a_session FROM sessions  
> WHERE id = 'c159f8d7bbab4b0f9a177b520198df47'
>                     144 Query       SELECT  * FROM Users WHERE Name =  
> 'RT::CurrentUser=HASH(0x903ce8)'
>                     144 Query       UPDATE sessions SET a_session =  
> '\0\0\0\n c159f8d7bbab4b0f9a177b520198df47\0\0\0
>                                                                         
>                                               
> _session_idRT::CurrentUser\0\0\0\0\0\?\0\0\0\rfast_update_? 
> \0\0\0\rcache_for_se?\0\0\0cache_p\0\0\0
>                       _CacheConfig\0\0\0\nid\0\0\0
>                                                   _PrimaryKeys
>                                                                
> RT::I18N:: 
> en\0\0\0\0\0\0\0\nLangHandle\nUsers\0\0\0table\0\0\0\0\0\0\0user\0\0\0
>                                                                         
>                                                                         
> CurrentUser' WHERE id = 'c159f8d7bbab4b0f9a177b520198df47'
>                     144 Query       SELECT  
> RELEASE_LOCK('Apache-Session-c159f8d7bbab4b0f9a177b520198df47')
>                     145 Connect     rt_user at localhost on rt3
>                     145 Query       SELECT  * FROM Users WHERE Name =  
> 'RT_System'
>                     145 Query       SELECT  * FROM Users WHERE Name =  
> 'Nobody'
> 031209 18:19:17     145 Query       SELECT  
> GET_LOCK('Apache-Session-c159f8d7bbab4b0f9a177b520198df47', 3600)
>                     145 Query       SELECT a_session FROM sessions  
> WHERE id = 'c159f8d7bbab4b0f9a177b520198df47'
>                     145 Query       UPDATE sessions SET a_session =  
> '\0\0\0\n c159f8d7bbab4b0f9a177b520198df47\0\0\0
>                                                                         
>                                               
> _session_idRT::CurrentUser\0\0\0\0\0\?\0\0\0\rfast_update_? 
> \0\0\0\rcache_for_se?\0\0\0cache_p\0\0\0
>                       _CacheConfig\0\0\0\nid\0\0\0
>                                                    
> _PrimaryKeys\nUsers\0\0\0table\0\0\0\0\0\0\0user\0\0\0
>                                                                         
>                                  CurrentUser' WHERE id =  
> 'c159f8d7bbab4b0f9a177b520198df47'
>                     145 Query       SELECT  
> RELEASE_LOCK('Apache-Session-c159f8d7bbab4b0f9a177b520198df47')
>
> Note, in particular, the multiple queries like "SELECT  * FROM Users  
> WHERE Name = " asking for "RT_System" and "Nobody", but nothing  
> mentioning "antonio". His data's all correct, and can be checked using  
> the mysql command line utility. It looks like the  
> "RT::CurrentUser=HASH(0x903ce8)" on the fifth query down might be  
> related to my issue (clearly that's not a valid user name). Can anyone  
> suggest what this might be related to?
>
> Alternately, if anyone can tell me what hash function RT uses to  
> produce the user hash above, I'd like to verify my working theory by  
> checking to see if "antonio" indeed hashes to "0x903ce8".
>
> I'm using 3.0.6 with MySQL 4.0.14, Apache 1.3.28, Perl 5.8.1 RC3,  
> mod_perl 1.26.
>
> Any and all pointers much appreciated.
>
> Anthony Sorace
> CIBERNET Corp
> Director of Information Technology
>
> _______________________________________________
> rt-users mailing list
> rt-users at lists.fsck.com
> http://lists.fsck.com/mailman/listinfo/rt-users
>
> Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm




More information about the rt-users mailing list