So, I’m boppin’ along on my Ruby on Rails website, just screwin’ around with a few migrations, trying to decide how I want things to work. Stuff looks good, so I go to check in. But, in the meantime, my partner on the site as done an update, so I pull down the newest stuff. I then go re-run my migrations and tests (just to be sure), and get an error:
ERROR 1130 (00000): Host 'd-48-91-542-192.hsd1.mn.comcast.net' is not allowed to connect to this MySQL server
“Odd,” I say to myself, “Why can’t I connect to my localhost database? And how is it figuring out my external IP address?” And that’s when it dawns on me.
I was firing at production.
Good times.
A quick check confirms my suspicion: the last update screwed up some configuration, which set my environment to “production”.
If it weren’t for my hyper-paranoid configuration of MySQL, this would have been Very Bad Times.
Just in case being our own coding horror wasn’t bad enough, we are apparently our own SysAdmin horrors, too.
One Comment
Heh. At work we use different names for production’s superuser account and development’s superuser account, with different passwords. And then I set up a special account which has select privileges on everything, but insert/update/delete privileges on nothing. I then set up my ~/.pgpass so I can log into development superuser or the read-only user without giving a password, but to log into development superuser I have to give a password.
This means that before I can do anything that might actually cause damage, I have to stop and type in a password- which forces me to stop and think. But I can jump on to production any time I want easily enough- in read only mode. Look, but don’t touch.
This has only saved my ass about three times… in the last seven days.
Also, backups, backups, backups. I haven’t yet had to recover from backups yet (I have recovered a couple of times just to make sure I could- I’m not paranoid, they are out to get me). It’s nice to know they’re there, however.