As I mentioned before, Ubuntu doesn’t have lighttpd-1.4.22 for 8.04, and it’s also not available in the updates or backports repositories. Fortunately, I’ve found that the package is available from Debuian Sid (unstable). Here are some instructions on how to install it.

Start By downloading the following packages.

wget http://ftp.de.debian.org/debian/pool/main/l/lighttpd/lighttpd_1.4.22-1_amd64.deb
wget http://ftp.de.debian.org/debian/pool/main/p/pcre3/libpcre3_7.8-2_amd64.deb

You can statisfy using the offical repositories all the dependencies of lighttpd-1.4.22 except the libpcre3, which is also available from Debian Sid. So start by installing it.

sudo dpkg -i libpcre3_7.8-2_amd64.deb
sudo aptitude markauto libpcre3

You statisfy the rest of the dependencies by using apt-get and the official repositories. In case you encounter the following problem when starting lighttpd:

/usr/sbin/lighttpd: Symbol `FamErrlist' has different size in shared object, con
sider re-linking

it can be solved easiliy by installing libfam3.

sudo apt-get install libfam3

(don’t worry if it complains about needing to remove libgamin0). You should be done now, and you can start enjoying your shining lighttpd-1.4.22.

Lighttpd book's front cover

The book starts with a introduction and installation guide for Lighttpd. Bogus starts by describing how to install via a package-manager. This is pretty straight forward and should be good for any user of a modern Linux distribution (although I did find it strange that he ignored the automatic dependency handling in every distribution except Gentoo). Bogus doesn’t stop at the obvious, he goes on to describe the installation from source procedure, for both Lighttpd 1.4 and 1.5. I find it convinient because not always the package-manager installed on the server has the latest stable and development versions of Lighttpd (as matter of fact Ubuntu 8.04LTS has Lighttpd-1.4.19 while the latest stable is 1.4.22). Choosing to describe both 1.4 and 1.5 installation is beneficial for the user. While currently 1.5 is under development, it will one day become stable and by addressing it, Bogus insures that his book will remain relevant after that too.

After the installation process, Bogus describes the basic configuration of a Lighttpd server. He includes a nice regular-expressions tutorial, and thus save the reader time by not having to read and learn the subject elsewhere. Having a regex tutorial together with the url rewriting and selectors sections is indeed useful and serves as a nice reference to experienced users too.

After the basic configurations are covered the book moves on to more advanced ones. Covering CGI the book describes both 1.4 and 1.5 ways for running CGI scripts and related technologies such as Fast-CGI and SCGI used in Lighttpd for running PHP, Python and Ruby (as well as other) applications. Once again the decision to describe both 1.4 and 1.5 is great in my opinion. The book continues to more advanced stuff, like configuring Lighttpd for streaming and SSL encryption, which will be relevant for some users.

The next chapters (7-9) cover securing and optimizing the Lighttpd installation. They describe methods that are important to every Lighttpd user, whether he a single user or a system admin managing many corporate servers. Focusing on security is important for todays web-applications that many times contains users’ sensitive data and are focused by malicious activity.

Chapter 10 gives a migration guide from Apache. Many new Lighttpd users switch over from Apache, and this chapter eases the migration. The chapter is useful even for those not familiar with Apache at all, because some popular applications are designed with only Apache in mind, and thus require the user to configure on his own any other web-server he might use. By understanding the migration process from Apache to Lighttpd, a potential user will have less problems installing applications designed for Apache later on.

In chapters 11 the author overviews installation of many popular applications such as Ruby on Rails, Wordpress, MediaWiki, Trac, AWStat and AjaxTerm. While the overview guides you through the basic installation, I felt that sometimes it doesn’t go all the way. For example, in the WordPress overview, the users is ends of WordPress installed but without clean urls, an important feature in my opinion. While clean urls for WordPress under Lighttpd is well documented in the internet (when I’ve moved my blog to Lighttpd I’ve wrote about configuring WordPress permalinks using mod_rewrite), I think it could have been better to describe it too in the book itself, or at least give a reference to some other guide.

Chapters 12 and 13 cover more advanced topics like server-side scripting with Lua and writing custom Lighttpd modules. While I’m not sure if the average user will find this topics of interest, they surely be of help to more advanced users looking to extend Lighttpd’s features.

Overall, I’ve found this book to be a nice reference and manual for Lighttpd. It goes through from basic setup to more the advanced topics of custom modules. While I think it will be more appropriate for novices, I believe advanced users and system admins may find it beneficial too, even as only a reference to Lighttpd. Packt publishing offers the book in two forms: a regular old fashioned paperback and a DRM-free eBook (in PDF) allowing both printing and copy-pasting. I found the eBook a nice way to read, especially since it provides a simple way to copy and paste the configuration and code examples from the book.

Disclosure: I receive a 12% percent referral commission for every Lighttpd book sold through the above links.

One possible solution is the one oulined in the CakePHP manual. The solution uses the mod_magnet module (which basically runs a Lua script to do the rewriting), and I found it an overkill. I was looking for a simple solution based only on mod_rewrite, something like the solution for Wordpress.

$HTTP["host"] =~ "^(www\.)?example.com" {
        server.document-root = "/home/guy/example.com/app/webroot/"
        url.rewrite = (
                "(css|files|img|js)/(.*)" => "/$1/$2",
                "^([^\?]*)(\?(.+))?$" => "/index.php?url=$1&$3",
        )
}

I will go line by line over the solution. The first line defines a vhost for the site. This is a simple vhost that uses conditional configurations. The second line sets the server’s document root to my app’s webroot directory (you’ll need to change the path accordingly). The next section is the URL rewriting which is the most important part. The first line of the rewriting rules takes care of the static files you serve from the document root, e.g. CSS, JavaScript, image etc. You can add to the begining of the rule (the css|files|img|js any other directory you would like to sever static files from). The next line takes care of Cake’s clean URLs. It’s important to capture any query string explicitly, if exists, and pass it in appropriate way so GET variables will be passed correctly.

I hope other CakePHP users who want to develop their apps on lighttpd will find this “lightweight” solution helpful. Don’t hesitate to ask question and post your comments about this.

In this post I’ll try to walk you through the necessary steps to install phpMyAdmin with Lighttpd in Gentoo.

Installing Lighttpd and PHP

Before installing Lighttpd and PHP you’ll need to enable some USE flags. For Lighttpd you’ll need to at least enable the php and fastcgi USE flags. For PHP enable the cgi, crypt, ctype, pcre, session, unicode. The first one is required for working with Lighttpd, while the others are required for phpMyAdmin.

See the handbook for information about enabling USE flags.

Now install the packages

emerge -av lighttpd php

After installation is complete, start the Lighttpd process

/etc/init.d/lighttpd start

and you should have a working Lighttpd server with PHP support.

Installing phpMyAdmin

phpMyAdmin depends on a package called webapp-config. While usually we let Portage take care of dependencies, this time we’ll have to install webapp-config manually before we install phpMyAdmin, so we can change its configuration for suit Lighttpd.

emerge -av --oneshot webapp-config

After installation is done edit using your favourite editor the /etc/vhosts/webapp-config and change the line:

vhost_server="apache"

to

vhost_server="lighttpd"

Now we are ready to install phpMyAdmin.

emerge -av phpmyadmin

After installation is complete, you’ll need to create a phpMyAdmin configuration file

cp /var/www/localhost/htdocs/phpmyadmin/config.sample.inc.php /var/www/localhost/htdocs/phpmyadmin/config.inc.php

Now open the newly created configuration file and edit the line with the blowfish_secret (at the top of the file) as explained in it. An easy way to generate the password would be to use spass.

Now if you use the default Lighttpd configurations you’re done. You can access the phpMyAdmin via http://localhost/phpmyadmin. If however you’ve changed the document root, there is one more step for you. Enable the mod_alias module in /etc/lighttpd/lighttpd.conf and append to the file

alias.url += ("/phpmyadmin" => "/var/www/localhost/htdocs/phpmyadmin")

and don’t forget to restart the Lighttpd server after making the changes.

You should have by now everything installed and configured to work. If you have any further questions don’t hesitate to comment.

sed -r "s/.*(GET|POST) (.*?) HTTP.*/\2/" access_log | sort

After doing so, I turned out that I don’t need the the query string (the part after the ‘?’ in the url) and I can discard URLs consisting only of ‘/’. So I altered the code to be:

sed -r "s/.*(GET|POST|HEAD|PROPFIND) ([^\?]*?)(\?.*?)? HTTP.*/\2/" \
access_log | grep -v "^/$" | sort

This time I also took care of URLs access by other ways than just POST and GET.

After I got this list, I thought it would be nice to have all the duplicate URLs stripped out. A quick search turned out that there is a nice command-line utility called uniq that does just that and is part of the coreutils package.

sed -r "s/.*(GET|POST|HEAD|PROPFIND) ([^\?]*?)(\?.*?)? HTTP.*/\2/" \
access_log | grep -v "^/$" | sort | uniq -u

So the final solution uses sed to take out the URL part that I wanted. grep discards URLs consisting of only ‘/’. sort and uniq sort out the results and dumps all the duplicate lines.

It’s nice how one can integrate different command line utilities to do this task in one-liner.

After setting up the server, I started moving the blog. Importing the files and the database was pretty straight forward. But when I thought every thing is ready and I transfered the domain to the new server I’ve found out that none of my inner pages are accessible. The reason, as it turned up pretty quickly, is that the Wordpress depends on Apache’s mod_rewrite to create the clean URLs (the so called permalinks). This actually posed two problems:

1. Wordpress depends on Apache’s mod_rewrite.
2. Wordpress used .htaccess files for the clean URLs configuration

Luckily, Lighttpd has its own mod_rewrite, however it operates a bit differently. The Wordpress generated .htaccess has the following lines:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

This rules tells Apache to check if the requested URL is a file or directory that exist on the server, otherwise append the requested URL to index.php. The last statement can be written in Lighttpd’s mod_rewrite syntax as

"^/(.+)/?$" => "/index.php/$1"

If we only use this rule, the posts will load up fine, but all static files will not be available, that includes CSS files and images which isn’t desired. Apache handles this by checking if the requested URL exist as a file or directory. Unfortunately Lighttpd’s mod_rewrite has no way to check if a file exists. I’ve found out that a possible workaround for this is to use mod_magent which allows to embed LUA code in Lighttpd, and use it to check if files exist and handle the clean URLs. This seemed to me an overkill, and as some people noted it has some performance hit which I wanted to avoid.

I’ve figured out that I shouldn’t just translate the rewrite rules, instead I need to adapt them. In Apache we check if a file exist in order to be able to serve the static files. The directories are checked so the server would be able to list them. The problem is now to achieve those objectives in Lighttpd. First we don’t really need to allow the directories to be listed (actually I’ve planed to block this option in my blog a long time ago). So the rule about the directories can be fully ignored. All the static files that need to be served have an extension, this includes all the files I’ve uploaded. We note that Wordpress generated permalinks never have a dot (‘.’) in their URLs. So we can exploit this behavior to achieve our goal. The following condition uses regular expressions to check if a given url has an extension, and if so serves it.

"^/(.*)\.(.+)$" => "$0"

The only difference from the Apache configuration is that the web-server itself returns the 404 message when a requested file is missing, instead of passing it to Wordpress and letting it return the error.

To sum everything up, our mod_rewrite configuration should look like this:

url.rewrite = (
	"^/(.*)\.(.+)$" => "$0",
	"^/(.+)/?$" => "/index.php/$1"
)

As I noted before (the second problem), there is no equivalent to .htaccess files in Lighttpd. So this configuration has to go directly into the main configuration file in /etc/lighttpd/lighttpd.conf (or where it exists in your server). Make sure you’ve enabled mod_rewrite, as this is required. You can enable it by putting the following line some where above the block.

server.modules += ("mod_rewrite")

If you have multiple sites hosted, you should use include the url.rewrite block inside a conditional statement. For example my configuration looks like this

$HTTP["host"] =~ "(www.)?guyrutenberg.com" {
	url.rewrite = (
		"^/(.*)\.(.+)$" => "$0",
		"^/(.+)/?$" => "/index.php/$1"
	)
 
	[...other unrelated configurations...]
}

And I've enabled the mod_rewrite at the top of the /etc/lighttpd/lighttpd.conf file.

This workaround works well, as you can read this post now. If you run into problems, or have any question about why or how I did soemthing, don't hesitate to comment.