>
Benvenuto/a su www.classicistranieri.com, la Biblioteca Multimediale Libera
SCEGLI LA SEZIONE CHE PREFERISCI:
[Il blog della biblioteca] [Le nostre pubblicazioni] [Magnatune MP3 Project] [Lirica MP3] [il DVD ROM della biblioteca]
[Letture Creative] [Musica Creativa] [GNUtemberg] [Appunti di informatica libera] [Portalinux]
[The "Punch Illustrated" Mirror] [PG-Historical Fiction Collection] [PG-Audiobook Collection] [Lethal]
[PG-Classicals of English Literature] [PG-Biblioteca Italiana] [PG-Bibliothèque Française]
[PG-Deutsche Bibliothek] [PG-Biblioteca Portuguesa] [PG-Biblioteca Española]
[PG-Illustrated Children Book Collection] [PG-CD ROM]
Se questi contenuti ti sono stati utili, prendi in considerazione la possibilità di effettuare una libera donazione alla biblioteca, in modo che possano continuare a essere gratuiti per tutti.
[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico] [volume] [parte]
Apache (1) è 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 160.
Apache è costituito essenzialmente dall'eseguibile httpd, che si avvia di solito come demone autonomo dal supervisore dei servizi di rete:
|
|
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.
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.(2)
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.
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.
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 174 viene trattata la configurazione di Apache per la gestione di una cache proxy, cosa che riguarda in modo particolare proprio questo file.
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.
|
|
La direttiva ServerType permette di informare Apache su come questo viene avviato: in modo autonomo o attraverso il supervisore dei servizi di rete.(3)
|
Nell'esempio si mostra la dichiarazione per il funzionamento autonomo (standalone) che corrisponde alla situazione più comune (e anche più adatta).
|
|
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.
|
|
|
Se httpd viene utilizzato in modo autonomo, è possibile richiedere che stia in ascolto anche di un'altra porta, per mezzo della direttiva Listen.
|
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.
|
|
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:
|
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).
|
|
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.
|
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.
|
|
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.
|
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.
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.
|
|
|
|
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 #.
|
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.
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.
|
|
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.
|
L'esempio mostra la posizione più conveniente di questa directory per aderire allo standard FHS sulla struttura del file system.
|
|
|
|
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.
|
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.
|
|
|
|
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.
|
L'esempio mostra la dichiarazione dei due file delle registrazioni, con un percorso assoluto: /var/log/apache/.
|
|
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.
|
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.
|
|
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.
|
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.
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 |
Nelle sezioni seguenti vengono descritte solo alcune direttive più importanti.
La funzione principale di srm.conf è quella di definire la collocazione dei documenti ipertestuali, oltre ad altre informazioni di contorno.
|
|
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).
|
L'esempio mostra il caso in cui la directory /home/httpd/html/ corrisponda all'inizio dei documenti HTML.
|
|
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://nodo/~utente.
|
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.
|
L'esempio mostra in che modo possa essere impedito ai singoli utenti di creare le proprie pagine HTML nella loro directory personale.
|
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.
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.
|
|
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.
|
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.
|
|
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.
|
|
|
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).
|
|
|
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.
|
|
|
Questa direttiva abbina un'icona a una o più estensioni del nome dei file.
|
|
|
Questa direttiva permette di definire un'icona predefinita per i file che non rientrano in una classificazione diversa.
|
|
|
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).
|
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.
|
|
|
|
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.
|
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.
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.
|
|
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.
|
|
|
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.
|
|
Questa direttiva permette di abbinare un'estensione a un tipo di codifica. Ciò permette ad alcuni programmi cliente di sapere come gestire tali dati.
|
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.
Per evitare confusione, oltre che per motivi di sicurezza, è opportuno dichiarare alcune directory speciali in forma di alias.
|
|
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.
|
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.
|
|
|
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.
|
È 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:
|
|
Il nome dell'azione definisce un tipo preciso di operazione da abbinare ai file che contengono l'estensione indicata.
|
|
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.
|
È 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:
|
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.
|
|
|
|
|
|
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.
|
L'esempio mostra il caso in cui si voglia fare apparire una stringa particolare in occasione del verificarsi dell'errore 500.
|
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.
|
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.
|
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.
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 |
Le sezioni del file di configurazione degli accessi hanno una forma simile a quella seguente:
|
|
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.
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.
|
Questo esempio è il più comune: si dichiara una sezione riferita alla directory /home/httpd/html/, che qui si vuole intendere corrispondere alla document root.
|
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:
|
Di seguito sono descritte alcune delle direttive che possono essere usate all'interno della sezione Directory.
|
|
La direttiva Options permette di definire alcune opzioni in forma di parole chiave. La tabella 159.2 ne riporta l'elenco. In particolare, le opzioni None e All vanno usate da sole.
Tabella 159.2. 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 document root), in cui è consentito visualizzare il listato del contenuto e seguire i collegamenti simbolici.
|
|
|
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 159.3 ne riporta l'elenco. In particolare, le opzioni None e All vanno usate da sole.
Tabella 159.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.
|
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.(4)
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.
|
|
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.
|
|
Questa direttiva è obbligatorie e specifica il tipo di autorizzazione.
|
|
Specifica un file da utilizzare come elenco di utenti e parole d'ordine. Questo file viene creato e aggiornato utilizzando il programma htpasswd.
|
|
Specifica un file da utilizzare come elenco di gruppi abbinati agli utenti. Non contiene parole d'ordine e viene creato in modo manuale.
|
|
|
|
|
|
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.
|
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.
|
|
|
|
|
|
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.
|
|
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.
|
|
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.
|
L'esempio seguente, invece, concede solo al dominio mehl.dg di poter accedere.
|
L'esempio seguente è una variante del precedente, in cui si utilizza anche l'indicazione di una sottorete in forma di indirizzo numerico.
|
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.
|
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 159.4.
Tabella 159.4. Alcune direttive utili nella sezione Limit.
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.
|
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.
|
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 159.5
Tabella 159.5. Alcune direttive utili nel file .htaccess.
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.
|
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.
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 159.1. Il programma cliente chiede all'utente di identificarsi quando per la prima volta ciò viene richiesto dal servente HTTP.
|
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 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].
|
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:
|
|
Quindi, i nominativi dei vari utenti sono separati da uno spazio, come nell'esempio seguente:
|
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.
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.
|
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;
|
oppure si può indicare il nome di uno o più gruppi.
|
Solo nell'ultimo caso è necessario predisporre e dichiarare la posizione del file dei gruppi.
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 120 e 121.
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:
|
|
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.
|
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:
|
Apache
Appunti di informatica libera 2003.06.29 --- Copyright © 2000-2003 Daniele Giacomini -- daniele @ swlibero.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
[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico]
