From SliceHost to VPSLink

I have migrated from SliceHost, i.e. the RackspaceCloud, to VPSLink for hosting this blog. See my previous VPSLink review here.

SliceHost has served me very well for the last 3 years. In fact at one stage I had > 450 days of uptime, before one of my Python script crashed the slice by using up too much memory. Performance has been great. Absolutely tops in stability. Highly recommended if you are looking for the “Rackspace of Xen VPS host” (which it literally is).

I am however switching to VPSLink for this site for a few reasons (together with about 10 other sites I run). Because,

• It costs me less. From heavy discount & referral system, I am getting a Xen Link4 for ~$251/12 months ($29.36/month x 12 – 10% coupon code discount – $66 referral bonus), which has 512MB RAM, 20GB disk space & 500GB/month data transfer. It’s actually free to me because of past referral credit.
• Sydney to Seattle is around 20ms less than Sydney to St. Louis
• VPSLink has 32bit templates, which saves memory for my LAMP stack.
• Accessing to all 8 cores of an Xeon E5420 rocks (not that I need it).
• Did I say it’s free?

So due to simple economics I made the change to migrate my sites from SliceHost to VPSLink. Thanks for the service!

From Drupal to WordPress

Another big change that I have made is switching from Drupal to WordPress as the blogging platform.

Man I love Drupal. It is flexible and very customisable. It is a developer’s dream CMS because of its flexibility. It is powering my main hobby site at the moment (which takes way too much of my time) serving over 4 million page views a month.

However what I am doing here is just blogging. I am not running a community, nor trying to organise some structured content. I am just posting things here a few times a month, and the flexibility of Drupal has actually became a curse. Drupal 7 is almost out, but I cannot even upgrade to Drupal 6 without heavily tweaks on my modules.

So I gave up. Might as well run WordPress and keep things simple.

I ended up spending a day developing a converter to migrate all my old posts + comments from Drupal to WordPress and retain all the permalinks. So far so good.

Other Updates

A few other updates around the place.

• Updated serverstats to 0.2. Ended up rewriting the tokenizer to get rid of dependency on libpcre so it uses even less memory.
• Updated phpmonitor.py as Linode cleaned up their pastebin thus removed my code.

Since I have briefly touched on the “URL rewrite-ability” of Nginx and Lighttpd in my previous post, I think it might actually be useful to have some examples showing how rewrite rules are written on these web servers to support clean URLs. I will take the open source CMS Drupal for example, as it is what Hosting Fu runs on. Btw, Drupal 5.0 has just been released and it rocks.

Prerequisite

These are the things that I assume you would know before reading this article.

• Why clean URL. Pick your reason. SEO or general dislike of query string.
• Setting up PHP. I won’t be talking about how to set up PHP/FastCGI on Nginx or Lighttpd. Here’s one for Nginx and one for Lighttpd.
• Installing Drupal. Check related section in Drupal handbook.

I am only going to discuss the rewriting rules needed to enable clean URL in Drupal on either Nginx or Lighttpd.

Apache’s Mod_Rewrite

Like most open source PHP applications, Drupal came with a .htaccess file assuming Apache is serving the pages. We will use it as the reference on how the rewrite rules can be written for the other two web servers.

Here’s the bit in .htaccess that does rewrites:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

What it does is:

• If requested file exists, serve it.
• If requested directory exists, serve it depending on how index option is configured.
• Otherwise, send all requests to index.php, setting parameter ‘q’ as the path of the original request, and then append the rest of the query string.

Simple. Now let’s see how you can do the same with the other two web servers.

Lighttpd

This site runs on Lighttpd 1.4.13, and there seems to be a lot of different ways to do clean URL with Drupal on Lighttpd. Although it came with its own “mod_rewrite”, but I found the functionality is very limited. The biggest problem I found is the lack of conditional rules to check whether a file or directory already exists. At the end you have to either (1) make lots of exceptions in Lighttpd’s rewrite rules, or (2) modify Drupal so it works better with Lighttpd.

I went with the second option.

Well, here are the steps.

1. After Drupal has been installed and tested with clean URL disabled, add the following rules to lighty’s configuration file:

   server.error-handler-404 = "/index.php";
   

   It basically makes index.php the 404 error handler, so any request that does is not handled by a local file or directory will be sent to Drupal.

2. Add the following PHP code to Drupal. I just append them to the end of sites/default/settings.php.

   if (strpos($_SERVER['SERVER_SOFTWARE'], 'lighttpd') !== false) {
       $_lighty_url = $base_url.$_SERVER['REQUEST_URI'];
       $_lighty_url = @parse_url($_lighty_url);
   
       if ($_lighty_url['path'] != '/index.php' && $_lighty_url['path'] != '/') {
           $_SERVER['QUERY_STRING'] = $_lighty_url['query'];
           parse_str($_lighty_url['query'], $_lighty_query);
           foreach ($_lighty_query as $key => $val)
               $_GET[$key] = $_REQUEST[$key] = $val;
           $_GET['q'] = $_REQUEST['q'] = substr($_lighty_url['path'], 1);
       }
   }
   

   Let me explain what it does:

   • If we are behind lighty, turn on this hack (I use Nginx for my development box so this code does not apply).
   • Try to parse the REQUEST_URI. If invoked as 404 error handler, we will parse the QUERY_STRING ourselves and copy the values to PHP’s $_GET and $_REQUEST variables.
   • Also set the path bit of REQUEST_URI as query argument q.

   The reason why we have to parse QUERY_STRING is, Lighttpd deliberately does not set QUERY_STRING if FastCGI is invoked as 404 error handler.

3. Restart lighty, go to Drupal to enable clean URL and see whether it works.

Well, it has been working fine for me, but YMMV.

Nginx

Nginx comes with conditional code for rewrite rules so it is much easier. I basically have the following code in my Nginx configuration file to emulate Apache’s behaviour.

if (!-e $request_filename) {
    rewrite ^/(.*)$ /index.php?q=$1 last;
}

That’s it! Restarting Nginx, and you can now turn on clean URL in Drupal.

However, Nginx is not perfect, and so far I have found one small issue with its rewrite engine. When you use regular expression in Nginx’s rewrite rules, it will try to encode the matches in the replacement URL. So far I have seen it broke Drupal’s search module. For example, if you search for “Hosting Fu”, Drupal will use the following URL:

GET /search/node/Hosting+Fu HTTP/1.1

However, Nginx will rewrite that to:

GET /index.php?q=search/node/Hosting%2BFu HTTP/1.1

Note it encoded ‘+’ to ‘%2B’, which confuses Drupal, who thinks that you are actually searching the phrase ‘Hosting+Fu’. In case of Apache, ‘+’ passed through rewrite rules untouched.

Conclusion

Many open source PHP applications that I have experience with always assume the existence of Apache, and provide clean URL to only Apache users. On the other hand, developers of other frameworks like Ruby on Rails, Django, Webpy, etc take clean URL for granted because it is something handled right inside the framework. It makes the life of the web server guy much easier — what rewrite? Just proxy or pass through the whole damn thing!

I am hoping more and more PHP applications will use simplified rewrite rules. Let applications themselves take care of parsing the REQUEST_URI, instead of generating a million lines of Apache mod_rewrite rules and dumping them into .htaccess files.

Meanwhile, Nginx users will have much easier time porting those rules then the Lighttpd users.