Capitolo 160. Servente HTTP: Apache

Apache ⁽¹⁾ è un servente HTTP derivato da quello di NCSA, che costituisce lo standard di fatto per i sistemi GNU e molte altre piattaforme.

Le funzionalità che Apache mette a disposizione sono molte e di conseguenza la sua configurazione può anche essere complicata. Eventualmente, quando non ci sono esigenze particolari, si può preferire l'installazione di un servente HTTP meno sofisticato, come Boa, descritto nel capitolo 161.

160.1 Visione generale

Apache è costituito essenzialmente dall'eseguibile httpd, che si avvia di solito come demone autonomo dal supervisore dei servizi di rete:

httpd [opzioni]

Nelle sezioni seguenti si fa sempre riferimento a un'installazione in cui il servizio viene avviato in modo indipendente dal supervisore dei servizi di rete. Eventualmente si può consultare la documentazione originale per un'impostazione differente.

Opzione	Descrizione
`-d directory_radice_del_servente`	Permette di definire la directory che funge come punto di partenza per il servizio che viene offerto. Questa è già stabilita in modo predefinito in fase di compilazione del programma e ciò dipende dalla scelta di chi ha compiuto questa operazione. Attraverso questa opzione, si può indicare in modo esplicito una posizione diversa, che però può essere scavalcata dalla direttiva `ServerRoot` del file di configurazione `httpd.conf`.
`-f file_di_configurazione`	Permette di indicare in modo esplicito il file di configurazione che `httpd` deve leggere ed eseguire prima di iniziare a gestire il suo servizio. Se il file viene indicato utilizzando un percorso relativo, se cioè manca la prima barra obliqua che identifica la directory radice, si fa riferimento a una posizione relativa che parte dalla directory `ServerRoot`, ovvero quella definibile con l'opzione `-d`. Il valore predefinito di questa opzione, dipende dal modo in cui è stato compilato il programma. In un sistema GNU dovrebbe trattarsi di `/etc/apache/httpd.conf`.

Di solito, non occorre configurare nulla per vedere funzionare il servente in modo «normale», per la pubblicazione di qualche pagina senza esigenze particolari, ma la gestione di un sito vero e proprio richiede quasi sempre un intervento nella configurazione.

Purtroppo, Apache gestisce più di un file configurazione e questo può creare un po' di confusione. In generale, questi file potrebbero trovarsi nella directory /etc/apache/ e si tratta almeno di: httpd.conf, srm.conf e access.conf.

Prima di vedere i dettagli dell'impostazione del servente Apache, è il caso di descrivere alcune caratteristiche che lo riguardano.

L'accesso al servizio HTTP avviene a partire da una parte del file system, che inizia dal cosiddetto document root.
Il programma servente non esegue la funzione chroot() in questa directory, pertanto è possibile articolare le directory successive anche attraverso l'uso di collegamenti simbolici in posizioni precedenti alla directory document root.
In linea di massima, ogni utente può realizzare una struttura personalizzata di documenti HTML, a partire dalla propria directory personale (home).
Il servente è in grado di mettere in funzione dei programmi, detti CGI, per la gestione interattiva di pagine HTML contenenti dei moduli.⁽²⁾

160.1.1 Struttura di directory

Nella configurazione di Apache si distinguono due directory che vengono definite attraverso un nome particolare; si tratta di ServerRoot e DocumentRoot. A queste se ne affiancano altre che derivano dalla configurazione consueta di questo programma servente.

server root

La directory nota come server root è il punto di origine dei file amministrativi di Apache. Viene dichiarata nel file httpd.conf e gli altri file dichiarati all'interno di questo sono intesi essere collocati in posizione relativa a tale directory.
document root

La directory nota come document root è il punto di origine dei documenti HTML.
Programmi CGI

Convenzionalmente, è opportuno collocare i programmi CGI in una posizione estranea alla gerarchia che si articola a partire dalla directory document root, per facilitare la configurazione della sua accessibilità.
Icone di sistema

Il servente HTTP ha spesso la necessità di utilizzare icone per rappresentare delle informazioni in modo grafico, per esempio quando si visualizza il contenuto di una directory appartenente alla gerarchia di document root. Sotto questo aspetto, è conveniente togliere tali icone dalla struttura dei documenti normali, perché non fanno parte di questi.
Documenti personali

In linea di massima è concesso agli utenti di creare una propria struttura di documenti ipertestuali. La directory di partenza di questi documenti viene definita come user dir ed è relativa alla directory personale di questi utenti. È importante tenere presente che gli utenti hanno tale possibilità, per configurare opportunamente il servente in modo che questi non possano creare danni.

160.1.2 Avvio e conclusione dell'attività del servente

Come già descritto, il servizio viene gestito dal demone httpd che può essere avviato direttamente dalla procedura di inizializzazione del sistema, oppure può essere controllato dal supervisore dei servizi di rete. In questo secondo caso, quando si fanno delle modifiche alla configurazione, non occorre fare in modo che httpd le rilegga, perché è costretto a farlo ogni volta che viene risvegliato dal supervisore dei servizi di rete.

Quando httpd è indipendente dal supervisore dei servizi di rete (standalone), si può osservare la presenza di una serie di processi httpd discendenti da uno di origine.

# pstree -p[Invio]

init(1)-+-...
        |
        |-httpd(244)-+-httpd(859)
        |            |-httpd(860)
        |            |-httpd(861)
        |            |-httpd(862)
        |            `-httpd(863)
        |-...
        ...

Per fare in modo che tutti questi processi rileggano i file di configurazione, basta inviare un segnale SIGHUP a quello principale; in questo caso il numero 244.

# kill -HUP 244[Invio]

# pstree -p[Invio]

init(1)-+-...
        |
        |-httpd(244)-+-httpd(901)
        |            |-httpd(902)
        |            |-httpd(903)
        |            |-httpd(904)
        |            `-httpd(905)
        |-...
        ...

Come si può osservare, il processo httpd principale rimane attivo, mentre quelli inferiori vengono conclusi e riavviati (lo si vede dal numero PID). Attenzione però: se si invia un segnale di questo tipo al processo httpd dopo aver modificato la configurazione in modo errato, questo termina il suo funzionamento.

160.2 Configurazione essenziale con httpd.conf

httpd.conf è il file di configurazione principale di Apache. La sua collocazione dipende dal modo in cui è stato compilato Apache, oppure dall'opzione -f della riga di comando del demone httpd. Nelle sezioni seguenti vengono descritte solo alcune direttive più importanti. Inoltre, nel capitolo 175 viene trattata la configurazione di Apache per la gestione di una cache proxy, cosa che riguarda in modo particolare proprio questo file.

160.2.1 Impostazioni varie

