Webserver mit Lighttpd aufsetzen

[Falk]

Lighttpd oder kurz lighty ist ein Webserver, der den meist verwendeten Apache komplett ersetzen kann.

Die Anleitung ist nur als Leitfaden zu verstehen und hat nicht den Anspruch, unter allen Bedingungen auf allen Systemen zu funktionieren. Die Installation sollte auf jeden Fall ausgiebig getestet werden, bevor der Server ans Netz geht.

Das folgende Setup bietet einige Vorteile, am wichtigsten: php-Scripte werden jeweils mit dem passenden User ausgeführt, die Scripte eines Users können nicht die Scripte eines anderen beeinflussen. Zudem ist es möglich, für jeden VirtualHost eine eigene php-Binary und/oder eine eigene php.ini zu verwenden.
Im Folgenden wird davon ausgegangen, dass ein Debian-System benutzt wird. Soweit möglich und sinnvoll wird auf apt zurückgegriffen. Lighty sowie php wird jedoch aus den sourcen kompiliert, es muss also alles vorhanden sein, um Software kompilieren zu können.

Zuerst müssten die Software-Anforderungen erfüllt sein:

$ apt-get install libpcre3
$ apt-get install zlib1g
$ apt-get install mysql-common libmysqlclient12
$ apt-get install libpcre3-dev
$ apt-get install zlib1g-dev

MySQL sollte hier in der Version 5.x installiert werden, im Zweifelsfall müssen hier backports benutzt werden.

Sind die Anforderungen erfüllt, müssen die aktuellen Sourcen von der lighty-Website heruntergeladen werden:

http://www.lighttpd.net/download/

Entpacken in Arbeitsverzeichnis (in diesem Fall /opt/src)

$ cd /opt/src
$ tar xvfz lighttpd-X.tar.gz

Sind die Sourcen entpackt, kann lighty kompiliert und installiert werden:

$ cd /opt/src/lighttpd-X
$ ./configure
$ make && make install

Besondere Optionen werden beim ./configure nicht gebraucht, der lighty wird so nach /usr/local installiert. Bei bedarf kann dies mittels --prefix=/installdir geändert werden. Sind alle Software-Bedingungen erfüllt sollte dieser Schritt ohne Probleme durchlaufen.

Um den lighty dann problemlos starten und stoppen zu können braucht man noch ein passendes Script in /etc/init.d/. Der Einfachheit halber enthält das folgende Code-Tag ein komplettes Script, sodass man entweder dieses Verwenden oder es anpassen kann.

#! /bin/sh
#
# skeleton example file to build /etc/init.d/ scripts.
# This file should be used to construct scripts for /etc/init.d.
#
# Written by Miquel van Smoorenburg <miquels@cistron.nl>.
# Modified for Debian
# by Ian Murdock <imurdock@gnu.ai.mit.edu>.
#
# Version: @(#)skeleton 1.9 26-Feb-2001 miquels@cistron.nl
#
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/local/sbin/lighttpd
OPTS="-f /etc/lighttpd/lighttpd.conf"
NAME=lighttpd
DESC=lighttpd
test -x $DAEMON || exit 0
# Include lighttpd defaults if available
if [ -f /etc/default/lighttpd ] ; then
. /etc/default/lighttpd
fi
set -e
case "$1" in
start)
echo -n "Starting $DESC: "
start-stop-daemon --start --quiet \
--pidfile /var/run/$NAME.pid --exec $DAEMON -- $OPTS
echo "$NAME."
;;
stop)
echo -n "Stopping $DESC: "
if start-stop-daemon --stop --pidfile /var/run/$NAME.pid \
--exec $DAEMON; then
rm -f /var/run/$NAME.pid
echo "$NAME."
fi
;;
reload)
#
# If the daemon can reload its config files on the fly
# for example by sending it SIGHUP, do it here.
#
# If the daemon responds to changes in its config file
# directly anyway, make this a do-nothing entry.
#
echo "Reloading $DESC configuration files."
start-stop-daemon --stop --signal 1 --quiet --pidfile /var/run/$NAME.pid \
--exec $DAEMON
;;
restart|force-reload)
#
# If the "reload" option is implemented, move the "force-reload"
# option to the "reload" entry above. If not, "force-reload" is
# just the same as "restart".
#
echo -n "Restarting $DESC: "
start-stop-daemon --stop --quiet --oknodo --pidfile /var/run/$NAME.pid \
--exec $DAEMON
rm -f /var/run/$NAME.pid
sleep 1
start-stop-daemon --start --quiet --pidfile /var/run/$NAME.pid \
--exec $DAEMON -- $OPTS
echo "$NAME."
;;
*)
N=/etc/init.d/$NAME
echo "Usage: $N {start|stop|restart|reload|force-reload}" >&2
#echo "Usage: $N {start|stop|restart|force-reload}" >&2
exit 1
;;
esac
exit 0

