Guida Apache. Introduzione: i Web Server

Transcript

1 Guida Apache 1. Introduzione: i Web Server 2. Installare Apache su Linux 3. Installare Apache su Windows 4. Operazioni base di Apache: avvio, riavvio e arresto 5. httpd.conf: il cuore di Apache 6. Configurare Apache: httpd.conf - 1a parte 7. Configurare Apache: httpd.conf - 2a parte 8. Agire sulle risorse: direttive di Apache 9. Gestione dinamica e metodi di controllo 10. Autenticazione in Apache 11. I filtri di Apache 12. Creazione dell'index e gestione delle directory di Apache 13. Domini virtuali di Apache 14. Errori su Apache e la loro gestione 15. Opzioni avanzate di Apache: alias e redirect Introduzione: i Web Server Come funziona Internet? Una semplice domanda la cui risposta svela spesso dinamiche complesse. Il comune fruitore della Rete non ha bisogno di conoscere le meccaniche che regolano il funzionamento del Web, un browser per la navigazione con il quale accedere alle risorse desiderate gli è più che sufficiente. Lo stesso discorso non può essere applicato a coloro che vogliono fare della creazione e della gestione di pagine web il loro mestiere, per essi è necessario conoscere quali meccanismi entrano in gioco durante la normale attività di navigazione che milioni di persone mettono in atto ogni giorno. Cerchiamo allora di rispondere alla nostra domanda iniziale: come funziona Internet? Il Web si basa sul principio del trasferimento di informazioni da un terminale (Host) all'altro attraverso dei sistemi di trasmissione detti protocolli, tra questi HTTP (Hyper text Transfer Protocol) è quello più diffuso. Questo protocollo prevede che l'utente navigatore digitando una URL o cliccando su un link richieda l'accesso a determinate risorse (input); queste risorse, quando disponibili, gli vengono inviate sotto forma di file, generalmente pagine html o immagini (output). In pratica l'utente grazie al meccanismo delle URL e dei link, non fa altro che indicare attraverso il programma di navigazione (browser) del suo computer (client), il percorso da seguire per raggiungere determinate informazioni contenute in un altro computer (server). Un server è quindi un elaboratore che contiene e fornisce file. Nel caso specifico dei server Web si parla di computer destinati ad ospitare siti internet, questi ultimi possono essere composti da pagine statiche (semplici pagine.htm e html) o dinamiche (.php, asp..), una distinzione molto importante per l'argomento che andremo a trattare in questa guida: il Web server Apache. Un Web server non è altro che un software installato in un server con la funzione di elaborare pagine web e generare dinamicamente contenuti. Le semplici pagine.htm non necessitano di particolari interventi da parte del Web server, il loro codice viene interpretato dal browser del computer client e per questo l'html è definito come un linguaggio client side. Le pagine.php o.asp, contengono dei codici destinati a produrre dei comportamenti e a generare dinamicamente html, perchè ciò sia possibile è necessaria la mediazione di un Web server; PHP e ASP vengono quindi definiti linguaggi server side. Esemplificando, quando si invia ad un Web server la richiesta di una pagina.htm, statica, esso: 1. riconosce la richiesta 2. cerca e, se presente, trova la pagina nel computer server 3. invia la pagina al browser. Nel caso di una pagina dinamica, invece, il Web server:

2 1. riconosce la richiesta 2. cerca e trova la pagina all'interno del server Web 3. esegue le istruzioni contenute all'interno del codice producendo dinamicamente contenuti 4. invia la pagina browser. La differenza salta immediatamente agl'occhi. Nei prossimi capitoli ci occuperemo appunto dell'installazione, della configurazione, della gestione e delle caratteristiche peculiari di Apache, il Web server più utilizzato della rete. Installare Apache su Linux Il Web server Apache è un software Open Source, questo vuol dire che il suo codice è pubblicamente disponibile ed aperto al contributo di chiunque desideri modificarlo agevolando così il suo continuo sviluppo; in questo modo Apache ha potuto usufruire dell'opera volontaria di migliaia di programmatori sparsi in tutto il mondo. Inoltre, Apache è un programma scaricabile gratuitamente e liberamente dalla Rete ( elemento che insieme alle sue indubbie qualità di stabilità e potenza ha contribuito non poco alla grande diffusione di questo Web Server. Apache lavora agevolmente sia in ambiente Linux che Windows, dunque in questo e nel prossimo capitolo della Guida descriveremo le procedure necessarie all'installazione in entrambi i Sistemi Operativi. Esistono vari modi per installare Apache in ambiente Linux: possiamo utilizzare i CD d'installazione della nostra distribuzione; possiamo usare il sistema RPM (RedHat Package Manager); infine, possiamo utilizzare il metodo classico basato sulla compilazione dei sorgenti. Se disponiamo dei CD d'installazione di una distribuzione Linux, come per esempio la Mandrake (da un pò di tempo ribattezzata con il nome di Mandriva), potremo integrare Apache nel nostro sistema utilizzando il comodo Rpmdrake, un software con cui gestire le installazioni, le disinstallazioni e l'aggiornamento dei pacchetti presenti nell'os. Da Kde andremo su: Configurazione > Gestione pacchetti A questo punto avremo a disposizione una comoda interfaccia grafica dotata di un motore di ricerca; cerchiamo la voce Apache è dal database verranno estratti i risultati relativi al programma che stiamo cercando; una volta selezionato il quadratino bianco posto alla destra del suo nome e cliccato su installa, Rpmdrake controllerà la presenza nel sistema delle necessarie dipendenze e ci richiederà il CD d'installazione in cui Apache è contenuto. Non dovremo fare altro che inserire il CD nel lettore e rimpiazzarlo con un altro se e quando ci verrà chiesto, in pochi attimi avremo un Web server Apache installato su Linux. Oltre all'uso di Rpmdrake, abbiamo l'alternativa di poter installare manualmente l'rpm di Apache dopo averlo scaricato dalla rete (per esempio da questo link). Una volta terminato il download di una delle versioni disponibili (ad esempio la apache i386.rpm), dovremo digitare da Shell la seguente riga di comando: rpm -ihv./apache i386.rpm Tanto basterà ad installare Apache. Il nostro sistema verrà però integrato da un Web server "essenziale" a cui dovremo aggiungere man mano i "moduli", di cui avremo bisogno come quello per PHP, SSL, PERL e molti altri. L'ultimo sistema di installazione di cui parleremo, è quello classico in ambiente Linux effettuato per compilazione di sorgenti. Nonostante la nomea di procedura ostica che si porta dietro, questo metodo non presenta particolari difficoltà. Quello che dovremo fare sarà scaricare dalla rete un archivio compresso contenente i sorgenti di Apache (per esempio l'archivio apache_ tar.gz da questo link). A questo punto dovremo scompattare e decomprimere l'archivio attraverso il comando: tar xvfz apache_ tar.gz Raggiungeremo quindi i sorgenti con il comando: cd apache_ e cominceremo la compilazione digitando:./configure --prefix=/usr/local/apache dove "prefix" indicherà il percorso verso la directory d'installazione. Per terminare la compilazione useremo il comando: make