Alcune direttive sono importanti per definire se il demone httpd funziona in modo autonomo o meno; inoltre, nel primo caso, per sapere su quale porta deve restare in ascolto.

Tipo di gestione del demone

ServerType { standalone | inetd }

La direttiva ServerType permette di informare Apache su come questo viene avviato: in modo autonomo o attraverso il supervisore dei servizi di rete.⁽³⁾

ServerType standalone

Nell'esempio si mostra la dichiarazione per il funzionamento autonomo (standalone) che corrisponde alla situazione più comune (e anche più adatta).

Porta del servizio

Port numero_porta

Si tratta dell'indicazione della porta (di solito è 80, corrispondente alla denominazione http), necessaria nel caso in cui il demone sia stato avviato in modo autonomo. Infatti, diversamente, è il supervisore dei servizi di rete a stare in ascolto della porta corrispondente al servizio http.

Port 80

Listen numero_porta

Se httpd viene utilizzato in modo autonomo, è possibile richiedere che stia in ascolto anche di un'altra porta, per mezzo della direttiva Listen.

Listen 80
Listen 8080

L'esempio mostra in che modo si possa indicare a httpd di stare in ascolto sia della porta 80 che della 8 080; dove la seconda viene utilizzata normalmente per interrogare un servente proxy.

Indirizzi numerici o nomi di dominio

HostnameLookups { on | off }

Permette di decidere se si intende annotare nei file delle registrazioni l'indirizzo numerico o il nome dei nodi che accedono al servizio. Attivando questa direttiva (on) si registrano i nomi corrispondenti. L'attivazione di questa è necessaria se si intendono definire dei limiti di accesso basati sul nome di dominio dei clienti, come si vede nell'esempio seguente:

HostnameLookups on

160.2.2 Identificazione

Spesso, un nodo che offre un servizio HTTP può essere identificato attraverso degli alias al nome di dominio canonico. Nella configurazione è opportuno definire un nome corretto, che può corrispondere anche a un alias, purché sia valido. Nello stesso modo, è importante definire l'indirizzo di posta elettronica presso cui può essere raggiunto l'amministratore del servizio (webmaster).

Webmaster

ServerAdmin email

La direttiva ServerAdmin permette di definire l'indirizzo di posta elettronica dell'amministratore del servizio. Generalmente si tratterà dell'utente fittizio webmaster che dovrebbe essere ridiretto automaticamente all'utente root dal sistema di gestione della posta elettronica.

ServerAdmin webmaster@dinkel.brot.dg

L'utilità di utilizzare un indirizzo di posta elettronica specifico, sta nella facilità con cui poi si intende il contesto a cui fanno riferimento questi messaggi.

Nome ufficiale del servente

ServerName nome_standard_del_servente

Attraverso questa direttiva si può dichiarare espressamente il nome di dominio del servente HTTP. Può trattarsi alias di un alias definito nel sistema DNS, ma quello che conta è che si tratti di un nome valido.

ServerName www.brot.dg

L'esempio dichiara che il nome del nodo che offre il servizio è www.brot.dg, anche se magari il nome canonico di questo, secondo il DNS, è diverso. Quello che conta è che il sistema DNS sia in grado di risolvere anche questo nome qui dichiarato.

160.2.3 Utenti

L'utilizzo di un servizio HTTP è qualcosa di prettamente anonimo, in quanto la natura di questo, per cui tutto si traduce in semplici richieste seguite da risposte, impedisce una gestione sensata di identificativi utente e delle parole d'ordine relative.

Utente e gruppo per l'accesso al servizio

