Archive for the ‘lighttpd’ Category

Webserver switched from lighttpd to nginx

Saturday, December 5th, 2009

For some time now, I have been experiencing weird bugs with my webserver. I was running a lighttpd, version 1.4.22. Two annoying bugs occurred:

The first was more a nuisance when uploading files through a POST, which resulted in error 417 "Expectation failed" on the first attempt (while on the second it worked).

The second bug resulted in a reproducible denial-of-service, as it crashed the webserver. It occurred whenever a firefox-webbrowser attempted to connect to the server through HTTPS.

I hoped these bugs to be solved by upgrading from 1.4.22 to 1.4.23 and 1.4.24, but that did not happen. As I needed a solution to these bugs, I decided to switch from lighttpd to nginx.

The transition went surprisingly smooth. The configuration is a bit more complicated as it was with lighttpd, but easily set up and quite good explained on nginx's website, too.

Now, nginx runs all my websites, interacts with PHP through FastCGI, and problems seem to be gone.

Follow up: lighttpd rewrite-rules for WordPress MU

Thursday, April 10th, 2008

While looking closer at those rules I posted earlier I noticed an important but missing rule, which would prevent e.g. the preview-functionality of the post-/page-editor. The following rule enables this:

"^/(.*/)??(.*=.*)$" => "index.php?$2"

The whole ruleset would thus now look like this:

 1.$HTTP["host"] =~ "^blog.nifelheim.info" {
 2.  url.rewrite-once = (
 3.    "^/(.*)?/?sitemap.xml$" => "wp-content/blogs.php?file=sitemap.xml",
 4.    "^/(.*)?/?robots.txt$/" => "wp-content/blogs.php?file=robots.txt",
 5.    "^/(.*)?/?files/$" => "index.php",
 6.    "^/(.*)?/?files/(.*)" => "wp-content/blogs.php?file=$2",
 7.    "^/(.*/)??(.*=.*)$" => "index.php?$2",
 8.    "^/(wp-.*)$" => "$1",
 9.    "^/([_0-9a-zA-Z-]+/)?(wp-.*)" => "$2",
10.    "^/([_0-9a-zA-Z-]+/)?(.*.php)$" => "$2",
11.    "." => "index.php"
12.  )
13.}

As with the previous posting, the same lines (1, 3, 4, 6) as before need to be adjusted to your own demands, and may be can even be skipped.
Line 7 is the new rule. It reroutes every parameterized request that does not mention a php-file directly, but a directory, to call the index.php with all parameters of the request applied.

lighttpd rewrite-rules for WordPress MU

Thursday, April 10th, 2008

Today, someone in the channel #wordpress on freenode (see WordPress.org's IRC-page for more information about the channel) asked whether WordPress would work with lighttpd. As I am running such an installation myself, I took it up to help him, looking for rewrite-rules on the net, since my own were only for WordPress MU. I was looking for my own rules as well, which I picked up myself from somewhere, but did not find them. So I decided it might be good to post them here.

For WordPress MU, the following rewrite-rules work well:

 1.$HTTP["host"] =~ "^blog.nifelheim.info" {
 2.  url.rewrite-once = (
 3.    "^/(.*)?/?sitemap.xml$" => "wp-content/blogs.php?file=sitemap.xml",
 4.    "^/(.*)?/?robots.txt$/" => "wp-content/blogs.php?file=robots.txt",
 5.    "^/(.*)?/?files/$" => "index.php",
 6.    "^/(.*)?/?files/(.*)" => "wp-content/blogs.php?file=$2",
 7.    "^/(wp-.*)$" => "$1",
 8.    "^/([_0-9a-zA-Z-]+/)?(wp-.*)" => "$2",
 9.    "^/([_0-9a-zA-Z-]+/)?(.*.php)$" => "$2",
10.    "." => "index.php"
11.  )
12.}

Please note, that at least the lines 1, 3, 4 and 6 needs to be adjusted if you try to use these rules for the single-blog WordPress (probably line 6 can be removed completely?). I cannot really say how far these rules do apply for the single-blog WordPress-installation, since I do not have one :) .

For WordPress MU, only line 1 needs be changed. The lines 3 and 4 are only necessary, if you have a sitemap.xml and a robots.txt residing in you blog's file-directory, as you would for example when using MU Sitemap-Generator Plugin

If you have a better set of rules for either WordPress MU and/or WordPress, feel free to post them as comments.

lighttpd <= 1.4.19 has a denial of service vulnerability

Monday, April 7th, 2008

On Thursday, March 27th 2008, a DoS-vulnerability in lighttpd 1.4.19 and lower versions was reported on cve.mitre.org. It has been confirmed through lighttpd's bug-tracking system. As of this writing, there is no official bugfix-release of lighttpd, yet, but according to the bug-tracking system, the issue is closed and marked as fixed. This suggests that there might be a new release soon, especially as this has been discussed in several comments on the bug-tracking system.

The problem as described in the bug-tracker: "if a user killed his ssl connection, lighttpd would kill another ssl connection as it didn't clear the ssl error queue."