2007.11_Lighttpd serwer HTTP–alternatywa dla Apache_[Administracja].pdf

rozwiązania

Lighttpd serwer HTTP

– alternatywa dla Apache

Dariusz Zielinski

Internet dla wielu ludzi to przede wszystkim serwery HTTP, gdzie największy udział w tym segmencie

przypada serwerowi Apache, a jest to bardzo popularny i solidny serwer. Jednak powszechnie używane

są moduły języka python, perl czy php, które mocno są związane z samym serwerem. Błąd w skryptach,

pracujących w trybie "mod_php" czy "mod_python" odbija się bardzo niebezpiecznie na stabilności

systemu HTTP.

wer, a problem nie dotyczy tylko Apache'a, lecz tak-

że windowsowego IIS.

Czy w takim razie jest jakieś inne rozwiąza-

nie, które nie będzie miało tych wad? Owszem jest – ser-

wer Lighttpd . Lighttpd to bezpieczny, szybki, zgodny ze

standardami i łatwy w obsłudze serwer HTTP, zaprojekto-

wany dla środowisk wymagających wysokiej wydajności,

a poza tym ma bardzo małe zapotrzebowanie na pamięć

i moc procesora; obsługuje m.in.: FastCGI, CGI, Auth, Out-

put–Compression, URL–Rewriting. Ma także wbudowa-

ny mechanizm rozkładania ruchu na wiele serwerów. Li-

ghttpd jest bardzo dobrą alternatywą dla Apache'a, zwłasz-

cza jeśli chodzi o wydajność. FastCGI zwiększa możliwo-

ści serwera. Skrypty mod_php na Apache’u pracują w ob-

rębie jednego użytkownika, a to stanowi dosyć poważną

lukę w bezpieczeństwie systemu. Każdy może przeglą-

dać pliki innych użytkowników za pomocą prostego skryp-

tu PHP i wszyscy mają dostęp do wszystkich. W Fast-

CGI tego problemu nie ma, a każdy użytkownik jest izolo-

wany z własnym osobnym procesem FastCGI. Procesy Fa-

stCGI są izolowane od serwera, a w przypadku gdy ulegną

zawieszeniu serwer pracuje dalej, natomiast proces można

ubić lub zrestartować. Otrzymujemy, wtedy znacznie więk-

szą stabilność pracy. Apache 2.x potrai pracować w dwóch

trybach: wielowątkowym (worker) lub wieloprocesorowym

(prefork). Pierwszy jest nowocześniejszy, szybszy i mniej

potrzebuje pamięci – niestety PHP nie ma poprawnie za-

implementowanej wielowątkowości i dlatego możemy za-

pomnieć o trybie wielowątkowym. Pozostaje nam zatem

pracować w starym trybie prefork (używanym w Apache 1.x).

Rysunek 1. Strona startowa serwera Lighttpd

listopad 2007

J eden błąd w skrypcie PHP potrai zawiesić cały ser-

rozwiązania

Lighttpd serwer HTTP

sudo /etc/init.d/lighttpd

{start|stop|restart|reload|

force–reload}

Jeśli dalej poszło coś nie tak – to pod lupę bie-

rzemy nasze logi: tail –n30 –f /var/log/

lighttpd/error.log oraz access.log ). Za-

kładam, że uporaliśmy się z wystartowaniem

serwera – co raczej nie powinno sprawić więk-

szych problemów.

Teraz połączymy nasz serwer z obsługą ję-

zyka PHP. Komenda lighty–enable–mod po-

każe dostępne moduły do załadowania, m.in.:

auth cgi fastcgi proxy simple – vhost ssi ssl

userdir. Załadujmy potrzebne moduły:

sudo lighty–enable–mod fastcgi

simple–vhost userdir .

Komenda lighty–disable–mod robi to samo

tylko odwrotnie, czyli deaktywuje moduły za-

ładowane wcześniej.

W katalogu /etc/lighttpd mamy nasze pliki

