Les htaccess n’existent pas sous Lighttpd, mais il y a un équivalent de taille. Vérifiez avant de commencer que le module mod_auth est bien chargé.
Nous allons dans un premier temps générer (avec -c pour la première fois, comme un htaccess) un fichier contenant les identifiants pour être autoriser à consulter tel ou tel site :

Command htdigest
htdigest -c /etc/lighttpd/.passwd 'Authorized users only' deimos


Je créer ici l’utilisateur deimos. Le realm (ici ‘Authorized users only’) va nous permettre de différencier les différents fichiers de login/mot de passe que nous allons pouvoir avoir car nous ne pouvons en spécifier qu’un seul pour tout le serveur.

Ensuite on rajoute ces lignes dans la configuration global de lighttpd :

Configuration File /etc/lighttpd/lighttpd.conf
  1. auth.backend = "htdigest"
  2. auth.backend.htdigest.userfile = "/etc/lighttpd/.passwd"
  3. auth.debug = 2


Puis je rajoute à l’endroit qui m’intéresse la protection :

Configuration File /etc/lighttpd/lighttpd.conf
  1. auth.require = ( "/docs/" =>
  2.    (
  3.       "method" => "digest",
  4.       "realm" => "Authorized users only",
  5.       "require" => "valid-user"
  6.    )
  7. )


On redémarre lighty et c’est bon. L’exemple ci dessus montre comment ajouter la restriction à l’endroit qui nous intéresse, nous allons donc le faire en modifiant notre conf d’awstats :

Configuration File /etc/lighttpd/conf-available/50-awstats.conf
  1. alias.url = (
  2.                 "/awstats-icon" => "/usr/share/awstats/icon/",
  3.                 "/awstats/" => "/usr/lib/cgi-bin/",
  4.                 "/icon/" => "/usr/share/awstats/icon/"
  5.               )
  6. # provide awstats cgi-bin access
  7. $HTTP["url"] =~ "/awstats/" {
  8.     cgi.assign = ( ".pl" => "/usr/bin/perl" )
  9.     auth.require = ( "/awstats/" =>
  10.         (
  11.         "method" => "digest",
  12.         "realm" => "Trusted users only",
  13.         "require" => "valid-user"
  14.         )
  15.     )
  16. }

Multiple light-weight httpd server

In search for a lightweight solution to run some php pages on my Debian diskless shellserver it appears there are several lightweight httpd daemons in Debian that can do php.

I created some virtual machines on KVM to do some testing. Here follows a short howto to get the different httpd servers running 🙂

Howto install lightweigt httpd daemons with PHP support

Debian comes with several httpd daemons. On this page we look at the following httpd servers:




Nginx requires the most work.

Lighthttpd with PHP

apt-get install mysql-server mysql-client

apt-get install lighttpd

comment this line out in /etc/lighttpd/lighttpd.conf include_shell « /usr/share/lighttpd/use-ipv6.pl »

check that lighthttpd is running.

Point your browser to http://<ip-number>

screenshot of lighttpd

Screenshot of lighttpd just after installing

apt-get install php5-cgi

ln -s /etc/lighttpd/conf-available/10-fastcgi.conf /etc/lighttpd/conf-enabled/

/etc/init.d/lighttpd restart

PHP ready to use

Your server should be ready to use PHP now. To test it, create a file info.php in /var/www. The contents of the file should be something like this:




screenshot of lighttpd running php info

Screenshot of lighttpd running phpinfo

Cherokee with PHP

apt-get install mysql-server mysql-client

apt-get install cherokee

apt-get install php5-cgi

test that cherokee runs, point your browser to http://<ip-number>

screenshot of cherokee

Screenshot of cherokee just after installing

Run cherokee-admin -b

The -b option makes it possible to reach cherokee-admin from other machines than localhost.

screenshot of cherokee admin

Screenshot of cherokee admin

Click on Virtual servers

Click on « default »

Click on « Wizzards »

