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.
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 ;)
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)
ln -s, comando che funziona come
cp con l'unica differenza che crea un link simbolico
(ln -s directory-sorgente link-di-destinazione).
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.
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.
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.
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.
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.
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.
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/).
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
/etc/inetd.conf e aggiungerci le linee per Apache
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).
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.
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.
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
/usr/local/etc/httpd/sbin/, ma che
può comunque essere cambiata modificando httpd.h nella directory dei
sorgenti e ricompilando Apache. Ricordatevi che Apache guarderà solo
in questa directory, e non nel path. È poi necessario cambiare il
proprietario del file e settarlo a root (chown root suexec)
e settare il bit suid (chmod 4711 suexec).
Infine, riavviate Apache e dovrebbe apparire sullo schermo che si sta
utilizzando su-exec.
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
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>
mapfile.map è il mapfile mentre picture.gif
è l'immagine su cui cliccare.
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.
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.
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/