koniguracyjne:

Rysunek 2. Strona testowa PHP Lighttpd

• katalog conf–available z plikami:

10–auth.conf ; 10–cgi.conf ; 10–fastcgi.conf ,

10–proxy.conf , 10–simple–vhost.conf ,

10–ssi.conf , 1 0–ssl.conf , 10–userdir.conf;

Lighttpd działa szybciej z PHP niż Apache

z mod_php – są to różnice rzędu dwa, trzy ra-

zy. Jeszcze szybszym i wydajniejszym serwe-

rem jest rosyjski „Nginx", lecz nieco trudniej

go uruchomia się z PHP.

Poniżej podaję przykład uruchomienia

serwera Lighttpd z obsługą PHP, kontami wir-

tualnymi, ograniczonym dostępem do zaso-

bów i szyfrowaną transmisją SSL. Opis jest

przygotowany w oparciu o dystrybucję Ubun-

tu Serwer, lecz w innych dystrybucjach koni-

guracja serwera będzie bardzo podobna.

Instalujemy potrzebne oprogramowanie:

Listing 2. Plik /etc/lighttpd/conf–enabled/10–

userdir.conf

• sudo aptitude install lighttpd

libterm–readkey–perl libterm–

readline–perl–perl lighttpd

php5–cgi php5–common ;

server.modules += ( "mod_userdir" )

userdir.path = "public_html"

userdir.exclude–user = ( "root" ,

"postmaster" )

Listing 1. plik: /etc/lighttpd/conf–enabled/10–fa-

stcgi.conf

W zasadzie mamy już działający serwer WWW

– sprawdzamy to w przeglądarce pod adre-

sem:

Listing 3. Wprowadzamy zmiany w pliku /etc/

lighttpd/conf–enabled/10–simple–vhost.conf

server.modules += ( "mod_fastcgi" )

