<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<TITLE>Linux WWW HOWTO : Apache</TITLE>
<LINK HREF="WWW-HOWTO-8.html" REL=next>
<LINK HREF="WWW-HOWTO-6.html" REL=previous>
<LINK HREF="WWW-HOWTO.html#toc7" REL=contents>
</HEAD>
<BODY>
<A HREF="WWW-HOWTO-8.html">Avanti</A>
<A HREF="WWW-HOWTO-6.html">Indietro</A>
<A HREF="WWW-HOWTO.html#toc7">Indice</A>
<HR>
<H2><A NAME="apache"></A> <A NAME="s7">7. Apache</A></H2>
<P>La versione corrente di Apache è la 1.2.4. La versione 1.3 è in fase beta.
Il sito principale di Apache è a
<A HREF="http://www.apache.org/">http://www.apache.org/</A>.
Un'altra buona fonte di informazioni è Apacheweek a
<A HREF="http://www.apacheweek.com/">http://www.apacheweek.com/</A>.
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.
<P>
<H2><A NAME="ss7.1">7.1 Dove trovarlo</A>
</H2>
<P>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).
<P>I codici sono disponibili presso il sito web Apache
<A HREF="http://www.apache.org/dist/">http://www.apache.org/dist/</A>.
I file binari si trovano nello stesso posto. È inoltre possibile scaricarli
da SunSite a
<A HREF="ftp://sunsite.unc.edu/pub/Linux/apps/www/servers/">ftp://sunsite.unc.edu/pub/Linux/apps/www/servers/</A>.
Per chi ha Red Hat, l'RPM con i più recenti eseguibili è di solito
nella directory contrib a
<A HREF="ftp://ftp.redhat.com/pub/contrib/i386/">ftp://ftp.redhat.com/pub/contrib/i386/</A>.
<P>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 ;)
<P>
<P>
<H2><A NAME="ss7.2">7.2 Compilazione e installazione</A>
</H2>
<P>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
(<CODE>./Configure</CODE>). 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 <CODE>/usr/local/etc/httpd/</CODE>, ma potreste
volerla cambiare in un più semplice <CODE>/etc/httpd/</CODE>.
La root del server (dove cioè vengono conservate le pagine HTML) è per
default <CODE>/usr/local/etc/httpd/htdocs/</CODE>, ma io preferisco la directory
<CODE>/home/httpd/html</CODE> (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.
<P>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:
<BLOCKQUOTE><CODE>
<PRE>
/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)
</PRE>
</CODE></BLOCKQUOTE>
I links possono essere creati con <CODE>ln -s</CODE>, comando che funziona come
cp con l'unica differenza che crea un link simbolico
(<CODE>ln -s directory-sorgente link-di-destinazione</CODE>).
<P>Quando make ha finito, ci dovrebbe essere un eseguibile chiamato http nella
directory. Questo file deve essere spostato in una directory binaria:
<CODE>/usr/sbin</CODE> o
<CODE>/usr/local/sbin</CODE> potrebbero essere delle buone scelte.
<P>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 <CODE>-dist</CODE>
(es <CODE>httpd.conf-dist</CODE> diventa <CODE>httpd.conf</CODE>).
<P>Ci sono inoltre molti programmi di supporto inclusi con Apache. Si trovano
nella directory <CODE>support</CODE> 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
<CODE>Configure</CODE>). Nessuno di questi programmi è indispensabile per usare
Apache, ma alcuni facilitano il compito dell'amministratore.
<P>
<H2><A NAME="ss7.3">7.3 Configurazione</A>
</H2>
<P>Adesso dovreste avere quattro file nella sub-directory <CODE>conf</CODE> (sotto la
directory home del server). <CODE>httpd.conf</CODE> configura il demone del server
(numero di porta, utente, ecc.). Il <CODE>srm.conf</CODE> imposta la struttura di
base dei documenti, gli handler speciali, ecc. Il <CODE>access.conf</CODE> si occupa
invece della configurazione di base per l'accesso. Infine
<CODE>mime.types</CODE> comunica al server quale tipo MIME inviare al browser a
seconda delle diverse estensioni.
<P>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.
<P>Il file <CODE>mime.types</CODE> 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).
<P>Ricordatevi sempre, quando cambiate i file di configurazione, di riavviare
Apache o di inviargli il segnale SIGHUP con <CODE>kill</CODE> 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 <CODE>httpd.pid</CODE> 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.
<P>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.
<P>Raccomando comunque a tutti gli utenti di leggere i suggerimenti sulla
sicurezza nella documentazione Apache, disponibile anche sul sito Apache a
<A HREF="http://www.apache.org/docs/mics/security_tips.html">http://www.apache.org/docs/mics/security_tips.html</A>.
<P>
<H2><A NAME="ss7.4">7.4 Ospitare siti web virtuali</A>
</H2>
<P>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.
<P>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.
<P>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.
<P>È poi possibile realizzare un mix di IP condiviso e non sullo stesso
server: per informazioni, visitate Apacheweek a
<A HREF="http://www.apacheweek.com/features/vhost">http://www.apacheweek.com/features/vhost</A>.
<P>
<H3>Hosting basato sugli IP virtuali</H3>
<P>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.
<P>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.
<P>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
<A HREF="http://sunsite.unc.edu/LDP/HOWTO/Kernel-HOWTO.html">Kernel HowTo</A>.
<P>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.
<P>Se utilizzate invece delle altre distribuzioni, è probabile che dobbiate
farlo a mano. Potete semplicemente mettere i comandi nel file <CODE>rc.local</CODE> che
si trova in <CODE>/etc/rc.d</CODE> (in realtà dovrebbe essere tutto nelle cose
collegate alla rete). Dovreste avere un comando <CODE>ifconfig</CODE> e <CODE>route</CODE>
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:
<BLOCKQUOTE><CODE>
<PRE>
ifconfig eth0:0 192.168.1.57
route add -host 192.168.1.57 dev eth0:0
</PRE>
</CODE></BLOCKQUOTE>
È anche possibile aggiungere un indirizzo broadcast e una netmask al
comando ifconfig: se avete un sacco di alias, si potrebbe creare un ciclo
for per facilitare le cose. Leggete comunque l'
<A HREF="http://sunsite.unc.edu/LDP/HOWTO/mini/IP-Alias.html">IP alias mini howto</A>.
<P>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
<A HREF="http://www.internic.net">Internic</A> per registrarlo. Date
comunque un'occhiata al DNS-HOWTO per creare il vostro DNS.
<P>Infine, è necessario configurare Apache per fargli gestire correttamente
i domini virtuali: per far ciò è necessario modificare il file <CODE>httpd.conf</CODE>
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
<CODE>virtualhost</CODE>, 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 <CODE>virtualhost</CODE>.
<P>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.
<P>
<H3>Hosting basato sugli indirizzi IP condivisi</H3>
<P>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.
<P>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.
<P>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 <CODE>ServerPath</CODE> per ogni host virtuale
all'interno della direttiva <CODE>virtualhost</CODE>. Per esempio, aggiungendo
<CODE>ServerPath /mysite/</CODE> 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/).
<P>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
<A HREF="http://www.apache.org/manual/host.html">http://www.apache.org/manual/host.html</A>.
<P>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.
<P>
<H2><A NAME="ss7.5">7.5 Script CGI</A>
</H2>
<P>Ci sono due metodi diversi per consentire ai propri utenti di utilizzare
script CGI: la prima è di considerare tutto ciò che finisce con <CODE>.cgi</CODE>
uno script CGI, la seconda è quella di creare una directory per gli script
(generalmente <CODE>cgi-bin</CODE>). Si possono anche utilizzare entrambi i metodi:
in tutti e due i casi, comunque, gli script devono poter essere eseguiti da
tutti (<CODE>chmod 711</CODE>). Nel concedere accesso agli script si apre una grande
falla nella sicurezza: state bene attenti, drizzate le orecchie e cercate
di minimizzare i rischi.
<P>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 <CODE>.cgi</CODE> alla fine del file <CODE>srm.conf</CODE>. Assicuratevi poi
che tutte le vostre directory abbiano l'opzione <CODE>option ExecCGI</CODE> oppure
<CODE>All</CODE> nel file <CODE>access.conf</CODE>, e il gioco è fatto.
<P>Creare una directory apposita per gli script è però considerato più
sicuro. Per farlo bisogna utilizzare la direttiva ScriptAlias nel file
<CODE>srm.conf</CODE>, in cui il primo argomento è l'Alias ed il secondo la directory
che sarà utilizzata quando qualcuno chiederà della directory
<CODE>/cgi-bin/</CODE>:
per esempio <CODE>ScriptAlias /cgi-bin/ /usr/httpd/cgi-bin/</CODE>
abilita la directory <CODE>/usr/httpd/cgi-bin</CODE> ad eseguire degli script.
Per motivi di sicurezza sarebbe poi meglio cambiare anche le proprietà delle
directory togliendo i commenti alle linee <CODE>Options none, AllowOveride none</CODE>
nel file <CODE>access.conf</CODE> 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 è
<CODE>/home/httpd/html/</CODE>, non mettete gli script in
<CODE>/home/httpd/html/cgi-bin</CODE>, bensì in <CODE>/home/httpd/cgi-bin</CODE>.
<P>Se volete consentire ai vostri utenti di avere le loro directory di script,
potete usare più comandi <CODE>ScriptAlias</CODE>, che dovrebbero essere all'interno
della direttiva <CODE>virtualhost</CODE> 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.
<P>
<P>
<H2><A NAME="ss7.6">7.6 Directory Web degli Utenti</A>
</H2>
<P>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
è <CODE>public_html</CODE>), 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 <CODE>access.conf</CODE>.
<P>Il primo metodo è quello di default di Apache: quando arriva una richiesta
per <CODE>/~bob/</CODE>, il server va a cercare la directory <CODE>public_html</CODE>
nella cartella di bob. È possibile cambiare la directory con la direttiva
<CODE>UserDir</CODE> nel file <CODE>srm.conf</CODE>: è 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.
<P>Il secondo metodo è molto facile da settare: bisogna cambiare la direttiva
<CODE>UserDir</CODE> nel file <CODE>srm.conf</CODE>. 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
<CODE>/home/httpd/</CODE>, dovete usare <CODE>UserDir /home/httpd</CODE>.
In questo caso, quando viene richiesta <CODE>/~bob/</CODE>, viene tradotta in
<CODE>/home/httpd/bob/</CODE>. Se poi volete una sub-directory nella cartella di
bob, allora dovrete usare <CODE>UserDir /home/httpd/*/html</CODE>: questo infatti
porta il server a tradurre in <CODE>/home/httpd/bob/html/</CODE> e vi consente
anche di avere una directory per gli script
(ad esempio <CODE>/home/httpd/bob/cgi-bin/</CODE>).
<P>
<H2><A NAME="ss7.7">7.7 Daemon mode vs. Inetd mode</A>
</H2>
<P>Apache può essere eseguito in due modalità: come demone ("daemon")
sempre in funzione (modalità che Apache chiama 'standalone') oppure
lanciato dal super server inetd.
<P>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.
<P>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).
<P>Per impostare la modalità inetd è necessario modificare un po' di file.
Per prima cosa, in <CODE>/etc/services</CODE> vedete se http è già presente:
se non lo è, aggiungetelo:
<BLOCKQUOTE><CODE>
<PRE>
http 80/tcp
</PRE>
</CODE></BLOCKQUOTE>
Il posto migliore è dopo 79 (finger). Poi dovete modificare il file
<CODE>/etc/inetd.conf</CODE> e aggiungerci le linee per Apache
<BLOCKQUOTE><CODE>
<PRE>
http stream tcp nowait root /usr/sbin/httpd httpd
</PRE>
</CODE></BLOCKQUOTE>
Assicuratevi di cambiare il path se avete Apache in un altro posto: il secondo
httpd non è un errore, dal momento che il demone inet lo richiede. Se
non utilizzate questo demone, potreste voler togliere i commenti al resto
delle linee nel file così da evitare l'attivazione di altri servizi (FTP,
finger, telnet e molte altre cose che di solito funzionano con questo
demone).
<P>Se già avete in esecuzione il demone inet (<CODE>inetd</CODE>), 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 <CODE>rc.local</CODE>).
<P>
<H2><A NAME="ss7.8">7.8 Autorizzare i comandi put e delete </A>
</H2>
<P>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.
<P>Se qualcuno è a conoscenza di uno script che funzioni bene me lo dica,
e lo aggiungerò qui.
<P>Per informazioni, consultate Apacheweek
<A HREF="http://www.apacheweek.com/features/put">http://www.apacheweek.com/features/put</A>.
<P>
<H2><A NAME="ss7.9">7.9 Autenticazione dell'utente/Controllo d'accesso</A>
</H2>
<P>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).
<P>Per attivare l'autenticazione dell'utente la directory deve avere
<CODE>AllowOverrides AuthConfig</CODE> settato nel file <CODE>access.conf</CODE>.
Per consentire poi il controllo d'accesso (tramite dominio o indirizzo IP)
bisogna poi impostare nella directory anche <CODE>AllowOverrides Limit</CODE>.
<P>Per configurare la directory è necessario mettervi un file <CODE>.htaccess</CODE>
Per l'autenticazione dell'utente si usa invece di solito un file <CODE>.htpasswd</CODE>
oppure <CODE>.htgroup</CODE>: questi file possono essere condivisi tra vari file
<CODE>.htaccess</CODE>.
<P>Per ragioni di sicurezza raccomando vivamente a tutti di utilizzare le
seguenti direttive nel file access.conf:
<P>
<BLOCKQUOTE><CODE>
<PRE>
<files ~ "/\.ht">
order deny,allow
deny from all
</files>
</PRE>
</CODE></BLOCKQUOTE>
<P>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).
<P>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
<A HREF="http://www.apacheweek.com/features/userauth">http://www.apacheweek.com/features/userauth</A> o le pagine NCSA
a
<A HREF="http://hoohoo.ncsa.uiuc.edu/docs-1.5/tutorials/user.html">http://hoohoo.ncsa.uiuc.edu/docs-1.5/tutorials/user.html</A>.
<P>
<H2><A NAME="ss7.10">7.10 su-exec</A>
</H2>
<P>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.
<P>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).
<P>Il codice per su-exec si trova nella directory <CODE>support</CODE> dei sorgenti.
Dapprima bisogna modificare il file <CODE>suexec.h</CODE> per il proprio sistema:
poi bisogna compilare il codice per su-exec con il comando
<BLOCKQUOTE><CODE>
<PRE>
gcc suexec.c -o suexec
</PRE>
</CODE></BLOCKQUOTE>
In seguito si deve copiare l'eseguibile su-exec nella directory giusta, che
Apache preimposta a <CODE>/usr/local/etc/httpd/sbin/</CODE>, ma che
può comunque essere cambiata modificando <CODE>httpd.h</CODE> 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 (<CODE>chown root suexec</CODE>)
e settare il bit suid (<CODE>chmod 4711 suexec</CODE>).
Infine, riavviate Apache e dovrebbe apparire sullo schermo che si sta
utilizzando su-exec.
<P>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
<CODE>cgi.log</CODE>.
<P>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).
<P>Assicuratevi infine di leggere la documentazione Apache riguardante su-exec:
è inclusa con i sorgenti ed è anche disponibile sul sito di Apache a
<A HREF="http://www.apache.org/docs/suexec.html">http://www.apache.org/docs/suexec.html</A><P>
<H2><A NAME="ss7.11">7.11 Imagemap</A>
</H2>
<P>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 <CODE>.map</CODE> alla fine del
file <CODE>srm.conf</CODE>: così facendo, tutti i file con estensione <CODE>.map</CODE>
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:
<BLOCKQUOTE><CODE>
<PRE>
<a href="/map/mapfile.map">
<img src="picture.gif" ISMAP>
</a>
</PRE>
</CODE></BLOCKQUOTE>
In questo esempio <CODE>mapfile.map</CODE> è il mapfile mentre <CODE>picture.gif</CODE>
è l'immagine su cui cliccare.
<P>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
<A HREF="http://www.apacheweek.com/features/imagemaps">http://www.apacheweek.com/features/imagemaps</A>.
<P>
<H2><A NAME="ss7.12">7.12 SSI/XSSI</A>
</H2>
<P>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.
<P>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 è
<CODE>.shtml</CODE>.
<P>Per abilitare SSI/XSSI assicuratevi per prima cosa che il modulo per gli
include sia installato: poi, modificate <CODE>srm.conf</CODE> e togliete i commenti
alle direttive <CODE>AddType</CODE> e <CODE>AddHandler</CODE> per i file <CODE>.shtml</CODE>. Infine
dovete settare <CODE>Options Includes</CODE> per tutte le directory dove volete
eseguire file SSI/XSSI modificando il file <CODE>access.conf</CODE>. Fatto ciò,
tutti i file con l'estensione <CODE>.shtml</CODE> saranno processati per controllare
se contengono comandi SSI/XSSI.
<P>Un altro modo per abilitare le includes è quello di usare la direttiva
<CODE>XBitHack</CODE>: se abilitata, controlla che il file sia eseguibile dall'utente
generico e se per quella directory è settata <CODE>Options Includes</CODE>: 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 <CODE>.html .htm</CODE>): comunque, non è consigliabile usare questo
metodo.
<P>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 <CODE>Option IncludesNOEXEC</CODE> invece che <CODE>Option
Includes</CODE> nel file <CODE>access.conf</CODE>. Tutti gli altri comandi SSI continueranno
a funzionare.
<P>Per maggiori informazioni, leggete la documentazione Apache su mod_includes,
distribuita con i sorgenti e disponibile a
<A HREF="http://www.apache.org/docs/mod/mod_include.html">http://www.apache.org/docs/mod/mod_include.html</A>.
<P>Per una discussione più dettagliata su SSI/XSSI, andate su Apacheweek a
<A HREF="http://www.apacheweek.com/features/ssi">http://www.apacheweek.com/features/ssi</A>.
<P>Informazioni sui comandi SSI si trovano anche alla NCSA a
<A HREF="http://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html">http://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html</A>.
<P>Mentre per l'XSSI date un'occhiata a
<A HREF="ftp://pageplus.com/pub/hsf/xssi/xssi-1.1.html">ftp://pageplus.com/pub/hsf/xssi/xssi-1.1.html</A>.
<P>
<H2><A NAME="ss7.13">7.13 Sistema modulare</A>
</H2>
<P>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
<A HREF="http://www.zyzzyva.com/module_registry/">http://www.zyzzyva.com/module_registry/</A>.
<P>Per informazioni su come scrivere il proprio modulo andate a
<A HREF="http://www.zyzzyva.com/module_registry/reference/">http://www.zyzzyva.com/module_registry/reference/</A><P>
<P>
<P>
<P>
<HR>
<A HREF="WWW-HOWTO-8.html">Avanti</A>
<A HREF="WWW-HOWTO-6.html">Indietro</A>
<A HREF="WWW-HOWTO.html#toc7">Indice</A>
</BODY>
</HTML>
