Blog

Yesterday, I quietly switched this site over from its old Apache server to the much more lightweight combination of nginx + XCache.  As someone who has worked with Apache servers for roughly 14 years now, the thought of moving my personal site to a server environment that I didn’t know how to troubleshoot in great detail was terrifying.  But you start becoming irrelevant the second you allow yourself to stop learning new things.  So I took a play from the Ol’ Jack Burton playbook and said “what the hell?“.

Surprisingly, it’s still chugging along without any complaints.  Most of the thanks for that goes to DreamHost‘s default nginx config and easy to follow tutorial tho.

All I really needed to do to get it going was:

• Select the server from the Private Server configuration menu in the DreamHost web panel.
• Wait for a configuration update to run on the server.
• Flush my local DNS cache.
• Check the HTTP headers to verify I was seeing the right server.
• Comment out a few conflicting mod_rewrite rules from .htaccess.
• Copy and paste new rules into my personal site config file.

And while that might seem like that list had a bunch of stuff in it, I can honestly say that it took no more than 30 minutes to make those changes.

The only weird thing that has happened so far is that it had a weird memory spike last night — but that dropped off this morning for no discernible reason.  Since everything has been level after that, I guess I’ll have to keep an eye on my graphs and make sure it’s not a nightly thing…

P.S. Since I’ve never been one to leave “good enough” alone, I’m going to keep making tweaks (and maybe start piling on a few more active sites) to see what nginx can do. Expect more nerdy updates on this eventually.

After examining a customer’s 150,000+ row wp_comments table at work yesterday, I realized that they’d managed to let WordPress approve a massive amount of spam.  Since there was no way I was going back thru all of that by hand, I knew that I had to come up with something clever.

Fortunately, running your already approved comments thru Akismet is pretty easy.  Well, that might be a bit disingenuous. It’s easy for the geeky types that are comfortable with the MySQL command line and raw queries.  So if you manage to fall into that category, feel free to give this a go…

1. Fire up your favorite MySQL management tool and feed the following command to your WordPress database:
   update wp_comments set comment_approved=’0′ where comment_approved=’1′;
   This tells WordPress to take any comment already flagged as “approved” and set it to “pending”.
2. Visit “Comments” in your WordPress dashboard.  You should notice that you’ve got a bunch of comments under “Pending”.
3. So long as you have Akismet installed, you should have a button marked “Check for Spam”.  Click it.
4. This step is going to require some patience.  You’ll need to wait while Akismet does its thing.  This means chilling out while watching your browser’s “loading” animation spin for a little bit.
   1. If you have a lot of comments — and we’re talking about thousands — you might run into your server’s PHP execution timeout. You’ll know this has happened when you see either a 404 or aren’t redirected back to the “Comments” page.  Don’t panic.
   2. If you run into a timeout, simply press “Back” in your browser and click “Check for Spam” again.  When the number of comments listed under “Pending” stops decreasing, you’re really close to being done!
5. Go back to the MySQL management tool you used in step one and give it one last command:
   update wp_comments set comment_approved=’1′ where comment_approved=’0′;
   This takes the “pending” comments and sets them back to “approved”.
6. Congratulations!  Your comments are now much tidier and you’ve helped stamp out the spammers who’ve gotten past your defenses.  Since your copy of Akismet has just done a bunch of heavy lifting, you might want to consider giving it a bit of a rest by implementing something like Hashcash as your first line of defense. When it comes to fighting spam, they’re a great combination.

If I can hack together a way to work around the PHP execution timeout issue, I’ll do my best to make this into a simple to use plugin.  Since I’ve got a lot on my plate right now, I’d prefer it if the lazyweb could beat me to getting that done.  Any takers?

Have you recently found yourself editing a post on your WordPress install only to find yourself facing the following prompt?

The server at Magic requires a username and password.

Well my friend, you’ve been hacked.  Apparently this has something to do with the cross-site scripting (XSS) bug addressed with the WordPress 2.8.2 and 2.8.3 updates.

I’ve uncreatively dubbed this little baddie “The Magic Hack” and there appears to be a simple way to clear it up.  As it stands, the only file that I’ve seen get affected by this is in “wp-includes/vars.php”.  So if your copy of that file looks nothing like the one available over in the WordPress subversion repository, replace yours with a fresh copy, stat.

In fact, it’d probably be a better idea to upgrade your blog to the most recent version of WordPress using the extended upgrade instructions over on the WordPress Codex.  So yeah, do that instead.

Oh, and if you’re still seeing that prompt after updating “wp-includes/vars.php”, let me know and I’ll update the post when I dig up some more info.

Update: Some people are seeing the hack showing up outside of “wp-includes/vars.php”. If you have SSH access to your server, you should be able to pick out the infected files rather quickly by doing a recursive grep from your site’s root directory:

grep -r -l gzinflate .

This will show you just the filenames where the string “gzinflate” is found. If you want to see the code that grep finds — to provide yourself with a little context — just leave the “-l” switch off of the command.

Should you not have SSH access to the server where your copy of WordPress is installed, I suggest writing your host’s support team. Any host worth their salt wouldn’t mind running the command above and giving you the results.

And if you host your WordPress sites in a Windows based server environment — which doesn’t normally allow for commands like grep — do yourself a favor and go get a real host… ;)