Tag Archives: lighttpd

Creare una macchina KVM

Per creare una nuova macchina virtuale con KVM il consiglio è quello di utilizzare l’infrastruttura libvirtd e l’utilissimo virt-install.

Con Fedora è sufficiente il comando yum per installare entrambi:

yum install libvirt python-virtinst

Un esempio per installare Scientific Linux 6 (clone di RHEL 6) direttamente da un mirror (in questo caso il GARR):

virt-install -n sl6 -r 1024  --disk /var/lib/libvirt/images/sl6.qcow2,size=20,format=qcow2 --vcpus=1 --os-type linux --os-variant=rhel6 --network bridge=br0 --vnc --location='http://rm.mirror.garr.it/mirrors/scientific/6/x86_64/os/'  --vnclisten=192.168.1.254

E’ possibile anche effettuare l’installazione testuale senza utilizzare VNC grazie al comando console di virsh

virt-install -n sl6 -r 1024  --disk /var/lib/libvirt/images/sl6.qcow2,size=20,format=qcow2 --vcpus=1 --os-type linux --os-variant=rhel6 --network bridge=br0 --location='http://rm.mirror.garr.it/mirrors/scientific/6/x86_64/os/' --extra-args 'console=ttyS0,115200'
virsh console sl6

Aggiornamento: per installare Fedora 16 e successive in modalità console seriale è necessario specificare alcuni parametri extra da passare a –extra-args. Essi sono serial text.

virt-install -n f16-server -r 1024  --disk /var/lib/libvirt/images/f16_server.qcow2,size=40,format=qcow2 --vcpus=2 --os-type linux --os-variant=fedora16 --network bridge=br0 --location='http://mirror1.mirror.garr.it/mirrors/fedora/linux/releases/16/Fedora/x86_64/os/' --extra-args 'console=ttyS0,115200 text'
virsh console f16-server

lighttpd: attiviamo la compressione

MicroServer, il mio home-server che eroga i servizi web, è connesso alla WAN attraverso una line ADSL. Questa tecnologia, assimetrica, comporta velocità di upload abbastanza limitate (384 Kbit/s nel caso in esame): negli ultimi tempi, con un uso intenso di css e js (che arrivano anche a 200KB) nelle applicazioni web, questa limitazione è diventata ancora più evidente.

Per ovviare è possibile utilizzare la compressione trasparente delle pagine (ma non solo) lato webserver; a patto che il browser supporti la decompressione “on-the-fly” (ormai qualsiasi browser degno di tal nome la supporta) è possibile ridurre notevolmente la banda necessaria. Lo scotto è la necessità di un po’ più di potenza di calcolo, ma d’altro canto mai nel passato abbiamo avuto a disposizione tanta potenza a buon mercato.

Per attivare la compressione dei contenuti statici attraverso lighttpd è sufficiente abilitare il supporto e definire quali MIME comprimere (principalmente quelli testuali):

creiamo il file compress.conf in /etc/lighttpd/conf.d

server.modules += ( "mod_compress" )
 
compress.allowed-encodings = ("bzip2", "gzip", "deflate")
compress.filetype = ("text/plain", "text/html", "text/javascript", "text/css", "text/xml")

Per attivare la compressione dei contenuti dinamici generati dall’interprete php è sufficiente attivare il supporto a zlib nel file php.ini

zlib.output_compression = On

Al termine riavviamo i servizi

bash$ service lighttpd restart

Riferimenti:

http://redmine.lighttpd.net/projects/lighttpd/wiki#Documentation

lighttpd front controller

Oramai è prassi diffusa l’utilizzo di un front controller nelle applicazioni web. Per implementarlo correttamente è necessario che il web server effettui delle rewrite dell’URL.

Se si utilizza Apache non è un grosso problema poiché quasi tutti i software che richiedono l’esecuzione di una o più rewrite contengono il file .htaccess pronto all’uso.

Per nginx c’è l’utilissima funzione try_files

try_files $uri $uri/ /index.php?url=$uri;

Per lighttpd? E’ possibile implementare anche in lighttpd una funzione simile alla try_files di nginx tramite una rewrite

url.rewrite-once = ( "^/(.*)\.(.*)" => "$0", "^/([^.]+)$" => "/index.php?url=$1" )

Questa regola, alla pari di try_files, verifica che la risorsa richiesta esista: nel caso di esito positivo non avviene la rewrite, mentre se non esiste l’uri viene passata al front controller.

Per poterla utilizzare il modulo mod_rewrite deve essere caricato

server.modules  += ( "mod_rewrite" )

awstats on lighttpd

Ecco una semplice e veloce configurazione di lighttpd per l’esecuzione di awstats:

server.modules  += ( "mod_cgi", "mod_alias" )
 
$HTTP["host"] =~ "awstats.mydomain.tld" {
        alias.url += (
                "/awstats/"      => "/usr/share/awstats/wwwroot/cgi-bin/",
                "/awstatsicons/" => "/usr/share/awstats/wwwroot/icon/",
        )
 
        cgi.assign = (
                ".pl" => "/usr/bin/perl",
                ".cgi" => "/usr/bin/perl"
        )
        server.document-root = "/usr/share/awstats/wwwroot/"
}

La configurazione è consigliato salvarla in un file .conf (es. awstats.conf) in /etc/lighttpd/conf.d/ in modo da rendere la configurazione il più modulare possibile.

SVG e SVGZ con lighttpd

Per fornire correttamente contenuti SVG e SVG compressi (.svgz) attraverso un server lighttpd è necessario aggiungere alcune righe alla configurazione di default.

Attivare il supporto al modulo compress nel file /etc/lighttpd/lighttpd.conf de-commentando la relativa riga in server.modules oppure aggiungendo il comando

server.modules  += ( "mod_compress" )

Aggiungere al gruppo

mimetype.assign   = ( [...] )

Il MIME corretto per SVG (image/svg+xml)

  ".svg"          =>      "image/svg+xml",
  ".svgz"         =>      "image/svg+xml",

E in ultimo aggiungere il supporto all’SVG compresso (e in questo caso anche anche al javascript compresso)

$HTTP["url"] =~ "\.(svg|js)z$" {
    setenv.add-response-header = (
    "Content-Encoding" => "x-gzip" ), compress.filetype = ("")
}

Per comodità è possibile salvare la configurazione in un nuovo file in /etc/lighttpd/conf.d/ (es. /etc/lighttpd/conf.d/svg.conf)

Riferimenti:

http://redmine.lighttpd.net/projects/lighttpd/wiki#Documentation