Click on « Languages »

Click on « Run Wizzard » next to the PHP logo

(See screenshot below)

screenshot of cherokee admin ready to invoke php wizzard

Screenshot of cherokee admin ready to invoke the PHP-wizzard

PHP ready to use

Your server should be ready to use PHP now. To test it, create a file info.php in /var/www. The contents of the file should be something like this:




screenshot of cherokee running php info

Screenshot of cherokee running phpinfo

viaRun PHP with a light weight webserver | box.matto.nl.

Canonical URL is part of a problem for most blogs. Most people who concern about different versions of a URL that display the same content are likely worry about duplicate content issue. As we know, that is not good from the search engine standpoint. The solution is to www redirect — redirecting your blog from non-www to www or vice versa.

URL canonicalization goes beyond www vs non-www, but interestingly this topic alone has been discussed very often. The problem is, a lot of people get it incorrectly.

Let me elaborate…

The other day, I was browsing the WordPress plugin directories and saw many similar plugins that for www redirection using 301 permanent redirect.

What’s Wrong with “Typical” Solutions?

Don’t get me wrong. The problem is not is its simplicity. In fact, I’ve used a simpler plugin before that removes two meta header tags from standard WordPress header. If something allows me to accomplish something without modifying WordPress code everything I need to upgrade, I’ll take it if it serves a purpose.

This is quite different for 301 www redirection plugins. Most of them are not necessary anyway. One version extends functionalities to include Apache-based redirections, 404 monitoring and more.

I won’t name names, but the rest is just redundant. No, scratch that, they hurt the performance of your WordPress, although that might be just a bit.

For instance, a typical WordPress execution takes the following path:

Web browser → Web server → WordPress (PHP) → MySQL

Assuming that the data is placed within MySQL database, you need to go through the entire process, which adds delay every step of the way. The returning path is again as far, although the flow is exactly the opposite.

If your web server setup is optimized in a way that you don’t have to invoke PHP when processing static and other files (you should), you also have added CPU and memory usage to your server unnecessarily.

In other words, the cost is not only delay time, but also performance-wise.

Do you need to execute the WordPress core just to redirect www to non-www and vice versa? The answer is NO.

Let the Web Server Do the Work

All web servers I know of support this feature. You can either 301 (permanent) or 302 (temporary) redirect right in the web browsers, either to another page within the same domain or externally to the corresponding domain.

The flow of a redirection becomes:

Web browser → Web server

If you prefer the www version and the visitor uses non-www, the server will immediately return 301 Moved Permanently code in the header, including the new URI in the Location: header.

By the way, it has to be 301 redirection if you want to solve the canonical URL problem and avoid duplicate content.

Before implementing the redirection code, make sure you have think about the version you’d like to keep. I personally prefer the non-www version simply because it is shorter.

For the curious mind, the following gibberish code uses regular expression (or regex) to match the domain. For instance, the tilde sign (^) means start of a string. You don’t need to understand it though, unless you want to dig into advanced configuration.

Note: The following solution works for every blog and web site, and it doesn’t require any type of blog platform or software to work.

WWW Redirect with Apache

Note that you should put this into .htaccess file in your root directory of your web site, even if your blog is in a sub-directory.

mod_rewrite module is required for this to work. If you have used clean URLs or fancy URLs feature for your blog (permalinks), you already have this feature.

Here is the code to redirect www to non-www:




RewriteEngine On

RewriteCond %{HTTP_HOST} ^www\.(.*) [NC]

RewriteRule ^(.*) http://%1/$1 [R=301,L]

An alternative which includes domain name is as follow:




RewriteEngine On

RewriteCond %{HTTP_HOST} ^example\.com$ [NC]

RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,L]

Put it close to the top or on the first line of .htaccess. You don’t have to modify a thing, edit your domain, or such. It works out of the box.

The following is the version to redirect non-www to www:




RewriteEngine On

RewriteCond %{HTTP_HOST} ^example\.com$ [NC]

RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,L]

WWW Redirect with nginx

WWW redirect requires rewrite module, but it is included as standard HTTP modules during compilation of nginx. All Linux distribution packages that I’ve tested with include this feature.

Add this code to the top of the page, separately from the server {} section for the preferred canonical name.

For instance, if you like to redirect to non-www, add the following code:






server {

listen 80;

server_name www.example.com;

rewrite ^/(.*) http://example.com/$1 permanent;


The word permanent is key. It turns the redirect into 301 redirection. After this block, you may configure the domain without www.

Here is the code for redirecting non-www to www:






server {

listen 80;

server_name example.com;

rewrite ^/(.*) http://www.example.com/$1 permanent;


WWW Redirect with lighttpd

This trick requires mod_redirect module. You should put it close to the top of the configuration file before other redirect or rewrite rules.

Redirecting www to non-www can be done with the following code:




$HTTP[« host »] =~ « ^www\.(.*)$ » {

url.redirect = ( « ^/(.*) » => « http://%1/$1 » )


This version redirects non-www to www inside the same domain. Substitute example.com with your domain.




$HTTP[« host »] =~ « ^example\.com$ » {

url.redirect = ( « ^/(.*) » => « http://www.example.com/$1 » )


How to Edit Server Configuration

Usually web hosting providers allow you to edit configuration options per directory. Just drop a .htaccess on the root directory of your web documents. You can edit this directly by loging into your web hosting account or use the cPanel editor (or any web administration interface).

You don’t need to restart or reload your Apache server because it will read .htaccess in a directory when accessing it.

For lighttpd and nginx, you should have direct access to your configuration file. If not, ask your admin to edit it for you. Don’t forget to reload or restart to apply the new configuration.

viaHow to WWW Redirect the Right Way! (Apache, nginx and lighttpd).

lighttpd + PHP-FPM on Debian Squeeze

I’m not a super-BOFH but I do like to host my own blog (not this on, though) and play with stuff.

In the past I used to use Apache, but I never liked the VirtualHosts configuration, specially when it gets big. Don’t get me wrong, I’m not saying its not right, its just not right for me. So I switched to lighttpd and I loved the configuration. It also has good performance.

This lighttpd server hosts a couple of WordPress blogs among other stuff and I noticed some slowness from time to time. Since its not critical to me I didn’t bother much. But then, reading some of my RSS feeds I heard about PHP-FPM. Never heard of it before.

It will run as a system daemon and take care of spawning PHP processes for handling requests when necessary, among other things. Its performance should be better than old FastCGI, so I decided to give it a try.

There is no PHP-FPM package on Debian Squeeze, but fortunately we can use the Dotdeb respository which does have one. Follow the instructions here and install PHP-FPM:

apt-get install php5-fpm

You may also want to upgrade all your PHP related packages, Dotdeb contains good and updated packages.

Now we need to configure lighttpd to use PHP-FPM. Lets create a configuration file for that in /etc/lighttpd/conf-available with the following content:

server.modules += ( « mod_fastcgi » )

fastcgi.server = ( « .php » =>

( « localhost » =>


« host » => « »,

« port » => « 9000 »




view raw gistfile1 This Gist brought to you by GitHub.

I suggest you name the file 10-fastcgi-fpm.conf. Now lets disable old FastCGI and enable our new module:

lighttpd-disable-mod fastcgi

lighttpd-disable-mod fastcgi-php

lighttpd-enable-mod fastcgi-fpm

And last, restart the server:

/etc/init.d/lighttpd force-reload

I didn’t benchmark it thoroughly, but my rtGUI page used to take up to 10 seconds to load and now it takes less than a second. Not bad!

vialighttpd + PHP-FPM on Debian Squeeze – saghul, on code.

Setting up a simple SSL configuration¶

Setting up a simple SSL configuration with Lighttpd is quite easy. Though this method should be used with care because this setup will only provide proper encryption, not authentication! The user will be presented with a query whether to accept the certificate or not!

First, go into your SSL Certificates directory and do:

cd /etc/lighttpd/certs

openssl req -new -x509 -keyout lighttpd.pem -out lighttpd.pem -days 365 -nodes

chmod 400 lighttpd.pem

The previous instuctions were saying the file should be owned by www-data (depending on the OS)

but this is a really bad idea (in case the server gets compromised etc.). As lighttpd starts

with root-privileges and drops his rights, you can safely set the owner of the certificate

to root and chmod 400 it.

Then edit /etc/lighttpd/lighttpd.conf and add:

$SERVER[« socket »] == « :443 » {

ssl.engine = « enable »

ssl.pemfile = « /etc/lighttpd/certs/lighttpd.pem »


After restarting the webserver, you should be able to access your webserver through https.

Because without ssl.ca-file configured, firefox will not accept this certificate, even if it’s valid certificate.

See Also

viaLighttpd – HowToSimpleSSL – lighty labs.

Password protection can limit access to your website or a specific sub-directory.


Make sure you enable mod_access and mod_auth in your lighttpd.conf:

server.modules += ( « mod_access » )

server.modules += ( « mod_auth » )


#htpasswd -c ~/lighttpd/foo-auth.xt username

Running this command will prompt for this user’s new password to store in the txt file. Combining this with a special $HTTP[« host »] conditional ruleset in our lighttpd.conf will allow us to enable BASIC http authentication.

$HTTP[« host »] =~ « .*domainroot.* » {

$HTTP[« url »] =~ « ^/somesubdir/ » {

auth.backend = « htpasswd »

auth.backend.htpasswd.userfile = « /home/you/lighttpd/foo-auth.txt »

auth.require = (« /somesubdir » => (

« method » => « basic »,

« realm » => « anything »,

« require » => « valid-user »




Plain Text

If you don’t have access to htpasswd or don’t care if the password is not encrypted, you can simply create a plain text file with the following:


« Username » can be any user name you like and the « 123 » is the password.

The configuration is a little different for this form of authentication:

$HTTP[« url »] =~ « ^/somesubdir » {

auth.backend = « plain »

auth.backend.plain.userfile = « /home/you/lighttpd/foo-auth.txt »

auth.require = (« /somesubdir » => (

« method » => « basic »,

« realm » => « whatever »,

« require » => « valid-user »



via2skies.com :: basic http authentication with lighttpd.

<span class="html">Want to avoid segmentation with  apc.shm_segments?If your linux server limits the shared memory block  size and you're forced to use apc.shm_segments instead, change the  setting by using (here is 512M but change it as you like):
# sysctl -w kernel.shmmax=536870912

(but if you want the change to be permanent after a restart you would have to add the following line in /etc/sysctl.conf


and updating apc.ini


apc.stat is an extremely important setting for a production server,  especially if many files are accessed on every request, which is quite  normal on complicated web applications.

Always aspire to use:
so that APC does not try to check that each and every file exists on  every request you make. It also means you can update files on your  server without crashing incoming requests on that time fragment.  Whenever you wish to force APC to re-read all the files, simply clear  the cache or restart your server.</span>

Pour faire fonctionner wordpress avec le rewriting et lighttpd, j’ai trouvé ça en surfant :

$HTTP[« host »] =~ « votreurl » {

url.rewrite-final =(

# On ne reecrit pas certain dossiers

« ^/(wp-admin|wp-includes|wp-content|gallery2)/(.*) » => « $0 »,

# meme chose pour les fichiers .php

« ^/(.*.php) » => « $0 »,

# Par contre on refait les permaliens

« ^/(.*)$ » => « /index.php/$1 » ) }

Mon conseil dans la rubrique permalien de wordpress est d’activer la réécriture suivante :


du coup les articles ressemblent à des pages statiques .

Ma source :URL rewriting for wordpress and lighttpd « Emil Haukeland.