Posted: 4th December 2009 by Darren Cassar in Databases, MySQL, Networking, OS, Solaris
Tags: , , , , ,

A MySQL is running happily on a machine situated in a land far far away. I grant access to a user@machine_aaaaaa (grant select on db.* to ‘user’@’machine_aaaaa’ identified by ‘password’; flush privileges;), send an email to the user saying it should run fine and happily go off my way. Mistake!

It seems this user can’t connect to the mysql gets access denied:
Access denied for user ‘user’@’machine_bbbbb’ (using password: YES)

Note that the machine the user is being seen from is totally different from the one I set up in the grant!! WHY?

run a reverse lookup on the ip of machine_aaaaa, turns out it shows machine_bbbbb. So I figure a big bad guy messed up /etc/hosts, I was right! `cat /etc/hosts` just to find an entry for machine_aaaaa blehh

Ok, solution is to remove the entry from /etc/hosts (after finding out it wasn’t even necessary and wasn’t even supposed to be there in the first place), restart nscd.

AGAIN – Access denied for user ‘user’@’machine_bbbbb’ (using password: YES)

What the ….

What’s wrong now? — yeah silly me forgot to `flush hosts` :)

YOHOO I’m in!

I’ve seen quite a few blogs about disabling name resolve in mysql with skip-name-resolve and granting privileges using IPs – something which would also have avoided the above (but still not found the root of the problem):

VN:F [1.9.22_1171]
Rating: 10.0/10 (1 vote cast)
VN:F [1.9.22_1171]
Rating: +1 (from 1 vote)

MySQL – IP vs DNS, 10.0 out of 10 based on 1 rating

  1. [...] Read the full article the source. Share Code cache, databases, dns, grants, hosts, mysql, networking, os, [...]