Konfigurace generovaná skriptem
Konfigurace se vztahuje pouze na jeden soubor, ale můžeme do něj vkládat i další. Můžeme si také napsat skript, který vygeneruje konfiguraci třeba pro každý jednotlivý web a ta se pak vloží do hlavního konfiguračního souboru při spouštění web serveru.
Možná už na začátku jsem měl zmínit, že konfigurace se nedá za běhu jakkoli ovlivňovat (pokud nepočítáme např. modul mod_mysql_vhost) a i při nepatrně změně musíme web server restartovat. To je naštěstí u Lighttpd otázkou pár vteřin.
Příklady:
# tímto řádkem do konfigurace mého lighttpd vkládám rewrite a redirect pravidla pro každý web
# používám k tomu skript rrmods s adresářem jako parametrem
# includuje se standardní výstup skriptu
include_shell "/usr/local/bin/rrmods.py /etc/lighttpd/rrrules/"
# druhou možností je vložení obsahu jednoho pevně daného souboru
include "/etc/lighttpd/rules/rule1.conf" Komprese
Pro ušetření pár procent linky, na které je web server připojen, je možné zapnout kompresi odesílaného obsahu. Na první pohled se možná jedná o zbytečnou vlastnost, ale lidé, kteří používají mobilní nebo jiné „pomalé“ připojení, kompresi ocení. Ale ani ostatní kompresí nepohrdnou. Správně nastavený server může načítání stránek urychlit i na relativně rychlých linkách. Samozřejmě jsou zde kladeny větší nároky na procesor.
V každém požadavku prohlížeč odesílá na server informace o tom, že podporuje kompresi, a podle toho se server rozhodne, co pošle. Nastavení pak tkví v určení adresáře pro ukládání zkomprimovaných dat, typ dat, která se mají komprimovat a nakonec maximální velikost originálního souboru. Lighttpd aktuálně podporuje kompresi pouze statických souborů, ale u dynamického obsahu není nic ztraceno.
Většina způsobů vytváření dynamických stránek má podporu pro kompresi již rovnou v sobě. Například u PHP stačí zapnout:
zlib.output_compression = 1
zlib.output_handler = On Do nastavení Djanga přidat:
MIDDLEWARE_CLASSES = (
[...]
'django.middleware.gzip.GZipMiddleware',
[...]
) Zapnutí komprese vypadá následovně:
compress.max-filesize = 4096
compress.cache-dir = "/tmp/cache"
compress.filetype = ("text/plain", "text/html") Cachování
mod_cache
Pro cachování obsahu se používá modul „mod_cache“. Je to modul třetí strany a tak není zahrnut v oficiálním repozitáři. Cachování slouží pro odlehčení linky mezi cache a web serverem, ale také například pro redukci SQL dotazů na databázový server. Tento modul je silně spojen s modulem mod_proxy a pracuje pouze s ním. Hodí se na místech, kde slouží Lighttpd jako „předvoj“ pro další web servery.
Instalace spočívá v aplikování patche, který lze nalézt v dokumentaci. Problémy mohou nastat u aktualizací, kdy nemusí být k dispozici tento modul hned po vydání nové verze.
Konfigurace je jednoduchá a víceméně spočívá v určení, která URL se mají cachovat a jak často aktualizovat. Pro vypsání seznamu zboží se už aplikace nemusí dožadovat několikrát databáze o data a použije se stránka z cache. Některé volby se liší ve verzi 1.4 a 1.5, proto v příkladu uvedu pouze 1.4, protože je momentálně stable a vyskytuje se ve většině distribucí.
cache.bases pole s adresáři, kde se budou ukládat cachované stránky
cache.enable zapnutí/vypnutí cachování
cache.domains pole s doménami, které budou cachovány
cache.support-queries zohledňování proměnných v URL
cache.debug zapnutí/vypnutí ladících hlášek
cache.purge-host seznam IP adres (i s maskou), kterým se zobrazí originální obsah
cache.refresh-pattern pole s URL, které budou cachovány Příklad jednoduchého nastavení:
cache.bases = ("/tmp/cache") #adresář pro ukládání cachovaných dat
cache.refresh-pattern = (
# cachovat hlavní stránku a obnovit ji při požadavku a refresdh nebo po pěti minutách
"/$" => "5 update-on-refresh no-expire-header",
"\.(?i)(htm|html|shtml)$" => "30", # cachovat *htm* soubory a obnovovat je každých 30 minut
"\.(?i)(jpg|bmp|jpeg|gif|png)$" => "2880", # cachovat obrázky a obnovovat je každé 2 dny
)
proxy.server = ( "/" => (( "host" => "10.1.0.1", "port" => 80 )) ) # napojit se na web server
proxy.worked-with-mod-cache = "enable" #zapnout podporu mod_cache v mod_proxy Modul mod_cache musí být načten až po modulu mod_proxy.
mod_mem_cache
Tento modul opět není zahrnut do oficiálního stromu a patche lze stáhnout z odkazů v dokumentaci. Na rozdíl od mod_cache funguje i na lokálních souborech. Druhá odlišnost je, že cachovaná data neukládá do souborů, ale do paměti. Díky tomu je servírování několika tisíc malých souborů pro lighttpd doslova hračkou.
Konfigurace není náročná, a proto je dobré aspoň pár MB pro tuto činnost obětovat. Při zobrazení stránky web server neodpovídá pouze na jeden požadavek, ale někdy i na několik desítek. Když pak nemusí lovit na disku CSS a obrázky s designem k vašemu webu při každém kliknutí uživatele, ušetří se spousta času, který by se jinak strávil čekáním na disk. Podobné problémy zažívá každá větší webová stránka.
Hodnoty:
mem-cache.filetypes mimetypy, které se mají cachovat
mem-cache.enable zapnutí/vypnutí cache
mem-cache.max-memory maximální celková velikost cache
mem-cache.max-file-size maximální velikost soubory v cache
mem-cache.lru-remove-count počet položek které se zahodí, pokud cache dostane k horní hranici paměti
mem-cache.expire-time čas po kterém data v cache expirují Příklad:
mem-cache.filetypes = ("application/x-javascript", "text/css", "text/html", "text/javascript") # cachovat javaskript, css a html soubory
mem-cache.max-memory = 256 # K dipozici bude 256 MB pamětí
mem-cache.max-file-size = 128 # cachovat se budou maximálně 128 kB velké soubory Monitoring
mod_status
Informace o aktuálních spojeních, propustnosti a také uptime zajišťuje mod_status. Ten zpřístupní jednoduchou stránku s těmito informacemi.
Konfigurace spočívá prakticky jen v načtení modulu a nastavením URL. Je možné přidat i javaskript, který seřadí seznam spojení.
status.config-url URL s konfigurací web serveru
status.statistics-url URL pro informace dostupné v čistém textu
status.enable-sort Zapnout/vypnout javaskript, který řadí seznam spojení
status.status-url URL s informacemi Příklad:
status.config-url = "/server-status-config"
status.status-url = "/server-status"
status.enable-sort = "enable" mod_rrdtool
Lighttpd umí monitorovat samo sebe a poskytovat údaje o provozu přes rrdtool. Tento nástroj slouží ke generování grafů a v dokumentaci lze nalézt i bash skripty, které generují k těmto datům grafy.
Příklad nastavení:
rrdtool.binary = "/usr/bin/rrdtool" # cesta k rrdtool
rrdtool.db-name = "/var/www/lighttpd.rrd" # soubor s daty WebDAV
WebDAV je rozšíření HTTP protokolu, které umožňuje uživatelům pracovat se soubory na serveru. V Lighttpd nemá kompletní implementaci a neobsahuje některé operace. Pro ukládání informací o souborech a adresářích se používá sqlite databáze.
Příklad konfigurace:
webdav.activate = "enable" # zapneme WebDAV
webdav.is-readonly = "disable" # umožňíme zapisovat do sdíleného adresáře
webdav.sqlite-db-name = "/var/run/lighttpd/lighttpd.webdav_lock.db" # databáze pro uchovávání informací o souborech Redirect a rewrite
Pokud si přejeme přesměrovat požadavek z jednoho URL na druhé, můžeme to udělat buď pomocí mod_rewrite nebo mod_redirect. Reagovat můžeme na část URL za lomítkem, takže jakoby v rámci jednoho webu.
Redirect se od rewrite liší tím, že odesílá klientovi hlavičku (výchozí 302) se správnou adresou, ten tam svůj požadavek nasměruje a změna se projeví i v řádku s adresou u uživatele. Rewrite změní adresu pouze interně ve web serveru, takže když nasměrujeme „/a“ na „/b“, v URL bude „/a“ a ve skutečnosti se bude pracovat s „/b“.
Příklad nastavení mod_redirect:
#přesměrujeme obrázky na správnou adresu
url.redirect = ( "/images" => "/media/imgs", "/index.php?page=([a-z0-9]*)" => "/mainpage/$1" ) Příklad nastavení mod_rewrite:
# přesměrujeme index.php
url.rewrite = ( "/mainpage/([a-z0-9]*)" => "/index.php?page=$1" ) Pravidel lze napsat více a oddělit je čárkou. Mod_rewrite nabízí více možností, protože dokáže pravidla aplikovat opakovaně.
url.rewrite stejné jako rewrite-once
url.rewrite-once aplikování pravidel jednou
url.rewrite-repeate aplikování pravidel několikrát Závěr
Vypisoval jsem všechna nastavení bez podmínek, která by omezovala funkce jen na určité domény a adresáře. Každý web server je jiný a pro samotnou funkci nejsou nutné.
Modulů pro Lighttpd je mnohem víc, ale jejich použití v praxi není tak časté. V článcích jsem se snažil vysvětlit, jak se tento web server konfiguruje a co od něj čekat, ale aspoň zběžné prostudování dokumentace by mělo být podmínkou užívání.
Užívám Lighttpd již přes rok a i s několika problémy, za které jsem si mohl víceméně sám, jsem s ním velmi spokojený a to jsem zdaleka nevyzkoušel všechno, co nabízí.
