7. Apache

La versione corrente di Apache è la 1.2.4. La versione 1.3 è in fase beta. Il sito principale di Apache è a http://www.apache.org/. Un'altra buona fonte di informazioni è Apacheweek a http://www.apacheweek.com/. La documentazione Apache è abbastanza buona, perciò non mi addentrerò nei dettagli della configurazione: i doc sono infatti sia sul sito web che inclusi con i sorgenti (in formato HTML: ci sono anche dei file di testo ma quelli in HTML sono meglio). Inoltre, la documentazione dovrebbe migliorare appena prende il via l'Apache Documentation Project. Fino ad oggi gran parte dei manuali sono scritti dagli sviluppatori: non per criticarli, ma obiettivamente i loro testi sono un pò difficili da capire se non si padroneggia la terminologia.

7.1 Dove trovarlo

Apache è incluso nelle distribuzioni Red Hat, Slackware e OpenLinux: sebbene non siano magari le ultime versioni, sono comunque degli eseguibili molto affidabili. L'aspetto negativo, però, è che non si può cambiare la configurazione delle directory (che è totalmente diversa fra l'una e l'altra distribuzione nonché rispetto ai default Apache).

I codici sono disponibili presso il sito web Apache http://www.apache.org/dist/. I file binari si trovano nello stesso posto. È inoltre possibile scaricarli da SunSite a ftp://sunsite.unc.edu/pub/Linux/apps/www/servers/. Per chi ha Red Hat, l'RPM con i più recenti eseguibili è di solito nella directory contrib a ftp://ftp.redhat.com/pub/contrib/i386/.

Se il server sarà utilizzato per scopi commerciali, è molto meglio se vi scaricate i sorgenti dal sito Apache e lo compilate voi stessi. L'altra possibilità consiste nell'utilizzare gli eseguibili che vengono distribuiti con Slackware, Red Hat o OpenLinux, ma questi possono causare dei problemi di sicurezza: un eseguibile sconosciuto può avere delle backdoor per gli hacker, oppure una patch instabile potrebbe causare danni al sistema. Inoltre, scaricare i sorgenti vi dà più controllo sui moduli da compilare e sulle directory di default. Non è poì così difficile compilare Apache, e comunque sia non vi potete dire dei veri utilizzatori di Linux finché non compilerete da soli i vostri programmi ;)

7.2 Compilazione e installazione

