Some of you may have noticed that the various websites hosted here on multimedia.cx were having a tad bit of difficulty recently. Long story short: My previous web host was having some serious problems and I decided it was time to ditch them and move on to a better one. Fortunately, I had (and continue to maintain) consistent, automated backups of everything hosted on multimedia.cx. But I really wasn’t looking forward to the task of finding a new provider. Whenever I have studied web host providers in the past, they all seem pretty much the same– offering UNLIMITED EVERYTHING!! along with perfect uptime and reliability for next to nothing^{(*** see details below in 5-point font)}. And most of their websites boast a design style reminiscent of the worst e-marketing sites and guaranteed to annoy the utilitarian, tech-savvy geek.

When it boils right down to it, I think I was being asked to make a decision regarding a new web host based on the female smiling at me on the front page. Honestly, these photos were generally the only distinguishing feature among the various services:

Miss 1&1 Hosting	Miss midPhase
Miss FastDomain

You will notice that laptops are a common feature in these advertisements:

Miss Host Monster	Miss StartLogic
Miss ThinkHost

Miss ThinkHost up there encourages you to spend your web hosting dollar towards a “green” host (i.e., a somehow environmentally friendly web hosting service). I found several other web hosting services that boasted their green-ness. You might have certain, ah, stereotypes about the type of spokemodels they would put on their front page, and you might be right when you see Miss Go Green:

Miss Go Green

Miss Solar Energy Host

Go Daddy has the closest thing to a celebrity out of all the hosting services, race car driver Danica Patrick:

Miss Go Daddy

And some leftovers:

Miss Apollo Hosting	Miss Gate Hosting
Miss Glob@t	Miss Netfirms
Miss Omnis	Miss WebHostingPad

Now, to their credit, my previous web host does not now — nor have they ever, to my knowledge — featured some random laptop-toting chick on their front page. But when their RAID system is effectively inoperative for 48 hours (remind me again of the point of having a RAID system in the first place?), that motivates me to investigate alternatives.

I decided that I might want to look for a service that could host Python CGI scripts that can interact with MySQL. This is why I had to write the web frontend of FATE in PHP — it was either that or Perl. A little searching for Python-friendly web hosts turned up this page at the Python.org wiki which led me to WebFaction. Let’s see how it holds up.

The first thing I liked was that their front page had no female implying “choose this web host because I’m pretty and have a soft-colored laptop”. The next item I liked is that they have the necessary MySQL interface modules for Python. Further, they have Python 2.5 (and 2.6 and 3.0, in parallel with older versions), which means that I’m free to do ever more ridiculous things with SQLite from Python. Further, the site offers the most comfortable method for administering one’s websites — SSH access. I didn’t think web hosts still offered this.

Ironically, another positive factor that caught my eye was that WebFaction does not advertise unlimited bandwidth and disk space. That’s quite common among the cheaper web hosts and the reason those claims put me off is that I know they’re false (try hosting some large, popular content and you’ll quickly find out how limiting unlimited claims can be). Further, I know they’re unnecessary in my case. In the 4+ years I have been running multimedia.cx, I have barely exceeded 35 GB of bandwidth in one month and I use well under the 10 GB of disk space that my new hosting plan provides, though FATE may make a dent in that. But the next tier does not cost too much more. At the same time, I appreciate that this new host has unlimited things like email address, unique databases, and subdomains. When web hosts try to limit those things, it’s artificial; when they claim unlimited bandwidth and disk space, it’s phony.

I was extremely fortunate that, just this past weekend, I finally sat down and re-evaluated my website-wide backup strategy. I have been making automated backups of databases and associated files for years. But I finally verified that I could actually recreate the wiki and blogs on a local server, thus giving me peace of mind that my backups are actually worth something. Little did I know that I would need to put this knowledge to use just days later. With the SSH access, it’s trivial to set up an encrypted tunnel and recreate the databases on the web host without having to transfer an entire MySQL dump. However, the FATE database is so large at this point that it takes just over a 1/2 hour to completely dump to my local machine from the old web host via cable modem working at full capacity, while also using network compression (–compress). I shuddered to think how long it would take to recreate that on the new server (since cable modem upstream is so much slower than downstream). Then it dawned on me to use to remote access feature that my old host provided (at this point, the damaged RAID was mounted read-only):

mysqldump –compress –host=oldhost -p –user=me fate_database | mysql -p –user=me fate_database

The command completed in just under 20 minutes and all 2.5 GB in the FATE database was transferred. I’m happy to be able to put other people’s vast bandwidth resources to such good use.

So I just wrote this entry as a brief status update and as trivia for the more technical folks out there (and for venting my annoyance that the best that most web hosts can do to sell their service is slap a photo of a girl and a laptop on their front page). One more humorous item from this episode: When I moved my private FATE administration PHP script, I hadn’t changed the credentials yet for the new database setup. Usually, PHP is reasonably good about saying that a script failed to work while providing some useful clue but not any damaging details. Usually. This is the exception, apparently, and I filed it in my notes as “awesome error”:

Fatal error: Uncaught exception ‘PDOException’ with message ‘SQLSTATE[28000] [1045] Access denied for user ‘melanson_logdata’@’localhost’ (using password: YES)’ in /home/melanson/webapps/fate/logdata/index.php:8
Stack trace:
#0 /home/melanson/webapps/fate/logdata/index.php(8): PDO->__construct(‘mysql:host=loca…’, ‘melanson_logdat…’, ‘cZa2giAItvY3EvpI…’)
#1 {main}
thrown in /home/melanson/webapps/fate/logdata/index.php on line 8

You might notice that the call to the construct method of the PDO object contains the database credentials, including the plaintext password (which I substituted for another random string for this post, even though it’s now obsolete). I don’t have those values hardcoded into the call; PHP substituted them in and then printed them in this stack trace. Sure, this doesn’t really help an attacker unless they can somehow gain authorization to connect to the database server in the first place. Still, it’s the principle of the matter.