[rt-users] Database relocated onto alternate server

[Keith A McDermott]

Thanks Odhiambo,

Yes - I can connect fine through the standard mysql tools from the same 
host without issue however, I was trying "rt_user" previously.  It 
actually does fail when connecting with "rt_user at hostname".  As I 
manually moved the database over, manually create the user and manually 
granted the rights (I don't want to run make initialize-database against 
our very stable and department-wide mysql server), I'll look through and 
see what else I need to do.

Keith

Odhiambo Washington wrote:
> On Tue, Mar 31, 2009 at 4:59 PM, Keith A McDermott 
> <kmcdermo at purdue.edu <mailto:kmcdermo at purdue.edu>> wrote:
>
>     Hi there,
>
>     I'm moving forward with my testing of RT 3.8.2.
>
>     Setup:
>     Virtual machine (Virtualbox) running RT3.8.2 in Debian Etch.  Web port
>     is forwarded to the virtual machine through the host but otherwise
>     there
>     is no access to the VM.  I moved the database onto a production
>     database
>     server.
>
>     RT_SiteConfig.pm has been altered to say:
>     $DatabaseHost is set to dbproductionserver
>     $DatabaseRTHost is set to the hostname of the vm host machine
>
>     Problem:
>     In the apache error logs, I get:
>     DBI connect('dbname=rt;host=dbproductionhost','rt_user',...) failed:
>     Access denied for user: 'rt_user at hostmachineHostname' (Using password:
>     YES) at /usr/local/share/perl/5.8.8/DBIx/SearchBuilder/Handle.pm
>     line 106
>     [Tue Mar 31 08:58:05 2009] [error] [client hostmachine.ip.goes.here]
>     Connect Failed Access denied for user: 'rt_user at hostmachineHostname'
>     (Using password: YES)\n at /opt/rt3/bin/../lib/RT.pm line 204\n
>
>     And I get a 500 server error page returned to me.  However, I can use
>     the mysql command line tools from the virtual machine and connect
>     just fine.
>
>     Is there possibly a port that's being expected to be open that i
>     need to
>     forward or something else that I'm missing?  This seemed like a pretty
>     straightforward change in the beginning...
>
>
> It should be straighforward just as you say.
> Have you tested manually connecting to the DB like:
>
> mysql -h dbproductionserver -urt_user at hostmachineHostname -pSec3t rt
>
> ?? Did it work?
>
> If not, then go to the dbproductionserver and give the necessary 
> privileges for rt_user to connect:
>
> mysql> GRANT ALL ON rt.* TO rt_user at hostmachineHostname IDENTIFIED BY 
> "Sec3t";
> mysql> flush privileges;
>
>
> -- 
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254733744121/+254722743223
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> "The only time a woman really succeeds in changing a man is when he is 
> a baby."
>                              - Natalie Wood