3 e finiremo quindi l'installazione con un: make install A questo punto potremo controllare se tutto è andato bene lanciando da Shell l'istruzione: /usr/local/apache/bin/apachectl start Se non riceveremo messaggi di errore facciamoci pure i complimenti, l'installazione di Apache sarà avvenuta con successo! Installare Apache su Windows Notoriamente Linux rappresenta l'ambiente di sviluppo e di produzione privilegiato per Apache. La sterminata comunità di sviluppatori che ruota intorno a questo Web server ha comunque prodotto una buona integrazione anche per Windows; quindi coloro che non hanno pratica del Pinguino potranno in ogni caso testare le funzionalità di Apache nel loro PC dotato di OS Microsoft. Il sito ufficiale di Apache mette a disposizione dei comodi pacchetti.exe comprendenti una facile installazione guidata non dissimile da quella utilizzata per la maggior parte degli applicativi esistenti. I download disponibili sono numerosi e ruotano principalmente attorno alle due versioni principali di Apache, la 1.3.x e la 2.x; dato che la prima è indubbiamente la più testata e meno afflitta da bugs (soprattutto per quanto riguarda Windows), sarà questa che utilizzeremo negli esempi del presente capitolo. Una volta scaricato il pacchetto di installazione di una versione di Apache, per esempio la " win32-x86- no_src.exe", sarà sufficiente un doppio click sul file di Setup e la procedura guidata avrà inizio. Dopo aver visualizzato il classico messaggio di benvenuto cliccheremo su [Next]; accetteremo i termini di utilizzo del programma, leggeremo le note su questa versione e poi cliccheremo ancora su [Next]. Appariranno tre campi form da compilare: 1. Network Domain: sarà sufficiente scrivere "localhost" se stiamo operando su un PC che non fa parte di una rete intranet; in caso contrario dovremo inserire il nome del dominio di riferimento. 2. Server Name: inseriamo un nome a piacere per il nostro server; nel caso in cui operiamo in una rete dovremo invece indicare il nome della nostra postazione all'interno della stessa. 3. Administrator's Address: inserite un indirizzo . Per terminare questa fase selezioniamo l'opzione per avviare Apache come un servizio disponibile per tutti gli utenti e clicchiamo su [Next]:

4 A questo punto ci verrà chiesto di selezionare la tipologia di installazione: scegliamo quella completa e andiamo avanti. Ora dovremo indicare la directory d'installazione; se non abbiamo particolari preferenze in merito lasciamo invariata quella di default e clicchiamo su [Next] poi su [Install] e [Finish]. Dato che Apache potrà partire automaticamente a fine installazione, per controllare se tutto è andato per il meglio lanceremo il nostro browser e digiteremo l'url: oppure: Il messaggio di benvenuto di Apache sarà: Funziona! Il Server Web Apache è stato installato su questo sito Web! Operazioni base di Apache: avvio, riavvio e arresto Descrivere le semplici operazioni relative all'avvio, al riavvio e all'arresto di Apache, rappresenta un'utile occasione per approfondire il discorso riguardante il funzionamento di questo Web server. Innanzitutto, come funziona Apache? In pratica, al suo avvio esso genera un processo principale, noto come httpd, a cui si accompagnano tutta una serie di processi subordinati ognuno destinato ad una particolare funzione e tutti "in ascolto" (listening), pronti ad entrare in gioco nel caso sia necessario il loro intervento. I processi di Apache attendono gli input provenienti dai client attraverso una "porta", in genere la n 80; questo parametro può però essere modificato rimanendo nell'ambito delle prime 1024 porte. Nel momento del riavvio vengono arrestati tutti i processi secondari, rimane invece in vita httpd che si occuperà di rigenerare gli altri processi seguendo le indicazioni del file di configurazione (httpd.conf). Quando invece, richiediamo ad Apache di arrestarsi il processo principale si spegnerà e causerà la "morte" di tutti i processi secondari. In Linux abbiamo la possibilità di avviare Apache e i suoi processi attraverso due comandi principali: "/etc/rc.d/init.d/httpd" e apachectl entrambi devono essere corredati dalle eventuali opzioni o argomenti: "start, "restart" e "stop". Così, nel caso di "/etc/rc.d/init.d/httpd" per avviare Apache digiteremo: /etc/rc.d/init.d/httpd start Per riavviare Apache avremo poi: /etc/rc.d/init.d/httpd restart Infine, per arrestare Apache utilizzeremo: /etc/rc.d/init.d/httpd stop Stesso discorso per quanto riguarda "apachectl": apachectl start avvierà Apache. Il comando: apachectl restart riavvierà il Web server e: apachectl stop provvederà ad arrestarlo. Per quanto riguarda le medesime operazioni in ambiente Windows, non sarà necessario inoltrarci in descrizioni approfondite, ci limiteremo ad indicare le semplicissime procedure per l'avvio, il riavvio e l'arresto di Apache che il lettore potrà eseguire con pochi click del mouse: Start / Programmi / Apache HTTP Server / Control Apache Server / Start Start / Programmi / Apache HTTP Server / Control Apache Server / Restart Start / Programmi / Apache HTTP Server / Control Apache Server / Stop httpd.conf: il cuore di Apache

