By
Conditions
So you have seen that modules can make lighttpd’s configuration more manageable, but until now it all stays rather simple. There will always be some situations, though, where you want to take different actions depending on the value of some variable. lighttpd can do this too: it knows conditions, which for example make it possible to override global settings for a specific directory. An example:
[sourcecode language=”bash”]dir-listing.activate = “disable”
$HTTP[“url”] =~ “^/download/” {
dir-listing.activate = “enable”
}
[/sourcecode]
So we have first a general configuration directive that disables a directory listing in directories without index file, but then we enable this feature for the URL /download/. The line $HTTP[“url”] =~ “^/download/” is a condition: we ask the URL type of the HTTP class and compare the value to the regular expression ^/download/. We use =~ for a regular expression that is true, !~ for a regular expression that is false, == for a string that equals the condition and != for a string that doesn’t equal the condition.
Another example of this conditional directive is the following:
[sourcecode language=”bash”]$HTTP[“useragent”] =~ “Google” {
url.access-deny = ( “” )
}
[/sourcecode]
Here we deny all access to our website for Googlebot. Conditional directives can also be used recursively. This example comes from Debian’s default lighttpd.conf:
[sourcecode language=”bash”]$HTTP[“remoteip”] =~ “127.0.0.1” {
alias.url += (
“/doc/” => “/usr/share/doc/”,
“/images/” => “/usr/share/images/”
)
$HTTP[“url”] =~ “^/doc/|^/images/” {
dir-listing.activate = “enable”
}
}
[/sourcecode]
Here we first have the condition that the remote IP address should be 127.0.0.1, so all directives inside the block only apply when the visitor comes from localhost. Then we define some aliases (from /doc to /usr/share/doc and
/images to /usr/share/images) and then another conditional directive: we activate the directory listing only for /doc and /images. The result of these two levels of conditional directives is that only someone visiting the website from the computer the web server is running on is able to get a directory listing of /doc and /images, which are aliases to local directories.
Variables and includes
Conditional directives are really flexible, but they can make the configuration file rather messy. Luckily, there is a solution. Just like modules can make a configuration file more manageable, variables and includes can do the same. This is especially handy if you have different websites hosted by the same lighttpd instance. Maybe one website only hosts some static files, and another one uses FastCGI. Probably they need a lot of different settings.One solution to do this cleanly is this kind of code in /etc/lighttpd/lighttpd.conf:
[sourcecode language=”bash”]var.basedir = “/var/www/sites/”
$HTTP[“host”] == “www.foobar.co.uk” {
var.servername = “www.foobar.co.uk”
include “www.foobar.co.uk.conf”
include “docroot.conf”
}
$HTTP[“host”] == “www.loremipsum.org” {
var.servername = “www.loremipsum.org”
include “www.loremipsum.org.conf”
include “docroot.conf”
}
[/sourcecode]
And then /etc/lighttpd/docroot.conf contains this code:
[sourcecode language=”bash”]server.document-root = basedir + servername + “/html/”
[/sourcecode]
And the configuration files /etc/lighttpd/www.foobar.co.uk.conf and /etc/lighttpd/www.loremipsum.org.conf contain site-specific settings for www.foobar.co.uk and www.loremipsum.org, respectively.
In the first line we define a variable basedir, which contains the path /var/www/sites/. Then depending on the host the visitor is surfing to, we define a variable named servername. When including docroot.conf, the server’s document root gets the value of basedir concatenated to the servername and ‘/html/’. The result: if someone visits www.foobar.co.uk/index.html, he will be redirected to /var/www/sites/www.foobar.co.uk/html/index.html. And because site-specific configuration happens in another file, our main lighttpd.conf stays clean, even if we add dozens of other websites.
Migrating to lighttpd
By now you have learnt the basics of lighttpd’s configuration, and you should be able to migrate your current Apache setup to lighttpd. Maybe you’ll encounter some issues, because Apache is the de facto standard and many PHP projects such as content management and blog systems suppose that you run Apache. So if you read installation instructions for Apache, you have to find the corresponding configuration directives for lighttpd. However, most of the time this is rather straightforward and many users have done this before, so it’s not difficult to find some lighttpd migration instructions for your favourite blog system somewhere on a blog. You’ll be off the beaten path with lighttpd, but the rewards can be high.
Click here for more tutorials from Linux User & Developer, or see what else features in issue 92…
