One of the more common design patterns in installable web applications today is the Front Controller pattern. Unlike other web applications that have separate files to respond to specific requests, the front controller pattern funnels all requests through a single file, and that file processes the requested URL to respond as appropriate.

In typical scenarios, you'll accomplish this with Apache using a set of mod_rewrite directives. These directives first check to see if the requested file or directory exists. If it does not exist, then the request is passed on to the front controller. This allows requests for existing files - like images, stylesheets, and client-side scripts - to be requested directly rather than passing through the URL rewriting mechanism.

If you are familiar with implementing a front controller using Apache, you will recognize these directives, which are commonly found in an .htaccess file within the application directory:

RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [PT]

I have been running a low-budget VPSLink server for a few months. The server is a complete Virtual Private Server (VPS) to which I have root access, and it only costs about $7 per month - less than the price of many less feature-rich shared hosting plans. The downside of such a cheap server is that it only has 64MB of RAM and 2.5GB of drive space to work in. In short, it doesn't have the requisite resources to run both Apache and MySQL.

As you might be aware, there are other web servers available. A web server of particular interest is Lighttpd, which is a small, fast web server that seems perfect for the needs of this small VPS. Because the disk and memory footprint of Lighttpd is so small, I can run an efficient web server on this tiny VPS without an issue. But one problem's solution had eluded me until recently, which is how to enable the front controller on Lighttpd.

Lighttpd does not use the same directives as Apache. Instead, they have a completely different mechanism for configuring the server. After much research, trial, and error, I think I have come across a combination of directives that result in a working front controller.

First, the configuration must enable the mod_rewrite module. This is named the same as the Apache module, but is different for the Lighttpd server. Add this module to the server.modules list:

server.modules = ( "mod_access", "mod_alias", "mod_accesslog", "mod_fastcgi", "mod_rewrite" )

With that module enabled, you can set rewrite rules that enable the front controller. The tricky part to solving this is to also allow requests to files that exist to pass through the rewrite so that they are not rewritten. I believe that the following rules will successfully accomplish this task:

url.rewrite-once = ( "^/(.*)\.(.*)" => "$0", "^/([^.]+)$" => "/index.php", "^/$" => "/index.php" )

In concert with these Lighty rules, I have configured the server to use SQLite instead of MySQL. (There simply isn't enough memory to run MySQL on this small server, even with the web server completely disabled) Using Lighttpd and SQLite on the server allows me to run a Habari instance on this super-small, custom-configured server for about $7/month. When using Habari with the Flickr silo plugin, I can host the bulk of my photo resources at Flickr where the bandwidth and storage space are plentiful, leaving me with a clean, fully-featured server.

Running a tight server where the server itself was running only the necessary services and a content delivery network was hosting the bulk of my content has been a goal of mine for quite some time. Prior to these configuration options, I had been able to do this only on more expensive VPSes or flaky shared hosting. With this configuration, I can have the best of both worlds - a cheap and full-featured blog server.

I'm taking on some more server-management related responsibilities for work, and I'm trying to be a little proactive with getting things under control so that I still have time to code. One thing that I would like to do is have a server configuration that we can standardize on so that when something goes wrong on a server we have many benefits.

The advantages of having a pre-configured system are that we'll have a way to set up a server again quickly that we know will work with the software we already have on the system. If something goes wrong with one of them that is related to the system settings, we'll know what we need to fix on all of the servers to make them right, not guess at whether the fix needs to be applied to each.

The process of standardizing allows us to pick the tools that we want to be on the system without having to rely on them being provided by a host. This gets particularly hairy when we try to build tools on a hosted environment and we're not sure what other tools might be on the system that could be affected or affect the tool we're trying to build. There are too many questions.

One way I would like to mitigate these issues is to have a go-to OS platform that we use to build systems. One reason I would like to steer away from RedHat Enterprise Linux is that we're not easily able to replicate those systems locally for testing. The free version of RHEL is not identical to RHEL, and who knows what trouble minute version differences might cause.

For that reason, and some others, I'd like to standardize on Debian. Debian seems to have a good track record with testing and I like the way they deploy packages in separate stable/testing packages. It's great that you can upgrade anything in-place, and that the repositories for adding new software are the same for what we would use on the live server as what we would use for local testing.

I need a way to convince my coworkers that this will suit us well in the future, that it's not so much of a change to what they're used to, and that the additional benefits of the OS and the system I'm devising will be of immediate use to them.

I've spent the last couple of nights building a script that will deploy a working LAMP server with all of the tools I like to use to a bare Debian Etch installation. I know that the host provides images with LAMP tools already on it, but like I said, if I control what goes on, then I know how the things on it interact.

I've managed to put together a pretty comprehensive script that works really well with VPSLink, a host I've found that offers affordable Virtual Private Servers with Debian installs. The script deploys Apache 2.2, PHP5, and MySQL 5. It builds the environment with mod_vhost_alias so that creating a new domain or subdomain is as easy as creating a new directory for it. It also has APC pre-installed so that all of the work I've done recently to increase server speed on some of our clients' servers won't need to be a thing that we add on later, and it comes with svn pre-configured and ready to use as either a client or a server.

I've got the basics pretty well set, and the server runs smoothly. There are still a few things that I need to improve.

I've been writing a script to install postfix and dovecot to work together with a mysql user database. This will let the VPS have unlimited virtual users without having to touch configuration files. You could write a front-end to it in any CMS, and such a thing would be a great value-add to our customers who frequently use Drupal.

Unfortunately, the script is not yet complete. I get really close to having everything work, but then I have to rebuild the server to make sure that changes to the script apply cleanly. Thank goodness the server setup script only takes 5 minutes to create a fully-functional server out of a blank slate.

I would also like to tie in some more basic tools with the install so that they're standard on the system. A reporting tool that reports back to us when one of our clients' servers is down would be great. Also, a tool that does periodic backups of vital data - email, web - to an external location would be very nice. Something that logs traffic and server load over time, and perhaps outputs MRTG graphs, would be nice. And to put the icing on the cake, a mysql performance monitoring tool would be great, since although I've had plenty of ISPs tell me that my site's queries are taxing the server, none of them have been able to tell me which ones.

If I really wanted to get fancy, I would also include a standard install of lighttpd, for use as either a caching proxy or a faster, lighter web server. One of my VPSLink VPSes runs Habari on lighttpd with sqlite in a scant 64MB of RAM without a hiccup. For $8/month and the option to upgrade in-place to something more roomy, there's no reason to go to a more expensive shared host.

Primarily, if I can get the email working via this script, I'll be in really good shape. But I'm impressed so far with what I've been able to build in a couple of days, and how much it will reduce my personal time for server setup.