5 I comportamenti e le funzionalità di Apache vengono stabilite da un file di configurazione chiamato httpd.conf modificabile attraverso un semplice editor di testo come Vim o Gedit per Linux e NotePad per Windows. Se non ricordate la directory in cui avete installato Apache in Linux, generalmente: /usr/local/apache/conf/ potrete facilmente accedere al percorso del file di configurazione digitando da Shell la riga di comando: locate httpd.conf Per quanto riguarda Windows, la directory di default è in genere: C:\Programmi\Apache Group\Apache\conf In alternativa basterà un semplice: Start / Trova / File e Cartelle / httpd.conf Editando httpd.conf troverete una lunga serie di istruzioni; alcune righe saranno precedute dal simbolo del cancelletto "#", ciò significa che sono state "commentate" e le istruzioni che contengono non avranno influenza sul funzionamento di Apache; in molti casi si tratta di semplici indicazioni riguardanti le diverse tipologie di configurazione. Le righe non precedute da "#" sono invece vere e proprie istruzioni di configurazione abilitate; prendiamo per esempio le righe: #AddModule mod_rewrite.c AddModule mod_access.c Il cancelletto davanti ad "AddModule mod_rewrite.c" indica che questo modulo non è abilitato e non lo sarà fino a quando questa riga non verrà "decommentata" eliminando il "#"; al contrario "AddModule mod_access.c" indica un modulo abilitato che potrà essere disabilitato inserendo il cancelletto a inizio riga. Come potrete notare httpd.conf è un file lungo e ricco di opzioni, non sarà possibile descriverle tutte in un unico capitolo, dedicheremo quindi i prossimi due a sottolineare nel miglior modo possibile le sue funzionalità principali. Configurare Apache: httpd.conf - 1a parte La prima sezione del file httpd.conf, ("Section 1"), è dedicata all'ambiente in cui opera Apache ("Global Environment"). All'interno di essa troviamo alcune istruzioni fondamentali come il ServerType, attraverso cui viene indicata la modalità di funzionamento di Apache; nel nostro caso quest'ultima sarà: ServerType standalone, che consente di mantenere il Web server sempre attivo limitando i tempi di latenza. In pratica la modalità standalone permette ad Apache di lavorare come servizio in background ("demone") rispondendo autonomamente agli input provenienti dai client. Abbiamo poi la ServerRoot, che stabilisce la directory in cui si trovano i file di configurazione e gli altri file necessari per il funzionamento di Apache. Di seguito troviamo il PidFile, il cui percorso su Linux è in genere: /var/run/httpd.pid mentre in Windows sarà di solito in: logs/httpd.pid httpd.pid è in pratica il file in cui Apache scrive i processi in atto al momento del suo avvio. Continuando a scorrere la Section 1, troveremo altre due opzioni: ResourceConfig e AccessConfig, rispettivamente correlate ai file "srm.conf" e "access.conf". Questi ultimi dovrebbero essere letti dal Web server una volta terminata la lettura di httpd.conf; in realtà nelle ultime versioni tali istruzioni sono ormai obsolete e le funzioni dei due file sono state incorporate da httpd.conf. Ne consegue che le opzioni ResourceConfig e AccessConfig appariranno commentate in Windows e settate su "/dev/null" in Linux. Andando oltre visualizzeremo l'istruzione Timeout dalla funzione abbastanza intuitiva: quando il tempo di attesa per la soddisfazione dell'input inviato da un client supera il valore impostato espresso in secondi, allora viene inviato un messaggio d'errore. Di default il time out scatta dopo 300 secondi, ma può essere modificato a piacere soprattutto per limitare i problemi generati dal "traffico" sul proprio server Web. Dopo Timeout abbiamo l'istruzione KeepAlive che può essere completata tramite le opzioni "On" ed "Off". Se settata

6 in "On", KeepAlive permetterà di inviare più file attraverso una stessa connessione TCP. In caso contrario (sconsigliato), "Off" aprirà una nuova connessione ad ogni richiesta. A KeepAlive segue l'istruzione MaxKeepAliveRequests, grazie alla quale potremo indicare un valore (di default 100) corrispondente alla quantità di richieste possibili per singola connessione TCP. KeepAliveTimeout, di default impostato a 15, esprime in secondi il tempo che il Web Server dovrà aspettare per accogliere un'ulteriore richiesta prima che la connessione venga chiusa. Sottolineiamo poi MaxRequestsPerChild: se httpd, il processo principale di Apache, è "padre", allora i suoi processi secondari saranno "figli". Grazie a questo parametro è possibile settare la quantità di richieste gestibili da ciascun processo subordinato; se indichiamo "0" (infinito), ogni processo figlio avrà la possibilità di gestire illimitate richieste. Consigliamo in ogni caso di specificare comunque un valore (anche in miliardi) in modo da evitare eccessivi sovraccarichi. Segnaliamo infine il supporto per i DSO (Dynamic Shared Object). Questa voce si divide in due parti: "LoadModule" e "AddModule". Osservando queste istruzioni troveremo una serie di righe, molte delle quali commentate, che permettono di abilitare o disabilitare alcuni "moduli" o funzionalità addizionali. Quando viene decommentata, aggiunta o commentata una voce in "LoadModule" è necessario operare nello stesso modo sull'"addmodule" corrispondente. Se per esempio decidiamo di installare PHP 5 come modulo aggiuntivo di Apache, per rendere operativa questa modifica dovremo aggiungere in corrispondenza dei "LoadModule" la riga non commentata LoadModule php5_module "PATH/php/php5apache.dll" e, in corrispondenza degli "AddModule", dovremo fare lo stesso scrivendo AddModule mod_php5.c Configurare Apache: httpd.conf - 2a parte Passiamo ora all'analisi delle istruzioni più importanti riportate nella "Section 2" del file di configurazione di Apache httpd.conf; come vedremo, questa sezione contiene voci correlate alla configurazione del Web server ("'Main' server configuration"). Innanzitutto troviamo il riferimento alla porta di "ascolto" dei processi di Apache, di default la Port 80. Come abbiamo già avuto modo di sottolineare, è possibile modificare il numero di questa porta TCP rimanendo nell'ambito delle prime 1024 porte. Se per esempio nel nostro computer è installato un altro Web server che attende le richieste sulla porta 80, come IIS della Microsoft, potremo modificare quella di default di Apache in 81. Andando oltre, troveremo altre opzioni sulle quali è possibile intervenire. Tra queste abbiamo l'indirizzo di posta del ServerAdmin che, se ciò non è già stato fatto in installazione, può essere modificato inserendo la nostra mail personale o di lavoro. Il ServerName, cioè il nome della nostra macchina server, varia a seconda del dominio di appartenenza; se lavoriamo in locale e al di fuori di una rete potremo lasciare senza problemi la consueta dicitura "localhost". La DocumentRoot, stà ha indicare il percorso che porta alla cartella in cui sono contenute le pagine del nostro sito Web. Questo parametro può essere variato a seconda delle nostre esigenze; generalmente avremo in Linux qualcosa come: "/var/www/html" mentre in Windows troveremo: "C:/Programmi/Apache Group/Apache/htdocs" Leggeremo poi una serie di voci di questo tipo: <Directory "PATH_per_la_ROOT"> Options Indexes FollowSymLinks Includes AllowOverride All Order allow,deny Allow from all </Directory>

