Bagel Belly Blog

Lighttpd vs. Apache

For one of the Ruby on Rails sites we're about to deploy, we've been working on getting lighttpd running, as the Apache fastcgi module has caused us some trouble due to high memory requirements and hanging processes.

The big issue I'm struggling with is the decentralised approach that lighttpd takes, compared to Apache's central-and-modular approach. It seems that commonly with lighttpd, you essentially run one server for each user needing a web server. Each user has a complete server config (some basic virtual hosting is also possible, but all in one central file as far as I can tell). With Apache you often run one server for the entire site (or sites, through virtual hosts), and then devolve configuration of sections to individuals through seperate config files or htaccess files.

Most of the documentation and most people I've spoken to in the Rails community seem to advocate running lighttpd as a regular user, rather than a specific service user such as 'nobody' or 'www-data', which is my preferred method. This isn't a webserver-specific thing: it's good practice. Don't give away more permissions and privileges than you need. The WWW Security FAQ has much to say on this, even though it is quite old/out-of-date.

The problem with enforcing a centralised configuration and management policy is that Rails itself seems to expect certain privileges: for example, to be able to write to the 'public' directory of a Rails application. Write access should only be given out when absolutely needed, and should be kept separate from immutable files. Therefore if Rails wants to cache dynamic files (a good thing), the cache directory should not be the same as the static files directory. For added security, static files should not be writable by the httpd - that way, if there's an exploit in the httpd, it's harder to deface static pages. This is all just common sense ...

I think I need some more time to understand the Rails approach to all this.