Soweit sollte alles funktionieren. Ein /etc/init.d/lighttpd start sollte den lighty starten.

Als nächstes kümmern wir uns um die grundlegenden Settings in der lighttpd.conf (/etc/lighttpd/lighttpd.conf). Folgende Module müssen aktiviert sein:

- mod_status
- mod_auth
- mod_fastcgi
- mod_simple_vhost
- mod_accesslog

Zur Sicherheit sollte man auch ein document-root für nicht VirtualHosts setzen:

Server.document-root = "/data/httpd

Danach muss das Verzeichnis des allgemeinen accesslogs gesetzt werden:

accesslog.filename = "/var/log/lighttpd/access.log

Diese Datei muss UID/GID lighttpd haben:

$ chown lighttpd:lighttpd /var/log/lighttpd/access.log

Unter url.access-deny müssen .htpasswd und .htaccess hinzugefügt werden, damit diese Dateien von Usern nicht heruntergeladen werden können.

Die Option server.pid-file muss aktiviert werden, damit das run-script den lighty neustarten kann.

Damit nicht jeder jede Datei einsehen kann wenn im Verzeichnis keine index-Datei vorhanden ist, muss

dir-listing.activate = "disable

gesetzt werden.

Um die VirtualHosts übersichtlich außerhalb zu lagern, wird die Datei lighttpd-vhost.conf eingebunden:

include "lighttpd-vhosts.conf

In dieser Datei werden die VirtualHosts nach folgendem Schema angelegt (Die Verzeichnisse müssen natürlich entsprechend des jeweiligen Servers angepasst werden):

$HTTP["host"] =~ "(^|\.)vhost1.de$" {
Server.document-root = "/data/httpd/vhosts/vhost1/html"
Server.errorlog= "/data/httpd/vhosts/logs/vhost1_error_log"
Accesslog.filename = "/data/httpd/vhosts/logs/vhost1_access_log"
Fastcgi.server = ( ".php" =>
(
( "socket" => "/data/httpd/fastcgi/vhost1/vhost1.socket",
"check-local" => "disable",
"broken-scriptfilename" => "enable"
)
)
)
}

Für eine Subdomain mit entsprechendem VirtualHost muss (^|\.) durch den entsprechenden Subdomain-Namen ersetzt werden, genauso müssen alle anderen Dateien angepasst werden.

Um jetzt php via fastcgi und entsprechenden Berechtigungen auszuführen, müssen folgenden Schritte gemacht werden. Zuerst wird php mit folgenden Settings kompiliert:

./configure --prefix=/opt/php-fcgi/5.1.2 \
--with-config-file-path=/etc/lighttpd/ \
--with-send-vm=GOTO \
--enable-exif \
--without-mm \
--enable-fastcgi \
--enable-force-cgi-redirect \
--enable-track-vars \
--with-calendar=shared \
--enable-magic-quotes \
--enable-trans-sid \
--enable-wddx \
--enable-ftp \
--enable-inline-optimization \
--enable-memory-limit \
--enable-imap \
--with-mysql \
--enable-mbstring \
--with-zlib-dir=/usr/local \
--with-gd \
--enable-gd-native-ttf \
--enable-gd-strttf \
--with-png-dir=/usr/lib \
--with-jpeg-dir=/usr/lib

Nach dem configure php mit make && make install installieren. Unter /opt/php-fcgi/5.1.2/bin/ steht nun das php-Binary zur Verfügung, was später verwendet wird.

Nun werden die entsprechenden Start-Scripte und Verzeichnisse und User erstellt. Für jeden VirtualHost wird ein User und eine Gruppe erstellt.

$ groupadd vhost1
$ useradd vhost1 g vhost1

Danach wird unter /data/httpd/fastcgi ein Ordner vhost1 erstellt und dem eben erstellten User zugeteilt:

$ mkdir /data/httpd/fastcgi
$ mkdir /data/httpd/fastcgi/vhost1
$ chown vhost1:vhost1 vhost1
$ chmod 750 *

In dieses Verzeichnis wird nun die php.ini kopiert und die Verzeichnisse (insbesondere tmp-Verzeichnisse) entsprechend in der php.ini angepasst.
Die Startscripte werden in /data/httpd/fastcgi/startup abgelegt.

$ mkdir /data/httpd/fastcgi/startup

Das eigentliche Startscript sieht dann so aus:

