How To

Are you really backing up your WP blog?

When those of us with self-hosted WordPress blogs back up our content using the built-in WXR functionality, do we ever check the downloaded XML file? Until recently, I didn’t worry about it. I’d click on the Export button, copy the WXR file to a backup folder and think my blog was safe, but I was wrong.

You see, what may be happening is the creation of the WXR file on the server side may be terminated before all the content gets written to it, and we’ll end up with a partial backup of our blogs. This is no fault of the WordPress platform, but will happen when the server settings don’t allow enough resources to the PHP script which writes out the XML file. When that’s the case, this is what the end of the WXR XML file looks like.

In the screenshot you see above, the script ran out of memory (I’d set PHP’s memory_limit at 64 MB, which was too little for my needs), but it can also run out of time, if PHP’s max_execution_time is set too low.

Depending on your scenario, you may or may not have access to the original php.ini file on your web server. If not, check with your host, you may be able to create a php.ini at the root of your hosting account to adjust these parameters (within limits). The thing to do is set the memory_limit and the max_execution_time high enough to allow PHP enough resources to generate the full WXR file. I can’t prescribe any specific limits here, because the amount of memory and time the script needs depends on how big your blog is. All I can suggest is that you experiment with the settings until they’re high enough for the WXR file to generate fully. You don’t want to set them too high, because your server will run out of memory, and that’s not fun either. This is what my setup looks like.

What happens if you use a cheap web host is that you’ll get crammed along with hundreds of other sites on a single virtual server where all the settings are tightly reined in, to make sure no one’s hogging any resources. Chances are that as your blog grows, your WXR file will get too big and will need more resources than are available to write itself, which means you’ll start getting truncated backup files. If you never check them by opening up the XML and scrolling to the end to rule out any error messages, you’re not really backing up your blog.

Keep this in mind if you want to play it safe. Always check the WXR file. A good backup should close all the tags at the end, particularly the tag, like this screenshot shows.

Standard
Thoughts

Are you subscribed to the right feed for my site?

A lot of my readers are still subscribed to the standard site feed, at

http://www.raoulpop.com/feed/rss2/

but that may become inactive, as I’m making some changes on the server side, so please make sure you’re subscribed to

http://feeds.feedburner.com/Raoul

which will continue to stay the same for the foreseeable future. Check your feed readers and make the change so you can continue to receive updates from me.

By the way, I’d like to apologize for the frequent and recent server outages. I’m looking into what’s causing them. They started happening as soon as I upgraded to WordPress 2.9. I’d hoped they’d go away with 2.9.1, but they’re still here… I made no other changes on the server side before or immediately after the upgrade, so the only thing I can think of is that 2.9.x has some issues. I disabled all but three essential plugins: Akismet, FeedBurner FeedSmith and WordPress.com Stats, and while my server crashes less frequently now, it still does.

It’s the strangest thing though. The server doesn’t run out of memory, my other sites stay up, Apache stays up, mySQL stays up, and yet raoulpop.com goes down. I’ve tried tweaking and re-tweaking Apache2 and PHP5 and mySQL settings to no avail. The only thing I need to do to bring my site up is to reload Apache2, but it is a very annoying thing indeed. If I had to deal with this thing long-term I’d schedule a cron job to restart Apache every once in a while, but I’ve got something in the works that should eliminate the need for that.

If anyone is having this problem and you’ve got it solved, I’d love to hear how you did it.

Standard
Thoughts

Catching a code injection hacker in the act

Several days ago, I installed the Redirection plugin from Urban Giraffe. It’s truly awesome, in more ways than one. John Godley, you are an amazing programmer! As I re-arranged the categories on my blog, I tracked the 404 errors through the plugin. On Saturday morning, I noticed the following bit of information in my log:

You can click on the thumbnail to view the screenshot at full size. Look at the entries for IP address 65.90.251.169. Notice something peculiar? That’s a hacker trying to inject malicious code into my pages. He was trying to call to code contained in a text file by the name ide.txt located on a possibly compromised domain.

First, I checked out his domain, new-fields.com. It looked legitimate. The text file was another story altogether. Have a look at the screenshots above. I also saved the code to my computer in case it ends up disappearing from the hacker’s website.

I tested the code, and it looks like some pages from the podPress plugin are targeted or affected — at least that’s what the error message given by WP referenced when I ran the code. I had that plugin enabled at the time, and I’ve disabled it since. It seems that the code tries to modify one of the header.php pages, along with checking disk space (?). So I thought, let me find out who this hacker is. Apparently, he’s from Napperville, IL, US, or at least that’s where his IP address lives.

What’s more, I thought it’d be interesting to see who owns that domain name where his text file resides. It turns out to be one Samir Farajallah from Dubai.

So what we’ve got so far is some dude in Dubai who owns the domain where the malicious code resides, and some hacker in Napperville, IL, trying to exploit my blog using that malicious code.

