The Files

templates/main:

This is the main “meat” of the entire vhost system. It sets the root directory, the indexes, the access log path, as well as some sane defaults for static files. You can modify this file as you might need, but I would recommend leaving it barebones.

templates/php5:

This allows you to easily enable FastCGI’ed PHP on a host-by-host basis. For instance, you might not want your static media vhost to have PHP access. You may need to modify this file, depending on how you have PHP setup on your server. This exceeds the scope of this article, but I do plan to write on it in the future.

NOTE: It came to my attention that there was a security vulnerability in my configuration. As such, I’ve added the if (!-f $request_filename) portion to my php5 block above. This prevents PHP from executing arbitrary files, such as /image.jpg/index.php. Without this fix, php would execute /image.jpg as a PHP file, allowing for arbitrary code execution. If you don’t like using an if block, you can also modify the cgi.fix_pathinfo setting in php.ini, setting it to 0. Just remember to uncomment it as well Thanks to Seph on the #nginx IRC channel!

templates/clean-urls:

This script allows you to easily setup Drupal/Wordpress Clean URLs. If you use these web applications, this template will be useful to you!

templates/vhost-template:

This is the “template” that you’ll create vhosts from. You can enable PHP5 and Clean URLs by simply uncommenting the respective lines. Just replace “DOMAIN” with your domain name.

Using the templates

You may need to tweak the templates to fit your system configuration. For instance, if your web root directory isn’t /srv/www, you’ll need to modify the templates with the correct paths. Also, you may wish to change the directory names (i.e., /srv/www/DOMAIN/www) to something else (i.e., /srv/www/DOMAIN/public_html). Depending on your configuration and requirements, you may want to add additional variables. For instance, if you’re hosting sites for multiple users, you may change the $user variable to become the username (as in, /home/$user/) and then add another variable to signify the domain.

If you’re deploying many instances of the same application (i.e., WordPress, Drupal, etc), you can also create a separate template for those applications.
I’ll leave those modifications as an exercise for the reader..moving on.

Generally, my workflow for using the templates looks like such:

I am planning on writing a few “helper” scripts to automate this even further, so stay tuned! In the mean time, enjoy!

Thanks to MTecknology on the #nginx IRC channel for the idea!

Installing MariaDB

OurDelta provides Debian and Ubuntu packages of MariaDB, making it simple to install on these distributions. If you’re running something else, there are likely to be packages somewhere.

At the time of this writing, OurDelta’s Ubuntu does not mention a build available for Lucid Lynx, but there is one available here. To setup the repository, you can follow the instructions on OurDelta’s mirror page. For your convenience, here they are:

Once you’ve added the repository, you can install the -server and -client package:

It’ll prompt you to set a root password, just like the MySQL packages. After that, you’re almost good to go!

Configuring MariaDB for WordPress

As it turns out, the default configuration file included with OurDelta’s will run the SQL server in “Strict,” also known as “Traditional,” mode. We’ll need to disable this in order for WordPress (and other applications) to work properly without spewing SQL errors. In your /etc/mysql/my.cnf file, you will look for the sql_mode line. By default, it looks something like sql_mode = NO_ENGINE_SUBSTITUTION,TRADITIONAL . You’ll want to remove the TRADITIONAL part, as well as the preceding comma. Following the changes, your sql_mode line should look something like this:

Once the MariaDB packages are installed, you should be able to install any packages that require MySQL, such as php5-mysql. The OurDelta packages will provide the mysql-server and mysql-client packages, providing compatibility for packages that aren’t aware of MariaDB.

After that, WordPress should install and operate as you would expect it to. Enjoy!

Without further ado, here it is:

Hope this will help someone.

UPDATE: I’ve updated the template with some of the Nginx best practices, as per their pitfalls page. Enjoy.

UPDATE: It came to my attention that there was a security vulnerability in my configuration. As such, I’ve added the if (!-f $request_filename) portion to my php5 block above. This prevents PHP from executing arbitrary files, such as /image.jpg/index.php. Without this fix, php would execute /image.jpg as a PHP file, allowing for arbitrary code execution. Bad stuff! Thanks to Seph on the #nginx IRC channel!

Here’s some of my configuration that I used to enable Clean URLs while not breaking the SCRIPT_FILENAME (and php5-fpm):

Note: yes, it’s Gist…Wordpress cannot handle code blocks worth a damn. If you run a WordPress blog, please, for the love of God, use Gist or something else that can do code blocks.

It uses try_files to handle static files and if that fails, sends it to the @wordpress location, which rewrites the URL for WordPress. Just add it to your existing server directive and you’ll be good to go!

Although this is for WordPress, it should work in many other CMSes and blogs that use the same setup for handling Clean URLs.

Cheers!

UPDATE: I’ve updated this configuration snippet to follow nginx best practices, as outlined on their Pitfalls page. Enjoy!