#!/bin/bash
## ABSOLUTE path to the spawn-fcgi binary
SPAWNFCGI="/usr/local/bin/spawn-fcgi"
## ABSOLUTE path to the PHP binary
FCGIPROGRAM="/opt/php-fcgi/5.1.2/bin/php-fcgi"
## bind to tcp-port on localhost
FCGISOCKET="/data/httpd/fastcgi/vhost1/vhost1.socket"
## path to php.ini
PHPRC="/data/httpd/fastcgi/vhost"
## number of PHP childs to spawn
PHP_FCGI_CHILDREN=5
## number of request server by a single php-process until is will be restarted
PHP_FCGI_MAX_REQUESTS=1000
## IP adresses where PHP should access server connections from
FCGI_WEB_SERVER_ADDRS="127.0.0.1"
# allowed environment variables sperated by spaces
ALLOWED_ENV="PATH USER"
## if this script is run as root switch to the following user
USERID=vhost1
GROUPID=vhost1
################## no config below this line
if test x$PHP_FCGI_CHILDREN = x; then
PHP_FCGI_CHILDREN=5
fi
export PHP_FCGI_MAX_REQUESTS
export FCGI_WEB_SERVER_ADDRS
export PHPRC
ALLOWED_ENV="$ALLOWED_ENV PHP_FCGI_MAX_REQUESTS FCGI_WEB_SERVER_ADDRS PHPRC"
# copy the allowed environment variables
E=
for i in $ALLOWED_ENV; do
E="$E $i=${!i}"
done
# clean environment and set up a new one
env - $E $SPAWNFCGI -s $FCGISOCKET -f $FCGIPROGRAM -u $USERID -g $GROUPID -C $PHP_FCGI_CHILDREN
chmod 770 $FCGISOCKET

An dieser Stelle ist ein Workaround nötig: diese Datei, die zur eindeutigen Zuordnung z.B. vhost1-startup benannt werden sollte, wird nicht automatisch ausgeführt, wenn lighty gestartet wird. Um bei mehreren VirtualHosts nicht jedes der Startup-Scripte einzelnd ausführen zu müssen, wird ein Script (php-start) mit folgendem Schema verwendet:

#!/bin/sh
ROOT="/data/httpd/fastcgi/startup"
killall php #ggf. php-fcgi
sh $ROOT/vhost1-startup
sh $ROOT/vhost2-startup

usw.
Nach dem Anlegen der Startscripte braucht es nun die entsprechenden Daten-Verzeichnisse auf dem Webserver:

$ mkdir /data/httpd/vhosts
$ mkdir /data/httpd/vhosts/vhost1/
$ chown vhost1:vhost1 vhost1
$ cd vhost1
$ mkdir tmp html
$ chown vhost1:vhost1 *
$ chmod 750 *

Nun sollte noch einmal der Webserver und die php-server neu gestartet werden:

$ /etc/init.d/lighttpd restart
$ sh /data/httpd/fastcgi/startup/php-start

Jetzt ist es geschafft. Nach dem Schema sollten jetzt ohne Probleme weitere VirtualHosts hinzugefügt werden können.

 

[|L1n3]

Schön und gut ..
Nur WARUM sollte man ausgerechnet Lighttp nehmen und nich den Apache ?
Speicherbedarf kann ja wohl kein grund sein ..

 

[Falk]

In einigen Situationen ist Lighty dem Apache überlegen, was Speed usw. angeht. Seiten wie Youtube oder Wikipedia setzen auf lighty (laut lighty-Webseite).

Nur weil es für den Apache vielleicht die meisten Tutorials gibt (und er damit für einsteiger das leichteste ist) heißt das noch nicht, das er für alle Anwendungszwecke das beste ist.

 

[|L1n3]

In einigen Situationen ist Lighty dem Apache überlegen, was Speed usw. angeht. Seiten wie Youtube oder Wikipedia setzen auf lighty (laut lighty-Webseite).

Nur weil es für den Apache vielleicht die meisten Tutorials gibt (und er damit für einsteiger das leichteste ist) heißt das noch nicht, das er für alle Anwendungszwecke das beste ist.

Xampp setzt auf Apache.
Die meisten Linux Distris werden mit Apache ausgeliefert.

Youtube empfinde ich persönlich als langsam.
Also ich seh immer noch keine Grund ^^

 

[Falk]

Xampp setzt auf Apache.
Die meisten Linux Distris werden mit Apache ausgeliefert.

Youtube empfinde ich persönlich als langsam.
Also ich seh immer noch keine Grund ^^

Die meisten Home-PCs haben Windows...

Lighty kann aus vorhandener Hardware mehr rausholen als der Apache (mehr Request/s beantworten). Das Youtube langsam ist liegt dann an der Hardware/der Bandbreite.

Vorteil, für privatanwender kaum relevant: ein Setup wie es obige ist mit Apache eher kompliziert.

Allerdings will ich auch niemanden zu lighty drängen, das schöne an Linux ist ja eben, das es für jedes Problem verschiedene Software-Lösungen gibt und man die freie wahl hat.

 

[Fonce]

Danke Falk
Ich war schon länger auf der Suche nach Alternativen zu Apache, nur habe ich(aus welchen Gründen auch immer) da nie was gefunden.
Werd mir den Lighttpd in den Ferien mal anschauen