7 in esse viene impostata una directory recante direttive (container) per la configurazione del server. Delle direttive parleremo più approfonditamente tra poco. Andando avanti troveremo: <IfModule mod_mime.c> TypesConfig /PATH/mime.types </IfModule> Un'istruzione, quella appena proposta, con la quale viene indicato che, nel caso (if) in cui sia abilitato il "modulo per i MIME" ("mod_mime"), dovrà essere caricato il file/elenco con la lista dei MIME file type ("mime.types"). Ora passiamo a DefaultType, solitamente predefinito come "text/plain", che stabilisce la tipologia di file forniti da Apache. Un'altra istruzione importante è ErrorLog, per la quale viene stabilito il percorso che dovrà portare ai "log" in cui verranno scritti gli errori conseguenti alle richieste non soddisfatte ("error_log"). Ad ErrorLog si accompagna un'opzione relativa al livello di debugging generalmente settata in "warn", un valore medio in una scala crescente che conta: "debug", "info", "notice", "warn", "error", "crit", "alert", "emerg". Sono poi degni di nota i riferimenti alla direttiva Alias e al relativo "modulo"; di questa direttiva parleremo più avanti, per ora specificheremo il fatto che grazie a queste istruzioni è possibile definire un alias (URL "traslata") per una cartella destinata ad ospitare script CGI posizionata esternamente rispetto alla DocumentRoot e quindi non accessibile dal web. Andando oltre troveremo alcune delle istruzioni più note dei Web Server, gli ErrorDocument 500, 404 e 403. L'errore 500, conosciuto anche come "Internal server error" viene notificato nel caso in cui una condizione inaspettata (un errore interno al programma che gestisce il servizio) impedisca al server di soddisfare una richiesta del client. L'errore 404, il notissimo "File Not Found", viene notificato quando il Web server non trova l'informazione richiesta. Le cause di questa notifica sono in genere due: un errore nella sintassi dell'url o l'inesistenza della risorsa desiderata all'interno del percorso indicato. L'errore 403, conosciuto anche come "accesso negato" ("Unauthorized user"), si verifica quando l'utente prova ad accedere ad una pagina "protetta" senza averne l'autorizzazione. I messaggi di notifica degli ErrorDocument sono personalizzabili e possono consistere in un'informazione da inviare al client: ErrorDocument 500 "The server made a boo boo O in una pagina da visualizzare in alternativa a quella richiesta: ErrorDocument 404 /missing.html Terminiamo il nostro discorso riguardante le impostazioni di httpd.conf segnalando l'istruzione relativa al "mod_setenvif": <IfModule mod_setenvif.c> BrowserMatch "Mozilla/2" nokeepalive BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0 BrowserMatch "RealPlayer 4\.0" force-response-1.0 rowsermatch "Java/1\.0" force-response-1.0 BrowserMatch "JDK/1\.0" force-response-1.0 </IfModule> In essa vengono settate differenti opzioni per le risposte da inviare alle particolari richieste che possono pervenire da specifiche tipologie di browser. Agire sulle risorse: direttive di Apache Alla base del funzionamento di Apache abbiamo le direttive, note anche come container. I container raggruppano risorse e informazioni con direttive di configurazione comuni; in pratica, i file e le cartelle di uno stesso gruppo rispondono alle medesime regole. Per isolare un gruppo dagli altri e rendere valide soltanto per esso determinate direttive basterà utilizzare una sintassi simile a quella HTML: <Directory /PATH/file o cartella> istruzione istruzione.

8 </Directory> Abbiamo visto un esempio di container nel capitolo precedente: <Directory "PATH_per_la_ROOT"> Options Indexes FollowSymLinks Includes AllowOverride All Order allow,deny Allow from all </Directory> Come si avrà modo di osservare, le direttive vengono imposte attraverso semplici parole inglesi come Allow (permetti) o deny (nega). All'interno di httpd.conf, troveremo sovente alcune indicazioni che costituiscono la sintassi base delle direttive. Innanzitutto osserviamo i "tags" minore "<" e "maggiore" ">" con i quali viene delimitata la directory per cui le direttive avranno valore. Per ogni directory viene indicato il relativo percorso e le direttive influiranno sia sulla cartella principale che sul suo contenuto in termini di file e sotto cartelle. Grazie all'uso delle "espressioni regolari", è possibile indicare le cosiddette DirectoryMatch in modo da imporre determinate direttive soltanto ad alcune cartelle, come ad esempio quelle che cominciano con una determinata lettera dell'alfabeto. Oltre a <Directory..></Directory> e DirectoryMatch, avremo la possibilità di impostare direttive anche attraverso Files e FilesMatch, magari utilizzando il comodo carattere jolly "*" (tutto); se per esempio scriviamo: Files *.ext la nostra direttiva avrà valore per tutti (*) i file dotati di una determinata estensione indipendentemente dal loro nome. Location e LocationMatch funzionano similmente alle istruzioni precedenti, ma non si riferiscono a dei percorsi interni al server, bensì a delle URL specifiche. In httpd.conf troviamo per esempio questa direttiva: <pre><location /server-status> SetHandler server-status Order deny,allow Deny from all Allow from NOME_DOMINIO </Location> Che autorizza la ricezione dei "reports" del server all'indirizzo " Abbiamo poi VirtualHost utilizzato per le istruzioni relative alla gestione dei "domini virtuali" con più siti internet di cui parleremo a breve; per ora basti sapere che tramite VirtualHost è possibile settare diverse DocumentRoot, indirizzi di posta elettronica dell'administrator, percorsi verso i file di "log" e molto altro. Infine, è possibile utilizzare le istruzioni Limit e LimitExcept per differenziare i criteri di accesso a file e cartelle; se Limit stà appunto per "poni un limite a", LimitExcept svolge una funzione più specifica, significa infatti "poni un limite a tutti i metodi di accesso tranne che a quello indicato". Raramente queste due istruzioni sono espresse da sole e più frequentemente sono parte integrante di una direttiva principale. Prendendo spunto da httpd.conf, proponiamo un esempio che riguarda il controllo degli accessi alle directory dello User: <Directory "PATH"> AllowOverride FileInfo AuthConfig Limit Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec <Limit GET POST OPTIONS PROPFIND> Order allow,denyallow from all </Limit> <LimitExcept GET POST OPTIONS PROPFIND> Order deny,allow Deny from all </LimitExcept> </Directory> Gestione dinamica e metodi di controllo