fastcgi.server = ( ".php" =>

((

"bin–path" => "/usr/bin/php5–cgi" ,

"socket" => "/tmp/php.socket" ,

"max–procs" => 2,

"idle–timeout" => 20,

"bin–environment" => (

"PHP_FCGI_CHILDREN" => "4" ,

"PHP_FCGI_MAX_REQUESTS" =>

"10000"

"bin–copy–environment" => (

"PATH" , "SHELL" , "USER"

"broken–scriptilename" => "enable"

))

)

• http://127.0.0.1.

Powinna nam się zgłosić strona startowa świe-

żo uruchomionego serwera, jak to pokazano na

Rysunku 1.

Jeśli nie – to sprawdźmy, czy nasz serwer się

uruchomił:

server.modules +=

( "mod_simple_vhost" )

$HTTP [ "host" ] !~

"^(jacek \. domena \. pl) $" {

simple–vhost.server–root =

"/home/jacek"

simple–vhost.document–root =

"public_html"

simple–vhost. default –host =

"jacek.domena.pl"

}

$HTTP [ "host" ] ==

"jacek.domena.pl" {

server.document–root =

"/home/jacek/public_html"

}

• sudo lsof –i |grep lighttpd – po-

winniśmy zobaczyć coś podobnego:

• lighttpd 6906 www–data 4u IPv4

23816 TCP *:www (LISTEN)

Jak widać nasz serwer nasłuchuje na porcie 80

(www) protokołu TCP (IPv4) z prawami użyt-

kownika www–data . Jeśli komenda lsof nic

podobnego nam nie wypisała na terminal star-

tujemy serwer ręcznie:

www.lpmagazine.org

rozwiązania

Lighttpd serwer HTTP

Listing 4. Główny plik koniguracyjny /etc/lighttpd/lighttpd.conf

• katalog conf–enabled z dowiązaniami:

fastcgi.conf –> /etc/lighttpd/conf–available/

10–fastcgi.conf, 10–simple–vhost.conf –>

/etc/lighttpd/conf–available/10–simple–

vhost.conf, 10–userdir.conf –> /etc/lighttpd/

conf–available/10–userdir.conf

server.modules = (

"mod_access" ,

"mod_alias" ,

"mod_accesslog" ,

"mod_rewrite" ,

"mod_redirect" ,

"mod_status" ,

"mod_evhost" ,

"mod_compress" ,

"mod_expire" ,

)

server.document–root = "/var/www/"

server.errorlog = "/var/log/lighttpd/error.log"

index–ile.names = ( "index.lighttpd.html" , "index.php" , "index.html" ,

"index.htm" , "default.htm" )

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

url.access–deny = ( "~" , ".inc" )

server.port = 80

server.pid–ile = "/var/run/lighttpd.pid"

dir–listing.encoding = "utf–8"

server.dir–listing = "enable"

server.username = "www–data"

server.groupname = "www–data"

$HTTP [ "remoteip" ] == "127.0.0.1" {

alias.url += (

"/doc/" => "/usr/share/doc/" ,

"/images/" => "/usr/share/images/"

)

$HTTP [ "url" ] =~ "^/doc/|^/images/" {

dir–listing.activate = "enable"

}

include_shell "/usr/share/lighttpd/create–mime.assign.pl"

include_shell "/usr/share/lighttpd/include–conf–enabled.pl"

oraz główny plik koniguracyjny serwera: li-

ghttpd.conf.

Edytujmy plik:

sudo vim /etc/lighttpd/conf–enabled/

10–fastcgi.conf

Powinien wyglądać mniej więcej jak na Li-

stingu 1. Upewniamy się, czy mamy poprawną

ścieżkę do php5–cgi (lub php–cgi ).Sprawdźmy,

czy serwer poprawnie obsługuje język PHP i re-

startujemy serwer z nowymi ustawieniami:

sudo /etc/init.d/lighttpd restart

Tworzymy plik testowy: echo "<?php phpin-

fo() ?>" >/var/www/test.php

Teraz sprawdzamy w przeglądarce: http://

127.0.0.1/test.php – powinien się ukazać ekran

z informacjami o wersji i ustawieniach PHP –

Rysunek 2. Od tej chwili jest poprawnie skoni-

gurowane zestawienie serwera lighttpd z PHP,

a więc przejdźmy do dalszej koniguracji. Plik

/etc/lighttpd/confenabled/10–userdir.

conf wskazuje katalogi prywatnych stron użyt-

kowników, czyli standardowo: public_html

i raczej nie trzeba go poprawiać, a wygląda jak

na Listingu 2.

Dostęp do stron użytkowników odbywać

się będzie w ten sposób:

• http://domena.pl/~jacek

Listing 5. Dostosujmy plik koniguracyjny do naszych potrzeb

server.modules += ( "mod_auth" )

auth.backend = "htdigest"

auth.backend.htdigest.userile = "/etc/lighttpd/

lighttpd–htdigest.user"

auth.require = ( "/download/" =>

(

"method" => "digest" ,

"realm" => "strefa download" ,

"require" => " group =www| user =jacek| host =192.168.2.10 "

" /public/ " =>

(

" method " => " digest ",

" realm " => " strefa publiczna ",

" require " => " valid–user"

)

Jeśli chcemy odwołać się do serwisu bardziej

profesjonalnie, np.:

• http://jacek.domena.pl

musimy, więc zrobić dwie rzeczy. Po pierwsze

poprawnie rozwiązać nazwę domenową w na-

szym przypadku jacek.domena.pl na prawid-

łowy numer IP w serwerze nazw (DNS), po

drugie prawidłowo skonigurować konta wir-

tualne użytkowników, czyli zająć się plikiem

10–simple–vhost.conf naszego serwera WWW.

Wprowadźmy zatem odpowiednie zmiany:

sudo vim /etc/lighttpd/conf–enabled/

10–simple–vhost.conf [Listing 3]

W przypadku większej ilości użytkowników/

serwisów klonujemy w/w wpisy a potem je do-

listopad 2007

rozwiązania

Lighttpd serwer HTTP

Listing 6. Edytujemy plik /etc/lighttpd/

conf–enabled/10–ssl.conf

Edytujmy plik: sudo vim /etc/lighttpd/

conf–enabled/10–auth.conf

Dostosujmy plik koniguracyjny do na-

szych potrzeb [Listing 5].

Teraz dociągamy dodatkowy program

htdigest , który znajduje się w pakiecie apa-

che2–utils : sudo aptitude install apa-

che2–utils.

Generujemy plik z użytkownikami i ha-

słami:

O autorze

$SERVER [ "socket" ] == ":443" {

ssl.engine = "enable"

ssl.pemile = "/etc/ssl/certs/

lighttpd.pem"

}

Administrator systemów Unix/Linux, szef

działu Informatyki w ZEC Bytom SA,

a od 1996 r. pracuje w systemie Linux na

desktop i serwerach. Jest również zwo-

lennikiem ruchu Free Software i Open

Source.

Kontakt z autorem: KeRaD@opensys.pl

Strona url: http://KeRaD.opensys.pl

Listing 7. Generujemy plik

cd /etc/ssl/certs/

openssl req –new –x509 –keyout

lighttpd.pem –out lighttpd.pem

–days 365 –nodes

sudo chown www–data:www–data

lighttpd.pem

sudo chmod 600 lighttpd.pem

htdigest –c /etc/lighttpd/lighttpd–

htdigest.user 'strefa download' jacek

telniającym nasz serwer – oczywiście ten plik

musimy wygenerować, np. w sposób, opisany

w Listingu 7.

Po przeładowaniu serwera możemy cie-

szyć się pełnowartościowym serwisem HTTP

z VHOST, PHP, AUTH i SSL. W zasadzie do

większości zastosowań wystarczy wyżej po-

dana koniguracja, jak widać bardzo szybkie-

go, lekkiego i wydajnego serwera WWW, a po-

za tym jest banalnie prosta i nie wymaga dużej

wiedzy, natomiast pliki koniguracyjne są bar-

dzo czytelne. Warto się zastanowić nad prze-

siadką z Apache'a, który nie zawsze jest po-

trzebny. Jeśli ktoś jest zainteresowany rozbu-

dowaniem serwera, to dobrym pomysłem będą

odwiedziny strony domowej, aby zapoznać się

z bardzo dobrą dokumentacją oraz z dużą ilo-

ścią przykładów: http://trac.lighttpd.net/trac/

wiki/Docs.

UWAGA: Parametr –c dla komendy jest pod-

czas tworzenia pliku! Później przy zmianie ha-

sła jest już niepotrzebny.

Od teraz aby wejść do katalogu – w na-

szym przypadku download musimy zostać

autoryzowani na podstawie wpisów w pliku

/etc/lighttpd/lighttpd–htdigest.user

– i właśnie o to nam chodziło. Na koniec może-

my zestawić szyfrowane połączenie SSL z na-

szym serwerem na przykład do obsługi poczty

przez HTML (tzw. WEBMAIL).

Załadujmy odpowiedni moduł: sudo li-

ghty–enable–mod ssl.

Edytujemy plik: sudo vim /etc/light-

tpd/conf–enabled/10–ssl.conf (Listing 6).

W pliku załączamy silnik obsługi SSL

i wskazujemy plik z certyikatem, uwierzy-

stosowujemy wedle potrzeb. W zasadzie głów-

nego pliku koniguracyjnego nie trzeba zmieniać

/etc/lighttpd/lighttpd.conf, ale warto mu się przyj-

rzeć (Listing 4):

less /etc/lighttpd/lighttpd.conf

Teraz postarajmy się ograniczyć dostęp do nie-

których zasobów naszego serwera; najpierw

włączmy dodatkowy moduł do serwera:

sudo lighty–enable–mod auth

R E K L A M A

www.lpmagazine.org

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: