[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]


197. Servente HTTP: Apache

In precedenza, nel capitolo 106, è stato descritto il servizio HTTP, la configurazione di Apache in modo sintetico e l'utilizzo di un cliente in grado di accedere a tale servizio. In questo capitolo si vuole approfondire un po' la configurazione del servente Apache. Per quanto riguarda le funzionalità di proxy di Apache, si può consultare il capitolo 213.

197.1 Concetti essenziali

Prima di vedere i dettagli dell'impostazione del servente, è il caso di ripassare in breve il suo funzionamento.

  1. L'accesso al servizio HTTP avviene a partire da una parte del filesystem, che inizia dal cosiddetto DocumentRoot.

  2. Il servente non esegue la funzione `chroot()' in questa directory, e ciò consente di articolare le directory successive anche attraverso l'uso di collegamenti simbolici in posizioni precedenti alla directory DocumentRoot.

  3. In linea di massima, ogni utente può realizzare una struttura personalizzata di documenti HTML, a partire dalla propria directory personale (home).

  4. Il servente è in grado di mettere in funzione dei programmi, detti CGI, per la gestione interattiva di pagine HTML contenenti dei moduli.

197.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 servente.

197.1.2 Avvio e conclusione dell'attività del servente

Il servizio viene gestito dal demone `httpd' che può essere avviato direttamente dalla procedura di inizializzazione del sistema (Init), oppure può essere controllato da `inetd'. 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 da `inetd'.

Quando `httpd' è indipendente da `inetd' (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.

197.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 213 viene trattata la configurazione di Apache per la gestione di una cache proxy, cosa che riguarda in modo particolare proprio questo file.

197.2.1 Impostazioni varie

Alcune direttive sono importanti per definire se il demone `httpd' funziona in modo autonomo o meno, e in tal 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 sul modo in cui questo viene avviato: in modo autonomo o attraverso `inetd'. *1*

ServerType standalone

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

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, è `inetd' a stare in ascolto della porta corrispondente al servizio `http'.

Port 80

Listen <numero-porta>

Se `httpd' viene utilizzato in modo autonomo, è possibile fare in modo 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 8080; quest'ultima 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

197.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 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.

197.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 password 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'.

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, e può solo continuare a funzionare con i privilegi ottenuti all'avvio.

197.2.4 Collocazione e denominazione di file e directory

Il file `httpd.conf' contiene l'indicazione della directory ServerRoot, 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/'. Potrebbe essere definita anche attraverso l'opzione `-d' della riga di comando di `httpd'.

ServerRoot /etc/httpd

L'esempio mostra la posizione più conveniente di questa directory per aderire allo standard GNU/Linux sulla struttura del filesystem.

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 ServerRoot.

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 ServerRoot come punto iniziale.

ErrorLog	/var/log/httpd/error_log
TransferLog	/var/log/httpd/access_log

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

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 ServerRoot.

Comunicazione interna

ScoreBoardFile <file-di-informazioni>

Definisce il nome e la collocazione di un file contenente una serie di informazioni sul funzionamento corrente del 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 ServerRoot.

197.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 (le directory DocumentRoot e UserDir), 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 sezioni seguenti vengono descritte solo alcune direttive più importanti.

197.3.1 Documenti HTML

La funzione principale di `srm.conf' è quello 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.

UserDir

UserDir { <directory-iniziale-documenti-utenti> | DISABLED [<utente>] }

La direttiva `UserDir' dichiara la directory, relativa 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'.

197.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.

197.3.3 Tipi di file

Il servente ha bisogno di conoscere il tipo di file che si preleva per sapere come comportarsi, e 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 <MIME-type>...

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>/<tipo> <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 clienti 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 clienti quando viene inviato loro un file compresso con `compress' o con `gzip'.

197.3.4 Directory alias

Per evitare confusione, e 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, e quella reale indica la directory effettiva nel filesystem.

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/

197.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 in questo modo, 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

197.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

197.3.7 File di messaggi

In occasione di determinate situazioni errore, il 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, e viene riconosciuta 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 in cui si manifesta il problema.

197.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 si sezioni.

197.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.

197.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, e dichiara una sezione riferita alla directory `/home/httpd/html/'.

<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 197.1 ne riporta l'elenco. In particolare, le opzioni `None' e `All' vanno usate da sole.

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.

Tabella 197.1: Alcune opzioni della direttiva `Options' nella sezione `Directory'.

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 DocumentRoot), 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 197.2 ne riporta l'elenco. In particolare, le opzioni `None' e `All' vanno usate da sole.

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.

Tabella 197.2: Alcune opzioni della direttiva `AllowOverride' nella sezione `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 password. Questi nominativi e le password cifrate relative devono essere contenuti in un file creato con un programma apposito, `htpasswd', ed è necessario che non coincidano con nominativi e password già utilizzati per accedere al sistema. Infatti, il programma cliente memorizza queste informazioni la prima volta che vengono inserite, e quindi le fornisce automaticamente a ogni richiesta. *2*

A fianco del file di utenti e password, 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 password, in modo da permettergli di distinguere tra autorizzazioni diverse che possono richiedere un'identificazione differente.

AuthType Basic

Specifica il tipo di autorizzazione. In pratica è disponibile solo il tipo `Basic' ed è obbligatorio l'utilizzo di questa direttiva.

AuthUserFile <file-di-utenti-e-password>

Specifica un file da utilizzare come elenco di utenti e password. 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 password 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 password. 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/httpd/conf/.htpasswd
	AuthGroupFile /etc/httpd/conf/.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

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>

197.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/httpd/conf/.htpasswd
	AuthGroupFile /etc/httpd/conf/.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 197.3.

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.

Tabella 197.3: Alcune direttive utili nella sezione `Limit'.

197.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 filesystem 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

197.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 197.4

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.

Tabella 197.4: Alcune direttive utili nel file `.htaccess'.

197.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 alcuni punti.

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

# Prima si impedisce l'accesso alla radice del filesystem.
<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:

197.7 Utilizzo del sistema di autenticazione

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

158.jpg

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

La prima volta che l'utente accede, il cliente gli presenta la richiesta di inserire il nominativo e la password, poi tutto funziona normalmente. Però, essendo il protocollo HTTP privo di stato, non si instaura una connessione vera e propria; ogni richiesta è una connessione a parte, e ognuna di queste richiede un'autenticazione. In effetti, il cliente memorizza i dati inseriti dall'utente e continua a fornirli al servente. Questo fatto ha due implicazioni: la password viaggia continuamente attraverso la rete; più utenti possono accedere simultaneamente da postazioni differenti, utilizzando la stessa identificazione e password. Sotto questo aspetto, è importante che le password 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 password, e possibilmente anche un file di gruppi. Si utilizza il programma `htpasswd' che normalmente fa parte del pacchetto di Apache.

197.7.1 # htpasswd

htpasswd [-c] <file> <utente>

`htpasswd' crea o aggiorna un file di utenti e password 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 password viene richiesta subito dopo l'avvio del programma.

Esempi

htpasswd -c passwd tizio[Invio]

Adding password for tizio.
New password:

Viene inserita la password seguita da [Invio].

Re-type new password:

Viene reinserita la password 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 password 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 password di un utente già registrato.

197.7.2 File dei gruppi

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 password. 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'.

197.7.3 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 password. 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/httpd/conf/passwd
	AuthGroupFile /etc/httpd/conf/group

	require valid-user

</Directory>

La direttiva `require' stabilisce a chi, tra gli utenti che sono dichiarati nel file di utenti e password, sia concesso di accedere. La parola chiave `valid-user' rappresenta tutti gli utenti che siano 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.

197.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 DocumentRoot), e 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 93 e 94.

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, e 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:

È 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>

197.9 Riferimenti

---------------------------

Appunti Linux 2000.04.12 --- Copyright © 1997-2000 Daniele Giacomini --  daniele @ pluto.linux.it


1.) Quando `httpd' viene controllato da `inetd', 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.

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


[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]