9 Come abbiamo avuto modo di osservare, Apache risponde a decine di direttive che stabiliscono i diversi comportamenti del Web server. Dato che sarebbe abbastanza scomodo dove indicare una particolare direttiva e modificare il file di configurazione ogni volta che si presentano determinate fattispecie, caso che per esempio si verifica per l'introduzione di un nuovo "modulo", httpd.conf possiede alcune istruzioni grazie alle quali è in grado di gestire dinamicamente diverse situazioni a seconda dei casi e delle necessità. Riguardiamo un esempio già visto in precedenza: <IfModule mod_setenvif.c> BrowserMatch "Mozilla/2" nokeepalive BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0 BrowserMatch "RealPlayer 4\.0" force-response-1.0 rowsermatch "Java/1\.0" force-response-1.0 BrowserMatch "JDK/1\.0" force-response-1.0 </IfModule> Grazie al "mod_setenvif.c" è possibile stabilire le differenti risposte da inviare alle richieste che possono provenire da specifiche tipologie di browser. Alla base di tutto abbiamo il costrutto di controllo IfModule che permette di dar luogo alle istruzioni indicate nella direttiva sole se (if) il "modulo" è presente ed abilitato; in caso contrario non avremo la necessità di intervenire su httpd.conf in quanto questa possibilità è già prevista da IfModule. Oltre ad IfModule, abbiamo IfDefine che per quanto riguarda la sua funzione non si differenzia molto dal primo ma entra in gioco soltanto in casi specifici come per esempio test del Web server e debugging; quando il sistema è in queste fasi, IfDefine consente l'esecuzione di determinate direttive che ne rendono più semplice l'esecuzione. Se IfModule e IfDefine gestiscono risorse interne, Include permette di richiamare file di configurazione esterni alla DocumentRoot anche se questi sono indicati all'interno di direttive che richiamano risorse ad essa interne; in Linux per esempio abbiamo: Include /etc/httpd/conf.d un istruzione che richiama all'interno di una direttiva le risorse relative al percorso specificato. Per quanto riguarda i metodi di controllo, Apache viene regolato in particolare da due istruzioni chiamate Options e Overrides. La prima direttiva, Options, configura i rapporti tra il Web server e il sistema in cui esso è installato. Avremo quindi nove reazioni diverse (opzioni) di Apache a seconda degli stimoli provenienti dal File System: 1. All: è una "Global Option", ciò vuol dire che viene settata di default; essa ha la funzione di abilitare l'esecuzione delle funzionalità a cui è riferita. 2. None: è anch'essa una "Global Option", disabilita l'esecuzione delle funzionalità a cui è riferita; può comunque essere modificata accertandosi prima che gli interventi da effettuare non pregiudichino la sicurezza del sistema. 3. FollowSymLinks: abilita i percorsi indicati dai "link simbolici" che richiamano PATH realmente esistenti nel server. 4. SymLinksIfOwnerMatch: svolge la stessa funzione di FollowSymLinks ma solo se il proprietario coincide 5. Includes: rende possibile l'esecuzione di scripts lato server. 6. IncludesNOEXEC: svolge la stessa funzione di Includes ma impedisce l'esecuzione di comandi locali. 7. MultiViews: permette la "Content Negotiation"; contrariamente a quanto viene spesso detto riguardo a MultiViews, essa non elimina le estensioni dei file, più semplicemente crea molteplici rappresentazioni di una stessa risorsa web, si pensi per esempio ai siti internet "multilingua". Soltanto nel caso di MultiViews le "Global Option" All e None non sono settate di default. 8. Indexes: nel caso in cui non esista una pagina "index" (pagina d'"ingresso" del sito internet), permetterà di visualizzare l'elenco delle risorse interne alla directory indicata. 9. ExecCGI: permette l'esecuzione dei CGI ed è necessaria per qualsiasi eseguibile. Per quanto riguarda Overrides, dobbiamo sottolineare la funzione svolta dalla direttiva AllowOverride con la quale si definiscono le funzionalità che non verranno abilitate o limitate dai noti file ".htaccess"; questi ultimi sono dei file che opzionalmente possono essere usati per definire delle configurazioni specifiche riferite alle directory in cui vengono creati. Nel caso di AllowOverride, abbiano a disposizione sette opzioni per la configurazione:

10 1. All: autorizza il non rispetto delle direttive. 2. None: impedisce il non rispetto delle direttive. 3. AuthConfig: consente l'impiego di direttive di autorizzazione. 4. FileInfo: consente l'impiego di direttive per il controllo delle tipologie di documenti. 5. Indexes: consente l'impiego di direttive per il controllo della visualizzazione dell'elenco delle directory. 6. Limit: consente l'impiego di direttive per il controllo degli accessi. 7. Options: consente l'impiego della direttiva Options Per chiarire le idee proponiamo un piccolo esempio: <Directory /PATH/html> Options Indexes AllowOverride All </Directory> Come è facile osservare, il codice appena proposto rende possibile visualizzare l'elenco dei contenuti interni alla DocumentRoot, ed è inoltre consentito ignorare le direttive espresse tramite un file ".htaccess". In ogni caso, per questioni di sicurezza o di ottimizzazione del sistema sarà sempre possibile disabilitare gli ".htaccess" tramite il metodo AllowOverride utilizzando un semplice script da inserire in httpd.conf: <Directory /> AllowOverride None </Directory> questo script avrà efficacia per tutte le directory a parte quelle in cui saremo noi ad autorizzare l'override. Autenticazione in Apache Le direttive del Web server Apache possono tornarci utili per stabilire metodi di autorizzazione per l'accesso alla DocumentRoot utilizzando la classica procedura basata su un nome utente (user name) e su una parola chiave (password). Sarà possibile cifrare i dati di accesso inserendoli in un apposito file chiamato htpasswd con l'unica condizione che il nome utente e la parola chiave siano differenti da quelli già indicati per l'accesso al sistema in cui Apache è stato installato. Oltre ai dati di accesso, è possibile stabilire dei gruppi, ognuno facente capo ad un unico nome; la metodologia "per gruppi" permetterà di stabilire regole d'accesso valide per tutti gli utenti appartenenti ad essi. Otterremo questo risultato semplicemente agendo sulla direttiva AuthName a cui passeremo come parametro il nome necessario all'autorizzazione. Tramite AuthName, è possibile descrivere all'utente il tipo di autorizzazione richiesta in modo che egli sia sempre in grado di utilizzare la procedura corretta a seconda dei casi. Un'altra direttiva fondamentale è AuthType, riferita alla tipologia di autenticazione; in ogni caso per Apache quest'ultima dovrà essere settata come Basic o come Digest. Nel caso di Basic, l'autenticazione consisterà in un semplice invio dei dati inseriti dall'utente, con Digest, invece, nome utente e password verranno criptati utilizzando il sistema di codifica MD5; quest'ultimo metodo, in linea teorica preferibile, è purtroppo al momento non ben supportato. Ad AuthType segue AuthUserFile, una direttiva a cui dovremo far passare come parametro il percorso in cui si trova il file che contiene i dati necessari per l'autenticazione. Abbiamo poi AuthGroupFile, una direttiva che può essere inserita a discrezione dell'amministratore del Web Server nel caso in cui egli desideri fornire ad Apache una lista di utenti appartenenti ad uno stesso gruppo per i quali valgono le medesime regole di autenticazione. Se intendiamo impostare AuthGroupFile, sarà sufficiente passare come parametro a questa direttiva il percorso completo che porta al file contenente l'elenco degli appartenenti al gruppo. Possiamo poi specificare tre ulteriori direttive: require user, require group e require valid-user. Nel caso di require user è necessario indicare quali utenti sono autorizzati all'accesso; nel caso di require group è necessario indicare quali gruppi di utenti sono autorizzati all'accesso; infine, nel caso di require valid-user tutti vengono autorizzati all'accesso. Alla luce di ciò che abbiamo appena detto, possiamo fare un esempio completo di container per le direttive di autorizzazione: <Directory /PATH/area_riservata>

11 AllowOverride None Options Indexes AuthName Area Riservata AuthType Basic AuthUserFile /PATH/httpd/conf/.htpasswd AuthGroupFile /PATH/httpd/conf/.htgroup require user Amministratore </Directory> I filtri di Apache Apache ha la possibilità di filtrare le richieste provenienti dai client e di soddisfare soltanto quelle trasmesse da utenti eventualmente autorizzati alla fruizione delle risorse contenute nel server Web. L'opera di filtraggio viene eseguita attraverso differenti procedure basate su particolari fasi di controllo; in generale vi sono due modi attraverso i quali il Web server autorizza o meno la soddisfazione delle richieste: nel primo caso, tramite il modulo "mod_access", confronta l'indirizzo IP del client in attesa di risposta con l'elenco di quelli che hanno l'autorizzazione all'accesso; nel secondo caso, Apache non permetterà la soddisfazione della richiesta fino a quando il client non sarà in grado di autenticarsi tramite la comunicazione di un nome_utente e di una parola_chiave validi per il dominio di riferimento. I comportamenti di "mod_access" possono essere configurati sulla base delle intenzioni dell'amministratore indicando i dati necessari all'autenticazione come l'indirizzo IP e il nome di Host; si hanno poi tre direttive dal significato abbastanza intuitivo che regolano le impostazioni di questo modulo: 1. Allow: autorizza la soddisfazione delle richieste se il client rispetta i criteri prestabiliti per l'accesso alle risorse. 2. Deny: ha funzione contraria rispetto ad allow e 3. Order: rappresenta una direttiva complementare rispetto ad allow e deny, la sua funzione è quella di stabilire in che ordine queste due istruzioni dovranno essere osservate. A queste tre direttive basterà passare come parametro l'host da abilitare o disabilitare; nel seguente esempio: allow from lukeonweb.net viene autorizzato l'accesso all'host indicato. L'uso di Order risulta abbastanza semplice è và scelto di volta in volta a seconda delle esigenze; in questo esempio: order deny,allow deny from all allow from chasky.com la direttiva dany ha precedenza su allow ("order deny,allow") e nessun Host ha la possibilità di accedere ("deny from all") tranne quello autorizzato ("allow from chasky.com"). Il filtraggio degli accessi può essere operato anche specificando l'indirizzo o gli indirizzi IP che si desidera siano autorizzati ad accedere alle risorse: <Directory /> order deny,allow deny from all allow from </Directory> Nell'esempio appena proposto, abbiamo autorizzato unicamente l'ip corrispondente al "localhost", tutti gli altri IP non avranno la possibilità di veder soddisfatte le loro richieste. Creazione dell'index e gestione delle directory di Apache

12 Vi siete mai chiesti da cosa deriva il fatto che le HomePages della maggior parte dei siti internet siano rappresentate da file chiamati "index.html", "index.php", ecc.? Dietro a questa convenzione non ci sono motivazioni particolari se non la comodità dell'utente di non dover digitare per intero una URL completa del filename ma di ricorrere ad una scorciatoia. Dovendo accedere alla pagina: non sarà quindi necessario scrivere l'intera URL ma basterà digitare: del resto l'utente non è tenuto a sapere in che modo abbiamo chiamato la nostra Home e che estensione le abbiamo dato. Così, per consuetudine si è deciso di chiamare "index" le pagine d'ingresso dei siti internet e di notificare questo dato come predefinito al Web server in modo che la conversione dell'url (da abbreviata ad estesa) fosse automatica ed invisibile per l'utente. Gli "index", vengono impostati tramite la direttiva DirectoryIndex nel file httpd.conf seguendo una sintassi molto semplice che prevede la chiamata della direttiva seguita dal nome del file che dovrà svolgere le funzioni di "pagina di default" della DocumentRoot. Visualizzando il file di configurazione di Apache, troveremo sicuramente già impostate una lunga serie di possibili pagine "index" complete di estensioni: DirectoryIndex index.html index.shtml index.php Naturalmente, nulla ci vieta di impostare a piacere il nome della nostra Home intervenendo sull'apposita voce. Ad esempio potremmo decidere che la nostra pagina di default sia rappresentata dal file "pippo.html". In tal caso dovremo impostare come segue: DirectoryIndex pippo.html Quando nella DocumentRoot non è presente una pagina "index", può verificarsi il fenomeno del Directory listings, in questo caso infatti il Web server non trovando una pagina d'ingresso restituisce una lista delle risorse contenute all'interno della directory. Il Directory listings può essere voluto, come in quei siti che vengono messi in piedi semplicemente per consentire il download di determinati file tramite link; diversamente il Directory listings può essere involontario perchè il Webmaster non crea una pagina Home con uno dei nomi inseriti in httpd.conf, oppure, dimentica di passare il nome della propria pagina home come parametro a DirectoryIndex. Naturalmente non verrà prodotto alcun elenco se la necessaria direttiva non verrà abilitata. In caso di Directory listings involontario, il problema sarà facilmente risolvibile inserendo nella DocumentRoot un file (anche vuoto) recante un nome indicato in httpd.conf o aggiungendo un nome seguito da una estensione valida in corrispondenza di DirectoryIndex. Il Directory listings, produce quindi in all'alternativa all'homepage un semplice documento Html recante una lista dei file presenti nella DocumentRoot che saranno a cui si potrà accedere tramite link. Questo fenomeno è reso possibile da un modulo chiamato "mod_autoindex". La visualizzazione del "listing" è configurabile tramite alcune voci: HeaderName: consente di indicare il nome di un file da visualizzare automaticamente come "header" precedentemente alla lista delle risorse. IndexOptions: permette di impostare la visualizzazione dei contenuti, compresa la possibilità di nascondere particolari che non si vogliono rendere visibili. IndexIgnore: consente di non mostrare certi tipi di file interni alla directory. AddDescription: consente di descrivere determinati file. Addalt: associa il tag "alt" a determinati file. AddIcon: associa un'icona a determinati file. AddAltByType: consente di associare il tag "alt" a determinati file sulla base della loro tipologia. AddIconByType: consente di associare un'icona a determinati file sulla base della loro tipologia. AddAltByEncoding: consente di associare il tag "alt" a determinati file sulla base del "MIME Encoding". AddIconByEncoding: consente di associare un'icona a determinati file sulla base del "MIME Encoding". DefaultIcon: indica un'icona predefinita da mostrare quando non è stata associata alcuna icona ad un tipo di file.

13 Domini virtuali di Apache Con il nome "domini virtuali", o Virtual Hosts, si identificano tutti gli Hosts che vengono configurati in un server Web in aggiunta all'host originario. In pratica, con i "domini virtuali" avremo la possibilità di far operare separatamente più server in una stessa macchina, ognuno con un proprio dominio (" " Esistono due tipologie di Virtual Hosts: quelli che fanno capo a differenti indirizzi IP (IP Based Virtual hosts) e, quelli che vengono distinti sulla base del nome (host-based o non IP virtual hosts). In entrambi i casi, abbiamo la possibilità di far convivere più siti internet, ognuno con il proprio " su una stessa macchina. Per chi fa "Hosting", cioè coloro che per mestiere vendono porzioni di spazio Web destinate ad ospitare siti internet, la possibilità di creare Virtual Hosts rappresenta un indubbio vantaggio sia a livello operativo che economico. Se disponiamo di più indirizzi IP possiamo configurare dei "domini virtuali" IP Based. Dal punto di vista di Apache, questo tipo di configurazione può essere operata in due modi: utilizzare un unico processo http che faccia capo a tutti i domini, oppure, dedicarne uno per ognuno di essi; se disponiamo di una macchina abbastanza potente in termini di risorse, la seconda opzione è certamente preferibile, tutto dipende dal numero di domini che desideriamo siano presenti nel nostro computer Server. Se scegliamo di concedere ad ogni dominio un proprio httpd, dovremo modificare il file http.conf intervenendo sull'istruzione Listen ("ascolta"); ad essa vanno passati come parametri un indirizzo IP (o un nome di dominio) e il numero della porta che ogni httpd utilizzerà per mettersi in "ascolto" pronto a soddisfare le richieste provenienti dai client. Un esempio potrebbe essere questo: Listen :80 Listen :81 oppure Listen Listen Come avrete avuto modo di notare, ad ogni dominio viene dedicata una porta diversa. Se invece vogliamo configurare un solo httpd per tutti i "domini virtuali", dovremo indicare in httpd.conf per ogni dominio un container simile a questo: <VirtualHost ServerAdmin @nome_dominio.ext DocumentRoot /PATH/nome_cartella ServerName ErrorLog /PATH/error.log CustomLog /PATH/nome_access_log </VirtualHost> Niente di particolarmente complesso, dall'esempio si comprende facilmente che per costruire il container sono necessari: 1. La direttiva VirtualHost seguita dal nome del "dominio virtuale" che intendiamo porre in essere. 2. L'indirizzo dell'admin. 3. Il percorso completo verso la DocumentRoot del nuovo dominio. 4. Il nome del server (ServerName). 5. Il percorso in cui si trovano i file di "log" di Error 6. Il percorso in cui si trovano i "log" sul traffico delle risorse. Nel caso dei domini host-based, basati sul nome, il discorso è altrettanto semplice. Nel file httpd.conf dovremo indicare innanzitutto l'indirizzo IP come parametro all'istruzione NameVirtualHost, dopo di che costruiremo un container in cui dovremo indicare l'ip e il nome del ServerName: NameVirtualHost <VirtualHost > ServerName DocumentRoot /PATH/nome_cartella </VirtualHost>

14 <VirtualHost > ServerName DocumentRoot /PATH/nome_cartella </VirtualHost> Errori su Apache e la loro gestione L'errore più noto che può essere notificato da Apache è il 404, di cui abbiamo parlato in precedenza, il famoso "File not found". Alla base di questa notifica vi è una dinamica abbastanza semplice e conosciuta: 1. Il client vorrebbe accedere ad una risorsa è digita un'url o clicca su un link per comunicare la richiesta. 2. Il Web server non trova la risorsa desiderata nel percorso indicato, registra l'errore nei "log" e invia una notifica. 3. Il browser del client visualizza una pagina Html contenente la notifica dell'errore riscontrato. La maggior parte delle risposte di Apache a richieste che non possono essere soddisfatte sono configurabili, è sufficiente agire sulla direttiva ErrorDocument indicando la tipologia di errore ("numero", o "codice" di erore) e il messaggio che si desidera venga visualizzato dall'utente. In alternativa è possibile redirigere il browser del client su una pagina di notifica (tipo "error.html") in cui dare al navigatore maggiori informazioni, scusarsi del disagio arrecato o fornire consigli su come reperire ugualmente la risorsa cercata. Apache notifica principalmente due tipologie di errore: i 4XX, derivanti dalle richieste dei client e i 5XX dovuti alle risposte dei Web server. Tra i 4XX abbiamo: 400: la richiesta non viene recepita da Apache in quanto incomprensibile (ad es: un errore sintattico nella digitazione dell'url). 401: essendo necessaria un'autorizzazione per accedere alla risorsa richiesta, coloro che non la possiedono non potranno accedere ad essa. 402: la risorsa richiede un qualche forma di pagamento per poter essere accessibile. 403: Apache rifiuta di permettere l'accesso all'utente. 404: File Not Found 405: viene notificato un errore nel metodo con il quale viene effettuata la richiesta. 406: la risposta del server non è compatibile con la tipologia di richiesta. 407: la richiesta non può essere soddisfatta senza una previa autenticazione col proxy. 408: la richiesta del client si è fatta attendere oltre i tempi consentiti dalla Web Server ("Time Out"). 409: notifica dei conflitti tra richiesta e risposta desiderata. 410: risposta non disponibile, neanche tramite un redirect. 411: non sarà possibile una risposta fino alla definizione del "Content-Length" (lunghezza richiesta). 412: prerequisito necessario alla soddisfazione della richiesta fallito. 413: la richiesta richiede una risorsa più grande di quella che Apache è in grado di processare. 414: URL troppo lunga proveniente dalla richiesta. 415: il formato della richiesta non è supportato. Per quanto riguarda le notifiche 5XX, abbiamo invece appena sei voci: 500: errore interno al server, generalmente causato da un malfunzionamento del programma che mette a disposizione il servizio. 501: server non implementato per poter soddisfare la tipologia di richiesta. 502: il gatway o il proxy collegati al server inviano una risposta errata. 503: la richiesta inviata è temporaneamente inesaudibile. 504: il gatway o il proxy collegati al server inviano una risposta andando oltre il tempo concesso prima della notifica del "Time Out". 505: la versione del protocollo HTTP attraverso cui il client ha effettuato la richiesta non è supportata. Opzioni avanzate di Apache: alias e redirect

