GNU/LINUX LAMP Linux Apache Mysql Php V1.1 del 18/02/2013 1/45
Copyright 2013 Dott.Ing. Ivan Ferrazzi Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. 2/45
Indice generale INTRODUZIONE AL WWW...5 Il World Wide Web (WWW)...5 Il protocollo HTTP (Hyper Text Transfer Protocol)...5 I metodi del protocollo HTTP...6 Gli header del protocollo HTTP...8 L'INSTALLAZIONE...11 Introduzione...11 Installazione di Apache2...12 Installazione di Php5...13 Installazione di MySql5...14 Test per verificare l'installazione...15 LA CONFIGURAZIONE...17 La struttura della cartella base...17 Sintassi e direttive del file di configurazione...18 Le direttive di configurazione generale...20 Le direttive di identificazione...21 Le direttive per il comportamento delle connessioni...21 Le direttive di limitazione...22 Le direttive per la configurazione dei processi...23 I moduli e la loro gestione...24 La sequenza di elaborazione delle direttive...25 Attivare/disattivare le opzioni...27 Diritti di accesso...29 Personalizzare i logfile...30 HOST VIRTUALI...32 Introduzione...32 Virtual Host su indirizzi IP...32 Virtual Host utilizzando i nomi di dominio...33 Cartelle protette da username e password...33 SECURE SOCKETS LAYER (SSL)...35 Introduzione...35 Chiave e certificato SSL...35 Configurazione del server...36 WEBALIZER...38 Introduzione...38 Configurazione di Webalizer...38 Webmail con Squirrelmail...40 Introduzione...40 Installazione...40 Configurazione di Squirrelmail...41 Modulo mod_rewrite...42 Introduzione...42 Configurazione del server...42 Le regole...43 Le opzioni...44 Le variabili...44 3/45
Le condizioni...45 4/45
INTRODUZIONE AL WWW Il World Wide Web (WWW) Il World Wide Web è il servizio presente su Internet per l'invio di pagine ipertestuali (con tutti i loro contenuti) da un computer che mette a disposizione il servizio (detto Webserver) ad un computer che ne richiede l'utilizzo (detto client). Per poter richiamare, e quindi visualizzare, il contenuto di pagine presenti nel World Wide Web abbiamo bisogno di un apposito programma chiamato Webbrowser, o semplicemente Browser. Per l'invio dei contenuti di queste pagine il WWW si basa sul protocollo HTTP (Hyper Text Transfer Protocol) che mette a disposizione uno standard non dipendente dal sistema operativo utilizzato. Questo garantisce la corretta visualizzazione del contenuto delle pagine indipendentemente dal sistema operativo installato sul nostro computer. Il protocollo HTTP (Hyper Text Transfer Protocol) Come precedentemente accennato il protocollo HTTP mette a disposizione delle direttive che permette il trasferimento (e la corretta visualizzazione) di pagine internet (pagine di ipertesto scritte con il linguaggio HTML) su un qualsiasi sistema operativo. La prima versione del protocollo è la 0.9, identificata all'interno delle richieste al server con la sigla HTTP/0.9. Questa versione era stata concepita per effettuare un semplice trasferimento di un file dal server al client. Alla fine del trasferimento del file la connessione veniva terminata. 5/45
Pagine internet, come le conosciamo oggi giorno, hanno come contenuto un numero molto alto di tanti piccoli file che devono essere scaricati per visualizzare la pagina correttamente. Basta pensare alle varie immagini utilizzate per la creazione dell'interfacciamento grafico con l'utente all'interno del Browser. Ben presto si dovette, quindi, cercare nuove soluzione. Si arrivò quindi alla versione 1.0, ossia HTTP/1.0, che aggiunse al protocollo precedente la possibilità di utilizzare degli standard di riconoscimento per i file da scaricare (MIME) e la possibilità di inviare solamente l'intestazione della pagina con relative informazioni. Il problema legato alla gestione dei Proxy e alle cache rese necessaria la standardizzazione della nuova versione 1.1, ossia HTTP/1.1. Le principali funzionalità della nuova versione sono: Persistent connections: La connessione non viene chiusa subito dopo il trasferimento del file, ma rimane aperta per permettere l'invio di eventuali altre richieste. Chunked transfers: Nelle versioni precedenti era indispensabile conoscere inizialmente la dimensione del file da trasmettere per ottimizzare il traffico sulla rete. Questo divenne problematico con l'invio di pagine dinamiche per le quali non era possibile definire la dimensione prima dell'elaborazione. Per questo motivo si passò alla possibilità di inviare una pagina mediante più pacchetti spezzati per evitare di tenere occupata la rete per troppo tempo. Byte ranges: Il file non deve più essere trasferito per intero, ma si può trasferire anche solo una parte del file. Con questo sistema è, infatti, possibile definire l'intervallo di byte (da qui il nome byte ranges) da trasferire. Questo permette di iniziare il trasferimento (precedentemente interrotto) di un file da dove si era interrotto. Hostname identification: Questo permette di inviare all'interno della richiesta al Webserver anche il nome del dominio che ci interessa. Il Webserver può quindi gestire più nomi di dominio (chiamati dominio virtuali) su un'unica interfaccia di rete con il medesimo indirizzo IP. Proxy support: Vengono messe a disposizione delle informazioni all'interno dell'intestazione che permettono ai sistemi proxy e cache di verificare l'attualità delle pagine memorizzate per sincronizzare eventuali aggiornamenti delle medesime. Content negotiation: Questo permette di gestire più versioni della medesima pagina o del medesimo documento. Il browser (oppure il cliente stesso) può mettere a disposizione una piuttosto che un'altra versione (ad esempio sui siti multilingua) della pagina richiesta. I metodi del protocollo HTTP Prima di iniziare a spiegare i metodi della versione HTTP/1.1 vediamo 6/45
l'utilizzo in base alla versione HTTP/1.0. Per effettuare una richiesta ad un webserver utilizziamo una URL (Uniform Resource Location) come la seguente: http://www.ferrazzi.info/index.html La URL in questione è composta da protocollo (http://), indirizzo di dominio (www.ferrazzi.info) e URI (/index.html) che sta per Uniform Resource Indicator. La prima operazione che viene eseguita dal browser quando confermiamo la richiesta alla specifica URL è la risoluzione dell'indirizzo di dominio mediante server DNS (Domain Name System), che ha il compito di restituire l'indirizzo IP del nome di dominio desiderato. Il browser tenta poi di effettuare la connessione al webserver inviando, a connessione stabilita, una riga di comando composta da METODO URI PROTOCOLLO spazi vuoti Possiamo provare ad effettuare una connessione ad un webserver utilizzando il programma telnet come segue: telnet www.ferrazzi.info 80 Il webserver risponderà con le seguenti righe: Trying 62.149.140.19... Connected to www.ferrazzi.info. Escape character is '^]'. A questo punto il webserver rimane in attesa della nostra richiesta. Possiamo quindi digitare HEAD /index.php HTTP/1.0 e confermare premendo due volte il tasto INVIO, per richiedere il trasferimento delle informazioni relative alla risorsa inserita. Il risultato sarà il seguente: Date: Mon, 12 Jan 2009 13:40:16 GMT Server: Apache/2.2 Connection: close Content-Type: text/html Connection closed by foreign host. Il metodo HTTP permette di definire il tipo di richiesta da effettuare al webserver. Il protocollo HTTP/1.0 mette a disposizione i seguenti metodi: HEAD: per ricevere informazioni relative alla pagina desiderata. 7/45
GET: per ricevere il contenuto della pagina desiderata. POST: per inviare informazioni (definite nel corpo della richiesta stessa) al server, come utilizzato per l'invio da pagine HTML mediante form. Per quanto riguarda il protocollo HTTP/1.1 la richiesta diventa un po' più complessa. Il nuovo protocollo mette a disposizione dei metodi in più e diventa indispensabile fornire al server informazioni aggiuntive sotto forma di intestazioni. I nuovi metodi che si aggiungono a quelli della versione precedente sono: PUT: per permettere al client di inviare file sul server. DELETE: per eliminare risorse dal server. OPTIONS: permette di determinare le opzioni di comunicazione da parte del client per determinare le capacità del server. CONNECT: per i proxy che possono essere trasformati in maniera dinamica in tunnel. TRACE: permette al client di effettuare un controllo delle informazioni ricevute sul server durante la transazione. Gli header del protocollo HTTP Per poter usufruire delle funzionalità aggiuntive del protocollo HTTP/1.1 è necessario l'invio di informazioni aggiuntive al webserver sotto forma di header. Gli header hanno la struttura nome header: valore header Gli header vengono raggruppati in quattro categorie: general, request, response e entity. La categoria general contiene gli header utilizzati sia per le richieste che le risposte. Fanno parte di questa categoria tutti gli header legati all'utilizzo della cache, delle date, oppure della modalità di utilizzo del protocollo stesso. I principali header di questa categoria sono: Connection: con la quale si chiude immediatamente (close) o si tiene aperta (keep-alive) una connessione. Date: per definire la data e l'ora di quando è stato generato il codice Cache-Control: per definire le modalità di utilizzo della cache delle pagine La categoria request contiene gli header utilizzati per le richieste al webserver. Questi vengono utilizzati per inviare informazioni relative al client che effettua la richiesta, come la lingua desiderata, la codifica delle pagine e i tipi di file accettati. Gli header principali di questa categoria 8/45
sono: Accept: per definire l'elenco dei tipi di documenti accettati dal client Accept-Encoding: per definire l'elenco delle codifiche utilizzate per i file compressi accettati dal client Accept-Language: per definire l'elenco delle lingue accettate dal client Host: per definire l'indirizzo internet con eventuale porta del webserver al quale si effettua la richiesta (obbligatorio per HTTP/1.1) If-Modified-Since: la pagina richiesta viene inviata solamente se è stata modificata dopo la data indicata, altrimenti viene inviata solamente una conferma Range: per definire la parte della pagina che si vuole ricevere (indicato come intervallo in byte) User-Agent: per definire il client (o meglio il browser del client) che ha generato la richiesta La categoria response contiene gli header utilizzati per le risposte. Questi header vengono utilizzati per inviare informazioni relative al webserver. Gli header principali sono: Age: stima da parte del server dell'età della transazione, ossia il tempo trascorso dalla creazione della risposta Location: per inviare al cliente un'eventuale posizione alternativa delle informazioni richieste Retry-After: per indicare dopo quanto tempo il client dovrà tentare una nuova richiesta (in caso di indisponibilità del servizio) Server: per inviare informazioni relative al software del server ETag: una sorta di identificatore ai fini di gestione cache La categoria entity contiene gli header utilizzati sia per le risposte che per le richieste. Questi vengono utilizzati per inviare informazioni relative all'entità in questione (ossia la pagina stessa), come la lingua della pagina, la codifica del testo, la lunghezza oppure il tipo di formato utilizzato. Gli header principali sono: Content-Encoding: indica il tipo di codifica utilizzata per file compressi Content-Language: indica le lingue supportate Content-Length: indica la lunghezza del file Content-Type: indica il formato del file Expires: indica il termine di validità della risposta (utilizzato per la gestione della cache) Last-Modified: indica la data dell'ultima modifica 9/45
A questo punto possiamo ripetere il precedente esempio utilizzando la versione di protocollo HTTP/1.1. Effettuiamo la connessione al webserver con il comando telnet e digitiamo la seguente riga HEAD /index.php HTTP/1.1 Host: www.ferrazzi.info Vediamo apparire sullo schermo le nuove informazioni relative al protocollo HTTP/1.1. Nella prima riga della risposta riusciamo ad identificare il codice 200 con la scritta OK che indicano l'esito positivo della richiesta. I codici che restituiscono lo stato della transazione si dividono in cinque categorie identificate dal primo numero del codice stesso: 1xx: codici informativi 2xx: codici di successo 3xx: codici di redirezione 4xx: codici per errore del client 5xx: codici per errori del server 10/45
L'INSTALLAZIONE Introduzione Apache2, Php5 e MySql5 rappresentano probabilmente le migliori alternative OpenSource nei rispettivi campi. Installati poi su una Debian, si ottiene un sistema decisamente stabile e adatto a qualsiasi applicazione, dal webserver professionale all'os da casa su cui testare i propri siti web. La versione 2.0 di Apache ha introdotto il sistema MPM (Multi-Processing Modules), che consiste nella modularizzazione del sistema fino alle funzionalità più elementari. Il vantaggio di questo sistema è la possibilità di ottimizzazione delle funzionalità del server in base all'utilizzo o al sistema operativo desiderato. A differenza dei moduli delle estensioni gli MPM vanno definiti alla compilazione di Apache. Dobbiamo quindi già inizialmente sapere per che cosa, e come dovrà funzionare il nostro webserver. I moduli MPM disponibili per Apache2.0 sono: prefork: realizza il modello classico di Apache1.3 basato sull'uso dei processi worker: nuovo modulo basato sui thread che permettono di ottimizzare le prestazioni perchild: per assegnare a utenti diversi vari processi del server threadpool: variante sperimentale del modulo worker leader: altra variante sperimentale del modulo worker mpm_winnt: modulo ottimizzato per WindowsNT 11/45
Se non specificato diversamente verrà utilizzato prefork, che realizza il modello classico di Apache1.3. In questa sezione del manuale vedremo quindi come installare il cosiddetto LAMP server su Debian. Come suggerisce l'acronimo LAMP (Linux Apache MySql Php), verrà descritta una procedura molto semplice per una perfetta installazione di Apache2, Php5 e MySql5. La configurazione di ogni singolo componente del LAMP server che andremo ad installare sulla vostra Debian, sarà quella minima richiesta per rendere il sistema perfettamente funzionante, lasciando quindi ogni personalizzazione alle particolari esigenze di ognuno di voi. N.B. Prima di partire con l'installazione, assicuratevi che la vostra linuxbox sia aggiornata e sistemate le repository ufficiali della vostra Debian. Installazione di Apache2 Installare Apache 2 con il supporto per Php su Debian è molto semplice. Loggatevi da terminal e digitate: apt-get install apache2 apache2-mpm-prefork Digitato questo comando, vi verrà chiesto di confermare l'operazione. Rispondete sì (Yes), ed installate tutte le dipendenze necessarie che vi verranno suggerite da apt. Completata l'installazione, il vostro webserver Apache sarà già perfettamente funzionante con le impostazioni di default, e pronto per ogni vostra personalizzazione. In questo momento non ci interessa vedere come configurare ogni singolo aspetto di Apache, i virtual hosts e tutto il resto, ma soltanto installare il sistema base. E' comunque utile indicare quali sono le cartelle e i files di configurazione principali di Apache. In particolare: /var/www/ è la root folder del vostro webserver, ossia la cartella in cui verranno inseriti tutti i vostri siti web e i files che li compongono; /etc/apache2/ è la cartella in cui troverete tutti i files di configurazione relativi ad Apache; /etc/apache2/mods-available/ è la cartella in cui vengono inseriti i files di configurazione di tutti i moduli installati; /etc/apache2/mods-enabled/ è la cartella che contiene dei link simbolici ad ogni file presente nella cartella /etc/apache2/modsavailable/. Ognuno di questi link simbolici, ha la facoltà di abilitare ognuno dei moduli presenti nella cartella mods-available; 12/45
/etc/apache2/sites-available/ è la cartella in cui inserire il file di configurazione per ogni virtual host che verrà creato. Di predefinito, è presente unicamente il file default; /etc/apache2/sites-enabled/ è la cartella che contiene dei link simbolici ad ogni file presente nella cartella /etc/apache2/sitesavailable/. Come si può facilmente dedurre da questa struttura, ognuno di questi link simbolici, ha la facoltà di abilitare ognuno dei virtual host definiti nella cartella sites-available. Fatte queste semplici precisazioni, potete già testare il funzionamento del vostro webserver, digitando nel vostro browser l'indirizzo di rete della macchina su cui avete installato Apache (es. http://192.168.xxx.xxx), oppure se siete in locale digitando http://localhost/ nel vostro browser. Se tutto funziona correttamente, visualizzerete la scritta It Works che vi confermerà l'avvenuta installazione di Apache sulla vostra Debian. A questo punto, osservando l'url nel vostro browser, potete subito notare che la "cartella" principale del webserver è apache2-default. Ciò è definito nel file default di cui si è parlato brevemente in precedenza. Dategli un'occhiata per prendere un pò di confidenza su come Apache2 gestisce la configurazioni. Per ora è sufficiente sapere che se nel browser viene visualizzata correttamente la scritta It Works, Apache2 è installato correttamente e potete proseguire. Installazione di Php5 Installato Apache, è ora il momento di installare Php 5 e alcune delle sue componenti fondamentali. Per fare ciò, da terminal digitate molto semplicemente: apt-get install php5 libapache2-mod-php5 php5-cgi php5-gd php5-cli Dopo aver completato l'installazione, troverete il file di configurazione php.ini di php5 in /etc/php5/apache2/: nano /etc/php5/apache2/php.ini Abilitate sin da subito il supporto per MySql e per le gd libraries decommentando queste due linee nella sezione Dynamic Extensions: ;extension=mysql.so ;extension=gd.so Togliete i punti e virgola davanti di modo che risultino così (se non dovessero essere presenti, aggiungetele senza problemi): 13/45
extension=mysql.so extension=gd.so Assicuratevi che il modulo per php5 sia abilitato utilizzando il programma a2enmod di apache che permette di verificare (o di attivare) moduli per apache: a2enmod php5 Ora riavviate la configurazione di Apache: /etc/init.d/apache2 reload Dopo questi piccoli accorgimenti, php5 è correttamente installato sulla vostra Debian, ma prima di testarne il funzionamento, sarà preferibile riavviare il sistema (poi non lo farete mai più) per rendere effettive le configurazioni fatte. Provvederemo a riavviare la macchina tra pochissimo, non appena verrà installato e configurato anche MySql5. Installazione di MySql5 Per installare il server MySql 5.0, digitate da terminal: apt-get install mysql-server-5.0 php5-mysql Completata l'installazione, ricordate che di default MySql viene installato senza password per l'utente root. Ovviamente questo non è un bene per la sicurezza del vostro sistema, ed è opportuno settare subito una password per l'utente root. Per fare ciò, entrate in MySql da linea di comando digitando: mysql -u root ed eseguite i "comandi" seguenti: DELETE FROM mysql.user WHERE User = ''; e FLUSH PRIVILEGES; per eliminare eventuali account anonimi da MySql. Infine, settate la password per l'utente root digitando: SET PASSWORD FOR 'root'@'localhost' = PASSWORD('tuapassword'); e 14/45
SET PASSWORD FOR 'root'@'hostname' = PASSWORD('tuapassword'); sostituendo ovviamente tuapassword, con la password che avete scelto e HOSTNAME con l'hostname della vostra Debian. Utile inoltre ricordare che sarà preferibile impostare un utente non-root per ogni altra operazione che richiederà l'interazione tra webserver e sqlserver. Per ogni altra particolare configurazione di cui necessitate, il file su cui operare è: /etc/mysql/my.cnf Come ultima cosa, se lo desiderate, installate anche phpmyadmin, molto ultile per amministrare via browser i vostri databases. Per installare phpmyadmin, da terminal digitate: apt-get install phpmyadmin Dopo l'installazione potete trovare l'intero sistema nella cartella /usr/share/phpmyadmin. Per renderlo attivo entrate nella cartella del vostro dominio, ad esempio direttamente in /var/www/ e create un link simbolico come segue ln -s /usr/share/phpmyadmin phpmyadmin Test per verificare l'installazione A questo punto, tutto il necessario per un corretto funzionamento del nostro LAMP Server su Debian è stato installato, e per sicurezza riavviate la vostra macchina (facoltativo). Digitate: shutdown -r now e una volta riavviato il sistema, effettuate il login e testiamo le installazioni e le configurazioni fatte. Per testare Apache2, come è stato detto anche in precedenza, digitate nel vostro browser l'indirizzo di rete della macchina su cui avete installato Apache (es. http://192.168.xxx.xxx), oppure se siete in locale digitando http://localhost/ nel vostro browser. Se tutto funziona correttamente, visualizzerete la scritta It Works che vi confermerà l'avvenuta installazione del vostro webserver Apache. Per testare php5, da terminal create un file che chiameremo test.php nella root folder del vostro webserver. Muovetevi quindi nella cartella principale di Apache digitando: cd /var/www/ create il file test.php digitando: 15/45
nano test.php e inserite quanto segue nel suddetto file: <?php phpinfo();?> Salvate, chiudete il file, e richiamatelo con il vostro browser (es. http://192.168.10.x/test.php oppure http://localhost/test.php). Fatto ciò, se l'installazione è avvenuta con successo, visualizzerete tutte le informazioni relative alla versione di php appena installata. Per testare MySql5 e phpmyadmin, il metodo più semplice è quello di utilizzare phpmyadmin per creare un database e confermare dunque il corretto funzionamento di entrambi. Per fare ciò, digitate nel vostro browser http://192.168.10.x/phpmyadmin oppure http://localhost/phpmyadmin. Vi troverete di fronte la schermata di login di phpmyadmin, inserite root come utente e la password che avete settato prima, ed effettuate il login. A questo punto create un database di prova chiamandolo come volete, e se tale operazione va a buon fine, anche MySql è stato correttamente installato. 16/45
LA CONFIGURAZIONE La struttura della cartella base La cartella base di configurazione per apache2 che viene creata dopo l'installazione è /etc/apache2. Qui troviamo le seguenti parti: apache2.conf Questo è il file di configurazione standard del sistema. Nei sistemi più datati troviamo il file httpd.conf. Qui è presente, ma solamente per questioni di compatibilità con i sistemi più vecchi. ports.conf Questo file contiene la configurazione delle porte da utilizzare per il sistema di webserver. mods-available Questa cartella contiene i moduli presenti all'interno del sistema di apache2. mods-enabled Questa cartella contiene un link ai moduli presenti in modsavailable per attivare i moduli da utilizzare con apache2. Questo permette di attivare o disattivare dei moduli senza doverli per forza eliminare dal sistema. sites-available Questa cartella contiene i file di configurazione per ogni sito che viene creato all'interno del nostro sistema web. sites-enabled Questa cartella permette di attivare i siti creando un link simbolico ai file presenti nella cartella sites-available. Questo permette di 17/45
spegnere momentaneamente dei siti senza doverli per forza eliminare dal sistema. Dopo ogni modifica a questi file è consigliabile mandare un segnale di HUP al processo di apache2. Questo si ottiene con il seguente comando apache2ctl reload Sintassi e direttive del file di configurazione Il file di configurazione di apache2 permette di definire due tipi di direttive, quelle semplici e i cosiddetti container. Le direttive semplici hanno la forma direttiva1 valore1 direttiva2 valore1 valore2 mentre i container hanno una forma simile ai tag del linguaggio HTML <NomeContainer argomento> direttiva1 valore1 direttiva2 valore1 valore2 </NomeContainer> Inoltre utilizziamo il # all'inizio delle righe per inserire eventuali commenti. Le direttive semplici possono essere suddivise nuovamente in tre categorie: locali, globali e locali e globali. Le direttive locali permettono di definire il comportamento del server stesso e non possono essere utilizzate all'interno dei container. Quelle globali vengono utilizzate solamente all'interno dei container, perché ne modificano il comportamento. Le direttive locali e globali permettono di modificare il comportamento del server se utilizzate localmente, definiscono invece il comportamento di una rispettiva direttiva container se specificate all'interno di essa. Per quanto riguarda i container le direttive standard che si possono utilizzare sono le seguenti: Directory: Per definire una cartella e le relative sottocartelle alle quali applicare le direttive di questo container. All'interno del nome della cartella possono essere utilizzati anche i caratteri jolly (filename globbing). DirectoryMatch: Questa è identica alla precedente, ma permette di definire il nome della cartella utilizzando le espressioni regolari (regular expression). 18/45
Files: Questa è simile a Directory solo che permette di indicare il nome di un file (o di un gruppo di file utilizzando i caratteri jolly) al quale verranno applicate le direttive. FilesMatch: Questa è identica alla precedente, ma permette di definire il nome del file utilizzando le espressioni regolari. Location: Questa è simile a Directory solo che permette di indicare la URL (o parte di essa) presente nella richiesta del client alla quale verranno applicate le direttive indicate. LocationMatch: Questa è identica alla precedente, ma permette di definire il nome del file utilizzando le espressioni regolari. VirtualHost: Questa viene utilizzata per definire un dominio virtuale (trattato in seguito). Limit: Questa permette di definire le restrizioni da utilizzare su determinati metodi HTTP come GET, PUT, POST, DELETE, ecc. LimitExcept: Questa permette di definire le restrizioni da utilizzare per tutti i metodi HTTP non elencati come argomento. Oltre ai container appena elencati che permettono di definire il lavoro continuo del nostro webserver abbiamo a disposizione anche delle direttive che vengono lette solamente all'avvio del server stesso. Il primo container in questione è IfModule che permette di verificare la presenza di un'eventuale modulo attivo e di reagire in tal caso con una adeguata configurazione alternativa. In caso di modulo inattivo l'avvio del webserver non restituirà degli errori. Questa direttiva viene utilizzata come segue: <IfModule mod_status.c> ExtendedStatus On </IfModule> Il secondo container in questione è IfDefine che permette di interagire con l'eventuale valore definito con il parametro -D passato al server da riga di comando. Passando al server il parametro -D DEBUG possiamo utilizzare nel file di configurazione: <IfDefine DEBUG> LogLevel debug </IfDefine> Questa direttiva può quindi essere utilizzata per definire comportamenti alternativi in caso di necessità. Infine abbiamo la direttiva Include che permette, con l'utilizzo di caratteri jolly, di definire i file di configurazione secondari da includere all'interno del file di configurazione principale, ad esempio Include /etc/apache2/mods-enabled/*.load 19/45
Include /etc/apache2/mods-enabled/*.conf Le direttive di configurazione generale Come accennato precedentemente abbiamo delle direttive locali che consentono di effettuare una configurazione a livello server. La configurazione base di un webserver comprende le direttive Listen indirizzo:porta Permette di identificare a quale indirizzo (nel caso in cui ci fossere più indirizzi IP disponibili) e su quale porta del relativo indirizzo rimanere in ascolto per eventuali richieste. Questa direttiva (nel caso di Debian) si trova nel file /etc/apache2/ports.conf incluso poi nel file di configurazione generale. User username Direttiva che permette di definire l'utente con il quale verranno effettuate le varie operazioni. Apache viene inizialmente inizializzato e fatto partire da root, ma tutte le operazioni successive verranno eseguite dall'utente definito all'interno di questa direttiva. Group groupname Analoga alla precedente, ma definisce il gruppo proprietario delle varie operazioni. ServerRoot directory Questa direttiva permette di definire la cartella di lavoro del server, ossia la cartella all'interno della quale si trovano tutti i file di configurazione. Nel caso di Debian per Apache2.0 la cartella di lavoro è /etc/apache2. Tutte i percorsi relativi (quindi quelli che non iniziano con / ) utilizzati all'interno del file di configurazione si relazionano in base a questa cartella. LockFile filename Questa direttiva permette di definire il nome del file (completo di percorso) utilizzato come file di lock del server. Debian utilizza il file /var/lock/apache2/apache.lock come definito dal Filesystem Hyrarchy Standard che stabilisce l'utilizzo della cartella /var/lock. PidFile filename Questa direttiva permette di definire il file all'interno del quale verrà memorizzato il PID del processo principale di Apache. Debian ha preimpostato nel file di configurazione il file /var/run/apache.pid. 20/45
Le direttive di identificazione Le seguenti direttive possono essere utilizzate sia a livello globale che all'interno dei domini virtuali di cui parleremo più avanti. Le direttive sono: ServerName domainname Questa direttiva permette di impostare il nome di dominio per il quale viene messo a disposizione il relativo servizio. Il nome di dominio è quello presente all'interno della URL di richiesta e inviato mediante header HTTP Host. Questa direttiva può trovarsi anche all'interno di un container VirtualHost e permette di identificare la giusta allocazione nonostante venga utilizzato sempre lo stesso indirizzo IP. ServerAdmin emailaddress Questa direttiva permette di impostare l'indirizzo email dell'amministratore responsabile. L'indirizzo verrà visualizzato all'interno delle varie pagine di errore del webserver. Anche questa direttiva può essere inserita all'interno di un container VirtualHost per differenziare i vari amministratori responsabili. Le direttive per il comportamento delle connessioni Le principali direttive che possono essere utilizzate per definire il comportamento delle connessioni del server sono le seguenti. KeepAlive On Off Questa direttiva permette di mantenere attive o meno le connessioni TCP con il server. Mantenere attiva la connessione può aumentare notevolmente le prestazioni, soprattutto per pagine che al loro interno hanno molte immagini. Questo è il motivo per il quale questa direttiva viene attivata di default. KeepAliveTimeout seconds Con questa direttiva si può definire il numero di secondi che il server mantiene intatta una connessione prima di chiuderla. Si consiglia di non utilizzare un numero troppo elevato perché potrebbe mantenere aperte delle connessioni inutilizzate per troppo tempo. Avremmo un notevole calo di prestazione in caso di traffico elevato. MaxKeepAliveRequests number Questa direttiva permette di definire il numero massimo di richieste che possono essere fatte all'interno di una connessione. E' consigliabile utilizzare un numero elevato (Debian utilizza 150). 21/45
TimeOut seconds Questa direttiva permette di definire il tempo di attesa del server, per il tempo che trascorre nella ricezione di richieste GET, per il tempo che trascorre tra la ricezione di pacchetti TCP nelle richieste PUT oppure POST e per il tempo che trascorre tra i pacchetti di conferma di ricezione TCP nelle risposte. Tutte queste direttive possono essere inserite, oltre che a livello globale, anche all'interno dei container VirtualHost. Le direttive di limitazione Le principali direttive sono: LimitRequestBody bytes Questa direttiva permette di definire il limitare massimo consentito della dimensione (espressa in byte) complessiva di una richiesta. Il valore default è pari a 0 che non pone limiti. LimitRequestFields number Questa direttiva permette di definire il limite massimo consentito di headers all'interno di una richiesta. 0 significa illimitato, mentre il default è pari a 100. LimitRequestFieldSize bytes Questa direttiva permette di definire il limite massimo in byte utilizzato per gli headers. Il default è pari a 8190. LimitRequestLine bytes Questa direttiva permette di definire il limite massimo in byte utilizzato per le richieste HTTP e quindi di filtrare richieste anomale con le quali si possono effettuare attacchi DOS (Denial Of Service). RLimitCPU seconds Questa direttiva permette di definire il limite massimo del tempo della CPU in secondi messo a disposizione per ogni processo creato da uno dei processi Apache nel soddisfare una richiesta. RLimitMEM bytes Questa direttiva permette di definire il limite massimo espresso in byte di memoria messa a disposizione per ogni processo creato da uno dei processi Apache nel soddisfare una richiesta. RLimitNPROC number Questa direttiva permette di definire il limite massimo dei processi creati da uno dei processi Apache nel soddisfare una richiesta. 22/45
Le direttive per la configurazione dei processi Il comportamento del MPM prefork di Apache2.0 viene appunto chiamato pre-forking, perché non crea i processi nel momento in cui vengono effettivamente utilizzati, ma li crea preventivamente in maniera tale da essere già pronti quando questi vengono richiesti. Visto che a livello di Apache2.0 l'utilizzo del MPM prefork è facoltativo possiamo incapsulare la relativa configurazione all'interno della direttiva IfModule per evitare la segnalazione di errori in caso contrario. Le principali direttive sono: MaxClients number Questa direttiva permette di definire il numero massimo di processi che possono essere in esecuzione contemporaneamente. Tutte le eventuali richieste aggiuntive che eccedono questo numero verranno messe in coda fino a quando uno dei processi non si libera. StartServers number Con questa direttiva si può definire il numero dei processi figli che Apache deve far partire all'avvio, che di default è pari a 5. Siccome il numero dei processi viene adattato dinamicamente in base alle esigenze di solito si lascia invariato. MinSpareServers number Questa direttiva permette di definire il numero minimo dei processi che devono rimanere attivi in attesa di connessione oltre a quelli attualmente utilizzati. Questo permette una immediata elaborazione di eventuali richieste in entrata senza dover attendere la creazione di nuovi processi. Il sistema crea immediatamente il numero dei processi necessari in caso di superamento del limite. Il valore di default di questa direttiva è pari a 5. MaxSpareServers number Questa direttiva permette di definire il numero massimo di processi che possono rimanere attivi in attesa di connessione oltre a quelli attualmente utilizzati. Nel caso in qui, dopo la chiusura di varie connessioni, fossero attivi più processi di quelli definiti all'interno di questa direttiva Apache provvederebbe a chiude quelli in eccesso. Il valore di default di questa direttiva è pari a 15. MaxRequestsPerChild number Questa direttiva permette di definire il numero di richieste che ogni processo deve elaborare. Raggiunto questo limite il processo verrà chiuso. Il valore di default di questa direttiva è 0 che significa un numero illimitato di richieste. 23/45
I moduli e la loro gestione Apache si basa su un sistema modulare. Questo vuol dire che è possibile aggiungere delle funzionalità (mediante dei moduli appunto) al server in fase di esecuzione. Non è quindi indispensabile la ricompilazione di Apache per aggiungere nuovi moduli, e quindi, nuove funzionalità al server. Con il comando apache2 -l è possibile visualizzare la lista dei moduli con i quali è stato compilato Apache2.0. La presenza di un modulo all'interno di questa lista non implica automaticamente la sua attivazione. Abbiamo la possibilità di utilizzare la direttiva AddModule con il nome del modulo (come riportato nella lista dei moduli con il comando apache2 -l) per attivarne le sue funzionalità. Ad esempio: AddModule mod_so.c Se vogliamo caricare dei moduli messi a disposizione come shared objects, e quindi non integrati in fase di compilazione, dobbiamo utilizzare la direttiva LoadModule seguito da un nome identificativo del modulo ed il file.so con la sua posizione assoluta. Nella prassi si utilizza mod_nome.c come nome del file sorgente, NOME_module come nome identificativo del modulo e mod_name.so per il nome del file codice. Esempio: LoadModule alias_module /usr/lib/apache2/modules/mod_alias.so Nella versione 2.0 di Apache le direttive per il caricamento dei moduli non si trovano direttamente all'interno del file di configurazione principale, ma come Include come segue: Include /etc/apache2/mods-enabled/*.load Include /etc/apache2/mods-enabled/*.conf I file *.load contengono la direttiva LoadModule ed i file *.conf la specifica configurazione del rispettivo modulo all'interno del container IfModule. I file contenuti all'interno della cartella /etc/apache2/mods-enabled/ non sono altro che dei link simbolici che puntano sui rispettivi file presenti all'interno della cartella /etc/apache2/mods-available/. Questo permette di evitare il caricamento di moduli specifici eliminando solamente il link simbolico lasciando invariata la posizione dei file originali. Per attivare un modulo all'interno di mod-enabled (quindi per creare i link simbolici necessari) possiamo utilizzare il comando a2enmod con il relativo nome del modulo senza estensione, ad esempio: 24/45
a2enmod ssl Dopodiché appariranno i relativi link simbolici all'interno della cartella mod-enabled. Per disattivarli possiamo utilizzare il comando a2dismod con il nome del modulo senza estensione. La sequenza di elaborazione delle direttive Abbiamo visto nelle sezioni precedenti che una delle possibilità che mette a disposizione Apache per gestire le risorse è quella di utilizzare dei container come Directory per la gestione di cartelle, Files per la gestione di singoli file, oppure Location per gestire le risorse in base al contenuto espresso nella URL. Le direttive sopra citate hanno lo svantaggio che non possono essere modificate da terze pari senza dare accesso al o ai file di configurazione del server. Per questo motivo troviamo all'interno di Apache un meccanismo che permette di decentralizzare la configurazione delle risorse. In questo caso utilizziamo un file (normalmente.htaccess) all'interno della cartella stessa che può contenere le direttive che influenzano le proprietà della cartella principale e di tutte quelle presenti in essa. Il nome del file da utilizzare viene indicato dalla direttiva AccessFileName che possiamo trovare sia come direttiva del server che come direttiva all'interno di un container. Dato che le direttive inserite nel file di accesso potrebbero, in alcuni casi, soprassedere la configurazione del server è consigliabile utilizzare questo meccanismo solamente se non diversamente possibile. L'utilizzo del file di accesso ha come conseguenza, oltre la scarsa sicurezza, anche un peggioramento delle prestazioni. Apache deve, infatti, effettuare il controllo della presenza del file di accesso all'interno della cartella in cui si trova la risorsa desiderata, e non solo. Vista la possibilità di eredità delle direttive dovrà, per ogni singola risorsa, effettuare lo stesso controllo anche nelle cartelle di livello superiore. Questo meccanismo viene quindi utilizzato solamente se vogliamo dare all'utente la possibilità di effettuare la configurazione delle proprie cartelle senza dover per forza ogni volta modificare la configurazione base. Data la possibilità di utilizzo contemporaneo sia di vari container che dei file di accesso.htaccess diventa vantaggioso conoscere la sequenza con la quale Apache legge le varie direttive presenti: Apache inizia con i container Directory definiti al di fuori dei container VirtualHost, che non fanno utilizzo di regular expressions iniziando dal percorso, assegnato come argomento, più breve. Allo stesso tempo vengono presi in considerazione i relativi file di 25/45
accesso (se così definito con la direttiva AllowOverride). Nel caso in cui ci fossero due o più container per lo stesso percorso verranno elaborati in base alla loro posizione all'interno del file principale di configurazione. Con gli stessi criteri precedentemente accennati passa poi ai container Directory che si trovano all'interno dei container VirtualHost. Poi prosegue con i container Directory ~ e DirectoryMatch, ossia quelli che utilizzano le regular expressions, presenti al di fuori dei container VirtualHost. Nel caso in cui ci fossero due o più container per lo stesso percorso verranno elaborati in base alla loro posizione all'interno del file principale di configurazione. Con gli stessi criteri del punto precedente passa poi ai container Directory ~ e DirectoryMatch all'interno dei container VirtualHost. Si arriva poi ai container File e FileMatch dove anche qui prevale la posizione all'interno del file di configurazione principale in caso di sovrapposizioni. Poi ai container File e FileMatch dei VirtualHost. E si conclude con i container Location. In caso di sovrapposizioni prevale la posizione all'interno del file di configurazione principale. Passando poi ai relativi container Location dei VirtualHost. Se durante l'elaborazione Apache trova le stesse direttive con valori diversi tiene l'ultimo valore assegnato. Data la sequenza di elaborazione precedente (prima le direttive al di fuori dei VirtualHost, poi quelle all'interno) prevalgono le direttive definite all'interno dei container VirtualHost. Vediamo il seguente esempio <Files /var/www/dominio/index.html> Direttiva5 </Files> <Location /pippo/pluto> Direttiva6 </Location> <VirtualHost *> <Directory /var/www/pippo/pluto> Direttiva3 </Directory> </VirtualHost> <DirectoryMatch "^www.*$"> Direttiva4 </DirectoryMatch> <Directory /var/www/pippo/pluto> Direttiva2 </Directory> <Directory /var/www/> Direttiva1 </Directory> Direttiva1 è la prima direttiva che viene presa in considerazione perché 26/45
presente all'interno del container Directory (al di fuori di un VirtualHost) e perché con il percorso (/var/www) più breve. Poi passa alla Direttiva2 perché sempre all'interno di un container Directory, ma con percorso (/var/www/pippo/pluto) più lungo. Ora tocca alla Direttiva3 perché l'unica all'interno del container VirtualHost. Arriviamo poi alla Direttiva4 perché all'interno di un container DirectoryMatch, alla Direttiva5 che è all'interno di un container Files ed infine alla Direttiva6 che si trova all'interno di un container Location. Attivare/disattivare le opzioni Con la direttiva Options possiamo attivare e/o disattivare determinate opzioni per modificare le funzionalità del nostro server. Se definita al di fuori di un container modifica le funzionalità dell'intero webserver; utilizzata all'interno di un container modifica solo le funzionalità delle risorse legate ad esso. Le opzioni definite all'interno di un container Directory verranno applicate a tutte le sottocartelle se non esplicitamente definito come nel seguente esempio: <Directory /var/www> Options MultiViews AllowOverride None </Directory> <Directory /var/www/pluto> Options Indexes FollowSymLinks AllowOverride None </Directory> In questo caso verrà attivata l'opzione MultiViews per la cartella /var/www, mentre per la cartella /var/www/pluto verranno attivate le opzioni Indexes e FollowSymLinks. Utilizzando la direttiva Options come nell'esempio attiviamo solamente le opzioni specificate all'interno della direttiva stessa, per questo motivo non viene ereditata l'opzione MultiViews. Per evitare che opzioni definite in livelli superiori vengano eliminate all'interno di altre direttive possiamo utilizzare i simboli + e/o -. Modifichiamo il precedente esempio come segue: <Directory /var/www> Options MultiViews AllowOverride None </Directory> <Directory /var/www/pluto> Options +Indexes +FollowSymLinks AllowOverride None </Directory> <Directory /var/www/pluto/pippo> Options -MultiViews AllowOverride None 27/45
</Directory> In questo caso abbiamo attivato l'opzione MultiViews per /var/www, le opzioni MultiViews, Indexes, FollowSymLinks per /var/www/pluto e le opzioni Indexes e FollowSymLinks per /var/www/pluto/pippo. Vediamo ora in dettaglio le varie opzioni che si possono utilizzare con la direttiva Options: Options All All è il valore di default che attiva tutte le opzioni, tranne MultiViews. Options ExecCGI Questa opzione permette l'esecuzione di script CGI mediante il modulo mod_cgi. Options FollowSymLinks In questo caso sarà possibile seguire percorsi definiti da link simbolici. Anche se seguiti i link simbolici il percorso a tale risorsa rimane invariato quando confrontato con l'argomento del container Directory. Questa opzione verrà ignorata se utilizzata all'interno di un container Location. Options Include Con questa opzione vengono permessi gli include lato server mediante modulo mod_include. Options IncludeNOEXEC Con questa opzione vengono permessi gli include tranne gli #exec cmd e gli #exec cgi. Rimane però la possibilità di includere script CGI virtuali dalle cartelle con la direttiva ScriptAliased. Options Indexes Se la URL fa riferimento ad una cartella priva della direttiva DirectoryIndex (es. index.html) il webserver restituirà una lista formattata del contenuto della cartella utilizzando il modulo mod_autoindex. Options MultiViews Questa opzione permette di costringere Apache a trovare file alternativi per risorse non definite in maniera precisa. Poniamo il seguente esempio: Attiviamo l'opzione MultiViews per il container Directory che ha come argomento la cartella /pluto/pippo. Al server Apache viene richiesto di restituire la risorsa identificata dal file /pluto/pippo/paperino che però non esiste. In questo caso Apache inizia ad utilizzare il modulo mod_negotiation che gli permette di estrarre tutti i file /pluto/pippo/paperino.* e di paragonarne le estensioni con un elenco di estensioni conosciute. 28/45
Mediante determinati criteri proporrà il file che più rispecchia il tipo di risorsa richiesta inizialmente. MultiViews può incidere anche sul comportamento della direttiva DirectoryIndex. Poniamo il seguente esempio: DirectoryIndex index Nel caso in cui arrivasse al server una richiesta priva di file questo inizierebbe a verificare la presenza di tutti i file index.* scegliendo il primo che più rispecchia il criterio di contenuto HTML. L'opzione MultiViews può essere utilizzata all'interno di un container Directory, File, Location, oppure, se AllowOverride lo permette, anche all'interno del file.htaccess. Options SymLinksIfOwnerMatch Il server segue i link simbolici solamente se l'id dell'utente proprietario corrisponde all'id dell'utente proprietario del link. Questa opzione viene ignorata all'interno del container Location. Diritti di accesso I diritti di accesso all'interno di un container Directory possono essere definiti mediante la direttiva Order con i criteri Allow e Deny. Questa direttiva è valida anche per le sottocartelle, a meno che non siano stati definiti altri diritti di accesso. Order Deny,Allow In questo caso vengono controllate prima le regole Deny, poi le regole Allow. Nel caso in cui non ci fosse una regola corrispondente alla pagina richiesta la pagina verrebbe visualizzata. Order Allow,Deny In questo caso vengono controllate prima le regole Allow, poi le regole Deny. Nel caso in cui non ci fosse una regola corrispondente alla pagina richiesta la pagine NON verrebbe visualizzata. Allow from [indirizzo ip hostname area di indirizzi all] Questa direttiva ci permette di definire chi ha il permesso di visualizzare le pagine interessate. Possiamo inserire un indirizzo ip (es. 1.2.3.4), un hostname (es. test.it), oppure un'area di indirizzo (es. 1.2 per gli indirizzi 1.2.*.*). La direttiva Allow from all permette a chiunque di avere accesso. Deny from [indirizzo ip hostname area di indirizzi all] Questa direttiva ci permette di definire chi NON ha il permesso di 29/45
visualizzare le pagine interessate. Possiamo inserire un indirizzo ip (es. 1.2.3.4), un hostname (es. test.it), oppure un'area di indirizzo (es. 1.2 per gli indirizzi 1.2.*.*). La direttiva Deny from all blocca l'accesso a chiunque cerchi di visualizzare le nostre pagine. Vediamo ora un esempio che permette di limitare la visualizzazione delle nostre pagine solamente all'interno della nostra rete (192.168.0.*) e all'interno del nostro dominio aziendale (es..test): <Directory /var/www> Order Allow,Deny Allow from 192.168.0 Allow from localhost Allow from.test </Directory> Nel caso in cui non ci fosse una corrispondenza tra le regole Allow from l'accesso verrebbe direttamente negato (Order Allow,Deny). Personalizzare i logfile Apache mette a disposizione delle direttive che permettono di personalizzare i formatti da utilizzare per la registrazione dei logfile contrassegnandoli con un nome identificativo. Possiamo creare vari formati ed utilizzarli poi a piacere all'interno di configurazioni di domini diversi. Le direttive che si possono utilizzare sono LogFormat stringa_formato nome_identificativo con questa direttiva possiamo definire con stringa_formato il formato da utilizzare e con nome_identificativo il nome da poter poi utilizzare all'interno della direttiva CustomLog. La stringa da utilizzare per il formato può comprendere una serie di codici di formato che identificano un determinato dato che si vuole visualizzare all'interno della registrazione. Nella seguente tabella vediamo i codici di formato che possiamo utilizzare: %% inserisce il simbolo % %a Indirizzo IP remoto %A Indirizzo IP locale %B Byte della risposta senza HTTP %b Byte della risposta senza HTTP (nel formato CLF) %{foobar}c Il contenuto del cookie foobar nelle richieste al server %D Il tempo necessario per la richiesta in microsecondi %{foobar}e Il contenuto della variabile d'ambiente foobar %f Il nome del file %h Il host remoto %H Il protocollo della richiesta 30/45
%{foobar}i Le righe foobar estratte dal header della richiesta %l Il logname da remoto se inviato (identd) %m Il metodo utilizzato per richiesta %{foobar}n Il contenuto della nota foobar all'interno di un altro modulo %{foobar}o foobar righe estratte dal header della risposta %p La porta canonica del servizio che ha elaborato la richiesta %P L'ID del processo figlio che ha elaborato la richiesta %{format}p L'ID del processo o thread figlio che ha elaborato la richiesta. Come format possiamo utilizzare pid oppure tid. %q La stringa utilizzata come query %r La prima riga della richiesta %s Lo stato della richiesta originale (%>s per visualizzare lo stato dell'ultima richiesta) %t Tempo necessario a ricevere la richiesta %{format}t Tempo necessario a ricevere la richiesta in base al formato format desiderato (vedi strftime(3)) %T Tempo necessario ad elaborare la richiesta in secondi %u User remoto restituito da auth %U L'URL della richiesta, senza eventuale stringa query %v Il nome canonico del server che ha elaborato la richiesta %V Il nome definito dall'eventuale direttiva UseCanonicalName %X Lo stato della connessione dopo aver completato la risposta: (X) connessione interrotta prima del completamento della risposta; (+) connessione potrebbe essere rimasta in vita dopo l'invio della risposta; (-) connessione viene chiusa dopo l'invio della risposta. %I Byte ricevuti, inclusi la richiesta ed gli header %O Byte inviati, inclusi gli header Vediamo ora un semplice esempio: LogFormat %h %l %u %t \ %r\ %>s %b personal CustomLog percorso_file nome_identificativo Questa direttiva la utilizziamo per definire il logfile ed il formato con il quale effettuare le registrazioni. CustomLog /var/www/dominio1 personal 31/45
HOST VIRTUALI Introduzione Un webserver potrà essere utilizzato per la presentazione via Internet di un solo sito. Questo però di solito non avviene. In pratica è più probabile dover configurare un server per la presentazione di diversi siti. Per questo motivo apache2 ci mette a disposizione il sistema dei virtual host, ossia host virtuali. Questo sistema permette di identificare un sito, e quindi il proprio contenuto, mediante l'indirizzo IP al quale viene effettuata la richiesta alla porta 80 o mediante il nome di dominio inviato all'interno degli header di richiesta direttamente dal browser dell'utente. Nel caso in cui si volessero gestire più di quattro siti sul nostro server è consigliabile utilizzare il NameVirtualHost, ossia la seconda possibilità. Virtual Host su indirizzi IP Nel caso in cui volessimo utilizzare indirizzi IP diversi la configurazione dei relativi file di configurazione da posizionare all'interno della cartella /etc/apache2/sites-available verrebbe effettuata come segue: <VirtualHost IP_server> ServerAdmin root@miodominio.it DocumentRoot /www1 </VirtualHost> Questa è la configurazione base dove IP_server è l'indirizzo IP della 32/45
scheda di rete da utilizzare per il sito presente all'interno della cartella /www1 sul filesystem del webserver. Ricordiamoci di creare il link simbolico all'interno della cartella /etc/apache2/sites-enabled/ verso il file di configurazione all'interno di /etc/apache2/sites-available/ appena creato. Mandiamo poi un segnale di HUP ad Apache per attivare le modifiche effettuate. Virtual Host utilizzando i nomi di dominio Nel caso in cui volessimo utilizzare i nomi di dominio trasferiti negli header direttamente dal browser dell'utente la configurazione dovrà essere la seguente.: NameVirtualHost IP_server <VirtualHost IP_server> ServerAdmin root@test1.com DocumentRoot /var/www/test1.com ServerName www.test1.com </VirtualHost> In questo caso diventa indispensabile l'utilizzo del parametro NameVirtualHost con il quale si definisce il gruppo di appartenenza di tutti i siti da riconoscere mediante nome di dominio definito con ServerName. Attenzione! Il parametro NameVirtualHost viene utilizzato solamente all'interno del primo file di configurazione caricato da apache2. Cartelle protette da username e password Per proteggere delle cartelle all'interno di un sito mediante nome utente e password bisogna, come prima cosa, creare il file che contiene i dati degli utenti che avranno i permessi. Il file viene creato utilizzando il comando htpasswd -c /etc/apache2/users.pwd user dove -c viene utilizzato per creare il nuovo file (quindi da utilizzare solamente con la creazione del primo utente) /etc/apache2/users.pwd e user identifica il nome dell'utente da creare. Questo file viene utilizzato all'interno del file di configurazione del sito quando si definisce la cartella protetta. <VirtualHost IP_server> ServerAdmin root@test1.com 33/45
DocumentRoot /var/test1.com ServerName www.test1.com <Directory /var/test1.com/private> AuthName Zona protetta AuthType Basic AuthUserFile /etc/apache2/users.pwd require valid-user </Directory> </VirtualHost> In questo file la parte più importante è il blocco <Directory>. Qui definiamo il nome da visualizzare quando appare la finestra di pop-up per la richiesta del nome utente e la password (AuthName), il tipo di autenticazione da utilizzare (AuthType), il file da utilizzare per verificare le autenticazioni (AuthUserFile) e l'impostazione base di sicurezza (require). Nel caso in cui si volesse testare i siti con domini non riconosciuti bisogna ricordarsi di andare a configurare il file /etc/hosts. 34/45
SECURE SOCKETS LAYER (SSL) Introduzione Transport Layer Security (TLS) e il suo predecessore Secure Sockets Layer (SSL) sono dei protocolli crittografici utilizzati spesso e volentieri per garantire la sicurezza e l'integrità di dati trasferiti su reti classificate non sicure come ad esempio l'internet. Stabilire connessioni sicure con il webserver desiderato è di fondamentale importanza data spesso la necessità di invio di dati personali, privati o addirittura sensibili (es. online banking). Vediamo quindi in questo capitolo come abilitare il modulo SSL sul nostro webserver. Chiave e certificato SSL Per dare la possibilità al nostro server di effettuare connessione su protocollo SSL abbiamo bisogno di due cose fondamentali: una chiave e un certificato SSL. Nel momento in cui un browser si collega al nostro sito gli verrà inviato dal server il certificato SSL. In questo caso il client può essere sicuro di essersi collegato con il server desiderato. A verifica terminata si passa al passaggio dei dati su canale criptato. Il canale viene criptato con l'apposita chiave SSL. Un certificato, con relativa chiave SSL, deve essere richiesta ad un TrustCenter. Un TrustCenter deve verificare la correttezza dei dati inseriti nel certificato e siglarlo per renderlo efficace a tutti gli effetti. Effettuare la richiesta dei parametri SSL necessari può essere molto dispendioso sia da un punto di vista di tempo che di denaro. Per il nostro 35/45
esempio possiamo creare un nostro certificato (naturalmente non utilizzabile su Internet) utilizzando il software OpenSSL (www.openssl.org) che dobbiamo eventualmente installare apt-get install openssl Come prima cosa dobbiamo generare una chiave RSA. Nel nostro caso generiamo una chiave con lunghezza 1024 bit che verrà copiata all'interno del file server.key. Utilizziamo il seguente comando openssl genrsa -out server.key 1024 Il file con la chiave viene generata all'interno dell'attuale cartella (pwd). Dalla chiave generiamo ora il certificato dandogli una validità pari a 4 anni (ossia 1460 giorni). openssl req -new -x509 -days 1460 -key server.key -out server.crt Verranno poste una serie di domande alla quale rispondiamo di dovere. La domanda sul Common Name è molto importante e dovrebbe contenere il nome DNS del nostro server. Il certificato si trova ora all'interno del file server.crt. Configurazione del server Prima di poter utilizzare il modulo SSL dobbiamo attivarlo con il comando: a2enmod ssl Prendiamo poi i due file creati precedentemente server.key e server.crt e copiamoli all'interno della cartella /etc/apache2. cp server.crt server.key /etc/apache2 Ora ne modifichiamo l'utente proprietario ed i diritti di accesso per evitare che qualche utente vada a dare una sbirciatina. chown www-data server.* chmod 600 server.* Apriamo ora il file /etc/apache2/ports.conf ed aggiungiamo la riga listen 443 Dovrebbe già essere presente la riga listen 80. Nel file di configurazione del dominio web che stiamo creando e che inseriremo nella cartella /etc/apache2/sites-available inseriamo le seguenti righe: 36/45
SSLCertificateFile /etc/apache2/server.crt SSLCertificateKeyFile /etc/apache2/server.key Nel blocco VirtualHost dobbiamo solamente attivare il motore SSL con la seguente riga SSLEngine On Le opzioni più importanti, oltre a quelle appena viste, che possiamo utilizzare nella configurazione SSL sono: SSLProtocol SSLCipherSuite SSLRequireSSL Le versioni SSL che possiamo utilizzare sono SSLv2, SSLv3 e TLSv1. Utilizzando questa direttiva possiamo definire quale versione SSL utilizzare e quale no. Con la voce SSLProtocol -SSLv2 +SSLv3 +TLSv1 attiviamo tutte le versioni tranne la SSLv2. Con questa direttiva definiamo quali algoritmi SSL vogliamo permettere. Con la voce SSLCipherSuite HIGH:MEDIUM permettiamo una connessione solo dai browser che utilizzano algoritmi sicuri. Un server configurato per SSL risponde automaticamente anche a richieste su HTTP. Per rifiutare HTTP ed accettare solamente HTTPS inseriamo questa voce. Vediamo ora un semplice esempio: SSLCertificateFile /etc/apache2/server.crt SSLCertificateKeyFile /etc/apache2/server.key SSLProtocol All SSLCipherSuite HIGH:MEDIUM <VirtualHost 192.168.0.155:443> ServerAdmin root@test1.com DocumentRoot /var/www/test1.com ServerName www.test1.com SSLEngine On <Directory /var/www/test1.com/> SSLRequireSSL </Directory> </VirtualHost> Nel caso di siti che permettono l'accesso sia tramite HTTPS (quindi alla porta 443) che HTTP (alla porta 80) la configurazione deve essere fatte per entrambe le situazioni. Rimane quindi il blocco <VirtualHost 192.168.0.155:443> per definire il comportamento di accessi HTTPS, ma va aggiunto anche un blocco <VirtualHost 192.168.0.155:80> per definire il comportamento di collegamenti HTTP. 37/45
WEBALIZER Introduzione Webalizer è un sistema che può essere abbinato al webserver per creare delle statistiche relativi ai vari domini che abbiamo configurato. Installiamo il pacchetto come segue apt-get install webalizer Configurazione di Webalizer Dopo l'installazione troviamo all'interno della cartella per i documenti in linea del nostro webserver la seguente cartella vuota /var/www/webalizer Questa è infatti la cartella che webalizer utilizza come posizione di destinazione delle statistiche di default. Il file di riferimento lo troviamo all'interno della cartella /etc/webalizer e si chiama webalizer.conf /etc/webalizer/webalizer.conf I parametri più importanti all'interno di questo file di configurazione sono LogFile percorso_logfile Questo parametro definisce il logfile dal quale recuperare le informazioni 38/45
necessarie per la creazione della statistica di webalizer. OutputDir percorso_cartella Questo parametro definisce la cartella all'interno della quale verrà creata la situazione di statistica in formato HTML. La cartella definita mediante questo parametro deve esistere, altrimenti non verrà creata in automatico. Ogni configurazione si basa quindi su logfile diversi. Per questo motivo diventa importantissimo creare un logfile diverso per ogni dominio per il quale si vuole creare una statistica. La relativa statistica viene creata passando il file di configurazione come parametro al comando webalizer come segue webalizer /etc/webalizer/dominio1.conf Questo comando, eseguito per ogni file di configurazione presente all'interno della cartella /etc/webalizer/, viene inserito all'interno del crontab per essere eseguito quotidianamente (/etc/cron.daily/webalizer). Se creiamo quindi una cartella webalizer per ogni dominio che abbiamo in gestione e ne configuriamo l'esecuzione all'interno della cartella /etc/webalizer potremmo visualizzare i risultati della statistica con http://www.dominio.it/webalizer 39/45
Webmail con Squirrelmail Introduzione Squirrelmail è un webmail server scritto in PHP che supporta i protocolli IMAP e SMTP. Installazione Per installare il sistema digitiamo apt-get install squirrelmail Dopo l'installazione possiamo trovare l'intero sistema all'interno della cartella /usr/share/squirrelmail mentre come cartella per i file di configurazione troviamo /etc/squirrelmail Qui dentro troviamo il file apache.conf che contiene tutte le direttive di apache per il corretto funzionamento. Possiamo integrare la configurazione con un semplice Include /etc/squirrelmail/apache.conf 40/45
oppure creando un link simbolico all'interno della cartella /etc/apache2/conf.d come segue cd /etc/apache2/conf.d ln -s /etc/squirrelmail/apache.conf squirrelmail Facciamo poi ripartire apache con /etc/init.d/apache2 restart Configurazione di Squirrelmail Questo sistema viene fornito con il comando di configurazione squirrelmail-configure che mette a disposizione un tool interattivo per la configurazione del sistema stesso. Dopo aver fatto partire questo tool ci troviamo a disposizione un menu dal quale scegliamo il secondo punto 2. Server Settings per controllare le impostazioni del server. Avendo installato il nostro IMAP e SMTP server in locale possiamo lasciare la situazione invariata. Altrimenti possiamo modificare a piacere scegliendo i punti A oppure B. Per creare ora un dominio dedicato al nostro webmail possiamo creare un nuovo file di configurazione di apache all'interno del quale definiamo un nuovo punto di accesso. <VirtualHost 1.2.3.4> DocumentRoot /usr/share/squirrelmail ServerName webmail.example.com </VirtualHost> 41/45
Modulo mod_rewrite Introduzione Questo modulo è uno dei moduli presenti all'interno del sistema Apache e permette di riscrivere (rewrite) la richiesta URL fatta da parte dell'utente utilizzando delle regole ben precise prima che questa giunga e venga elaborata come richiesta ad una risorsa di Apache. La seguente richiesta http://www.nostrosito.it/chisiamo.html potrebbe puntare internamente alla pagina http://www.nostrosito.it/pages.php?page=chisiamo Configurazione del server Essendo questo modulo già presente all'interno di Apache l'unica cosa che dobbiamo fare è attivarlo con il seguente comando: a2enmod rewrite Da ora in poi il modulo sarà attivo. Possiamo verificare l'attivazione controllando la presenza dei file mod_rewrite.load direttamente nella cartella /etc/apache2/mods-enabled/. Per poter utilizzare questo modulo all'interno di un nostro dominio è 42/45
indispensabile far capire ad Apache che vogliamo rendere disponibile il motore mod_rewrite per il dominio desiderato. La direttiva per l'attivazione del motore in questione così come le regole necessarie alla sostituzione vanno inserite direttamente all'interno della configurazione del dominio, oppure nel file.htaccess. Per attivare il motore del modulo rewrite scriviamo RewriteEngine on nella direttiva directory principale del nostro sito. Le regole verranno spiegate nelle sezioni seguenti. Le regole Una regola viene identificata da Apache grazie alla parola RewriteRule. Questa direttiva ha la seguente sintassi RewriteRule {pattern} {sostituzione} [opzioni] dove i parametri utilizzabili hanno il seguente segnificato {pattern} {sostituzione} [opzioni] Qui inseriamo una regular expression che viene utilizzata sulla URL di richiesta fatta direttamente dall'utente. Questa è la risorsa interna che Apache dovrà far vedere in base alla URL di richiesta identificata da {pattern} Questo parametro non è indispensabile per il corretto funzionamento della regola, ma permette di gestirne il comportamento. Un semplice esempio in grado di indirizzare tutte le richieste fatta alla pagina prova.html alla pagina test.html è il seguente: RewriteEngine on RewriteRule ^prova.html$ test.html Dopo aver attivato il motore di rewrite definiamo la regola che riconosce la richiesta fatta grazie a ^prova.html$ e ne definisce la risorsa effettiva con test.html. Nelle regular expressions il ^ identifica l'inizio della riga (o stringa di richiesta), mentre $ ne identifica la fine. 43/45
Le opzioni Possiamo definire il comportamento delle regole in base a dei flag posti tra parentesi quadre [...]. Alcuni dei flag più importanti sono: C F L NC NE Questo flag permette di concatenare (chain) una regola con quella successiva. Se la regola corrisponde si passa direttamente alla prossima, altrimenti la procedura di elaborazione salterà tutte quelle collegate fra loro Permette di negare (forbidden) l'accesso alla risorsa definita dalla regola Definisce la regola come ultima (last) regola da elaborare. Questo evita che la richiesta possa subire ulteriori variazioni da parte di altre regole sottostanti. Questo flag rende case-insenitive il blocco pattern durante l'elaborazione della regola Normalmente i caratteri speciali ('%', '$', ';' ecc.) presenti all'interno del blocco di sostituzione vengono rimpiazzati dagli equivalenti valori esadecimali ('%25', '%24', '%3B', ecc.). Questo flag disattiva questa funzione lasciando i caratteri speciali invariati. Il seguente esempio RewriteRule /foo/(.*) /bar?arg=p1\%3d$1 [R,NE] trasforma la richiesta /foo/zed in /bar?arg=p1=zed. Le variabili Abbiamo la possibilità di registrare dei valori di variabili recuperati dalla sezione {pattern} per riutilizzarli nel blocco {sostituzione}. Per far capire qual'è il valore della variabile utilizziamo le parentesi tonde (...) mentre riutilizziamo questi valori con la forma ${numero}. {numero} è il numero di blocco a partire da sinistra verso destra dove il primo blocco è identificato dal numero 1. Per esempio possiamo utilizzare la seguente regola RewriteRule ^page/([^/\.]+)/?$ pages.php?page=$1 per prendere tutto quello che si trova dopo page/ ed inserirlo come parametro del blocco in sostituzione al posto di $1. La richiesta a http://www.miosito.it/page/chisiamo viene interpretato da Apache come 44/45
http://www.miosito.it/pages.php?page=chisiamo La sequenza di caratteri /?$ identifica tutte le richieste che terminano con o senza slash (/). Le condizioni La validità di una regola può essere definita da una o più condizioni che la precedono. La sintassi con la quale viene definita una condizione è la seguente RewriteCond {test} {pattern} [opzioni] dove test può contenere un blocco di raggruppamento presente all'interno del blocco pattern dell'ultima regola ($N: 0 <= $N <= 9), un blocco di raggruppamento presente all'interno del blocco pattern dell'ultima condizione (%N: 0 <= %N <= 9), un riferimento a RewriteMap (non trattato in questo manuale), oppure una variabile di ambiente del server %{NOME_VARIABILE} (es. %{HTTP_USER_AGENT}, %{REMOTE_ADDR}, ecc.). Il blocco pattern è una regular expression che permette di definire il valore del test in questione, mentre opzioni può contenere i flag NC (no case), oppure OR (concatenamento logico 'o'). Vediamo ora un semplice esempio per definire una pagina iniziale per il browser Mozilla Firefox RewriteCond %{HTTP_USER_AGENT} ^Mozilla RewriteRule ^/$ /homepage.moz.html [L] RewriteRule ^/$ /homepage.html [L] 45/45