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 …

Every so often we have a client worrying about unauthenticated users. For example, as part of the output of SHOW PROCESSLIST they will see:

+-----+----------------------+--------------------+------+---------+------+-------+------------------+
| Id  | User                 | Host               | db   | Command | Time | State | Info             |
+-----+----------------------+--------------------+------+---------+------+-------+------------------+
| 235 | unauthenticated user | 10.10.2.74:53216   | NULL | Connect | NULL | login | NULL             |
| 236 | unauthenticated user | 10.120.61.10:51721 | NULL | Connect | NULL | login | NULL             |
| 237 | user                 | localhost          | NULL | Query   | 0    | NULL  | show processlist |
+-----+----------------------+--------------------+------+---------+------+-------+------------------+

Who are these unauthenticated users, how do they get there, and why aren’t they …