15 Riassumendo e semplificando al massimo ciò di cui abbiamo parlato nel capitolo iniziale di questa guida, possiamo dire che lo schema client >> server su cui si basa la Rete si configura come un continuo avvicendarsi di richieste e di risposte gestite dai Web server come Apache. Il client richiede un'informazione e il Web server, continuamente in "ascolto", si occupa di reperirla all'interno del computer server per poi inviarla al client. Abbiamo così descritto uno schema "ideale" basato sulla dinamica domanda/risposta. Questo schema, per essere sempre efficiente, deve poter prevedere e gestire le possibili eccezioni. Sempre all'inizio di questa guida, abbiamo detto che seguendo il protocollo HTTP le richieste vengono inviate al server tramite la digitazione di URL indicanti i percorsi che è necessario percorrere per accedere alle risorse richieste. Ma cosa accade quando non vi è completa corrispondenza tra posizione delle informazioni ospitate nel server e URL? Quali metodi vengono utilizzati per soddisfare comunque le richieste dei client? Se noi digitiamo l'url " o clicchiamo sul link corrispondente, potrebbe accadere che la risorsa che cerchiamo non si trovi più o non sia più interamente contenuta nel percorso indicato. Grazie ad alcune funzionalità (le ormai note direttive) di Apache sarà comunque possibile soddisfare la richiesta. Stiamo parlando dell'aliasing e del redirecting. L'aliasing, basato sulla direttiva alias, non è altro che un processo di translazione delle URL. Il percorso indicato dal client sarà valido anche per l'accesso ad informazioni allocate esternamente rispetto alla DocumentRoot. L'aliasing è un sistema vantaggioso sia per il client che vede la sua richiesta soddisfatta in modo trasparente, sia per la sicurezza del Web server che può gestire risorse al di fuori dello spazio accessibile dal Web rendendole quindi meno esposte ad intenzioni malevole. L'aliasing si ottiene passando alla direttiva alias sia l'url che verrà digitata dal client per la richiesta, sia il percorso reale che indica l'effettiva posizione delle risorse. Quindi se una determinata risorsa, ad esempio un'immagine, verrà richiesta tramite l'url e quest'ultima si trova invece in una posizione esterna alla DocumentRoot "PATH/img.gif", basterà passare entrambe le informazioni come parametri ad alias per ottenere il risultato desiderato. La direttiva redirect è gestita dallo stesso "modulo" di alias, "mod_alias", ma si comporta in modo differente. Con redirect, infatti, l'url digitato tramite il client non verrà traslato ma sostituito da uno nuovo. Questo fenomeno è molto noto presso i navigatori di Internet, spesso infatti capita di dirigerci verso una determinata pagina ed essere rediretti verso altri documenti. Per permettere il redirect, possiamo passare all'omonima direttiva tre parametri: 1. status: indica il messaggio inviato al client all'atto del redirect; può essere "temp", quindi temporaneo,"permanent", se definitivo o "gone" quando invece di un redirect si ha una situazione di irreperibilità della risorsa. 2. prefisso (prefix URL): punto di partenza necessario per dar vita al redirect. 3. URL di destinazione. Un esempio di redirect potrebbe essere questo: Redirect temp /nome_cartella