[rt-users] Login fails after reinstall of RT 3.4.4
Luke Vanderfluit
lvanderf at internode.com.au
Mon Nov 7 01:16:46 EST 2005
Hi.
Not sure if this will help you but it might:
Execute this SQL command to reset the root password to 'password'.
update Users set Password='X03MO1qnZdYdgyfeuILPmQ' where Name='root';
hth.
Kind regards.
Luke
Scott Courtney wrote:
>Good evening, all
>
>Preface: I'm probably doing something stupid. I've been an RT user for several
>years, but only recently started administering. OTOH, I have been all over the
>list archives, "RT Essentials", and Google, looking for a solution to this, and
>I'm stumped.
>
>I had a perfectly good, working installation of RT 3.4.4 under Perl 5.8.5-12 on
>RHEL 4. I did a routine security update (via "up2date") of Perl itself, from
>5.8.5-12 to 5.8.5-16, and this blasted my RT installation.
>
>I've spent the last two days figuring out what went wrong, have reinstalled
>RT, reinvented the wheel of getting Mason to find its documents (I'll bet you
>all are sick of seeing *that* question in the list). Ironically, when I solved
>that one before, I carefully documented what I had done...in RT. Ouch. Next
>time I'll print that ticket out. {GRIN}
>
>Anyway, after about 10 hours of work, I'm back to the point of having RT up
>and running as far as the login screen, but I can't login. That's where I'm
>stuck.
>
>I have verified that cookies are enabled in my browser for this domain, and
>that RT is able to access the database for both read and update. I have
>two known-good userids, and I've checked that the MD5 password in the Users
>table matches the MD5 of what I thought was the password. I have verified
>that the Mason directory and the session data directory are being written
>to by RT, which creates files there. And I've verified that sessions are
>being created in the corresponding database table.
>
>There are no errors in the Apache logs. I've tried stopping Apache, flushing
>the sessions table and Mason cache files, then restarting Apache.
>
>A search of the archives of this list found that this problem could be caused
>by a server's timezone not matching the timezone in the RT_SiteConfig.pm file.
>It turns out I had that error, and I've since fixed it by copying my old
>site config file back to the $PREFIX/etc/ directory. After doing this, I
>repeated the stop-flush_everything-restart sequence (see above). I've also
>tried two different browsers, and restarting the browser, and forcing the
>browser to delete all cookies.
>
>The only oddity I see is that the sessions table, while it does have rows
>for sessions, has nothing in the a_session colum for any of them. Could
>this be a clue? If so, to what? I have verified that the times stored in
>the sessions table match the time the server reports.
>
>I would appreciate any help with this. It's especially frustrating because
>I had a wonderfully working installation, and what I thought would be a
>trivial security update to Perl broke it so badly. Is there a good way
>to turn up logging verbosity on the authentication process?
>
>Versions:
>RT 3.4.4
>Perl 5.8.5-16 installed from RHEL 4 RPMs
>Apache 2.0.55 built from source
>mod_perl 2.0.2 built from source
>MySQL 5.0.15 installed from official RPMs
>
>Incidentally, the versions of everything except Perl were all working before
>the problem arose, so I can rule out compatibility problems with that new
>version of MySQL.
>
>Thanks very much for any suggestions.
>
>Kind regards,
>
>Scott
>
>
>
--
Luke
More information about the rt-users
mailing list