All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Can't connect to mysql after 5.5.25-1~dotdeb.0 update
Sorry if this isn't the place for this, but since I've upgraded my mysql server, I've been unable to connect to it from another VPS from the same provider. I have my IP tables setup, the my.cnf is still the same, and I can still connect to other ports (I've only tried 80) on the VPS where the server is running.
I have no idea how to debug this, and this is the only pertinent information I could think of to show anyone else.
This is the output of netstat -lnp | grep mysql on the server, so it looks like its listening everywhere, and iptables is handling who can connect, like it should.
dengus@prumpkins:/etc/mysql# netstat -lnp | grep mysql tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 1951/mysqld unix 2 [ ACC ] STREAM LISTENING 630605830 1951/mysqld /var/run/mysqld/mysqld.sock
And here's the rule I added to iptables so my client can connect.
/sbin/iptables -A INPUT -p tcp -m tcp -s 172.16.245.146 --dport 3306 -j ACCEPT
This is what happens why I try to connect from my usual client.
dengus@pruppets:~$ mysql -u thisisntmyactualusername -h 172.16.104.197 -p Enter password: ERROR 2003 (HY000): Can't connect to MySQL server on '172.16.104.197' (110)
And here's what happens when I try to connect with telnet.
dengus@pruppets:~$ telnet 172.16.104.197 3306 Trying 172.16.104.197... telnet: Unable to connect to remote host: Connection timed out
If it matters, I'm using buyvm.
Comments
Can you connect deleting all your iptables stuff?
There's not really much in there to begin with (just the default stuff on Debian 6, I guess). If it helps, there are my rules.
root@prumpkins:/etc/mysql# iptables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT tcp -- anywhere anywhere tcp spt:9001 ACCEPT tcp -- anywhere anywhere tcp dpt:9001 ACCEPT tcp -- anywhere anywhere tcp spt:www ACCEPT tcp -- anywhere anywhere tcp dpt:www ACCEPT tcp -- anywhere anywhere tcp spt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:domain ACCEPT tcp -- anywhere anywhere tcp spt:https ACCEPT tcp -- anywhere anywhere tcp dpt:https ACCEPT all -- anywhere anywhere DROP all -- anywhere anywhere state INVALID ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT tcp -- 172.16.245.146 anywhere tcp dpt:mysqlChain FORWARD (policy DROP) target prot opt source destination DROP all -- anywhere anywhere state INVALIDChain OUTPUT (policy ACCEPT) target prot opt source destination ACCEPT tcp -- anywhere anywhere tcp spt:9001 ACCEPT tcp -- anywhere anywhere tcp dpt:9001 ACCEPT tcp -- anywhere anywhere tcp spt:www ACCEPT tcp -- anywhere anywhere tcp dpt:www ACCEPT tcp -- anywhere anywhere tcp spt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:domain ACCEPT tcp -- anywhere anywhere tcp spt:https ACCEPT tcp -- anywhere anywhere tcp dpt:https ACCEPT all -- anywhere anywhere DROP all -- anywhere anywhere state INVALID ACCEPT all -- anywhere anywhere state NEW,RELATED,ESTABLISHEDAnd again, this was ALL working without issue until a day ago when I upgraded mysql.
I am not sure why you need all that rules if at the end you are not doing a full DROP.
Isn't the same as having nothing? Maybe I'm wrong.
Returning to the issue, I don't have idea.
I don't know, these are just the rules that were already set. I only added one.
Already set??? o_O!!!!
I don't have any rule set wtf.
I think whatever version of LES I ran may have set them. I just checked on some of my newer VPSs that I set up myself, and they were both empty, so you might be right about the iptables.
That said, I can still connect on other ports. 3306 is the only one that's acting up as far as I can tell.
You can try flushing your iptables rules to see if that's where the problem is
That's what I am trying to say him u_u
Still is weird.
I just tried and it kicked me off of SSH. I'd connect via the serial console, but that's kind of impossible right now, since buyvm's management panel is down at the moment...
And then there's still the fact that everything was working with the same exact iptable rules since August 2011.
oops :S
Sorry about that, I never notices your default INPUT chain policy is drop.
Btw, what BuyVM node you're on?
The VPS with mysql on it is on node45, and the client is on node41. Do you think they started blocking port 3306 from communicating internally or something on their end?
I don't think so.
I use it xD
No, I don't think so, I'm just wondering why you can't access Solus Stallion panel as it's working fine for me.
Once you do, try to clear your iptables rules again but first change your chain policy to ACCEPT
If if they're on the same node.
There's an annoyance in the US VPN setup we have that it breaks local node chatter
We have a fix but it's normally a 'one or the other' kind of deal.
Lemme know,
Francisco
@Francisco I'm not sure I completely understand. If they're on the same node there's an issue? Or if they're on different nodes? Also, the problem doesn't exist on port 80 as far as I can tell, 3306 is the only one having issues.
@vedran I'm going to try clearing iptables soon.
@manma - If they're on the same node you will have issues. It's a known issue. Let me know
Francisco
@Francisco They're actually on different nodes, which explains why I never had trouble before. I guess this problem is related to my mysql configuration then... Back to the drawing board I guess.
Make sure you don't have skip-networking
Francisco
Yeah, I thought about that. It isn't in my my.cnf, but I've heard that it can show up at random in other places. Chances are the latest package from dotdeb just magically enabled it in one of those undocumented places.
open a second terminal and run this command
tcpdump -i eth0 port 3306
Then try to get into your mysql remotely. Might have to install tcpdump before.
@FRCorey On the client or the server?
Client.
@Boltersdriveer Looks like I don't have anything named eth0. I'm assuming I should choose venet0:1 since its inet addr is the internal IP I'm connecting from, but I just want to make sure. venet0 seems to be ipv6 addresses, and venet:0:0 is my external IP.
@Fransisco So here's where I am now. I've erased my IP tables on the server, and I can connect via its internal IP.
Now, despite doing this, I seem to be connecting via my clients external IP, rather than its internal one, seemingly at random. Why this didn't happen/didn't cause trouble before, I don't know, but I'm not entirely sure what I did to cause this, as everything was working before. Any chance this could be on your end? They aren't on the same node as far as I know. Could one of the two VPSs have been moved even though Stallion still says they're on different nodes?
Anyways, I granted all permissions to my mysql user on my client's hostname, which I -guess- works internally, so everything's working fine, but I'd love to know whatever the heck caused all of this in the first place.