Per prima cosa bisogna fare un untar dell'archivio in una directory temporanea. Poi, spostatevi nella directory src. Editate il file di configurazione per includere eventuali moduli speciali (la maggior parte dei più comuni è comunque già inclusa). Non c'è alcun bisogno di modificare le regole o i parametri del makefile per Linux. Eseguite poi lo script di configurazione (./Configure). Assicuratevi che dica "Linux platform" e che sia settato gcc come compilatore. È possibile editare adesso il file httpd.h per cambiare le directory di default. La directory home del server - dove vengono cioè mantenuti i file di configurazione - è settata (se non altrimenti specificato) a /usr/local/etc/httpd/, ma potreste volerla cambiare in un più semplice /etc/httpd/. La root del server (dove cioè vengono conservate le pagine HTML) è per default /usr/local/etc/httpd/htdocs/, ma io preferisco la directory /home/httpd/html (che tra l'altro è il default di Red Hat). Se avete intenzione di utilizzare su-exec (cfr. sotto, funzioni speciali) potrebbe essere utile cambiare anche quella directory. La root del server può essere cambiata anche nei file di configurazione, ma è una buona idea compilarcelo dentro nell'evenienza in cui Apache non sia in grado di trovare o leggere il file di configurazione: tutto il resto dovrebbe essere modificato nei file di config. Infine, lanciate make per compilare Apache.

Se avete problemi relativi alla mancanza di file include, assicuratevi delle seguenti cose: controllate di avere gli header del kernel (i file di include) installati per la vostra versione del kernel; assicuratevi inoltre di avere settati i seguenti link simbolici:

/usr/include/linux link a /usr/src/linux/include/linux
/usr/include/asm link a /usr/src/linux/include/asm
/usr/src/linux link alla directory del sorgenti di Linux (es. linux-2.0.30)

Quando make ha finito, ci dovrebbe essere un eseguibile chiamato http nella directory. Questo file deve essere spostato in una directory binaria: /usr/sbin o /usr/local/sbin potrebbero essere delle buone scelte.

Copiate poi le sub-directory di configurazione, di log e delle icone dai sorgenti alla directory home del server. Poi, bisogna rinominare 3 file nella sub-directory conf per liberarsi dell'estensione -dist (es httpd.conf-dist diventa httpd.conf).

Ci sono inoltre molti programmi di supporto inclusi con Apache. Si trovano nella directory support e devono essere copiati e installati separatamente. La maggior parte può essere creata usando il makefile in quella directory (che viene creato quando si lancia lo script principale Configure). Nessuno di questi programmi è indispensabile per usare Apache, ma alcuni facilitano il compito dell'amministratore.

7.3 Configurazione

Adesso dovreste avere quattro file nella sub-directory conf (sotto la directory home del server). httpd.conf configura il demone del server (numero di porta, utente, ecc.). Il srm.conf imposta la struttura di base dei documenti, gli handler speciali, ecc. Il access.conf si occupa invece della configurazione di base per l'accesso. Infine mime.types comunica al server quale tipo MIME inviare al browser a seconda delle diverse estensioni.

I file di configurazione hanno comunque una documentazione interna molto buona (sono pieni di commenti), sempre che si capisca il gergo. È consigliabile leggerli tutti almeno una volta prima di mettere su il server. Ogni argomento sulla configurazione è coperto esaurientemente anche nella documentazione di Apache.

Il file mime.types non è esattamente un file di configurazione. È infatti utilizzato dal server per tradurre le estensioni dei file in tipi MIME da inviare al browser e contiene già la maggior parte dei più comuni tipi di file cosicché poche persone hanno bisogno di modificarlo. Inoltre, col passare del tempo sempre nuovi tipi MIME saranno aggiunti e dunque la cosa migliore è scaricarsi un nuovo file (e magari anche una nuova versione del server).

Ricordatevi sempre, quando cambiate i file di configurazione, di riavviare Apache o di inviargli il segnale SIGHUP con kill per fare in modo che le modifiche abbiano effetto. Assicuratevi comunque di mandare il segnale al processo padre e non ai figli: il padre ha di solito l'indicatore di processo più basso, ricavabile anche dal file httpd.pid nella directory di log. Se accidentalmente vi capita di inviare il segnale ad un processo figlio, questo verrà terminato e il processo padre lo riavvierà automaticamente.

Non percorrerò qui tutti i passaggi nella configurazione di Apache: ho deciso invece di occuparmi di argomenti specifici, scelte da compiere e peculiarità del server.

Raccomando comunque a tutti gli utenti di leggere i suggerimenti sulla sicurezza nella documentazione Apache, disponibile anche sul sito Apache a http://www.apache.org/docs/mics/security_tips.html.

7.4 Ospitare siti web virtuali

Il Virtual Hosting si ha quando un solo computer ha più di un dominio. Il vecchio metodo consisteva nell'assegnare ad ogni host virtuale un differente indirizzo IP: col nuovo metodo, invece, si usa un solo indirizzo IP ma bisogna utilizzare un browser che supporti l'HTTP 1.1.

Il mio suggerimento per le applicazioni commerciali è di utilizzare ancora il vecchio metodo (più indirizzi IP) finché la maggior parte delle persone disporranno di un browser compatibile con lo standard HTTP 1.1 (basta aspettare un annetto o due): in questo modo, inoltre, si avrà una più completa illusione di virtual hosting. Non bisogna dimenticare poi che, mentre tutti e due i metodi consentono la posta virtuale (qualcuno me lo può confermare?), solo il virtual hosting basato su differenti indirizzi IP consente l'FTP virtuale.

Se si tratta invece di un server per un club o per una pagina personale, è forse meglio considerare l'hosting basato sugli IP condivisi: è più economico e si risparmia del prezioso spazio IP.

È poi possibile realizzare un mix di IP condiviso e non sullo stesso server: per informazioni, visitate Apacheweek a http://www.apacheweek.com/features/vhost.

Hosting basato sugli IP virtuali

Con questo metodo ogni host virtuale ha il suo indirizzo IP: determinando l'indirizzo a cui è stata inviata la richiesta, Apache e gli altri programmi possono decidere quale dominio servire. Questo è comunque uno spreco incredibile di spazio. Prendete per esempio il server su cui si trova il mio dominio virtuale: ci sono circa 35.000 account, e cioè 35.000 indirizzi. Eppure, è probabile che i server effettivamente funzionanti non siano nemmeno una cinquantina.

Per installare e far funzionare questo metodo si procede in due fasi distinte: prima si dice a Linux di accedere a più di un indirizzo IP e poi si setta Apache per servire gli host virtuali.

Il primo passo per configurare Linux a supportare più indirizzi IP è ricreare il kernel, operazione che funziona meglio con i kernel della serie 2.0 (o più recenti): è necessario includere il networking IP nonché il supporto dell'aliasing IP. Per informazioni sulla compilazione del kernel, date un'occhiata al Kernel HowTo.

La fase successiva è la configurazione di ogni interfaccia al boot: se state usando la distribuzione Red Hat potete farlo dal Control Panel avviando X-Windows come utente di root, cliccando sulla configurazione della rete nel pannello di controllo e specificando nella scheda delle interfacce la propria scheda di rete. È poi necessario cliccare su Alias (dovrebbe trovarsi al fondo dello schermo) e completare le informazioni: bisogna compiere queste informazioni per ogni host virtuale/indirizzo IP.

Se utilizzate invece delle altre distribuzioni, è probabile che dobbiate farlo a mano. Potete semplicemente mettere i comandi nel file rc.local che si trova in /etc/rc.d (in realtà dovrebbe essere tutto nelle cose collegate alla rete). Dovreste avere un comando ifconfig e route per ogni dispositivo. Viene così assegnato un sub-dispositivo ad ogni indirizzo alias: per esempio eth0 avrebbe gli alias eth0:0, eth0:1 ecc. Ecco un esempio di tutta la faccenda:

ifconfig eth0:0 192.168.1.57
route add -host 192.168.1.57 dev eth0:0

In seguito bisogna settare il domain name server (DNS) per coprire questi nuovi domini: se poi non avete ancora un dominio, allora vi dovete rivolgere alla Internic per registrarlo. Date comunque un'occhiata al DNS-HOWTO per creare il vostro DNS.

Infine, è necessario configurare Apache per fargli gestire correttamente i domini virtuali: per far ciò è necessario modificare il file httpd.conf verso la fine di cui viene comunque fornito un file di esempio. Tutti i comandi specifici per quell'host virtuale sono posti fra la tag di direttiva virtualhost, dove è possibile inserire quasi tutti i comandi. Di solito si setta una diversa directory radice per i documenti, una directory per gli script e per i file di log. Si possono aggiungere infiniti host virtuali semplicemente aggiungendo più tag virtualhost.

In rari casi potreste aver bisogno di lanciare server separati per specifici host: questo è necessario quando una direttiva è necessaria per un host virtuale ma non è fra quelle ammesse fra le tag per l'hosting virtuale. In questo caso si deve utilizzare la direttiva bindaddress: ogni server avrà un nome e dei file di configurazione diversi, ed ogni server risponderà ad un indirizzo IP, specificato dalla direttiva bindaddress. Questo è comunque un incredibile spreco di risorse.

Hosting basato sugli indirizzi IP condivisi

Si tratta di un nuovo metodo per l'hosting virtuale: viene utilizzato un solo indirizzo IP, riservandolo solo alle macchine reali (non a quelle virtuali). Nell'esempio precedente, dei 35.000 host virtuali solo 50 avrebbero un indirizzo IP (uno per ogni macchina). Tutto ciò è possibile sfruttando le caratteristiche dell'HTTP 1.1: è il browser che dice al server quale sito vuole. I problemi sorgono con quei browser che non supportano l'HTTP 1.1, perché questi leggeranno la pagina principale del server, che può comunque offrire una lista dei server virtuali a disposizione. Certo, questo rovina un po' l'intera illusione del hosting virtuale, e cioè quella di avere un proprio server.

Il settaggio è molto più semplice che nell'hosting basato sui diversi indirizzi IP. È sempre necessario avere un proprio dominio dalla Internic nonché configurare il proprio DNS, e Apache è settato nella stessa maniera di prima. Dal momento però che si usa sempre lo stesso indirizzo IP nella tag virtualhost, il server si accorge automaticamente che si sta utilizzando l'hosting virtuale basato sull'IP condiviso.

Ci sono molte soluzioni per i vecchi browser, e io adesso spiegherò quella che secondo me è la migliore. Per prima cosa è necessario trasformare la pagina principale in host virtuale (condiviso o no): in questo modo si libera la main page così da poterla utilizzare per una lista di link a tutti i virtual host presenti. Poi bisogna creare una backdoor per i vecchi browser utilizzando la direttiva ServerPath per ogni host virtuale all'interno della direttiva virtualhost. Per esempio, aggiungendo ServerPath /mysite/ a www.mysite.com i vecchi browser saranno in grado di accedere al sito attraverso www.mysite.com/mysite/. Infine si mette la pagina di default sul sito principale che dica gentilmente di scaricarsi un nuovo browser e che punti a tutte le backdoor per i siti ospitati sul server: quando un vecchio browser accede al sito, saranno automaticamente inviati alla pagina principale e riceveranno un menu con tutti i link disponibili. I nuovi browser, invece, non vedranno mai la pagina principale e andranno direttamente agli host virtuali. Bisogna ricordare però che si devono mantenere i link relativi al proprio sito web dal momento che le pagine saranno accessibili da due URL differenti (www.mysite.com e www.mysite.com/mysite/).

Spero di non avervi confuso troppo, ma non è comunque una soluzione facile. Magari potreste considerare l'hosting virtuale basato sugli indirizzi IP. Comunque un trucchetto molto simile è spiegato sul sito Apache a http://www.apache.org/manual/host.html.

Se mai qualcuno avesse una interessante fonte di informazioni per l'hosting basato sugli IP condivisi, mi farbbe piacere saperlo. Sarebbe anche simpatico sapere quanti e quali browser supportano l'HTTP 1.1.

7.5 Script CGI

Ci sono due metodi diversi per consentire ai propri utenti di utilizzare script CGI: la prima è di considerare tutto ciò che finisce con .cgi uno script CGI, la seconda è quella di creare una directory per gli script (generalmente cgi-bin). Si possono anche utilizzare entrambi i metodi: in tutti e due i casi, comunque, gli script devono poter essere eseguiti da tutti (chmod 711). Nel concedere accesso agli script si apre una grande falla nella sicurezza: state bene attenti, drizzate le orecchie e cercate di minimizzare i rischi.

Personalmente preferisco il primo metodo, specialmente quando gli script sono complessi: questo metodo consente infatti di mettere gli script in ogni directory, e a me piace metterli dove risiedono anche le pagine web che li utilizzano. Per i siti con un sacco di script, è molto più elegante che avere una directory piena zeppa di script. Questo metodo è poi molto facile da settare: per prima cosa, bisogna togliere il commento all'handler .cgi alla fine del file srm.conf. Assicuratevi poi che tutte le vostre directory abbiano l'opzione option ExecCGI oppure All nel file access.conf, e il gioco è fatto.

Creare una directory apposita per gli script è però considerato più sicuro. Per farlo bisogna utilizzare la direttiva ScriptAlias nel file srm.conf, in cui il primo argomento è l'Alias ed il secondo la directory che sarà utilizzata quando qualcuno chiederà della directory /cgi-bin/: per esempio ScriptAlias /cgi-bin/ /usr/httpd/cgi-bin/ abilita la directory /usr/httpd/cgi-bin ad eseguire degli script. Per motivi di sicurezza sarebbe poi meglio cambiare anche le proprietà delle directory togliendo i commenti alle linee Options none, AllowOveride none nel file access.conf fornito come esempio. Inoltre, non bisogna creare le directory per gli script come sub-directory delle cartelle che contengono la pagina web: per esempio, se la directory con le pagine è /home/httpd/html/, non mettete gli script in /home/httpd/html/cgi-bin, bensì in /home/httpd/cgi-bin.

Se volete consentire ai vostri utenti di avere le loro directory di script, potete usare più comandi ScriptAlias, che dovrebbero essere all'interno della direttiva virtualhost per ogni host virtuale. Se c'è qualcuno che conosce un metodo più semplice per permettere a tutti gli utenti di avere una propria directory di script senza ricorrere ogni volta al comando ScriptAlias me lo faccia sapere.

7.6 Directory Web degli Utenti

Ci sono due metodi diversi per trattare le directory web degli utenti. Si può avere una sub-directory nella directory degli utenti (che di solito è public_html), oppure una directory specifica per le directory web. Con entrambi i metodi bisogna assicurarsi comunque che queste directory siano settate in lettura e scrittura nel file access.conf.

Il primo metodo è quello di default di Apache: quando arriva una richiesta per /~bob/, il server va a cercare la directory public_html nella cartella di bob. È possibile cambiare la directory con la direttiva UserDir nel file srm.conf: è comunque necessaria settarla in lettura ed esecuzione per tutti. Come si può vedere, questo metodo crea un potenziale rischio di sicurezza perché Apache può accedere alla directory solo se la directory home degli utenti è eseguibile per tutti.

Il secondo metodo è molto facile da settare: bisogna cambiare la direttiva UserDir nel file srm.conf. Questa direttiva può assumere svariati formati e quindi è una buona idea dare un'occhiata alla documentazione Apache per chiarimenti. Comunque, se volete che ogni utente abbia la propria directory in /home/httpd/, dovete usare UserDir /home/httpd. In questo caso, quando viene richiesta /~bob/, viene tradotta in /home/httpd/bob/. Se poi volete una sub-directory nella cartella di bob, allora dovrete usare UserDir /home/httpd/*/html: questo infatti porta il server a tradurre in /home/httpd/bob/html/ e vi consente anche di avere una directory per gli script (ad esempio /home/httpd/bob/cgi-bin/).

7.7 Daemon mode vs. Inetd mode

Apache può essere eseguito in due modalità: come demone ("daemon") sempre in funzione (modalità che Apache chiama 'standalone') oppure lanciato dal super server inetd.

La modalità daemon è di gran lunga migliore rispetto a quella con inetd, ed è anche la modalità predefinita. L'unico caso in cui si potrebbe voler utilizzare quest'ultimo modo è in presenza di applicazioni poco frequenti: il test interno di alcuni script, l'Intranet di una piccola azienda. Il modo Inetd salva infatti memoria perché il server è caricato solo quando effettivamente richiesto, e solo il demone inetd risiede permanentemente in memoria.

Se non utilizzate Apache molto spesso, potreste utilizzarlo nella modalità daemon e lanciarlo solo quando vi serve, per poi ucciderlo una volta finito (assicuratevi di terminare il processo padre, e non uno dei figli).

Per impostare la modalità inetd è necessario modificare un po' di file. Per prima cosa, in /etc/services vedete se http è già presente: se non lo è, aggiungetelo:

http    80/tcp

http    stream  tcp     nowait  root    /usr/sbin/httpd httpd

Se già avete in esecuzione il demone inet (inetd), allora dovete solo inviargli il segnale SIGHUP (con kill; consultate la documentazione su kill per informazioni) o riavviare il computer perché le modifiche abbiano effetto: se invece non è già in esecuzione, dovete avviare il demone manualmente o metterlo nei file di inizializzazione così da caricarlo all'avvio (la scelta migliore è il file rc.local).

7.8 Autorizzare i comandi put e delete

I nuovi strumenti di authoring HTML supportano un nuovo metodo per inviare le pagine web al server utilizzando l'http invece dell'FTP: alcuni di questi prodotti nemmeno lo supportano più l'FTP. Apache è in grado di supportare questo metodo, ma manca lo script per gestire la richiesta: tale script, però, potrebbe aprire un serio buco nella sicurezza e perciò riflettete bene prima di scriverne o installarne uno.

Se qualcuno è a conoscenza di uno script che funzioni bene me lo dica, e lo aggiungerò qui.

Per informazioni, consultate Apacheweek http://www.apacheweek.com/features/put.

7.9 Autenticazione dell'utente/Controllo d'accesso

Questa è una delle caratteristiche che preferisco: consente infatti di proteggere una directory o un file senza dover usare degli script CGI nonché consentire o negare l'accesso in base all'indirizzo IP o al dominio del client. Si tratta di un grande servizio per tenere lontani rompiscatole dalla message board o dal guest book (si ricava il loro indirizzo IP o il dominio dai file di log).

Per attivare l'autenticazione dell'utente la directory deve avere AllowOverrides AuthConfig settato nel file access.conf. Per consentire poi il controllo d'accesso (tramite dominio o indirizzo IP) bisogna poi impostare nella directory anche AllowOverrides Limit.

Per configurare la directory è necessario mettervi un file .htaccess Per l'autenticazione dell'utente si usa invece di solito un file .htpasswd oppure .htgroup: questi file possono essere condivisi tra vari file .htaccess.

Per ragioni di sicurezza raccomando vivamente a tutti di utilizzare le seguenti direttive nel file access.conf:

<files ~ "/\.ht">
order deny,allow
deny from all
</files>

Se non siete ammnistratori del sistema, potete anche mettere nel vostro file .htaccess se AllowOverride Limit è impostato per la vostra directory. Questa direttiva impedirà agli altri di andare a curiosare dentro i vostri file per il controllo dell'accesso (.htaccess, .htpasswd, etc).

Ci sono svariate opzioni e tipi di file che possono essere utilizzati col controllo dell'accesso: non è quindi negli scopi di questo documento descriverli. Per informazioni su come impostare la User Authentication date un'occhiata ad Apacheweek a http://www.apacheweek.com/features/userauth o le pagine NCSA a http://hoohoo.ncsa.uiuc.edu/docs-1.5/tutorials/user.html.

7.10 su-exec

La funzione su-exec esegue degli script CGI come se l'esecutore ne fosse anche il proprietario: normalmente viene eseguito come l'utente del web server (di solito 'nobody'). In questa maniera si consente agli utenti di accedere ai propri script CGI senza doverli rendere leggibili a tutti (cosa che sarebbe un rischio per la sicurezza). Se non si sta attenti, è però possibile aprire un buco più grande di quello che si vorrebbe coprire dal momento che su-exec esegue dei controlli prima di eseguire gli script, ma se questi controlli non sono impostati bene sono problemi.

Utilizzare su-exec non è un mestiere per principianti: se non sapete quello che state facendo, lasciate perdere. Potreste finire per consentire ai vostri utenti di acquisire accesso di root al vostro sistema, e non è quindi conveniente scherzarci. La codifica ed l'impostazione su-exec è difficile apposta, così che i principianti se ne tengano alla larga (tutto deve essere fatto a mano, niente file di make, niente script di installazione).

Il codice per su-exec si trova nella directory support dei sorgenti. Dapprima bisogna modificare il file suexec.h per il proprio sistema: poi bisogna compilare il codice per su-exec con il comando

gcc suexec.c -o suexec

Gli script CGI dovrebbero essere in lettura per tutti come sempre: saranno eseguiti automaticamente da ogni utente come il proprietario del file. Se settate il bit SUID (set user id) sul CGI questo non verrà eseguito, così come non vengono eseguiti gli script posseduti dagli utenti di sistema (root, bin, ecc.). Per ulteriori informazioni sulle condizioni di sicurezza che devono essere rispettate, controllate la documentazione di su-exec: se poi avete problemi potete anche spulciare il file di log, che si chiama cgi.log.

Su-exec non funziona se lanciate Apache da inetd: questo problema sarà risolto nelle prossime versioni dal momento che non ci sarà più un modo inetd. Se vi piace giocare col codice sorgente, potreste voler modificare il file http_main.c per liberarvi delle linee in cui Apache annuncia che sta utilizzando su-exec (lo stampa erroneamente prima di qualsiasi output).

Assicuratevi infine di leggere la documentazione Apache riguardante su-exec: è inclusa con i sorgenti ed è anche disponibile sul sito di Apache a http://www.apache.org/docs/suexec.html

7.11 Imagemap

Apache è in grado di gestire le imagemap dal lato del server: si tratta di immagini su una pagina web che portano l'utente in diverse locazioni a seconda del punto su cui si clicca. Per abilitarle è per prima cosa necessario assicurarsi che il modulo per le imagemap sia installato (è uno dei moduli di default). Poi, togliete i commenti all'handler .map alla fine del file srm.conf: così facendo, tutti i file con estensione .map saranno dei file per le imagemap, dove cioè vengono settati i diversi link a seconda del punto in cui si clicca. Apache utilizza i file di mappa seguento lo standard NCSA, di cui vi presento un esempio:

<a href="/map/mapfile.map">
<img src="picture.gif" ISMAP>
</a>

Esistono molti programmi che possono generare dei mapfile compatibili con lo standard NCSA, ma è anche possibile crearseli da soli. Per una discussione più approfondita sull'argomento, andate a http://www.apacheweek.com/features/imagemaps.

7.12 SSI/XSSI

Il Server Side Includes (SSI) aggiunge contenuti dinamici - inseriti nella pagina - a documenti web altrimenti statici e non interattivi: il server, infatti, processa gli SSI e passa i risultati alla pagina. In questo modo, si possono aggiungere intestazioni e note di chiusura, la data di ultima modifica, eseguire comandi di sistema o degli script CGI. Con i nuovi eXtended Server Side Includes (XSSI) si può fare ancora di più, aggiungendo condizioni di controllo (if...else): è quasi come avere un linguaggio di programmazione.

Processare tutti i file HTML per cercare comandi SSI sarebbe una perdita di tempo ed uno spreco di risorse: pertanto, è necessario distinguere le pagine che contengono HTML normale da quelle con i comandi SSI. Generalmente si ricorre per questi file a delle estensioni diverse: la più usata è .shtml.

Per abilitare SSI/XSSI assicuratevi per prima cosa che il modulo per gli include sia installato: poi, modificate srm.conf e togliete i commenti alle direttive AddType e AddHandler per i file .shtml. Infine dovete settare Options Includes per tutte le directory dove volete eseguire file SSI/XSSI modificando il file access.conf. Fatto ciò, tutti i file con l'estensione .shtml saranno processati per controllare se contengono comandi SSI/XSSI.

Un altro modo per abilitare le includes è quello di usare la direttiva XBitHack: se abilitata, controlla che il file sia eseguibile dall'utente generico e se per quella directory è settata Options Includes: nel caso in cui si verifichino entrambe le condizioni, allora il file viene trattato come SSI. Questo procedimento funziona solo per file con il tipo MIME text/html .html .htm): comunque, non è consigliabile usare questo metodo.

Esiste poi un rischio di sicurezza nell'assicurare a file SSI di eseguire comandi di sistema e script CGI: è pertanto possibile bloccare questa funzione con la direttiva Option IncludesNOEXEC invece che Option Includes nel file access.conf. Tutti gli altri comandi SSI continueranno a funzionare.

Per maggiori informazioni, leggete la documentazione Apache su mod_includes, distribuita con i sorgenti e disponibile a http://www.apache.org/docs/mod/mod_include.html.

Per una discussione più dettagliata su SSI/XSSI, andate su Apacheweek a http://www.apacheweek.com/features/ssi.

Informazioni sui comandi SSI si trovano anche alla NCSA a http://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html.

Mentre per l'XSSI date un'occhiata a ftp://pageplus.com/pub/hsf/xssi/xssi-1.1.html.

7.13 Sistema modulare

Apache può essere ampliato per supportare quasi tutto attraverso i moduli, di cui ne esiste già un vasto numero in giro per il web. Solo i moduli di interesse più generale sono Distribuiti con Apache, ma link a tutti i moduli esistenti si possono trovare all'Apache Module Registry a http://www.zyzzyva.com/module_registry/.

Per informazioni su come scrivere il proprio modulo andate a http://www.zyzzyva.com/module_registry/reference/

Hosting by: hurra.com
Generated: 2007-01-26 17:56:15