Jump to content

[SOLVED] need help getting mysql to accept outside connections.


Recommended Posts

I am trying to set up my database so that a script I am running on another server can access the main database.  my my.cnf has 

 

#skip-networking

 

So it should listen for TCP IP connections.  but when I set the connection information to:

 

define("DB_SERVER", "axxxxx.org");

define("DB_USER", "xxxxxxxx");

define("DB_PASS", "xxxxxl");

define("DB_NAME", "xxxxs");

 

I get the error:

 

Warning: mysql_connect() [function.mysql-connect]: Can't connect to MySQL server on 'altimagroup.org' (10061) in C:\xampp\htdocs\xxxxxs\x.php on line 6

Can't connect to MySQL server on 'axxxxxx.org' (10061)

 

any ideas?

Try telnetting to mysql from the remote machine to the mysql server (have to install as an extra option if you use Vista on remote machine).  Syntax should be "telnet 192.168.1.18 3306" and you should get some garbage characters back.  Thats step #1, just make sure you can talk to the mysql server and that the port isnt being blocked. 

 

After that, it ends up being a permissions issue.  MySql has a field called HOST for the hosts that are allowed to connect to it from said host.  For example, ROOT should be a LOCALHOST only, and other users can be specified to specific hosts.

Thanks, Looks like I am connecting to the host in that I get some garbaly-gook back, then connection lost.  So now I am down to the permissions. I have the following set up on the host mysql

user        Host        Password    Global privileges    grant

brian        %            Yes              All Privileges        Yes

brian        alxxx.org    Yes              All Privileges        Yes

 

 

I am at a loss to know what I need to do know.  I think that either of the two would allow me in.  the connection stuff in php looks like this.

 

define("DB_SERVER", "alxxxxx.org:3306");

define("DB_USER", "brian");

define("DB_PASS", "xxxxxxl");

define("DB_NAME", "xxxxx");

 

small update.  I set up for a minute that any user, any host with no password could connect and still get the error on the connection.  I see that it can talk to the database on 3306 so its not being blocked.  this has to be some simple, stupid setting somewhere.  I have the line "skip-network" commented out as #skip-network. (don't have the # in front then not even the local host will connect.).  uggg

Welll apparently I was wrong.  I  did an online port scan and it tells me that its not responding on 3306 (when I telnet through local command line I get a response.)

 

I have tried looking through the windows 7 port settings but it looks like it should be able to see the mysql.  I am at a loss to know what to do at this point.

Try telnetting to mysql from the remote machine...

 

when I telnet through local command line I get a response.

I hope that does not mean that the "Looks like I am connecting to the host..." was done locally?

 

Back when you setup and got your web server so that it would accept external requests, do you remember configuring your router so that it would forward port 80 to the computer running the web server? You need to do the same with port 3306.

thanks, now I feel like such an idiot  :facewall:

 

I thought i had everything set up as needed on the router; but I was wrong.  You made my day so much better.  Now I can get to it from the other machines.

 

Thanks

 

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.