User { utente | #n }

Group { gruppo | #n }

Queste due direttive permettono di definire l'utente e il gruppo fittizio da abbinare agli accessi fatti al servizio. In pratica, quando si legge un file HTML o si interpella un programma CGI, lo si fa come se si fosse l'utente indicato da queste due direttive. Solitamente, per motivi di sicurezza, si utilizza l'utente e il gruppo nobody, oppure un utente e un gruppo specifici per il servizio HTTP.

Se per qualche motivo si preferisce una notazione numerica, invece di indicare il nome dell'utente e del gruppo si può usare il numero UID e GID, preceduto dal simbolo #.

User nobody
Group nobody

Perché queste direttive possano funzionare, occorre che il demone httpd sia avviato con i privilegi dell'utente root, altrimenti non ha modo di eseguire il cambiamento di utente e gruppo, potendo solo continuare a funzionare con i privilegi ottenuti all'avvio.

160.2.4 Collocazione e denominazione di file e directory

Il file httpd.conf contiene l'indicazione della directory server root, della posizione dei file delle registrazioni ed eventualmente anche degli altri file di configurazione.

ServerRoot

ServerRoot directory

Rappresenta la directory a partire dalla quale si diramano le informazioni sulla configurazione, sulla registrazione degli eventi e simili. Corrisponde solitamente a qualcosa come /etc/httpd/conf/ o /etc/apache/. Potrebbe essere definita anche attraverso l'opzione -d della riga di comando di httpd.

ServerRoot /etc/apache

L'esempio mostra la posizione più conveniente di questa directory per aderire allo standard FHS sulla struttura del file system.

Altri file di configurazione

ResourceConfig config_srm

AccessConfig config_access

Le direttive mostrate servono per definire rispettivamente il nome e la collocazione del file di configurazione delle risorse e del file di configurazione degli accessi. Generalmente, i nomi e la collocazione di questi file non devono essere dichiarate espressamente, perché è sufficiente quanto risulta predefinito all'interno del programma stesso.

ResourceConfig  conf/srm.conf
AccessConfig    conf/access.conf

L'esempio mostra la dichiarazione esplicita dei nomi utilizzati per gli altri file di configurazione. Mancando l'indicazione di un percorso assoluto, si intende che debbano essere discendenti della directory server root.

File delle registrazioni

ErrorLog registro_degli_errori

TransferLog registro_dei_trasferimenti

Queste direttive definiscono i nomi e la collocazione dei file delle registrazioni. Generalmente i percorsi indicati sono relativi, in tal caso si riferiscono alla directory server root come punto iniziale.

ErrorLog        /var/log/apache/error_log
TransferLog     /var/log/apache/access_log

L'esempio mostra la dichiarazione dei due file delle registrazioni, con un percorso assoluto: /var/log/apache/.

Processo del demone principale

PidFile file_pid

Definisce il nome e la collocazione del file utilizzato per contenere il numero di processo del demone httpd principale, quando questo funziona in modo autonomo.

PidFile /var/run/httpd.pid

L'esempio mostra l'indicazione del file /var/run/httpd.pid, con un percorso assoluto, in modo da non finire al di sotto della directory server root.

Comunicazione interna

ScoreBoardFile file_di_informazioni

Definisce il nome e la collocazione di un file contenente una serie di informazioni sul funzionamento corrente del programma servente, necessarie al servente stesso per la comunicazione tra processi.

ScoreBoardFile /var/run/apache_status

L'esempio mostra l'indicazione del file /var/run/apache_status, con un percorso assoluto, in modo da non finire al di sotto della directory server root.

160.3 Configurazione delle risorse con srm.conf

Il file srm.conf è il file di configurazione delle risorse di Apache. Viene letto subito dopo quello di configurazione del servente. Definisce in particolare dove si trovino i documenti (la directory document root e quella delle pagine degli utenti), gli alias di directory speciali e altre informazioni correlate. La sua collocazione dipende dal modo in cui è stato compilato Apache, oppure dalla direttiva ResourceConfig del file httpd.conf.

Nelle edizioni più recenti di Apache, le direttive del file srm.conf possono risiedere direttamente nel file httpd.conf.

Nelle sezioni seguenti vengono descritte solo alcune direttive più importanti.

160.3.1 Documenti HTML

La funzione principale di srm.conf è quella di definire la collocazione dei documenti ipertestuali, oltre ad altre informazioni di contorno.

DocumentRoot

DocumentRoot directory_iniziale_documenti_html

La direttiva DocumentRoot dichiara la directory da cui si possono diramare i documenti HTML (per qualche motivo oscuro, è importante che non abbia la barra obliqua finale).

DocumentRoot /home/httpd/html

L'esempio mostra il caso in cui la directory /home/httpd/html/ corrisponda all'inizio dei documenti HTML.

Pagine personali degli utenti

UserDir { directory_iniziale_documenti_utenti | DISABLED [utente] }

La direttiva UserDir dichiara la directory, relativamente alla posizione della directory personale di ogni utente, all'interno della quale ognuno può collocare i propri documenti HTML personali. Si accede a questi utilizzando l'URI http://host/~utente.

UserDir public_html

L'esempio mostra la dichiarazione tipica di questa direttiva e significa che ogni utente può creare la directory ~/public_html/ all'interno della quale collocare le proprie pagine.

Supponendo di accedere all'URI http://www.brot.dg/~tizio/elenco.html si fa riferimento effettivamente al file ~tizio/public_html/elenco.html. In questo modo, tra le altre cose, si evita di esporre l'intera directory personale dell'utente.

UserDir DISABLED

L'esempio mostra in che modo possa essere impedito ai singoli utenti di creare le proprie pagine HTML nella loro directory personale.

Quando si concede agli utenti di realizzare le loro pagine HTML personali, occorre tenere presente che questo fatto può costituire un problema di sicurezza del sistema: un utente potrebbe creare un semplice collegamento simbolico verso un file o una directory che, pur risultando leggibile a tutti gli utenti, non avrebbe dovuto essere accessibile al mondo intero. A questo si può porre rimedio, ma per farlo occorre intervenire sul file access.conf, come verrà mostrato in seguito.

UserDir DISABLED root

A partire dalla versione 1.3 di Apache è possibile specificare a quali utenti vietare la costruzione di pagine HTML personali, come nell'esempio mostrato, in cui questo viene impedito all'utente root.

160.3.2 Indici e file di informazioni

Quando si tenta di accedere a una directory, invece che a un file particolare, si ottiene l'indice del contenuto, come se si trattasse del protocollo FTP, oppure il contenuto di una pagina predefinita.

File indice

DirectoryIndex file_indice...

Quando si accede a una directory invece che a un file specifico, se questa contiene un file tra quelli elencati nella direttiva DirectoryIndex viene restituito quel file, invece del semplice elenco del contenuto. Solitamente si utilizza il nome index.html. Questo meccanismo permette di mascherare il contenuto effettivo della directory, oltre che di guidare l'utente del servizio in modo che non si perda in una miriade di file.

DirectoryIndex index.html index.htm

L'esempio dichiara due file (index.html e index.htm) come possibili indici da utilizzare quando si fa riferimento a una directory senza indicare un file specifico.

Indice grafico

FancyIndexing { on | off }

La direttiva FancyIndexing permette di definire se, quando viene restituito l'elenco del contenuto di una directory, si vuole una rappresentazione a icone, oppure se si vuole un testo puro e semplice. La parola chiave on attiva la visualizzazione a icone; off la disabilita.

FancyIndexing on

Definizione delle icone

AddIconByEncoding (sigla,file_icona) tipo_codifica...

Questa direttiva abbina un'icona a uno o più tipi di codifica. La sigla rappresenta una stringa da utilizzare al posto dell'icona quando non è possibile la sua rappresentazione (per esempio se si usa il navigatore Lynx).

AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip

AddIconByType (sigla,file_icona) tipo_mime/sottotipo

Questa direttiva abbina un'icona a un tipo e sottotipo MIME, eventualmente utilizzando l'asterisco nel sottotipo per includerli tutti. La sigla rappresenta una stringa da utilizzare al posto dell'icona quando non è possibile la sua rappresentazione.

AddIconByType (TXT,/icons/text.gif) text/*
AddIconByType (IMG,/icons/image2.gif) image/*
AddIconByType (SND,/icons/sound2.gif) audio/*
AddIconByType (VID,/icons/movie.gif) video/*

AddIcon file_icona estensione...

Questa direttiva abbina un'icona a una o più estensioni del nome dei file.

AddIcon /icons/binary.gif .bin .exe
AddIcon /icons/binhex.gif .hqx
AddIcon /icons/tar.gif .tar
AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv
AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip
AddIcon /icons/a.gif .ps .ai .eps
AddIcon /icons/layout.gif .html .shtml .htm .pdf
AddIcon /icons/text.gif .txt
AddIcon /icons/c.gif .c
AddIcon /icons/p.gif .pl .py
AddIcon /icons/f.gif .for
AddIcon /icons/dvi.gif .dvi
AddIcon /icons/uuencoded.gif .uu
AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl
AddIcon /icons/tex.gif .tex
AddIcon /icons/bomb.gif core

AddIcon /icons/back.gif ..
AddIcon /icons/hand.right.gif README
AddIcon /icons/folder.gif ^^DIRECTORY^^
AddIcon /icons/blank.gif ^^BLANKICON^^

DefaultIcon file_icona

Questa direttiva permette di definire un'icona predefinita per i file che non rientrano in una classificazione diversa.

DefaultIcon /icons/unknown.gif

File da ignorare

IndexIgnore modello_da_ignorare...

Quando si consente di accedere a una directory visualizzandone il contenuto (perché manca il file index.html o equivalente), si può fare in modo che alcuni file non appaiano in elenco. Utilizzando questa direttiva, si possono indicare i modelli di file da non includere. Per questo si possono usare i caratteri jolly consueti (punto interrogativo e asterisco).

IndexIgnore */.??* *~ *# */HEADER* */README* */RCS

L'esempio mostra l'esclusione dall'elenco di:

tutti i file che iniziano con un punto e sono lunghi almeno tre caratteri, perché si vuole continuare a includere il riferimento alla directory precedente;
tutti i file che terminano con il simbolo tilde, che sono solitamente delle copie di sicurezza di versioni precedenti;
tutti i file che terminano con il simbolo #, dal momento che anche questi sono generalmente copie di sicurezza di versioni precedenti;
tutti i file il cui nome inizia per HEADER o README, perché hanno un ruolo speciale;
il file RCS.

File «readme»

HeaderName file_readme_iniziale

ReadmeName file_readme_finale

Attraverso queste due direttive si possono specificare i nomi di file, il cui contenuto si vuole sia incluso nell'elenco della directory. Per la precisione, la direttiva HeaderName specifica il nome di un file da mettere prima dell'elenco; la direttiva ReadmeName specifica il nome di un file da mettere dopo l'elenco. L'esempio permette di chiarire altri dettagli.

HeaderName HEADER
ReadmeName README

In questo caso, viene cercato prima il file HEADER.html. Se viene trovato, viene incluso all'inizio dell'elenco della directory, mantenendo la formattazione HTML. Se manca, ma esiste il file HEADER, questo viene incluso in modo testuale. La stessa cosa vale per il file README.html o soltanto README, con la differenza che questo viene incluso alla fine, dopo l'elenco.

160.3.3 Tipi di file

Il servente ha bisogno di conoscere il tipo di file che si preleva per sapere come comportarsi, ma soprattutto per poterlo comunicare al cliente che lo ha richiesto. Questo si ottiene attraverso la configurazione dei tipi MIME, ma è pur sempre necessario specificare il tipo predefinito, quando non si riesce a determinarlo altrimenti.

Tipo predefinito

DefaultType tipo_e_sottotipo_mime...

Permette di definire il tipo MIME predefinito di un documento per il quale non si riesca a identificare diversamente. Di solito questo valore predefinito è text/plain.

DefaultType text/plain

Aggiunta di tipi nuovi

AddType tipo_mime/sottotipo estensione

Con questa direttiva si possono aggiungere dei tipi MIME senza intervenire nel file di definizione di questi, mime.types. Generalmente non è conveniente intervenire in questo modo; è sempre meglio utilizzare il file dei tipi MIME.

Codifica

AddEncoding tipo_di_compressione estensione

Questa direttiva permette di abbinare un'estensione a un tipo di codifica. Ciò permette ad alcuni programmi cliente di sapere come gestire tali dati.

AddEncoding x-compress Z
AddEncoding x-gzip gz

L'esempio mostra la configurazione tipica, che serve a informare i programmi cliente quando viene inviato loro un file compresso con compress o con gzip.

160.3.4 Directory alias

Per evitare confusione, oltre che per motivi di sicurezza, è opportuno dichiarare alcune directory speciali in forma di alias.

Alias normale

Alias directory_fasulla directory_reale

Questo tipo di direttiva, che può essere ripetuta, permette di definire delle directory in posizioni diverse da quelle reali. La directory fasulla fa riferimento a una directory indicata nell'indirizzo URI richiesto, mentre quella reale indica la directory effettiva nel file system.

Alias /icons/ /home/httpd/icons/

L'esempio mostra la dichiarazione di una directory cui si accede attraverso l'alias /icons/. In pratica, tutte le volte che viene richiesta una risorsa contenuta nella directory /icons/, questa verrà prelevata dalla directory reale /home/httpd/icons/.

La dichiarazione dell'alias /icons/ è molto importante nella consuetudine, dal momento che si tratta del riferimento alla directory contenente le icone utilizzare per la visualizzazione degli indici. Si è visto in un'altra sezione la dichiarazione dell'abbinamento delle icone a seconda dell'estensione dei file, come nell'esempio seguente, dove si fa riferimento a questo alias.

AddIcon /icons/binary.gif .bin .exe

Alias per i programmi CGI

ScriptAlias directory_fasulla directory_reale

Funziona come la direttiva Alias, ma si riferisce ai programmi CGI. Generalmente, i programmi CGI dovrebbero essere collocati esclusivamente all'interno di directory dichiarate attraverso questa direttiva, per non rischiare di creare problemi di sicurezza del sistema.

ScriptAlias /cgi-bin/ /home/httpd/cgi-bin/

160.3.5 Gestori specifici in base all'estensione

È possibile stabilire un comportamento particolare in base all'estensione dei file. Con questo si intende qualcosa di diverso dalla semplice lettura e invio al cliente che ne fa richiesta. La sintassi generale è la seguente:

AddHandler nome_dell'azione estensione

Il nome dell'azione definisce un tipo preciso di operazione da abbinare ai file che contengono l'estensione indicata.

Esecuzione di programmi CGI

AddHandler cgi-script estensione

Questa direttiva, usata così, permette di abbinare a un'estensione l'esecuzione automatica come programma CGI. È decisamente sconsigliabile di permettere l'utilizzo di programmi CGI al di fuori della directory dichiarata con la direttiva ScriptAlias. L'esempio seguente mostra questa direttiva commentata opportunamente per sicurezza.

#       AddHandler cgi-script .cgi

160.3.6 Configurazione di accesso della directory

È possibile definire il nome di un file di configurazione che, se presente, serve per definire l'accesso alla directory in cui si trova. Il nome predefinito di questo è .htaccess. Per questo si utilizza la direttiva AccessFileName, come nell'esempio seguente:

AccessFileName .htaccess

160.3.7 File di messaggi

In occasione di determinate situazioni errore, il programma servente emette delle segnalazioni di errore. Questi messaggi possono essere riscritti in forma di file HTML o di programma CGI. La direttiva per controllare questi messaggi ha tre sintassi possibili.

ErrorDocument n_errore file_alternativo

ErrorDocument n_errore uri_esterno

ErrorDocument n_errore "messaggio

Nel primo caso, l'ultimo argomento è un file HTML o un programma CGI; nel secondo si tratta di un URI esterno; nel terzo si tratta di una stringa, che viene identificata come tale perché inizia con gli apici doppi ("). La stringa non deve essere terminata, a meno di volere fare apparire gli apici doppi finali.

ErrorDocument 500 "Errore del servente www.

L'esempio mostra il caso in cui si voglia fare apparire una stringa particolare in occasione del verificarsi dell'errore 500.

ErrorDocument 404 /documento_mancante.html

In questo caso, in occasione dell'errore 404, viene inviato al cliente il file documento_mancante.html che conterrà qualche utile suggerimento per l'utente.

ErrorDocument 404 /cgi-bin/documento_mancante.pl

Questa è una variante dell'esempio precedente, in cui, invece di inviare un file HTML viene eseguito un programma CGI, /cgi-bin/documento_mancante.pl. Ciò può essere utile per comporre una risposta personalizzata, utilizzando le informazioni cui può accedere il programma stesso.

ErrorDocument 404 http://roggen.brot.dg/cgi-bin/documento_mancante.pl

Questa è una variante dell'esempio precedente, in cui si fa riferimento a una risorsa contenuta in un URI esterno al servente dove si manifesta il problema.

160.4 Controllare l'accesso con access.conf

access.conf è il file di configurazione globale che permette di controllare l'accesso alle directory del sistema. La sua sintassi è diversa da quella degli altri due file di configurazione già visti. In particolare, oltre a normali direttive, si utilizzano dei delimitatori simili a marcatori HTML che permettono di definire il contesto a cui si riferiscono le direttive contenute. Più precisamente si parla di sezioni.

Nelle edizioni più recenti di Apache, le direttive del file access.conf possono risiedere direttamente nel file httpd.conf.

160.4.1 Sezioni di controllo

Le sezioni del file di configurazione degli accessi hanno una forma simile a quella seguente:

<Nome ...> ... </Nome>

Nel marcatore che ne dichiara l'apertura possono apparire delle opzioni; nella parte compresa tra l'apertura e la chiusura si inseriscono delle direttive riferite a quella sezione particolare. A seconda del contesto, una sezione può contenere anche la dichiarazione di altre sezioni in modo annidato.

160.4.2 Sezione «Directory»

Le sezioni Directory raccolgono le direttive di controllo per una particolare directory e per quelle successive. La direttiva di apertura, ovvero il marcatore <Directory>, deve contenere l'indicazione della directory a cui si riferiscono le direttive della sezione, eventualmente usando anche i caratteri jolly (* e ?) o le espressioni regolari estese.

<Directory /home/httpd/html>
        Options Indexes FollowSymLinks
</Directory>

Questo esempio è il più comune: si dichiara una sezione riferita alla directory /home/httpd/html/, che qui si vuole intendere corrispondere alla document root.

<Directory "^/home/httpd/html/[0-9]{3}">
        Options Indexes FollowSymLinks
</Directory>

Questo esempio ulteriore, attraverso un'espressione regolare, dichiara una sezione riferita a tutte le directory discendenti di /home/httpd/html/ che iniziano con tre cifre numeriche.

Quando una sezione si riferisce a una porzione già presa in considerazione da un'altra analoga, conviene che queste appaiano in una sequenza tale da porre prima le sezioni generali e dopo quelle più particolareggiate, come nell'esempio seguente:

<Directory />
        AllowOverride None
</Directory>
...
<Directory /home/httpd/html>
        AllowOverride All
</Directory>

Di seguito sono descritte alcune delle direttive che possono essere usate all'interno della sezione Directory.

Options

Options [+|-]opzione...

La direttiva Options permette di definire alcune opzioni in forma di parole chiave. La tabella 160.2 ne riporta l'elenco. In particolare, le opzioni None e All vanno usate da sole.

Tabella 160.2. Alcune opzioni della direttiva Options nella sezione Directory.

Parola chiave	Significato
None	Disabilita tutto.
All	Abilita tutte le opzioni.
FollowSymLinks	Abilita l'uso di collegamenti simbolici.
SymLinksIfOwnerMatch	Abilita l'uso di collegamenti simbolici solo se il proprietario coincide.
ExecCGI	Permette l'esecuzione dei programmi CGI.
Indexes	Permette di ottenere il listato del contenuto.
Includes	SSI è permesso.
IncludesNOEXEC	SSI è permesso in parte.

Generalmente, se più direttive Options possono applicarsi alla stessa directory, quella riferita alla directory più specifica si sostituisce completamente alle altre. Tuttavia, se tutte le opzioni vengono precedute dal segno + o -, queste vengono unite a quelle già dichiarate. Le opzioni precedute dal segno + vengono aggiunte; quelle precedute dal segno - vengono eliminate. In ogni caso, per facilitare la lettura sarebbe opportuno dichiarare ogni volta le opzioni che si vuole siano abilitate.

L'esempio seguente mostra la semplice dichiarazione della directory /home/httpd/html/ (corrispondente a document root), in cui è consentito visualizzare il listato del contenuto e seguire i collegamenti simbolici.

<Directory /home/httpd/html>
        Options Indexes FollowSymLinks
</Directory>

AllowOverride

AllowOverride opzione...

La direttiva AllowOverride permette di definire quali opzioni possono essere scavalcate dalle dichiarazioni particolari contenute nei file di accesso delle singole directory (.htaccess). La tabella 160.3 ne riporta l'elenco. In particolare, le opzioni None e All vanno usate da sole.

Tabella 160.3. Alcune opzioni della direttiva AllowOverride nella sezione Directory.

Parola chiave	Significato
None	Impedisce che qualunque direttiva venga scavalcata.
All	Permette che siano scavalcate tutte le direttive.
Options	Permette l'uso della direttiva `Options`.
Limit	Permette l'uso di direttive di controllo sugli accessi.
AuthConfig	Permette l'uso di direttive di autorizzazione.
FileInfo	Permette l'uso di direttive di controllo del tipo di documento.
Indexes	Permette l'uso di direttive di controllo sul listato delle directory.

L'esempio seguente mostra la semplice dichiarazione della directory /home/httpd/html/ (corrispondente a DocumentRoot), in cui è consentito visualizzare il listato del contenuto e seguire i collegamenti simbolici. Per questa directory (e per le successive) non è possibile scavalcare alcuna direttiva utilizzando i file .htaccess.

<Directory /home/httpd/html>
        Options Indexes FollowSymLinks
        AllowOverride None
</Directory>

Autorizzazioni

Attraverso una serie di direttive è possibile definire l'autorizzazione all'accesso alla directory, fornendo un nominativo e una parola d'ordine. Questi nominativi e le parole d'ordine cifrate relative devono essere contenuti in un file creato con un programma apposito, htpasswd, ed è necessario che non coincidano con nominativi e parole d'ordine già utilizzati per accedere al sistema. Infatti, il programma cliente memorizza queste informazioni la prima volta che vengono inserite, quindi le fornisce automaticamente a ogni richiesta.⁽⁴⁾

A fianco del file di utenti e parole d'ordine, si può creare un file di gruppi che serve solo a facilitare la definizione delle autorizzazioni, quando si vuole fare riferimento a un intero gruppo di utenti, senza doverli elencare.

AuthName nome

La direttiva AuthName permette di definire un nome per identificare il contesto dell'autorizzazione. Questa descrizione viene data all'utente quando gli viene richiesto di inserire il nominativo e la parola d'ordine, in modo da permettergli di distinguere tra autorizzazioni diverse che possono richiedere un'identificazione differente.

AuthType Basic

Questa direttiva è obbligatorie e specifica il tipo di autorizzazione.

AuthUserFile file_di_utenti_e_parole_d'ordine

Specifica un file da utilizzare come elenco di utenti e parole d'ordine. Questo file viene creato e aggiornato utilizzando il programma htpasswd.

AuthGroupFile file_dei_gruppi

Specifica un file da utilizzare come elenco di gruppi abbinati agli utenti. Non contiene parole d'ordine e viene creato in modo manuale.

require user utente...

require group gruppo...

require valid-user

Una di queste direttive stabilisce la necessità dell'identificazione attraverso un nominativo-utente e una parola d'ordine. Nel primo caso si indicano precisamente quali utenti possono accedere, nel secondo quali gruppi di utenti e nel terzo si afferma semplicemente che possono accedere tutti.

L'esempio seguente definisce un accesso ristretto e condizionato al riconoscimento degli utenti. In particolare però, solo gli utenti tizio, caio e semproni possono accedere.

<Directory /home/httpd/html/riservato>

        AllowOverride None
        Options Indexes

        AuthName "Informazioni riservate"
        AuthType Basic
        AuthUserFile /etc/apache/.htpasswd
        AuthGroupFile /etc/apache/.htgroup
        require user tizio caio semproni

</Directory>

Limitazione dell'accesso

In origine, queste direttive erano consentite solo nella sezione Limit. Se vi appaiono fuori, indicano che si riferiscono a qualunque metodo di accesso. Quando si utilizzano queste direttive, se si intende fare uso di nomi di dominio è indispensabile avere attivato la risoluzione dei nomi di dominio attraverso la direttiva HostnameLookups nel file httpd.conf.

order allow,deny

order deny,allow

order mutual-failure

In questo modo si specifica l'ordine in cui devono essere prese in considerazione le direttive deny e allow. Quando si specifica la parola chiave mutual-failure, si intende che possono accedere solo i nodi che appaiono nella lista allow e non appaiono in quella deny.

deny from { all | host... }

Impedisce l'accesso da parte dei nodi elencati. Se si usa la parola chiave all si impedisce a tutti di accedere. I nodi possono essere indicati attraverso il nome di dominio, completo o parziale, e attraverso l'indirizzo numerico, completo o parziale.

allow from { all | host... }

Consente l'accesso da parte dei nodi elencati. Se si usa la parola chiave all si consente a tutti di accedere. I nodi possono essere indicati attraverso il nome di dominio, completo o parziale, e attraverso l'indirizzo numerico, completo o parziale.

L'esempio seguente stabilisce il blocco all'accesso da parte degli utenti del dominio mehl.dg, a partire dalla directory dichiarata nell'apertura della sezione Directory.

<Directory /home/httpd/html/polenta>
        AllowOverride None
        Options Indexes

        order allow,deny
        allow from all
        deny from .mehl.dg
</Directory>

L'esempio seguente, invece, concede solo al dominio mehl.dg di poter accedere.

<Directory /home/httpd/html/polenta>
        AllowOverride None
        Options Indexes

        order deny,allow
        deny from all
        allow from .mehl.dg
</Directory>

L'esempio seguente è una variante del precedente, in cui si utilizza anche l'indicazione di una sottorete in forma di indirizzo numerico.

<Directory /home/httpd/html/polenta>
        AllowOverride None
        Options Indexes

        order deny,allow
        deny from all
        allow from .mehl.dg 192.168.2.
</Directory>

160.4.3 Sezione «Limit»

Le sezioni Limit sono usate per racchiudere un gruppo di direttive di controllo di accesso, che riguardano solo i metodi specificati. I metodi di accesso in questione sono, per esempio, GET e POST.

<Directory /home/httpd/html/riservato>

        AllowOverride None
        Options Indexes

        AuthName "Informazioni riservate"
        AuthType Basic
        AuthUserFile /etc/apache/.htpasswd
        AuthGroupFile /etc/apache/.htgroup

        <Limit GET POST>
                require valid-user
        </Limit>

</Directory>

L'esempio mostra che per la directory specificata è richiesta l'autenticazione solo in caso di utilizzo dei metodi GET e POST.

Quando si vuole che le direttive di controllo di accesso riguardino tutti i metodi di accesso, non si usa la sezione Limit.

In linea di massima, la sezione Limit può contenere ogni direttiva, a esclusione della dichiarazione ulteriore di sezioni Directory e Limit annidate. In pratica, si utilizzano solo direttive per cui abbia senso porre un limite basato sul metodo di accesso. Generalmente ha significato l'utilizzo delle direttive indicate nella tabella 160.4.

Tabella 160.4. Alcune direttive utili nella sezione Limit.

Direttiva	Descrizione
require	Utenti che possono accedere attraverso autenticazione.
order	Ordine di valutazione delle direttive `deny` e `allow`.
deny	Specifica i nodi a cui viene negato l'accesso.
allow	Specifica i nodi a cui viene concesso l'accesso.

160.4.4 Sezione «Location»

Le sezioni Location raccolgono le direttive di controllo per un URI particolare. Si tratta di qualcosa molto simile alla sezione Directory, con la differenza che il riferimento è fatto all'URI piuttosto che alla directory del file system effettivo.

Questa sezione viene usata prevalentemente per abilitare l'accesso allo stato del servente attraverso l'indicazione di un URI, da parte di un particolare indirizzo autorizzato.

<Location /status>
        SetHandler server-status
        order deny,allow
        deny from all
        allow from dinkel.brot.dg
</Location>

Nell'esempio viene concesso al nodo dinkel.brot.dg di accedere all'URI /status cui è abbinata la generazione e la restituzione di informazioni sul sistema. Il risultato potrebbe essere qualcosa di simile a quello che segue.

Apache Server Status for dinkel.brot.dg

Current Time: Sun Sep 28 14:00:47 1997
Restart Time: Sun Sep 28 14:00:28 1997
Server uptime: 19 seconds
Total accesses: 0 - Total Traffic: 0 B
CPU Usage: u0 s0 cu0 cs0
0 requests/sec - 0 B/second -

Scoreboard:

K___W__...........................................
..................................................
..................................................

Key:
"_" Waiting for Connection, "S" Starting up,
"R" Reading Request, "W" Sending Reply,
"K" Keepalive (read), "D" DNS Lookup, "L" Logging

2 requests currently being processed, 5 idle servers

Srv PID   Acc  M CPU  SS Conn Child Slot         Host                Request
0   8449 0/0/0 K 0.00 10 0.0  0.00  0.00
4   8453 0/0/0 W 0.00 0  0.0  0.00  0.00 dinkel.brot.dg GET /status HTTP/1.0
------------------------------------------------------------------------
  Srv  Server number
  PID  OS process ID
  Acc  Number of accesses this connection / this child / this slot
   M   Mode of operation
  CPU  CPU usage, number of seconds
  SS   Seconds since beginning of most recent request
 Conn  Kilobytes transferred this connection
 Child Megabytes transferred this child
 Slot  Total megabytes transferred this slot

160.5 Controllare l'accesso con .htaccess

I file .htaccess possono essere usati per definire delle configurazioni specifiche riferite alla directory in cui si trovano. Non è necessario il loro utilizzo; si tratta solo di una possibilità, che peraltro deve essere controllata attraverso la direttiva AllowOverride nel file access.conf. In linea di massima, i file .htaccess possono contenere le direttive elencate nella tabella 160.5

Tabella 160.5. Alcune direttive utili nel file .htaccess.

Direttiva	Descrizione
Options	Opzioni varie.
DefaultType	Definisce il tipo e il sottotipo MIME predefinito per la directory.
ErrorDocument	Ridefinisce la risposta in caso si verifichino condizioni di errore.
AuthName	Nome o descrizione di una zona soggetta ad autenticazione.
AuthType	Definizione del tipo di autenticazione.
require	Dichiarazione degli utenti autorizzati all'autenticazione.
order	Ordine di valutazione delle direttive `deny` e `allow`.
deny	Specifica i nodi a cui viene negato l'accesso.
allow	Specifica i nodi a cui viene concesso l'accesso.

160.6 Considerazioni sulla sicurezza

Dalla descrizione dei file di configurazione di Apache si possono intuire i punti su cui agire per cercare di ottenere un servizio HTTP relativamente «sicuro». Vale comunque la pena di sottolineare alcune cose.

Il demone httpd viene avviato normalmente con i privilegi dell'utente root, quindi, attraverso delle opportune chiamate di sistema, httpd cambia questi privilegi portandoli a quelli dell'utente e del gruppo specificati con le direttive User e Group del file httpd.conf.

È molto importante che l'utente e il gruppo corrispondano a nobody, dove questo utente fittizio deve corrispondere idealmente al «perfetto sconosciuto» che accede al sistema, oppure, ancora meglio, che si tratti di un utente apposito. In questa ottica devono poi essere regolati i permessi delle directory.
I file amministrativi di Apache, cioè quelli di configurazione e di registrazione degli eventi, non devono essere accessibili in scrittura da parte degli utenti comuni (di qualunque tipo siano, escluso root). Nello stesso modo, non devono essere modificabili le directory che li contengono.

I file che compongono i documenti ipertestuali devono essere accessibili solo in lettura agli utenti comuni, così le directory non devono essere modificabili, eccetto i permessi che può avere l'utente root.

È consigliabile utilizzare la direttiva SymLinksIfOwnerMatch per evitare brutti scherzi da parte degli utenti che hanno la possibilità di creare documenti HTML a partire dalla loro directory personale.
È bene evitare di permettere l'utilizzo di programmi CGI al di fuori della directory definita con la direttiva ScriptAlias nel file srm.conf.
È opportuno evitare di concedere agli utenti comuni di modificare le impostazioni attraverso i file .htaccess. Si ottiene questo con la direttiva AllowOverride None.

Segue un esempio molto semplice della configurazione del file access.conf.

# Prima si impedisce l'accesso alla radice del file system.
<Directory />
        AllowOverride None
        Options None
        order deny,allow
        deny from all
</Directory>

# Si definisce la directory DocumentRoot.
<Directory /home/httpd/html>
        Options Indexes SymLinksIfOwnerMatch
        AllowOverride None
        order deny,allow
        allow from all
</Directory>

# Si concede di accedere alle directory personali degli utenti.
<Directory /home/*/public_html>
        Options Indexes SymLinksIfOwnerMatch
        AllowOverride None
        order deny,allow
        allow from all
</Directory>

# Si concede l'esecuzione ai programmi CGI che si trovano a
# partire dalla directory predisposta per questo.
<Directory /home/httpd/cgi-bin>
        AllowOverride None
        Options ExecCGI
        order deny,allow
        allow from all
</Directory>

# Si concede l'accesso alla directory contenente le icone di sistema.
<Directory /home/httpd/icons>
        AllowOverride None
        Options None
        order deny,allow
        allow from all
</Directory>

# Abilita la lettura dello stato del servente.
<Location /status>
        SetHandler server-status
        order deny,allow
        deny from all
        allow from .brot.dg
</Location>

Come si può osservare, non è stato consentito in alcun caso di utilizzare i file .htaccess e i collegamenti simbolici sono tollerati se il proprietario del collegamento equivale a quello del file o della directory di destinazione. Inoltre sono state prese le misure seguenti:

è impedito l'accesso a partire dalla directory radice del file system, obbligando a dichiarare l'accesso alle directory successive;
viene concesso l'accesso alla directory da cui si diramano i documenti ipertestuali;
viene concesso espressamente l'accesso alle directory personali degli utenti;
i programmi CGI possono essere eseguiti solo nella directory preposta a questo, il cui contenuto risulta illeggibile;
l'accesso alla directory contenente le icone utilizzate da Apache è stato dichiarato espressamente, altrimenti sarebbero risultate inaccessibili a causa del divieto iniziale sulla directory radice;
è stata abilita la lettura dello stato del servente, concedendo l'accesso solo al dominio brot.dg.

160.7 Utilizzo del sistema di autenticazione

Il sistema di autenticazione del programma servente permette di consentire l'accesso a directory determinate solo a utenti identificati in base a un nome e a una parola d'ordine. È molto importante capire come funziona il meccanismo, per non farsi delle illusioni sull'efficienza del sistema.

Figura 160.1. Il programma cliente chiede all'utente di identificarsi quando per la prima volta ciò viene richiesto dal servente HTTP.

figure/a2-web-directory-autorizzazione

La prima volta che l'utente accede, il programma cliente gli presenta la richiesta di inserire il nominativo e la parola d'ordine, poi tutto funziona normalmente. Però, essendo il protocollo HTTP privo di stato, non si instaura una connessione stabile; ogni richiesta è una connessione a parte e ognuna di queste richiede un'autenticazione. In effetti, il programma cliente memorizza i dati inseriti dall'utente e continua a fornirli al servente HTTP. Questo fatto ha due implicazioni: la parola d'ordine viaggia continuamente attraverso la rete; più utenti possono accedere simultaneamente da postazioni differenti, utilizzando la stessa identificazione e la stessa parola d'ordine. Sotto questo aspetto, è importante che le parole d'ordine che si adoperano per queste cose non abbiano alcun nesso con quelle «serie».

Per gestire questo tipo di autenticazione, occorre generare un file di utenti e di parole d'ordine, aggiungendo possibilmente anche un file di gruppi. Si utilizza il programma htpasswd che normalmente fa parte del pacchetto di Apache:

htpasswd [-c] file utente

htpasswd crea o aggiorna un file di utenti e di parole d'ordine per l'autenticazione degli accessi a directory protette con il servente Apache. L'opzione -c viene usata per creare il file la prima volta, mentre si inserisce il primo utente. La parola d'ordine viene richiesta subito dopo l'avvio del programma.

Vengono mostrati e descritti alcuni esempi.

# htpasswd -c passwd tizio[Invio]

Adding password for tizio.
New password:

Viene inserita la parola d'ordine seguita da [Invio].

Re-type new password:

Viene reinserita la parola d'ordine seguita da [Invio] e si ottiene il file passwd nella directory corrente.

# cat passwd[Invio]

tizio:njHIUkjjJLKn

Il file contiene solo i nomi degli utenti e le parole d'ordine cifrate relative.

# htpasswd passwd caio[Invio]

Quando si aggiungono utenti, non si utilizza l'opzione -c, altrimenti il file viene cancellato e ricreato.

# htpasswd passwd caio[Invio]

Lo stesso programma può essere usato per modificare la parola d'ordine di un utente già registrato.

Per facilitare la gestione di utenti che utilizzano l'autenticazione per accedere a directory protette, è possibile realizzare dei raggruppamenti e inserirli in un file senza parole d'ordine. Il formato del file è molto semplice: ogni record è costruito secondo la sintassi seguente:

gruppo: utente...

Quindi, i nominativi dei vari utenti sono separati da uno spazio, come nell'esempio seguente:

primo: tizio caio semproni
secondo: cane gatto topo

Nell'esempio sono dichiarati due gruppi: primo e secondo. A primo appartengono gli utenti tizio, caio e semproni; a secondo appartengono gli utenti cane, gatto e topo.

160.7.1 Configurazione

La configurazione delle directory che devono essere accessibili solo attraverso un'autenticazione, avviene nel file access.conf in una sezione Directory. Sono indispensabili le direttive AuthName, AuthType e AuthUserFile con cui si dà un nome all'autenticazione, si definisce il tipo e si indica il nome del file degli utenti e delle parole d'ordine. La direttiva AuthGroupFile serve solo se si intende fare riferimento a gruppi di utenti.

<Directory /home/httpd/html/riservato>

    AllowOverride None
    Options Indexes

    AuthName "Informazioni riservate"
    AuthType Basic
    AuthUserFile /etc/apache/passwd
    AuthGroupFile /etc/apache/group

    require valid-user

</Directory>

La direttiva require stabilisce a chi, tra gli utenti che sono dichiarati nel file di utenti e di parole d'ordine, sia concesso di accedere. La parola chiave valid-user rappresenta tutti gli utenti che sono stati previsti. In alternativa possono essere elencati gli utenti a cui concedere l'accesso, come nell'esempio seguente;

    require user tizio caio semproni

oppure si può indicare il nome di uno o più gruppi.

    require group primo terzo quinto

Solo nell'ultimo caso è necessario predisporre e dichiarare la posizione del file dei gruppi.

160.8 Siti virtuali

Apache è in grado di gestire diversi siti virtuali indipendenti sullo stesso elaboratore. In pratica, si distinguono diverse directory per le pagine HTML (diverse directory document root), dove ognuna di queste viene selezionata in base al nome di dominio utilizzato per accedere al servizio.

Evidentemente, per arrivare a questo risultato, occorre che lo stesso elaboratore sia accessibile utilizzando nomi di dominio differenti: si va dall'attribuzione di un semplice alias all'interno del DNS (i record CNAME), fino alla sovrapposizione di indirizzi IP differenti sulle stesse interfacce (con la conseguente attribuzione di nomi di dominio differenti). A proposito della gestione del DNS, si vedano i capitoli 122 e 123.

Quanto visto su Apache fino a questo punto, riguarda la gestione di un sito unico: quello «reale». Si osservi in particolare che la direttiva DocumentRoot viene inserita nel file srm.conf. Per definire dei siti virtuali alternativi si interviene nel file httpd.conf, attraverso delle sezioni simili a quelle del file access.conf:

<VirtualHost nome_di_dominio > direttiva_specifica ... </VirtualHost>

In pratica, all'interno del marcatore di apertura dell'ambiente VirtualHost si inserisce il nome del sito virtuale a cui si fa riferimento, mentre all'interno della sezione si inseriscono le direttive specifiche per questo sito.

<VirtualHost prova.brot.dg>
    ServerAdmin webmaster@prova.brot.dg
    DocumentRoot /home/httpd/html2
    ServerName prova.brot.dg
    ErrorLog logs/prova.brot.dg-error_log
    TransferLog logs/prova.brot.dg-access_log
</VirtualHost>

L'esempio mostra la predisposizione del sito virtuale prova.brot.dg. All'interno della sezione si vedono le dichiarazioni:

dell'indirizzo di posta elettronica dell'amministratore, con la direttiva ServerAdmin;
della directory di partenza delle pagine HTML, con la direttiva DocumentRoot;
del nome di dominio corretto per raggiungere il sito virtuale, con la direttiva ServerName;
dei percorsi assoluti dei file delle registrazioni, con le direttive ErrorLog e TransferLog.

È il caso di osservare la stranezza per la quale la direttiva DocumentRoot può apparire nella sezione VirtualHost all'interno del file httpd.conf, mentre per il sito reale si usa il file srm.conf.

Nel momento in cui si dichiara l'utilizzo di una nuova directory per i dati (le pagine HTML), ci si deve preoccupare anche di configurare l'accesso a tale directory. Questo si fa nel modo solito all'interno del file access.conf. Seguendo l'esempio mostrato, potrebbe essere necessario aggiungere la sezione seguente:

<Directory /home/httpd/html2>
        Options Indexes SymLinksIfOwnerMatch
        AllowOverride None
        order deny,allow
        allow from all
</Directory>

160.9 Riferimenti

Apache

<http://www.apache.org/>

1) Apache software libero con licenza speciale

2) moduli HTML.

3) Quando httpd viene controllato dal supervisore dei servizi di rete, per ogni richiesta bisogna aspettare l'avvio del demone. Ciò genera un certo ritardo nelle risposte e può essere giustificato da particolari esigenze di sicurezza che si possono attuare solo in questo modo.

4) È bene ricordare che il protocollo HTTP è privo di stato, per cui a ogni richiesta si ricomincia da capo.

Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome servente_http_apache.html