Wait, it gets better… On Saturday evening, I have another look at my blog’s 404 log, and I find that some other hacker from Vietnam (IP address: 203.171.31.19) is trying to hack into my blog using that exact same code, but this time the text file’s located on some domain in Argentina. That last link leads directly to the text file with the malicious code, but it’s harmless if you browse it. It only works if you run it as PHP code, like these hackers are trying to do.

So far, it looks like I’ve got two hackers, who may or may not be working together, using the same malicious code, located on two different, possibly compromised domains, and trying to modify my header files, possibly to insert code in there that will display splog content or some other stuff.

Update: It looks like three more hackers are trying their luck today, on Sunday morning, 9/30/07. Their IP addresses are 65.98.14.194, 66.79.165.19 and 66.11.231.48.

What I can tell you is that they haven’t been successful. I checked all of my files, and none of them have been touched. Everything’s fine. At this point, I’m not going to waste any more of my time trying to hunt them down. If I see that the attacks continue, I’ll notify my web hosting provider, along with the hosting providers of the other domains, and I’ll also notify the ISPs who own the IP addresses used in the attacks.

My thanks go out to John Godley for the wonderful Redirection plugin. I wouldn’t have been able to catch these hackers without it. I don’t often check my 404 log files, although I should.

I’ve been working in IT for 13 years or so. Maybe I’m naive, maybe I’m too honest for my own good, but I’ve stayed away from this hacking business, and I’ll continue to do so. It’s just not a sustainable lifestyle. I believe that the bad stuff you do in life will catch up with you sooner or later. It’s inevitable. These hackers will get what’s coming to them, and I won’t even have to lift a finger beyond what I’ve done so far.

Standard
Thoughts

Book giveaway: Object-Oriented PHP, by Peter Lavin

Remember my last book giveaway? I meant to get around to this second one a little sooner, but life intervened. This time, I’m giving away “Object-Oriented PHP“, by Peter Lavin. I reviewed this book back on August 30, 2006. It’s been sitting in my library since then. It’s still relevant, but more importantly, it’s still unused. Retail cost for the book is $29.95.

Would you like to get it for free?

The rules

This time, I’m keeping things even simpler. To make sure there’s no confusion, here are my goals:

  • Increase my readership, ideally the number of people subscribed to my feed.
  • Give away these books. They’re just sitting on the shelf gathering dust right now, and that’s not what books are for.

What I want you to do to qualify is to tell two of your friends or contacts about my blog. Send them an email to let them know about it, and invite them to subscribe to my RSS feed. Then leave a comment on this post to let me know you did it. That’s it. I’ll use the honor system and trust you.

Late Friday afternoon, I’ll gather the names and pick one at random, then notify the winner by email. The winner will need to pay for the book to be shipped to his/her address. That’s all they’ll pay for, nothing else. The money can be sent via PayPal. If the winner has a website/blog, I’ll also link to it in an announcement on my blog.

Standard
Reviews

Object-Oriented PHP: Concepts, Techniques, and Code by Peter Lavin

“Object Oriented PHP: Concepts, Techniques and Code”, by Peter LavinCan a single book get web designers to start writing better, reusable PHP code? Peter Lavin makes a go of it in Object Oriented PHP, and it comes out pretty darn well.

The gist of the book is this: would you rather write code that does the same sort of stuff over, and over, and over, and over, and… so on and so forth, or would you rather write a piece of code you can plug into any of your pages or sites when you need to do a certain thing? The object-oriented way involves a little more time upfront, but it pays off time and time again. Because let’s face it, none of us enjoys coding the same boring stuff unless we’re gluttons for punishment.

Some may say, “What?! What’s this nonsense about OOP with PHP?”, and I will duly point them to the specs for PHP 5. That’s when OOP techniques were truly made possible. I tell you, even I started reading Peter’s book with skepticism, because heck, PHP is “just” a scripting language, and besides, Dreamweaver can write a lot of the code I need for me. But as I went through the book, I realized an object-oriented approach is a scalable approach. It can be applied to multiple projects. In essence, that’s what Dreamweaver’s doing when I tell it to write a recordset for me, and Macromedia’s not doing too bad as a company… There are obviously benefits to be reaped from OOP in web development.

Peter’s book is great, because it walks you through and explains how OOP in PHP should work. He first explains the basics of OOP, then applies them to PHP, and provides real-world techniques and code to illustrate his points. He touches on AJAX, XML, RSS, thumbnail images, PDO, and other cool things, in an approachable and understandable manner.

It’s funny, but the illustration on the cover of the book says it all. Would you rather code a waffle from scratch, or code the wafflemaker, and make yourself waffles whenever you want them? That’s the difference between just writing code and object-oriented programming. It gives you the power of reproducibility and scalability. So what are you waiting for? Get cooking with OOP!

Standard