Apache - 30 - Home Page di Andrea Leotardi

Transcript

Apache Web Server
Il primo sito italiano completamente dedicato al Web Server Apache
Piattaforma Win32
Lezioni pratiche alla configurazione del server Apache su Windows98
Salve a tutti giovani amministratori, qui potrete trovare un elenco di lezioni che vi accompagneranno a passo a passo,
dall’installazione del server Apache fino alla completa configurazione. Ovviamente quelle in elenco non sono tutte le
lezioni poiché sono ancora in fase di stesura, ma solo le prime già pronte al download, spero di poter aggiornare l'elenco
aggiungendo almeno un paio di lezioni a settimana. Buon lavoro.
N° lezione
Titolo
Data
Introduzione
Introduzione
28/05/2000
Storia
Storia
28/05/2000
Lezione 1
Installazione di Apache su Win9x
28/05/2000
Lezione 2
Prima esecuzione
28/05/2000
Lezione 3
Configuriamo la rete
28/05/2000
Lezione 4
Configurazione di base del file config
02/06/2000
Lezione 5
Il nostro primo sito web
18/05/2000
Lezione 6
Gestione dei file index
20/05/2000
Lezione 7
Gestione di file index virtuali (prima parte)
20/05/2000
Lezione 8
Gestione di file index virtuali (seconda parte)
21/05/2000
Lezione 9
Gestione degli errori
25/05/2000
Lezione 10
Configurazione di Apache e delle CGI
28/05/2000
Lezione 11
Configurare le SSI in Apache
29/05/2000
Lezione 12
Sicurezza dei sistemi informatici
30/05/2000
Lezione 13
Codici di status HTTP 1.1
31/05/2000
Lezione 14
Variabili d'ambiente personali
02/06/2000
Lezione 15
Personalizzare le variabili a seconda del browser
03/06/2000
Lezione 16
File di config standard
05/06/2000
Lezione 17
Gestire i MIME
06/06/2000
Lezione 18
Negoziare il linguaggio
07/06/2000
Lezione 19
Negoziare le immagini
08/06/2000
Lezione 20
Mapping dei tipi
09/06/2000
Lezione 21
Direttive di blocco <VirtualHost>
12/06/2000
Lezione 22
Direttive di blocco <Directory> <DirectoryMatch>
12/06/2000
Lezione 23
Direttive di blocco <Files> <FilesMatch>
12/06/2000
Lezione 24
Direttive di blocco <Location> <LocatioMatch>
13/06/2000
Lezione 25
Direttive di blocco <IfDefine> <IfModule>
14/06/2000
Lezione 26
AccessFileName 1° Parte
09/09/2000
Lezione 27
AccessFileName 2° Parte
11/09/2000
Lezione 28
Come far girare Script CGI in Perl con Windows 95/98 e Apache
09/11/2000
Lezione 29
Come installare in Apache il modulo ASP già compilato.
14/11/2000
Lezione 30
Virtualhost e Alias
09/01/2001
Introduzione
Questa guida nasce dalla mia vana esigenza di trovare sulla rete del materiale utile e soprattutto in italiano
che trattasse in maniera approfondita la configurazione di un server Apache su sistemi Win32, ma ahimè le
ricerche in internet non sono state in grado di risolvere i miei problemi, non sono riuscito ad individuare nulla
a riguardo che superasse due facciate.
Pertanto, al fine di cercare di venirne a capo di quest’incresciosa situazione, mi sono mosso in altre direzioni
cercando di tradurre la documentazione in inglese fornita da Apache e partecipando ed anche visitando
stressanti mail-list e forum sulla rete al fine di individuare tra le varie richieste qualcosa che mi potesse
davvero essere di aiuto.
A tutt’oggi, anche se con il suddetto modo sono riuscito ad accumulare abbastanza esperienze in questo
campo, non auguro a nessuno di passare ciò che ho dovuto passare io, ed è per questo che ho deciso di
riunire tutte le mie esperienze in un file di testo, in modo da dare una guida, se non proprio completa,
perlomeno discreta, su come installare e configurare un server Apache in ambiente Win32.
Un po' di storia
Il Server Apache nasce dall’implementazione del codice sorgente in C del più anziano NCSA, messo a
disposizione, ed ancora reperibile gratuitamente, nel sito www.ncsa.uiuc.edu, mediante l’aggiunta di patch
da parte di terze persone.
Proprio da queste patch, almeno come affermano in molti, nasce il nome di Apache, ma le leggende in
materia sono tante ed esuli da questa guida.
Come molti di voi già saprà, il softwareserver Apache fa parte di una corrente di pensiero che ha adottato la
strada del OpenSources, e cioè di rendere di dominio pubblico il codice sorgente dei propri applicativi, in
modo tale da permettere a chiunque ne sentisse l’esigenza di poter apportare le proprie modifiche al
programma, personalizzarlo secondo le proprie necessità.
Grazie a questa linea di pensiero, tale software si è potuto evolvere ad una velocità spaventosa,
imbattendosi nelle simpatie di migliaia di programmatori sparsi per il mondo grazie anche all’aiuto della rete.
Tutt’oggi il server Apache, sia perché è possibile reperirlo gratuitamente sia perché garantisce una buona
robustezza, è divenuto il webserver più diffuso al mondo. Altri software che hanno adottato l’iniziativa
dell’OpenSources stanno avendo lo stesso successo ed altri se ne vanno aggiungendo, anche la tanto
blasonata Windows a dichiarato di voler rendere disponibili i codici sorgenti di Windows2000.
Sicuramente vi starete chiederete che cosa ci guadagnano, e cosa spinga i poveri programmatori a regalare
a chicchessia il loro operato costato miriadi di nottate insonni. Beh, apparentemente proprio nulla, la maggior
parte di loro lo fa solo per passione, gareggiando contro se stessi spingendo al limite le loro potenzialità, ma
è altresì vero che chi partecipa al gruppo come quello di Apache possiede una carta in più nella ricerca di
lavori più redditizi, potendo mettere con vanto sul proprio curriculum di essere un partecipante di tale gruppo.
C’è anche un’altra cosa, e cioè dando via il loro software gratuitamente, tali programmatori si liberano da
ogni responsabilità sul loro software o dal dover dare ai propri clienti alcun tipo di assistenza, o quantomeno
se la fanno pagare molto profumatamente.
Lezione 1
Come installare Apache
Al momento della stesura di queste pagine la versione più aggiornata d’Apache per Win32 è la 1.3.12 anche
se in versione beta, e personalmente credo che ci resterà anche per molto per le versioni successive, andrà
benissimo al nostro scopo.
Il motivo per il quale le versioni per sistemi Win32 di Apache sono definite versioni beta, è dato dal fatto che
un gran numero di funzioni dello stesso sono accessibili solo da sistemi Unix ( Linux va benissimo ), e
,almeno per il momento, il gruppo di Apache non ha alcuna intenzione di implementare tali funzioni per
Windows.
E’ possibile scaricare gratuitamente il webserver Apache per Windows dal sito ufficiale di Apache
www.apache.org,
Una volta scaricato il file dalla rete, non ti resta altro che installare il server, grazie all’impegno dei
programmatori di Apache, la fase tale operazione non comporta più un problema per i meno esperti come in
passato, in fatti se avete provveduto a scaricare la versione eseguibile del server anziché i file binari da
compilare, il tutto sarà semplificato da un allegro winzard che ci segue e ci aiuta chiedendoci solo dove voler
installare il Server e che tipo d’installazione intendiamo fare tra tipica, minima e custom. Voi per non
complicarvi la vita e meglio seguire i miei suggerimenti nel seguito delle lezioni, sceglierete C:\Apache come
directory nella quale installare il server, e la voce custom per ciò che riguarda il tipo d’installazione ( la voce
custom si differenzia da quella tipica per l’installazione dei file sorgenti ).
Fatto ciò fate eseguire l’installazione fino al suo completamento, dopo di ché dovrete riavviare il computer.
Lezione 2
Il primo avvio (fallito) di Apache
Eh sì gente l’installazione del nostro bel server Apache è terminata. Lo so che ai più ostici possa non
sembrare vero eppure è cosi, in poco meno di una manciata di secondi siamo riusciti a installare il server, lo
stesso server che fino a poche versioni precedenti richiedeva la compilazione manuale dei sorgenti e
soprattutto elevate conoscenze nel campo dell’informatica.
Una volta riavviato il computer potete avviare Apache grazie alla comoda icona start apache che troverete in
start>programmi>Apache Web Server>start Apache. Cliccandoci su con mouse si dovrebbe aprire un shell
del Dos, dico dovrebbe poiché pur provandoci tale finestra non resterà aperta per più di mezzo secondo.
Che cosa sta succedendo? Niente di più normale, non rattristatevi pertanto se credete di aver sbagliato
qualcosa, il server è perfettamente funzionante ma nel tentativo di avviarsi non riesce a trovare le direttive
necessarie alla sua corretta esecuzione.
Ebbene sì, è arrivato il momento di rimboccarci le maniche e di dare inizio alla configurazione di Apache. Per
far ciò dobbiamo andare a modificare manualmente il file di config httpd.conf reperibile all’interno della
directory C:\Apache\conf , normalmente file con estensione .conf non sono associati a nessun programma,
pertanto per aprirgli e modificarli dovrete farci su un doppio click del mouse si aprirà una finestra di Windows
che vi chiederà con quale programma vogliate aprire questo tipo d’estensione e se volete associare il
programma scelto anche in seguito. Voi tra i tanti programmi che usciranno in lista sceglierete Notepad di
Windows.
Comunque prima di dare inizio alle modifiche e alla configurazione del server, sarà bene accertarsi di avere
ben configurato sul PC un protocollo di trasmissione.
Lezione 3
Configuriamo la rete
Questa lezione può essere tranquillamente saltata da tutti coloro che abbiano il loro PC collegato in rete con
uno o più PC, poiché il protocollo di rete è già ben configurato e funzionante dal momento in cui il proprio
computer a riconosciuto e istallato i driver della scheda di rete.
Mentre per tutti coloro che intendano utilizzare la propria macchina sia da Server sia come client, il discorso
si complica un po’. In pratica un server, qualunque esso sia, funziona ed è stato sviluppato per gestire le
richieste di più macchine comunicanti tra di loro attraverso una rete, pertanto pur non essendo collegati
realmente a nessun PC dobbiamo far capire al server che lo potremmo essere in un secondo momento
(faccio un esempio più pratico, ammettiamo che nel nostro ufficio ci siano tre macchine collegate tra di loro
attraverso una rete e che una di esse sia in funzioni da server, il tutto funziona egregiamente dato che il
server si è accorto della presenza della rete, e tutte e tre le macchine compresa quindi anche quella server,
riescono attraverso l’uso del browser a visualizzare le risorse messe a disposizione del server. Ammettiamo
in fine che i due operatori del nostro uffici smettano di lavorare sulle loro macchine client alle sei del
pomeriggio spegnendo i loro PC mentre l’addetto alla manutenzione del server smonterà alle otto, nel
momento in cui i due client sono spenti viene a mancare il dialogo tra le macchine ma il softwareserver
continuerà a funzionare sulla macchina server continuando a mostrare tramite il browser i suoi contenuti,
questo perché al server in fondo non interessa chi sia in ascolto di esso ma che qualcuno abbia la possibilità
di farlo. Ora per concludere tutta sta pappardella il nostro scopo sarà di ingannare il server facendoli credere
di essere pronti ad inviare informazioni ai nostri inesistenti client, che al momento sono spenti.) In pratica
basta configurare un protocollo di rete tra i tanti messi a disposizione da Windows.
Qualcuno di voi potrebbe chiedersi perché non usare il protocollo utilizzato e perfettamente funzionante per
accedere ad Internet, tale protocollo va anch’esso bene ma funziona solo nel momento in cui vi collegate
alla rete, quindi se non avete intenzione di spendere una barca di soldi in bollette, solo per vedere come
funziona il vostro server ve lo sconsiglio di cuore.
Chiarita, almeno spero, la situazione passiamo ora alla configurazione della rete, andate nel pannello di
controllo di Windows e selezionate l’icona rete cliccandoci su per aprirla, ora cliccate su aggiungi si aprirà
una nuova finestra di dialogo cliccate su protocollo e ancora su aggiungi, si aprirà un'altra finestra scegliete
Microsoft e selezionate tra l’elenco protocollo compatibile IPX/SPX cliccate su OK ed il gioco è fatto non vi
resta che riavviare il vostro PC. Prima di fare tale operazione ricordatevi di avere sotto mano il disco di
Windows98. Se tutto è andato bene una volta riavviato il PC dovrebbe apparire sul desktop l’icona risorse di
rete.
Lezione 4
Configurazione di base del file config
Scusatemi tanto amici, ma avevo sottovalutato una lezione che ritenevo negligentemente superflua, e
ringrazio Marcello Sanci per avermelo ricordato.
Eravamo rimasti al settaggio della rete sulla nostra macchina Windows, ora se tutto è andato per il meglio,
sul vostro desktop dovrebbe apparire l'icona risorse di rete, e se al contrario non appare dovrete riprovare
reinstallando la rete, mentre per tutti coloro che visualizzato tale icona, non dovranno far altro che cliccarci
su col tasto destro del loro mouse e scegliere proprietà dal menù, a questo punto si aprirà una finestra di
dialogo con tre caselle, voi cliccate su identificazione e copiate il nome della vostra macchina che utilizzerete
per l'identificazione del localhost del server, volendo, se il nome riportato non vi piace, potrete scriverne un
altro ad esempio fastserver o qualunque altro vi possa venire in mente. Se avete scelto di cambiare il nome
alla vostra macchina sarete costretti a riavviare il sistema per il corretto funzionamento del sistema.
Una volta individuato il nome della macchina non vi resta che andare a modificare il vostro file confing, dalla
cartella conf di apache cliccando sul file httpd.conf, che potrete aprire con un comune editor di testi come
Notepad.
Per chi ancora non l'avesse intuito il file confing è il file più importante del server Apache, ed è considerato il
suo cuore in quanto è da esso che il server preleva i suoi impulsi vitali per il suo corretto funzionamento.
Questo file è composto da un insieme di direttive con i loro rispettivi valori, e da commenti individuabili dal
carattere # prima della linea, il server in fase di avviamento effettua una scansione di questo file ignorando
tutte le stringhe precedute dal #, ovviamente le direttive elencate non sono tutte, ma solo quelle che si
ritengono di uso comune scritte di default durante l'installazione, provvederemo in seguito ad aggiungere le
direttive mancanti a secondo delle necessità.
Aperto il file confing andate alla ricerca del direttiva ServerName ed eventualmente decommentatela
cancellando il carattere #, accanto a ServerName scriverete il nome della vostra macchina, in questo modo
sarà possibile designare un DNS virtuale al posto del più squallido localhost o dell'indirizzo Ip 127.0.0.1
Passiamo ora alle altre direttive da modificare, anche se ciò non è indispensabile per il corretto
funzionamento del server in quanto settate di default durante l'installazione è bene terne conto,
modificandole a nostro piacimento.
ServerType
Questa direttiva permette di specificare come Apache deve gestire più copie di se stesso. Le possibili
variabili sono 'inetd' o 'standalone'. Anche se vi è data la possibilità di scegliere, inetd è decisamente
sorpassata è valida solo per sistemi Unix, che comunque anche per essi si sceglie standalone, ed è ciò che
farete anche voi lasciando tutto com'è.
ServerRoot
Questa direttiva indica la posizione in cui è stato installato il server, ed è correttamente configurata durante
l'installazione dello stesso.
PidFile
Indica la posizione e il nome del file nel quale il server deve conservare il suo numero d'identificazione,
potrete scegliere tutte le posizioni e i nomi più assurdi, ma per il momento vi consiglio di lasciare quello di
default e cioè logs/httpd.pid
LoadModule
Con questa direttiva potrete caricare tutti i moduli aggiuntivi, in Win32 sotto forma di DLL, oltre quelli installati
di default dal server, voi non dovrete far altro che cancellare tutti i caratteri di commento # se non sono gia
stati tolti di default durante l'installazione, e se scaricate nuovi moduli dalla rete non dovrete far altro che
elencarli sotto questa direttiva.
Port:
Quando viene utilizzata in una sezione globale del file di configurazione e in assenza di direttive
'BindAddress' o 'Listen', la direttiva 'Port' imposta il numero di porta sul quale Apache deve mettersi in attesa
di richieste.
In realtà questa direttiva è stata inclusa solo per mantenere una compatibilità verso il basso, perché, per
ottenere questo scopo, bisognerebbe utilizzare le direttive 'BindAddress' e 'Listen'.
ServerAdmin
Tale direttiva fornisce ad Apache un indirizzo di posta elettronica (email_address) per l'invio di pagine
generate automaticamente dal server.
ServerName
Questa direttiva permette di impostare l'hostname del server da utilizzare per creare l'URL di redirezione, in
pratica corrisponde ad utilizzare la direttiva 'location' o ad accedere alla directory senza il carattere / finale.
Nota: tu non puoi inventare arbitrariamente sul nome del Server in quanto esso è definito dal DNS.
DocumentRoot
Questa direttiva specifica la directory dalla quale Apache preleva i file da inviare ai client.
UserDir
Con questa direttiva potrete impostare le pach server per la creazione delle directory dei vostri utenti potrete
scegliere il nome di tale cartella e la sua posizione in modo arbitrario.
ErrorLog
Specifica la directory e il nome nel quale salvare i file log degli errori.
CustomLog
Specifica il nome e la directory dove verranno salvati i file di log degli accessi.
ScriptAlias
Specifica il nome della directory e la sua posizione dove installerete i vostri script CGI o Perl, voi potrete
scegliere qualunque nome e posizione, è consigliabile cambiare i settaggi per questioni di sicurezza. Grazie
all'uso di questa direttiva non vi è bisogno di specificare nell'URL la diretta posizione di tale cartella per
accedere agli script, ma basta scrivere la pach scelta /cgi-bin/.
Lezione 5
Creazione del nostro primo sito
Oggi creeremo il vostro primo sito.
Come prima cosa andremo a prelevare il file di confing httpd.conf dalla directory "c:\apache\conf", tale
locazione dipende da dove avete scelto d'installare il server Apache. Molto probabilmente a tale file non è
associato nessun programma, e con un doppio click del mouse vi verrà chiesto di specificare con quale
applicazione lo volete aprire, voi sceglierete 'NotePad' di Windows.
Una volta aperto il file confing iniziate a cercare una stringa contenente la parola DocumentRoot, al fine di
semplificare tale ricerca potete anche usare il comando trova di Notepad, tale stringa individua la direttiva
"DocumentRoot" e serve a far capire al server dove andare a cercare le pagine e i vari file che comporranno
il vostro sito, troverai scritto "C:/Apache/htdocs" o qualcosa di simile a seconda di dove hai installato il
programma, all'interno della directory htdocs, creata di default dal programma, è contenuto il manuale di
Apache e la pagina di apertura del server (la classica pagina che vi informa del corretto funzionamento di
Apache).
A questo punto potrete decidere di cambiare la cartella nella quale pubblicherete le vostre pagine e di
nominarla come più vi aggrada, da questo punto in poi identificherò la nostra nuova cartella di root col nome
"new", pertanto se non volete correre rischi d'incomprensione vi consiglio di chiamare la vostra nuova
cartella con tale nome modificando la direttiva in questo modo: DocumentRoot "C:/Apache/new", dopo di ché
potrete salvare il file confing e riavviare Apache.
A differenza dei sistemi Unix, quelli Win9x non sono in grado di generare tale directory, quindi non devi fare
altro che andare in c:\apache e creare manualmente la tua nova cartella new, con un qualsiasi dei tuoi
programmi per l'elaborazione di pagine html potrai preparare la tua pagina di benvenuto e salvarla in
c:\apache\new col nome di index.html.
Aprendo il vostro browser preferito scriverete la vostra URl ed ecco che il server vi invierà la vostra pagina di
benvenuto del vostro nuovo sito.
La prossima volta vi insegnerò a definire quali pagine far aprire di default ad Apache, nell'evenienza in cui
digitando l'URL del vostro sito non specifichiate una determinata pagina. Per far questo preparerete alcune
cartelle interne alla directory c:\apache\new ( d'ora in avanti userò sempre tale percorso per indicare la
cartella di root e scriverò ..\new per semplicità) e salvate in esse alcuni tipi di file a piacere (cercate di
inserire quante più tipi d’estensioni possibili tipo txt, doc, rar, zip, java, class, bmp) inoltre potrete copiare in
..\new la cartella "manual" contenuta in htdocs. Fatto ciò modificate la vostra pagina index.html in modo da
creare soltanto dei collegamenti alle vostre nuove cartelle ma non ai file interni.
Lezione 6
Gestione dei file index
Come promesso, e nella speranza che siate riuscite a creare e visualizzare la vostre bella pagina
personalizzate nella vostra nuova directory di Root "new", oggi impareremo a gestire le index del server
Apache.
DirectoryIndex
Molto probabilmente, navigando per il Web, avrete avuto modo di notare che per visualizzare l'home page di
un sito non avete alcun bisogno di specificare nell'URL il nome della pagina. La stessa cosa accade
quando indicate l'URL del vostro sito in locale.
Che cosa accade in realtà?
Il server reagisce alla richiesta innocuamente incompleta da parte del client, cercando di esaudire il vostro
comando nel modo più opportuno ed attendibile, purtroppo tutt'oggi non esiste ancora un software in grado
di decidere liberamente e con criterio in particolari situazioni o richieste, ma è altresì compito
dell'amministratore di rete (cioè voi) preparare a priori il Server su come comportarsi.
Per iniziare non dovete fare altro che aprire il nostro bravo file di confing ed individuare la direttiva
"DirectoryIndex" accanto ad essa troverete gia alcuni nomi accompagnati da diverse estensioni di file, che il
server deve caricare di default nel qual caso non venga specificato, da parte di un client, un particolare tipo
di file.(ricorda che il nome Index e il nome index per Unix sono due nomi differenti mentre per Win32 non ha
alcuna differenza)
In questa direttiva potrete aggiungere e modificare i nomi con rispettive estensioni delle pagine che
desiderate far aprire di default, ricordate di lasciare sempre uno spazio tra i diversi nomi, che possono
essere così indicati:
< DirectoryIndex index.htm index.html index.shtml default.htm default.html home.htm home.html home.asp >
(senza i caratteri '<' e '>').
A questo punto, digitando un URl puntante ad una cartella, il server avvierà una ricerca, nella stessa, della
pagina da visualizzare a partire dal primo nome elencato nella suddetta direttiva, e non appena ne trova una
corrispondente, ammettiamo index.shtml, blocca la ricerca ed invia la pagina al client, ignorando eventuali
file interni alla cartella che ad esempio si possono chiamare home.html o qualunque altro tipo che venga
dopo il primo nome individuato.
Ma cosa succede se il server non riesce a trovare nella cartella nessuno dei file elencati in DirectoryIndex? A
questo scopo entra in gioco la richiesta che vi avevo fatto la volta scorsa di creare diverse directory e di
riempirle di file di diverse estensioni.
Lezione 7
Gestione di file index virtuali
La volta scorsa abbiamo illustrato, mediante la direttiva DirectoryIndex, il modo per far caricare di default le
pagine da noi desiderate. Oggi invece vedremo d'imparare come si comporta Apache quando, all'interno di
una directory, non riesce ad individuare alcun tipo file da noi elencato nella direttiva DirectoryIndex.
Generazione di file index virtuali
Il nome di file index virtuale è stato scelto da me in quanto ne ignoro la vera nomenclatura di questa
caratteristica, comunque ho deciso di chiamarlo così per il fatto che tale file in realtà non esiste, ma è
Apache che lo crea dinamicamente allo stesso modo di uno script CGI o JavaScript.
Se avete creato le cartelle e immesso in esse alcuni file, come vi avevo chiesto, sicuramente vi sarete
accorti che accedendo in esse da una finestra del browser digitando la vostra URL vi appare un elenco
ordinato dei file contenuti nella cartella con le rispettive icone, nome dei file, dimensioni dei file ecc.
Come intestazione vi apparirà la scritta "index of /tua directory" mentre in coda se non hai modificato nulla
che io vi abbia consigliato nel vostro file di confing dovrebbe apparire rispettivamente il nome e la versione
del software server e nel nostro caso sarà "Apache/1.3.12 Server" poi dovrebbe apparire il nome DNS che
avete scelto da dare al vostro sito, dovrebbe apparire il nome della tua macchina ed in fine dovrebbe
apparire il nome della porta su cui si e deciso di far girare di default Port 80.
Sin qui non è nulla di speciale anzi somiglia molto al modo di visualizzare le cartelle e i file su sistemi Unix
un po' più datati, tanto è vero che molti utenti Windows preferirebbero poter visualizzare il contenuto di una
cartella alla solita maniera (provate ad accedere nella stessa cartella dal vostro browser inserendo l'URL
c:\apache\tua_cartella, per capire cosa intendo).
Ma la cosa diventa molto più interessante se si modificano o si applicano alcune direttive contenute nel file di
confing (generalmente durante l'installazione, all'interno del file confing, vengono immesse di default tutte le
direttive di maggior uso, o meglio quelle standard, ma sappiate già d'adesso che non sono le uniche ma che
ve ne sono molte altre di maggiore o minore interesse, anche se per il momento ci accontenteremo di quelle
che abbiamo). Al fine di configurare il nostro file index virtuale ci interesseremo delle seguenti direttive:
•
•
•
•
•
•
•
•
DefaultType
Alias "Icons"
AddIcon
AddDescription
ReadmeName
HeaderName
IndexIgnore
AddEncoding
DefaultType
Questa direttiva istruisce il server su come comportarsi nel momento in cui gli viene chiesto di aprire un file
del tipo sconosciuto, di default viene indicato il valore "text/plain", costringendo il server a codificare il
contenuto dei documenti in formato testo, ma potreste scrivere anche "text/html" nel eventualità che vogliate
codificare i documenti in html.
A che serve tale direttiva..?
Questa direttiva è un residuo di Unix il quale permette di salvare dei documenti senza specificare nessuna
estensione, anche win98 si può settare per fare ciò, ma è esule dal mio compito.
Alias "Icons"
Questa direttiva crea una path server, e cioè crea una cartella speciale allo stesso modo di una cartella cgibin, con la differenza che in essa l'unico ad avere accesso è il solo server, qui puoi mettere tutte le iconcine
che vuoi in formato gif che rappresentino i vari tipi d'estenzioni dei file, in essa ci sono già quelle più comuni
in ambiente Unix ma puoi mettere quelle che ti pare.
AddIcon
Questa direttiva serve per far capire al server quale icona caricare a seconda dell'estenzione di file trovata
dovrai pertanto indicare al server dove sia possibile trovare tale icona, avendo però specificato in
precedenza la path server che contengono le icone ti basterà scrivere "AddIcon /Icons/nome.gif" e poi lascia
uno spazio e scrivi ".nomeestenzione".
A titolo di esempio copia questa iconcina di winzip nella cartella icons poi vai alla direttiva AddIcon e cerca
quella che visualizza l'estenzione .zip modifica il percorso in modo che carichi la nuova icona, diversamente
puoi riscrivere completamente la direttiva "AddIcon /Icons/winzip.gif .zip" ed inserirla come prima direttiva
addicon in modo da sovrascrivere eventuali doppioni, volendo puoi associare ad essa anche altri tipi di file
compressi scrivendo ad esempio "AddIcon /Icons/winzip.gif .zip .rar .gz .tgz .z .Z" .
AddDescription
questa direttiva analogamente alla precedente ti permette di associare ad una determinata estenzione o
gruppi di estenzioni, anziché una icona, un piccolo messaggio descrittivo su tipo di file.
Sempre sull’esempio dei file zip potresti scrivere così:
AddDescription "Directory compressa" .zip .rar .gz .tgz .z .Z
Lezione 8
Gestione di file index virtuali (parte seconda)
Oggi vi ho allegato un file zip con all'interno alcune delle icone più comuni in ambiente Windows, in più ti ho allegato
anche un file di testo dove troverai le direttive gia pronte, se seguirai l'ordine con cui sono state scritte non dovresti avere
problemi nel visualizzare le icone.
Adesso comunque andiamo avanti con la lezione, se la memoria non mi tradisce dovremmo essere rimasti alla
spiegazione di ReadmeName e HeaderName.
ReadmeName
La direttiva ReadmeName, tradotto in italiano leggimi, è una direttiva abbastanza interessante, generalmente non
necessita di particolari modifiche, pertanto la lascerai così com'è. Il modo migliore per capire a cosa serve consiste nel
preparare un file di testo o html e scriverci dentro qualcosa, dopo di che non ti resta che salvarlo all'interno di una delle
directory che non contiene il classico file d'index, col nome di Readme.txt o qualunque altra estenzione, anzi potresti
addirittura omettere l'estenzione in quanto come mi pare d'averti gia insegnato Apache è in grado di riconoscere e
codificare, mediante la direttiva DefaultType, anche i file sconosciuti.
Fatto ciò non ti resta che avviare il tuo server ed andare a visitare la directory nella quale hai salvato il file readme. Ed
ecco che a sorpresa anziché trovare a piè di pag la classica versione del software web ecc., vedrai il contenuto del tuo
bel file readme. Bello vero?
HeaderName
Allo stesso modo della direttiva precedente, HeaderName, anziché sostituire l'intestazione a piè di pag. sostituisce la più
squallida scritta d'intestazione Index of / (tua dir) con un più bello file di testo che preparerai accuratamente e salverai col
nome di Header , per quanto riguarda l'estensione vale la stessa regola di prima. ( Io ti consiglio comunque di creare tali
file in formato html, in modo tale da poter conservare il più possibile la formattazione del testo ).
A titolo d'esempio ti ho allegato inoltre un file zip "read&head.zip" dove ho inserito gia i due file, non ti resta quindi che
provarli ed eventualmente modificarli a piacimento.
IndexIgnore
Questa è una delle direttive che mi piacciono di più, essa è in grado di dire al server quale tipi di file mostrare o non
mostrare nelle index virtuali, creato in principio per nascondere file inutili e numerosi quali potrebbero essere le decine o
centinaia di file d'immagine contenuti in un documento web, potrebbe anche essere un metodo, se non proprio sicuro,
ma quantomeno in grado di nascondere file importanti dagli occhi dei male intenzionati più sprovveduti, e poi come si
dice "occhio non vede, cuore non duole" potendo rendere più difficile ai cattivi di individuare un file di cui non conosce né
il nome né le sue coordinate.
Di default tale direttiva è già impostata in questo modo:
IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t
come puoi notare gli si chiede di ignorare i file readme e header, in quanto sarebbero ripetitivi nella stessa pag, che ne
so tu per provare potresti aggiungere *jpg lasciando uno spazio vuoto per ignorare tutti i file jpg.( ricorda di salvare il file
confing dopo ogni modifica e di riavviare il server per le verifiche )
Alla fine di tale lezione avrai potuto notare che l'index virtuale, ti permette di creare qualcosa di più interessante rispetto
ad un normale elenco di file, potendo personalizzare il tutto secondo le proprie esigenze.
AddEncoding
Per finire parleremo della direttiva AddEncoding, che se pur non ci azzecca nulla con l'index virtuale ti è indispensabile
per definire alcuni tipi di mime al server sconosciuti.
A titolo di esempio la codifica text/html viene definita un MINE, e serve per far capire al server come comportarsi quando
incontra certi tipi di file, in questo caso gli si chiede di trattare file di testo come se fossero file html.
Vi sono molti tipi di file sconosciuti al server, ogni giorno quasi, escono nuovi tipi di estensioni e per piattaforme differenti,
pertanto pur essendo visualizzate in elenco in un index virtuale, cliccandoci sopra non accade nulla, in quanto il server
non è stato istruito su cosa fare, un caso che mi viene a mente si verifica con i file di winrar ( non so se lo conosci, e un
programma di compressione a mio parere migliore di winzip) che salva i file compressi in formato rar per far capire al
server che anch’esso e un file compresso, devi modificare la direttiva AddEncoding x-compress Z aggiungendo dopo
uno spazio rar,
il risultato dovrebbe essere il seguente >AddEncoding x-compress Z rar<.
Per oggi basta così, le direttive AddEncoding sono molte, ma ci ritorneremo ogni qualvolta ne sentiremo il bisogno.
Nella prossima lezione spiegheremo come personalizzare i messaggi di errore.
Lezione 9
Gestione degli Errori
Oggi spiegheremo come si comporta, o meglio come far comportare, il server Apache al verificarsi di errori. Parliamo in
questa lezione dei fatidici errori 400, 401, 500 ecc.
Innanzi tutto andrebbe configurata la direttiva errorlog, dico andrebbe ma effettivamente è già stata configurata a dovere
durante l'installazione tale direttiva dovrebbe riportare la seguente stringa >ErrorLog logs/error.log< dove logs si
comporta da path server pertanto non è necessario riportare l'URL completa c:\apache\logs mentre error.log ( che potrai
tranquillamente aprire con il notepad di windows ) è un file di log capace di registrare tutti gli eventi che hanno generato
un errore in Apache, in pratica viene visualizzato un elenco di richieste fatte dal client che il server non è riuscito ad
interpretare o a portare a termine. Ad ogni errore corrisponde una piccola descrizione di ciò che è accaduto in modo da
poter più facilmente individuare l'errore.
Mediane la direttiva LogLevel hai la possibilità di scegliere che tipo di informazioni vuoi ricevere sul tuo file errorlog e
quali errori vuoi che siano riportati rispetto ad altri che potrebbero benissimo essere ignorati, per il momento ti consiglio
di scrivere la seguente stringa >LogLevel debug< in modo da avere le informazioni necessarie per ripristinare gli errori.
> Andando avanti con la lezione facciamo in modo da generare un errore, il più classico e da te più conosciuto lo si
ottiene cercando di far eseguire uno script cgi al nostro server, se ancora non l'hai fatto fallo ora, e a sorpresa,
spiacevole, verrà aperto un messaggio di Apache che ti informa che qualcosa è andato storto invitandoti a contattare il
tuo amministratore di rete mediante l'indirizzo email che ha gia riportato nella direttiva ServerAdmin, e che non riuscivi a
capire a cosa poteva servire, ora dirai bella sozzeria se l'amministratore sono io!! Ma tale direttiva non è stata pensata
per gli amministratori ma bensì per gli sventurati utenti della rete che trovandosi d'innanzi questo odioso messaggio
d'errore pensano che tu sei l'unico super eroe capace di risolvere ogni loro problema.
Per il momento non ce ne frega ancora nulla di come correggere gli errori ma ci limiteremo a fornire ai nostri utenti alcuni
messaggi di errore.
Di default se generi un errore ti appare un messaggio del server di questo tipo:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, [email protected] and inform them of the time the error
occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Apache/1.3.12 Server at speedweb Port 80
Che in pratica ci informa che si sono verificati degli errori interni al server e che è necessario informare l'amministratore
di rete di quanto è accaduto. Potremmo modificare tale messaggio mediante la direttiva ServerSignature scegliendo tra
una delle tre opzioni a disposizione e cioè On - Off – Email. Di default è impostata su On dandoti così a piè di pag la
versione del server ecc; mettendo Off invece togli tale intestazione a piè di pag; in fine con EMail fai apparire un link sul
nome del tuo server che riporta alla Email configurata in ServerAdimir. Provarle tutte non ti costa nulla. Questo
comunque non è il miglior modo di gestire i messaggi d'errore ed oltretutto non funzionano neanche con tutti i possibili
errori. Per ottenere qualcosa di più decente e soprattutto nel rispetto dei nostri utenti è preferibile creare un bel po' di
pagine una per ogni tipo di errore possibile dove spiegherete che cosa è accaduto e che cosa dovrebbero fare gli utenti
stessi per ovviare ad alcuni errori.
Gli errori più frequenti sono:
400: La richiesta non può essere soddisfatta dal server per via di un errore di sintassi.
401: Errore di sintassi o richiesta impossibile da soddisfare perché è stata richiesta l'autenticazione
dell’utente.
402: E' richiesto un pagamento al fine di soddisfare tale richiesta.
403: La richiesta effettuata è proibita oppure non hai i permessi idonei per tale richiesta ( questo è uno degli
errori più frequenti che si verificano quando non configuri opportunamente i permessi dei programmini cgi ).
404: La richiesta non può essere soddisfatta in quanto il file richiesto non esiste.
500: Il server ha incontrato una condizione inaspettata.
501: Il server non sopporta il servizio richiesto.
502: Il server è temporaneamente sovraccarico di richieste da parte di altri utenti, provate a collegarvi tra
qualche minuto.
503: Il server tentando di accedere ad altri servizi non ottiene alcuna risposta.
Soffermandoci per il momento su gli errori sopra elencati, crea per ognuno di essi una bella pagina html e salvala col
nome dell'errore, ad esempio per l'errore 500 potresti preparare un file html che salverai col nome di 500.html, con il
seguente messaggio "o stai tentando di fare il furbo accedendo a risorse private oppure il tuo caro amministratore di
sistema sta trovando alcune difficoltà a configurare il servizio, ti prego di scusarmi!"
Spero di aver reso l'idea.
una volta create tutte le pagine html 400.html 401.html 402.html 403.html 404.html 500.html 502.html e 503.html le potrai
inserire in una cartella all'interno della tua directory di root "alex" che chiamerai "errore" (per rendere meglio l'idea vi
allego la cartella errore zippata ).
Fatto ciò non ti resta che riprendere il nostro bel file di confing e cercare "Customizable error response"
essa non è una direttiva ma individua le direttive per la personalizzazione dei file dei messaggi d'errori e cioè
ErrorDocument quindi scriverai quanto segue
ErrorDocument 400 http://tuoHost/errore/400.html
Ricorda di cambiare tuoHost col nome del tuo server.
Lezione 10
Configurazione di Apache per i CGI
Prima di passare al configurazione e alla modifica del file confing di Apache, è opportuno chiarire alcune
cose…
Che cosa sono le CGI e a cosa servono. Le CGI meglio conosciute come Common Gateway Interface,
tradotto in italiano Interfaccia d'Ingresso Comune, definiscono il modo in cui il Server ed i programmi
gateway comunicano specificando una serie di parametri d’ambiente, le quali offrono informazioni come
l’indirizzo del client remoto, la versione del softwareserver, o i parametri di un modulo da compilare.
Pertanto le CGI altro non sono che una specifica di programmazione riconosciuta e standardizzata per i più
diffusi server, al momento tale specifica è arrivata alla versione 1.1.
Ho avuto modo di constatare che molti confondono il Perl con le CGI, tale confusione è generata dal fatto
che le CGI nascono con il linguaggio di programmazione Perl, ecco spiegato anche perché l’interprete Perl
riesce a riconoscere sia gli script con estensioni PL che con quelle CGI, ma volendo, nessuno vi vieta di
scrivere le vostre CGI con qualsiasi altro linguaggio di programmazione, l’importante è che siano rispettate le
specifiche gateway.
Comunque a mio modesto parere il modo più semplice di scrivere le CGI rimane il Perl, dando oltretutto la
possibilità a terzi di poter prelevare il sorgente e personalizzarlo a loro gusto, un'altra ragione per il quale
preferisco il Perl è che il suo interprete e reperibile gratuitamente dal sito www.perl.com per i più diffusi
sistemi operativi, garantendo pertanto la più elevata compatibilità rispetto a quanta né possa garantire uno
stesso script scritto in C++.
Fatte queste premesse, e nella speranza che abbiate già provveduto a scaricarvi il vostro interprete Perl per
sistemi Win32, possiamo andare avanti con la configurazione del nostro bravo Server Apache.
Anche in questo caso devo fare una piccola premessa, e cioè devo ringraziare il mio amico Davide
Anastasia grazie al quale sono riuscito a trovare il modo più semplice per spiegare tale configurazione,
prima del suo aiuto tale lezione risultava scritta in una forma molto scoordinata e complessa.
Adiamo ora ad aprire il nostro file confing ed andiamo alla ricerca della nostra prima direttiva da modificare e
cioè Options
Options
Questa direttiva è una delle più strane e difficili da interpretare, in quanto sono molti i possibili scopi
applicativi rendendo difficoltoso il suo inserimento in determinate categorie o contesti. In pratica serve
all’amministratore di server per specificare i permessi e controllare a distanza ciò che gli utenti possono
consultare o meno all’interno del sito.
Di seguito sono riportate le varie specifiche di questa direttiva
All = definisce tutte le opzioni ed i permessi tranne che per MultiViews, IncludeNOEXEC e SymLinksIfMatch
ExecCGI = questa specifica serve per impostare i permessi per l’esecuzione delle CGI ( questa specifica è
inclusa in All)
FollowSymLinks
Includes = permette l’esecuzione delle include lato server
IncludeNOEXEC = questa specifica permette l’esecuzione delle include ma disabilita #exec e #include di
script CGI
Indexes = questa specifica permette la generazione delle index virtuali spiegata nelle lezioni precedenti
MultiViews
SymLinksIfMatch
Le specifiche, o argomenti, di questa direttiva possono essere elencati lasciando uno spazio vuoto tra un
argomento e l’atro, e possibile anche anteporre ad una o più specifiche il segno – o + in modo da specificare
quale ignorare e quali aggiungere, ad esempio potrete scrivere così:
Options All + MultiViews -Indexes.
in questo modo potrete specificare di definire l’esecuzione di tutti gli argomenti con All ed anche l’esecuzione
del MultiViews, che non viene compreso in All meno però la specifica Indexes che invece era compresa
all’interno di All.
Spero di essere stato chiaro.
Comunque per terminare sta pappardella sulla direttiva Options concluderemo con lo scrivere solamente All,
almeno per questa lezione.
La seconda direttiva che andremo a modificare sarà ScriptAlias /cgi-bin/ , tale direttiva specifica al server la
directory dove cercare gli script CGI e riconoscerli come tali, di default in fase d’installazione Apache ha
assegnato a tale cartella il percorso "C:/apache/cgi-bin/" ma voi potrete specificarne un qualsiasi altro, in
pratica non state facendo altro che creare una path server proprio come avete fatto per la cartella icons.
Comunque per il momento lascerei tutto così com’è.
Andando avanti dovremo cercare la direttiva AddHandler, tradotto in italiano aggiungi un appiglio una
maniglia una chiave, un qualcosa in pratica capace di far capire al server con cosa ha a che fare, in modo da
agire di conseguenza secondo le direttive sopra spiegate, noi per il momento scriveremo le seguenti
specifiche
AddHandler cgi-script .cgi
AddHandler cgi-script .pl
AddHandler cgi-script .exe
Per il momento questo è tutto ciò che vi occorre per cominciare a provare i vostri semplici script CGI, ma
presto preparerò altre lezioni in modo da implementare l’uso delle CGI con i DataBase e la posta elettronica.
Lezione 11
SSI Server Side Include per Win98 Server Apache
Cari amici, oggi impareremo a configurare il Server Apache in modo da ampliarne le potenzialità mediante
l’impiego delle ssi, Server Side Include, o meglio nel caso specifico di Apache delle Xssi (eXtended server
Side Include).
Grazie alla loro implementazione all’interno del server Web, è possibile realizzare dei siti dall’aspetto molto
professionale e dinamico, senza tuttavia imbattersi nelle comuni problematiche dei più o meno conosciuti
linguaggi di programmazione.
Infatti all’interno dei suoi tag le pagine ssi, con le classiche estensioni .stm o .shtml, contengono tutte le
specifiche in grado di comunicare con il server opportunamente configurato per interagire con le stesse.
L’uso più classico delle ssi consiste nel formattare i documenti Web assemblando in modo ordinato più
documenti, proprio come se si trattasse di semplici frame, anche se tale paragone molto riduttivo servirà per
rendere l’idea.
L’impiego delle ssi all’interno di siti Web, risale a tempi molto lontani ( si parla ovviamente di tempi relativi,
riguardanti, nel nostro caso, il mondo dell’informatica ) e cioè dall’impiego dei più anziani webserver come il
Cern, lontano antenato diretto del nostro attuale Apache, ed è ad esse che bisogna ringraziare se il Web si è
mosso dalle più squallide pagine statiche alle più fantasiose pagine dinamiche. Ovviamente da allora anche
le ssi, al pari passo dei server o di qualsiasi altro software, sono state modificate ampliando e potenziando le
loro potenzialità, potendo oggi sostituire come già detto parecchi linguaggi di programmazione o d’interagire
egregiamente con essi, il caso più classico è l’interazione con le CGI.
Non essendo questa la sede opportuna per dare altre spiegazioni sulle ssi, ci limiteremo di seguito alla
configurazione del server Apache.
Come prima operazione da fare, bisogna accertarsi che durante l’installazione di Apache sia stato installato
e configurato anche il modulo relativo alle ssi e cioè il module_include. Questa operazione nella maggior
parte dei casi è facoltativa in quanto tale modulo viene caricato di default, comunque verificare non costa
nulla, apriamo pertanto una shell del DOS e digitiamo la posizione in cui avete scelto d’installare Apache, se
avete seguito le altre lezioni passo a passo potrete tranquillamente scrivere cd C:\apache altrimenti
specificherete il vostro percorso personale, dopo di che cliccate sul tasto invio e scrivete quanto segue:
apache –l , cliccate nuovamente invio e potrete visualizzare l’elenco dei moduli installati sulla vostra
macchina, non dovete far altro che controllare che nell’elenco vi sia la stringa mod_include.c.
Se non la trovate, siete davvero sfortunati, provate comunque a cercare nel file di confing una stringa da
decommentare contenente qualcosa simile a AddModule mod_include.c se non trovate neanche questa
allora siete proprio sfigati e la soluzione più semplice consiste nel reinstallare Apache magari con una
versione più recente.
Una volta controllato con successo l’esistenza del modulo include, possiamo passare alla modifica del file di
confing in modo da settare il server per il riconoscimento dei file ssi aggiungendo le seguenti stringhe:
AddType text/html .shtml
AddType text/html .stm
AddHandler sever-parsed .shtml
AddHandler sever-parsed .stm
Fatto ciò dovremmo abilitare la directory del server in modo da permettere l’esecuzione delle ssi, se avete
seguito la lezione sulle CGI non dovrete modificare nulla della direttiva Options in quanto avendo specificato
il parametro All in esso è compreso anche il parametro Include specifico per l’esecuzione delle ssi. Potrete
inoltre specificare il parametro includesNOEXEC non contenuto in All, tale parametro permette l’esecuzione
delle ssi ma non anche dei comandi ssi.
Inoltre dovremo andare a modificare la direttiva DirctoryIndex aggiungendo index.shtml index.stm ed anche
se volete main.shtml default.shtm e tutti i nomi dei file che intendete far aprire di default al server.
Questo è tutto.
In attesa che il nostro amico Salvatore ci fornisca le sue lezione sulle ssi, vi consiglio di andare a visitare i siti
www.apache.org/docs/mod/mod_include.html (disponibile anche nella documentazione fornita con Apache)
e http://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html per la documentazione ufficiale, purtroppo in
lingua inglese, come anche il sito http://bignosebird.com/ssi.shtml dove troverete un tutorial ssi.
Per chi invece vuole mettere alla prova il corretto funzionamento delle ssi, potrà inserire nelle proprie pagine
i seguenti tag e salvare le pagina con estensione .shtml
Giorno ed ora locale: 


ed anche i seguenti
Giorno ed ora GMT (greenwich, UK): 


Il nome di questo documento è 


L'URl di questo documento è 


Modificato il 


Server name: 


Protocollo http: 


Webserver: 


Ancora qualche altro esempio pratico e poi vi lascio, create un file ti testo scriveteci dentro ciò che vi pare e
salvatelo come prova.txt nella directory root dove vi è anche il file shtml che modificherete inserendo la
seguente stringa

Scrivete ora l’url del vostro sito puntante al vostro file .shtml e vi appariranno sullo schermo le variabili prima
elencate ed un primo esempio di include, noi abbiamo deciso di includere prova.txt, ma voi intuendo il
procedimento potrete includere qualsiasi file. Se il file che volete includere non si trova nella directory del file
shtml dovrete specificarne il percorso all’interno dei tag include ssi nel seguenti modi:

oppure

Questo è davvero tutto ciò che da parte mia posso dirvi riguardante il mondo delle ssi.
Lezione 12
Rendere sicuro il nostro Server Apache
Cari amici mi ero prefissato di pubblicare questa serie di lezione sulla sicurezza, nelle prossime settimane, in
quanto richiedeva una più approfondita conoscenza del nostro Server.
Tuttavia ho deciso di pubblicarla oggi spinto da due motivi: il primo è dovuto all'implementazione nel nostro
server di funzionalità CGI e ssi che potrebbe essere causa di seri attacchi al nostro sistema, ed il secondo
motivo lo riconduco alla più striminzita, inutile, sconclusionata e limitante lezioni su Apache (la si potrebbe
considerare praticamente un'offesa a tale server) riguardante proprio la sicurezza pubblicata su www.html.it.
Premesso ciò partiamo subito col dare delle più sostanziose lezioni di sicurezza.
Sicurezza
Cominciamo subito a mettere le cose in chiaro, anche se ciò potrà amareggiarvi sappiate che non esiste al
mondo e mai esisterà la possibilità di creare un server sicuro, il vostro unico compito sarà di rendere il più
possibile ai vostri nemici la vita difficile.
Il rapporto di sicurezza da implementare al nostro server e paragonabile al modo in cui ognuno di noi
rendere difficoltosa l'intrusione dei ladri nella nostra abitazione, aumentando i sistemi di sicurezza in rapporto
ai nostri valori posseduti, per rendere l'idea provate ad immaginare il livello di protezione della banca sotto
casa vostra sicuramente noterete differenze sproporzionate rispetto a quelle adottate per la vostra
abitazione, ma nonostante ciò è più probabile che sia la banca ad essere violate, anziché la vostra piccola
casuccia.
Che cosa vuol dire ciò..? ..vuol dire che tutte le tecniche di sicurezza più o meno valide o potenti adottate a
seconda delle particolari esigenze servono solo a tenere alla larga i più sprovveduti, o quantomeno a
rendere difficile l'impresa.
Che cosa dobbiamo fare allora per difenderci?
Il nostro compito consiste nel conservare il più segreto possibile i privilegi di root, in quanto è solo lui che
può decidere il bello o il cattivo tempo all'interno della sua rete, decidendo chi può e chi no fare una
determinata azione. Ciò che dovremmo fare sarà pertanto seguire le seguenti linee di principio:
•
•
•
Nessuno deve essere in grado di copiare, modificare e cancellare file
Nessuno deve avere la possibilità di avviare programmi non approvati dal nostro Server
Configurare il server in modo da impedire ai nostri utenti con particolare permessi di commettere
errori, anche involontari (sia il vandalismo, sia l'inettitudine sono le principali cause dei disastri).
Purtroppo quando parliamo di sicurezza dei sistemi, ci riferiamo per antonomasia a quelli Unix e non a quelli
Win32, non perché non dispongano di meccanismi legati alla sicurezza, ma perché tali meccanismi sono
troppo fragili, poco documentati, e continuamente colpiti da nuovi bag.
Speriamo che le cose possano migliorare con la nuova release Windows2000, che non ho ancora avuto
modo di testare.
Tutti coloro che abbiano installato sulla loro macchina una versione di Linux, sicuramente, pur non avendoci
capito un h, avranno notato che qualsiasi operazione da effettuare deve essere eseguita da un utente noto
al sistema, che ne registrerà tutte le azioni in un file di log, in modo da poter risalire immediatamente a chi ha
causato un danno.
Tornando al nostro server, dovremmo decidere in che modo comportarci in ambiente interno, cioè
specificando i privilegi delle varie macchine client che possono collaborare con l'amministratore nella
realizzazione del server mediante una Intranet locale, ed anche come comportarci nei confronti dell'ambiente
esterno, e cioè della grande rete Internet.
E si ragazzi..! forse molti di voi lo ignoravano, ma il vostro bel Server locale funziona come tale anche in
Internet, sicuramente la maggior parte di voi non avrà a disposizione un identificativo DNS valido o un
indirizzo IP stabile, in quanto quest'ultimo cambia ad ogni nuova connessione, ma se qualche navigatore più
attento riesce ad individuarlo nel momento in cui siete connessi, non dovrà far altro che digitarlo all'interno
del suo browser come URL per visualizzare con tutta tranquillità il vostro sito locale. (questo è quello che
farebbero i più buoni se volete sapere i mezzi usati da quelli davvero cattivi vi consiglio di acquistare un libro
davvero utile edito dall'Apogeo "HACKER! Prevenire gli attacchi informatici è possibile, Tecniche di
protezione dei sistemi).
Neanche per i più impediti in materia di hacking sarà difficile scoprire il vostro identificativo Ip, in quanto
durante la navigazione lasciate tracce di voi ovunque, dalla posta, alle pagine Web, alle chat. Detto ciò, se
non volete che qualche mal'intenzionato possa navigare indisturbato nel vostro server le soluzioni da
adottare sono principalmente due o effettuate connessioni brevi oppure cominciate seriamente a mettere in
pratica restrizioni di accesso, non è detto però che non dobbiate far vedere a nessuno il vostro lavoro, anzi è
una delle soddisfazioni più grandi per un giovane amministratore, cercate tuttavia di nascondere e di limitare
i permessi per i documenti e i file più importanti e fragili, se ad esempio all'interno del vostro server avete
abilitato l'esecuzione CGI e vi state accingendo ad una rudimentale programmazione e prova delle stesse
tramite form, sarebbe opportuno restringere gli accessi a tale form, in quanto programmatori più esperti
potrebbero servirsene per conoscere informazioni riservate, questo è uno dei tanti motivi per il quale
preferisco scrivere da me le mie CGI , e consiglio a tutti di fare allo stesso modo, anziché usare script altrui
trovandomi nella condizione di dover tentare di decifrare innumerevoli stringhe dubbie delle quali se ne
potrebbe benissimo fare a meno senza tra l'altro corrompere in corretto funzionamento del programma.
Tornando a bomba, i permessi da impostare sia per l'ambiente interno che per quello esterno sono più o
meno simili, considerando infatti l'opportunità ed eventualità che anche gli utenti interni possano essere dei
potenziali cattivi magari involontariamente per inettitudine.
Dato che questa guida è dedicata ai possessori di una sola macchina, funzionante da server e da client allo
stesso tempo, tralasceremo, per il momento, le problematiche legate alle reti Intranet, approfondendo quelle
riguardanti la rete Internet.
Lezione 13
Cari amici, ieri avevamo lasciato il discorso sulla sicurezza del vostro server Apache, dicendo che ci occuperemo
soltanto delle problematiche riguardanti le reti Internet. Sicuramente la maggior parte di voi avrà sfruttato l'occasione
verificando l'effettivo funzionamento del suo server in Internet, chiamando a raduno amici e parenti per provare, e
sicuramente la maggior parte di voi avrà potuto constatare il corretto funzionamento del suo server (mi immagino la
vostra emozione), ma per quale motivo alcuni di voi non hanno avuto successo nella stessa impresa..? beh il motivo
sicuramente è da ricollegare al numero di porta configurato nel file confing diversa da quella 80 ricercata di default da
tutti i browser, diciamo che coloro che hanno modificato tale porta siano stati un po' più furbi o solo più fortunati, in
quanto già questo è da considerarsi un sistema di protezione, non tra i migliori, ma almeno basta ad allontanare i più
sprovveduti (esistono comunque programmini free appositi per scansionare in pochi minuti tutti i possibili intervalli di
indirizzi IP e le porte conducendo il cattivo al vostro server, ma dato che al momento nessuno sa della nostra esistenza
in rete, i cattivi non ci penseranno più di tanto, se invece vi mettessimo in mostra i dispettucci saranno molto frequenti,
tanto per capire di che parlo vi invito a scaricarvi dall'indirizzo web http://207.98.195.250/software/ il software free Pinger
di Rhino9). Comunque per coloro che hanno impostato una porta differente da quella 80 con ad esempio una 98, non
dovranno far altro che scrivere dopo l'indirizzo IP ":98" (127.0.0.1:98) ed il gioco è fatto, se non avete idea di dove
recuperare il vostro indirizzo IP provare a cliccare sul contatore in alto a sinistra di questo sito, l'ultimo indirizzo riportato
in elenco dovrebbe essere il vostro (per sicurezza riavviate il sito e cliccate sul contatore ora l'ultimo indirizzo è proprio il
vostro.) Abbiamo quindi verificato che il nostro server funziona benissimo in rete, ma a questo punto ed almeno fino alla
fine di queste lezioni sulla sicurezza, vi consiglio di arrestare il server prima di connettervi in rete specialmente se state
lavorando con Windows 98, perché oltre ai vostri amici, potrebbe entrare gente poco cortese, che senza alcuno
scrupolo, ed in maggior modo se non avete settato ancora alcun permesso sui file o directory chiunque potrà modificarli
a piacimento possedendo i vostri stessi privilegi , e date retta a me questo è peggio che se gli avessero solo cancellati,
se ad esempio nel vostro server sono state abilitate le CGI senza specificare accuratamente i permessi, il primo cattivo
di turno non impiegherà più di dieci secondi a modificare la tua pagina con pochi comandi capaci, in meno di quante
possiate immaginare, di formatterà l'intero HD irrimediabilmente.
Comunque detto ciò passiamo avanti e parliamo oggi dei codici di status, e bene conoscerli tutti al fine di poter
interpretare i file di log del vostro server non è che servano un gran che alla sicurezza ma cominceremo proprio da essi
per capire come funzionano tali file. Sapendo interpretare i codici di stato potrete avere un idea di cosa è stato chiesto di
fare al server e come esso si sia comportato, i file di log sono dei veri e propri file diagnostici, quindi se credete di aver
limitato l'accesso a qualcuno a un determinato file, e poi scoprite nel file di log un bel numero 200, allora avete fatto solo
un bel buco nell'acqua. Anche se al momento non mi vengono in mente gli indirizzi web, vi ricordo che vi sono in
circolazione moltissimi programmini capaci di esaminare e sminuzzare tali file facilitandovi il compito d'interpretarli, se ne
avete le capacità potrete anche scriverne di vostri in Perl, comunque non appena riesco a ritrovarne qualcuno facile e
decente vi informerò. Per oggi basta così di seguito e riportata una tabella con i codici di status.
100 Continua
101 Switch di protocollo
200 OK 201 Creato
202 Accettato
203 Informazioni non-authoritative
204 Nessun contenuto
205 Reset del contenuto
206 Contenuto parziale
300 Scelte multiple
301 Spostato in modo permanente
302 Spostato temporaneamente
303 Vedere altro
304 Non modificato
305 Utilizzare Proxy
400 Richiesta errata
401 Non autorizzato
402 Pagamento richiesto
403 Vietato
404
405
406
407
408
409
410
411
412
413
414
415
500
501
502
503
504
505
Non trovato
Metodo non permesso
Non accettabile
Richiesta di autenticazione del Proxy
Timeout della richiesta
Conflitto
"Gone"
Lunghezza richiesta
Prerequisito fallito
entità di richiesta troppo grande
URl della richiesta troppo lunga
Tipo di media non sopportato
Errore interno del server
Non implementato
Gateway errato
Servizio non disponibile
Timeout del gateway Versione HTTP non sopportata
Lezione 14
Variabili d'ambiente personalizzate
Salve a tutti, oggi illustrerò il modo di creare variabili d'ambiente personalizzate. Quando viene chiesto al
WebServer di eseguire uno script sia esso CGI, Perl, PHP, ssi e quant'altro possa esistere, riceve in
ingrasso numerose variabili settate di default sulla macchina server, potreste comunque sentire la necessità
di volerne passare alcune per proprio conto, sia per schiribizzo, sia per particolari script da voi scritti.
Per creare nuove variabili d'ambiente ci viene in aiuto una direttiva d'Apache, tra le numerose non elencate
di default nel file di confing, e cioè SetEnv, per mezzo del quale potrete specificare tutte le variabili e i valori
che volete.
Ad esempio potrete aggiungere una variabile riguardante l'amministratore di rete aprendo il vostro file
confing e scrivendo al suo interno la nuova direttiva in questo modo:
SetEnv NOME_AMMINISTRATORE Ing_Pinco_Pallino
Dove SetEnv corrisponde alla direttiva, NOME_AMMINISTRATORE corrisponde alla nuova variabile e
Ing_Pinco_pallino al corrispondente valore. Compreso il procedimento potrete creare allo stesso modo tutte
le variabili che vorrete.
Di seguito è riportato un piccolo script CGI scritto in Perl, in grado di visualizzare l'elenco completo di tutte le
variabili, non dovrete far altro che copiarlo e salvarlo in un file di testo con estensione CGI o PL nella
directory cgi-bin insieme a tutti gli altri script del vostro server, e richiamarlo dal server mediante un link.
#!c:\perl\bin\perl.exe
print "Content-type: text/html\n\n";
print "<html><head><title>Variabili d'ambiente</title></head>\n";
print "<body>\n";
foreach $key (sort keys %ENV)
{
print $key, "=",$ENV{$key}."\n";
}
print "</body></html>\n";
Lezione 15
Personalizzare le variabili d'ambiente a seconda del browser
Oltre alla direttiva SetEnv illustrata la scorsa lezione, esistono altre direttive capaci di aggiungere nuove variabili
d'ambiente al nostro Server, oggi illustreremo come modificare il nostro file confing in modo tale da informare mediante
l'impiego di nuove variabili ciò che un determinato browser può visualizzare correttamente, per ottenere ciò faremo uso
della direttiva BrowserMatch.
Come saprete i client non usano tutti lo stesso browser per navigare in rete, e purtroppo ogni software browser, pur
vantando innaturali capacità, non tiene conto di uno standard comune a tutti gli altri, rendendo praticamente incompatibili
le varie tecniche impiegate nel nostro sito a circa il 50% degli utenti, oltre a ciò si aggiunge anche la persistenza di
software un po' troppo datato incapace di visualizzare correttamente le immagini, i frame, gli applicativi Java, JavaScript,
ecc. ecc.
Generalmente in questi casi i WebMaster si impegnano in modo da fornire ai loro utenti più versioni del loro sito,
invitando gli stessi a cliccare qui o li a seconda del browser utilizzato, anche se ciò rende il tutto molto più professionale
(anche se si potrebbe ottenere lo stesso risultato con poche righe di JavaScript), molti utenti comunque ignorano quello
che il proprio browser può o non può visualizzare. A questo scopo potrebbe risulterebbe utile impiegare uno script CGI,
quello illustrato ieri va benissimo, con il quale si chiede di visualizzare le variabili d'ambiente, tra le quali avremo settato
le nostre personalizzate, che leggendo il valore fornito dal browser del client riporterà le chiavi di ciò che lo stesso è in
grado di fare o di non fare, a seconda delle nostre scelte.
Passiamo ora ad un esempio pratico, tutti noi sappiamo che versioni precedenti alla 3 sia di Netscape sia di Explorer non
sono in grado di visualizzare correttamente le Applet Java o JavaScript, pertanto sarà possibile informare tutti coloro che
utilizzano tali versioni aggiungendo la seguente direttiva nel nostro file di confing:
BrowserMatch ^Mozilla/[23] Applet_Java=Non sopportati JavaScript=Non sopportati
In sostanza non si chiede alla direttiva BrowserMach di analizzare tramite il carattere ^ la stringa Mozilla e di cercare al
suo interno qualcosa che corrisponda al contenuto delle parentesi quadre in questo caso la versione 2 o 3, se il server
trova questi valori riporterà le variabili "Applet_Java" e "JavaScript" con le rispettive chiavi da noi impostate "non
sopportati", per le versioni precedenti alla 2 e alla 3 di tali browser, non sono sopportati neanche i css i frame e tante
altre cose, che voi potrete decidere d'aggiungere alla direttiva.
Se ad esempio avete ottimizzato il vostro sito per Netscape potrete avvertire i possessori di Explorer dell'impossibilità di
visualizzazione inserendo tra le parentesi quadre la parola "MSIE" al posto del numero di versione, ed aggiungendo tutte
le variabili che ritenete più opportune.
Oltre a BrowserMatch esiste anche la direttiva BrowaerMatchNoCase, che è praticamente identica alla prima tranne per
il fatto che vengono ignorate le differenze tra lettere minuscole che maiuscole, con il risultato che scrivere Mozilla risulta
uguale a scrivere mOzILla o MoZiLlA.
Lezione 16
File Config
Carissimi amici, eccomi di nuovo insieme a voi per una nuova lezione su Apache, in realtà avevo in mete ben altre
lezioni da illustravi, ma essendoci ancora qualcuno rimasto indietro, riprenderò il discorso partendo dal file confing o
come lo chiamano in molti file config.
Per chi ancora non l'avesse intuito il file denominato config altro non è che il file httpd.conf reperibile all'interno della
directory C:\apache\conf\.
Molta gente è spaventata dalla moltitudine d'informazioni presenti nel file confing del server Apache, e dopo poche
modifiche errate si perde facilmente, nel suo contenuto, alla ricerca dell'errore.
In questa lezione spiegheremo cosa è questo fantomatico file, suddividendo il suo contenuto in due insiemi, i Commenti
e le Direttive.
I commenti possono identificarsi, in un primo momento, in tutte quelle scritte in lingua inglese precedute a capo d'ogni
stringa dal carattere # (cancelletto), e che potrete modificare come meglio volete, traducendole, implementandole con
vostre considerazioni, se non addirittura cancellarle completamente, esse infatti non sono altro che promemoria per
l'amministratore di rete (che sareste sempre voi) e vengono ignorate dal server in fase di avviamento, tra i commenti si
possono inoltre trovare delle direttive che non si vogliono far caricare al server e quindi commentate mediante l'uso del
#, mentre, se in futuro deciderete di voler utilizzare, non dovrete far altro che decommentarle cancellando il #.
Le direttive, invece, rappresentano la parte vitale del server, in esse si trovano tutte le istruzioni che il server deve
eseguire, sostengo che le direttive siano di vitale importanza, in quanto non appena il server si accorge di un errore
all'interno di una di esse si rifiuta di avviarsi.
Se volete conosce l'errore riscontrato dal server in fase di avviamento dovrete andare a leggere il file error.log nella
cartella logs di apache in C:\apache\logs\.
Durante l'installazione il server prepara il file di config scrivendo alcune delle direttive standard per una configurazione di
base per il vostro Server, lasciando a voi il solo compito di settare alcuni parametri, esse in realtà sono solo alcune tra le
più comuni direttive in quanto, almeno secondo le mie fonti, ne esistono quasi 190, che ci divertiremo a scoprire e settare
nel corso di queste lezioni.
Per tutti coloro che ancora non sono riusciti a configurare il loro Server Apache consiglio di creare un file di backup del
loro file config e di sostituirlo con questo, che ho scritto appositamente per voi, in esso sono riportate le direttive di base
e le istruzioni per modificarne alcune. Volendo potrete anche scaricare lo stesso file in formato zip.
Lezione 17
I MIME
Che cosa sono i MIME? e come utilizzarli per migliorare l'aspetto del proprio sito?
La termine MIME è l'acronimo di Multimedia Internet Mail Extensions, ed è colui che si occupa del riconoscimento
dell'estensioni dei file. Il Server Apache riesce a gestisce tali estensioni, grazie all'impiego del modulo mod_mime.c,
installato di default insieme ad un file con un elenco di tutte le più comuni estensioni, rintracciabile nella cartella
../apache/conf/mime.types.
Se all'interno del file mime.types non riuscite a trovare una particolare estensione, potrete aggiungerlo voi, oppure
servirvi di alcune direttive specifiche del file confing, che descriveremo nel seguito di questa lezione.
Generalmente il file mine.types viene individuato dal server tramite la direttiva TypesConfig specificando il valore
conf/mime.types, ma nessuno vi vieta di mutare tale posizione, se non addirittura crearne un nuovo tipo per ogni
directory specificata (Opss..! mi ero scordato che non vi ho ancora spiegato come configurare più directory all'interno del
vostro Server Apache, vabbè lo farò domani, ..forse).
Vediamo ora come potreste personalizzare il vostro file mime.types:
Innanzi tutto apritelo con un semplicissimo editor di testo,BloccoNote è più che sufficiente
Individuate tra i vari tipi quello che più si assomiglia al vostro file ed aggiungete l'estensione, ad esempio per specificare
l'estensione del file rar, la classica estensione dei file compressi generati con WinRar, andrete a cercare nell'elenco il
tipo di file che più si assomiglia, in questo caso potremmo associare la nostra estensione alla stringa application/zip zip
aggiungendo appunto il nome rar il risultato della stringa sarà application/zip zip rar, e ovvio che sulla stessa stringa
potrete aggiungere tutti i tipi d'estensioni che volete, senza dar nessun peso all'ordine con il quale vengono scritte.
Se proprio non riuscite a identificare nessuna tipologia di file, che assomigli alla vostra, ne aggiungerete di vostre
personalizzate.
Ora invece, vediamo d'illustrare come sia possibile modificare ed aggiungere i MIME, all'interno del file confing, senza
quindi dover intervenire nei modi precedentemente esposti. Per far ciò, utilizzeremo le seguenti direttive
AddType, AddEncoding, DefaultType, ForceType.
AddType
Questa direttiva serve per aggiungere nuove estensioni a particolari tipi di MIME in modo da indicare al server che cosa
rappresenti la nostra estensione, la direttiva potrà essere rappresentabile sinteticamente così mime-type est. est. ..., e
cioè ad esempio:
text-html htm html shtml ecc.
AddEncoding
A differenza di AddType, questa direttiva indica al server com'è può essere riconosciuto un tipo d'estensione,
aggiungendo nuovi tipi di codifica, ad esempio potremmo decidere di far interpretare al server il file rar, come se fossero
dei file zip, istruendolo in modo tale da inviarceli codificandoli tramite x-gzip (l'aggiunta della x- è facoltativa e serve per
mantenere la compatibilità con i browser più datati, diversamente basterà semplicemente gzip), scrivendo a questo
scopo
AddEncoding x-gzip zip rar gz tgz ecc.
DefaultType
Mediante l'utilizzo di questa direttiva, potremo decidere il tipo di MIME da utilizzare nel caso in cui il server non fosse in
grado di trovare nel file mime.types o nel file config il tipo d'estensione per il file richiesto dal client, questa direttiva è
valida anche quando non si specifichi l'estensione di un file. A questo scopo potremmo utilizzare la seguente direttiva
DefaultType text/html se vogliamo avere per risultato una pagina in html, mentre se vogliamo avere una pagina di testo
scriveremo
DefaultType text/plain.
ForceType
Questa direttiva è utile al fine di voler nascondere l'estensione di alcuni file, (sinceramente non è che abbia capito un
granché sulla loro utilità, forse potrebbe essere utile ai cattivi per nascondere, ad esempio, i loro mp3 dalle ricerche, ed
oltretutto ho notato comportamenti assai differenti a seconda del browser impiegato dal lato client, nuovi o vecchi essi
siano).
Immaginiamo che voi avete una bella raccolta di immagini o di mp3 o di quello che volete, se cancellassimo l'estensioni
di questi file, senza modificare il file confing, richiamandoli dal browser non otterremo altro che stringhe incomprensibili,
dovute alla codifica in txt o html, a seconda di come abbiamo impostato DefaultType, per risolvere questo inconveniente
basterà gestire una nuova directory all'interno del file config (avete visto! ed io che pensavo di parlarvene domani).
Raccogliamo tutte i nostri mp3 e mettiamoli in una nuova cartella all'interno della directory di root, chiamandola ad
esempio mp3box, fatto ciò non ci resta che andare nel file di config e scrivere in una qualsiasi posizione le seguenti
stringhe:
<Directory /mp3box>
ForceType audio/mpeg
<Directory>
Così facendo pur non avendo specificato l'estensione dei vostri mp3, e pertanto nascondendoli alle ricerche a tappeto
tipo "cerca *.mp3", richiamandoli dal browser potrete ascoltare la vostra musica.
Lezione 18
Negoziazione della lingua
Salve a tutti, e colgo l'occasione per ringraziarvi della vostra fiducia, grazie alla quale siamo stati in grado di raggiungere
in meno di due settimane la soglia delle 200 visite, non me lo sarei mai aspettato, comunque con l'augurio di raggiungere
in futuro lo stesso numero di visite per giorno, proseguiremo oggi con l'illustrare altre funzionalità dei MIME al fine di far
interagire in background il server con la macchina client.
Generalmente, i siti più professionali mettono a disposizione dei propri utenti più versioni delle loro pagine nelle più
svariate lingue, ma per offrire un sito davvero professionale, non si dovrebbe invitare l'utente a cliccare su questo o
quell'altro link, al fine di scegliere la lingua desiderata, ma bensì lasciare al server il compito di individuare la lingua
appropriata, interrogando il browser del client.
Non so se ci avete mai fatto caso, ma tutti i browser, almeno quelli più recenti, vi danno la possibilità di scegliere uno o
più tipi di linguaggi, per le pagine che intendete aprire di default sul web, se andate a controllare, vi accorgerete che il
software imposta in maniera standard il linguaggio in base alla versione del browser stesso (ad esempio IE in italiano
imposterà come linguaggio di partenza l'italiano, mentre se IE fosse stato in inglese il linguaggio risulterebbe l'inglese),
comunque voi potete scegliere il linguaggio che più vi aggrada ed eventualmente i linguaggi secondari.
Passiamo ora al nostro bel file di confing, apriamolo ed andiamo a cercare la direttiva Options, se avete seguito
attentamente le altre lezioni, dovrebbe riportare come valore la specifica All alla quale aggiungeremo MultiViews
scrivendo in questo modo Options All +MultiViews.
A questo punto non ci resta che andare a ricercare la direttiva AddLanguage, queste direttive sono gia belle e
configurate pertanto non dovremo preoccuparcene più di tanto, comunque nel caso vogliate specificarle in un altra
directory, ed anche per coloro che hanno fatto uso del mio file config pubblicato i giorni scorsi, questo sono le specifiche
d'aggiungere:
AddLanguage fr .fr
AddLanguage de .de
AddLanguage en .en
AddLanguage it .it
AddLanguage es .es
In pratica, non abbiamo fatto altro che specificare nuovi MIME al nostro server, da ricollegare ai suddetti linguaggi e cioè
il francese, il tedesco, l'inglese, l'italiano, e lo spagnolo, seguendo lo stesso principio potrete aggiungere tutte i linguaggi
più assurdi, comunque per assicurarvi un buon risultato è bene non inventare nuove lingue al di fuori di quelle elencate
alla voce lingue dei browser o quantomeno di mantenervi tra i 56 linguaggi offerti da Netscape
(modifica>preferenze>linguaggi>) anziché considerare tutte i 150 forniti da Explorer (strumenti>opzioni
internet>generale>lingue...).
Definiti i linguaggi potremo avere anche la necessità di specificare con quale priorità inviare, ad esempio, una pagina in
italiano anziché in inglese o francese, nel caso in cui il client richiami una pagina dal nostro server senza specificare
nessun linguaggio. Per ottenere questo utilizzeremo la direttiva LanguagePriority all'interno del file confing,
modificandone i valori a nostro piacimento, seguendo l'esempio precedente potremmo scrivere:
LanguagePriority it en de fr sp
In questo modo il server andrà a visualizzare il file richiesto dal client cercando prima se ne esiste uno con estensione it,
se non lo trova passa en, e via di seguito.
Ora che il nostro file Config è stato configurato a dovere, per il riconoscimento delle lingue, non dovremo far altro che
creare all'interno della nostra cartella di root più versioni multilingue dei nostri file, aggiungendo ad essi l'estensione
appropriata, e cioè .it per quelli in italiano .en per quelli in inglese ecc.
A titolo d'esempio creeremo cinque versioni della vostra homepage per le lingue sopra elencate, ovviamente per il
momento non vi è alcun bisogno di tradurre tali pagine, ma basterà aggiungere al loro interno la scritta versione italiana,
versione francese, ecc. Fatto ciò, salverete tali pagine come index.html aggiungendo l'estensione della lingua, il risultato
sarà index.html.it, index.html.en, index.html.de, index.html.es, index.html.fr
Per provare il tutto, salvate il file confing e riavviate il server, poi andate nel vostro browser e scegliete una delle lingue
che volete utilizzare, ad esempio l'inglese, richiamate il vostro sito e se vi appare versione inglese, il tutto è stato
configurato a dovere. Come non esce..? Beh riprova tutti i passaggi e vedrai che uscirà.
Ovviamente il discorso va ampliato a tutto il sito e non solo alla prima pagina, altrimenti, nel nostro caso, tutti i link del
sito versione inglese riporteranno alle sole ed uniche pagine in italiano.
Lezione 19
Negoziare le immagini
Oggi impareremo a far negoziare l'immagini contenute nel nostro server con i software client dei nostri utenti, purtroppo
come tutti saprete, ormai sono diverse lezioni che mi ripeto, ogni browser si comporta a modo suo, ed anche per quanto
riguarda la visualizzazione delle immagini, non esiste uno standard comune a tutti, ce chi può visualizzare i png chi solo
le gif e le jpeg, ecc. ecc., per farvi un idea di ciò che intendo dirvi andate a caricare l'esempio cgi, che vi ho mostrato la
scorsa lezione, e vi accorgerete che tra le variabili appare anche HTTP_ACCEPT che rappresenta tutti i MIME
riconosciuti dal browser che state utilizzando, sicuramente il risultato avrà delle piccole differenze se cambiate browser,
in sostanza vi viene indicato l'ordine con il quale il server, lette l'informazioni ricevute dal client deve inviare l'immagine, o
quantomeno invia l'immagine più piccola, in dimensione di byte.
Per comprendere meglio, ciò che intendo, passiamo subito ad un esempio, andate a modificare nella vostra index un
collegamento ad un immagine cancellando l'estensione.
es.
<img border="0" src="file:///C:/Apache/icons/apache_pb.gif" width="259" height="32">
diventerà
<img border="0" src="file:///C:/Apache/icons/apache_pb" width="259" height="32">
Fatto ciò, dovremmo andare a modificare il file config alla direttiva Options aggiungendo MultiViews, ma dato che
l'abbiamo fatto ieri, questa operazione non c'interessa.
In ultimo andremo ad aprire il nostro programma preferito, per la manipolazione dell'immagini, cercate di procurarvi dei
programmi decenti, del tipo PhotoShop, PaintShop, FireWorks ecc, e manipolate la vostra immagine in modo da
salvarne più versioni con estensione jpeg png ecc, nella cartella in cui puntava il nostro link e dove c'è la gif di partenza.
Fatto questo, avvierete Apache ed andrete ad aprire la vostra home page, il server tramite la direttiva MultiViews,
analizzerà il vostro link, che volutamente, non specifica l'estensione, ed andrà alla ricerca del nome del file inviandovi
generalmente quello che viene meglio gestito dal vostro browser o quantomeno quello più piccolo, tra quelli che avrete
messo a sua disposizione e cioè gif jpeg e png.
Lezione 20
Mapping dei tipi
Oggi termineremo il discorso sulla negoziazione dei documenti Web illustrando le mappe dei tipi (type maps), meglio
conosciuti come file *.var. Nelle ultime due lezioni abbiamo visto come sia possibile negoziare i documenti mediante la
direttiva Options MultiViews, anche se validissimo come metodo, non è certo il migliore. Grazie all'implemento dei
mapping dei tipi sarà possibile integrare nelle negoziazioni dei documenti anche i vari plug-in dei browser, rendendo
molto più flessibile l'associazione dei file.
Come ormai di consueto, andremo a modificare il nostro file di config in modo d'aggiungere le seguenti direttive:
AddHandler type-map var
DirectoryIndex index.var
Come avete potuto notare non abbiamo fatto altro che specificare un nuovo tipo di MIME mediante la direttiva
AddHandler, ed aggiungere alla lista della direttiva DirectoryIndex il nuovo file che vogliamo far aprire di default dal
server, si consiglia di inserire index.var a capo di tutta la lista di file (Es: DirectoryIndex index.var index.html index.shtml
ecc).
Ora, nella speranza che abbiate seguito le lezioni precedenti e fatto le vostre prove, dovreste disporre, nella vostra
directory di root, di più versioni multilingue del file index e di un bel po' d'immagini uguali in formati differenti, per cui non
ci resta che creare, sempre nella root-directory, mediante un editor di testi, il nostro file index.var, dove andremo a
scrivere quanto segue:
# questa prima riga rappresenta il nome privato del file
URI: index; vary='language'
# ora impostiamo l'URL del nostro file index in italiano
URI: index.html.it
# specifichiamo il tipo di codifica in html
content-type: text/html
# ed in fine specifichiamo il MIME del linguaggio
content-language: it
# una volta compreso il procedimento ripetiamo le sudette
# operazioni per tutti gli altri index in nostro possesso
# in questo caso ho specificato oltre all'italiano anche
# l'inglese, lo spagnolo, il tedesco e il fracese.
URI: index.html.en
content-language: en
URI: index.html.es
content-language: es
URI: index.html.de
content-language: de
URI: index.html.fr
content-language: fr
Fatto ciò, passeremo ora a definire il file .var per le immagini, nel nostro esempio prenderemo in esame una sola
immagine, una volta compreso il procedimento vi potrete divertire a definire un file .var per ogni vostra immagine
presente sul server.
In questo esempio, faremo finta di avere nella nostra directory di root più file contenenti la stessa immagine ma con
estensioni differenti, ammettiamo quindi di chiamare questa immagine "miaimg" e di averne una copia in gif jpg e png,
creeremo nuovamente un nuovo file var chiamandolo miaimg.var, scrivendo al suo interno quanto segue:
URI miaimg; vary="type"
URI:miaimg.gif
Content-type: image/gif; qs=0.8 level=3
URI:miaimg.png
Content-type: image/png; qs=0.9 level=10
URI:miaimg.jpg
Content-type: image/jpg; qs=0.7 level=7
Come avrete potuto notare, la procedura è molto simile a quello descritto per il file index.var, infatti come prima cosa
andrete a specificare l'URL del nome del vostro file, poi indicherete il tipo di variazione tramite il comando vary, nel
nostro caso type, (altri tipi oltre a language per la lingua, sono: charset per i caratteri, encoding per la codifica e length
per la dimensione del file), il nome dell'intestazione si ottiene aggiungendo a tali valori il prefisso Content-, pertanto le
intestazioni possibili saranno: Content-type, Content-language, Content-charset, Content-encoding, Content_length.
I numeri qs e level indicano un indice di qualità da 0 a 1, scelto a piacere dal webmaster, che aiutano il server a preferire
un file ad un altro a seconda del valore più alto.
Lezione 21
Direttive di Blocco
A rieccomi qua! Pensavate che vi avessi abbandonato vero? Ed invece no, son sempre qui per voi, mi son solo preso
una piccola vacanza per festeggiare il 30 e lode, del mio amico Giordano, e per convincerlo ed aiutarlo a dare inizio alla
stesura delle lezioni sul Perl, pubblicandone quattro in una sola serata.
Oggi parleremo delle direttive di blocco messe a disposizione dal Server Apache, per permettere di limitare l'esecuzione
di altre direttive a particolari host virtuali , directory o file.
E' molto importante conoscere ed implementare il proprio sito Web, con le direttive di blocco, grazie ad esse infatti ogni
WebMaster può configurare e settare un numero infinito di host virtuali gestibili tramite un unica istanza di Apache, in
modo da settare limitazioni e privilegi per ognuno di essi.
VirtualHost
La direttiva <VirtualHost> si comporta allo stesso modo di un tag html, determinando l'inizio di un blocco di testo
contenente direttive dirette ad un singolo host, per definire invece la fine di del host virtuale utilizzeremo la direttiva
<\VirtualHost>.
Di seguito è riportato un esempio sintetizzato della direttiva VirtualHost
<VirtualHost host[:port]>
.....
<\VirtualHost>
Mentre un esempio più realistico potrebbe essere così rappresentato:
<VirtuaHost www.nuovohost:1060>
# scegli il nome DNS da dare al tuo host virtuale
# oppure l'indirizzo IP
# e se lo credi necessario specifica un numero
# di porta, non indicandola verrà utilizzata
# la porta 80 di default
ServerAdmir amministratore@nouvohost
# specificare l'indirizzo email del l'amministratore del nuovohost
DocumentRoot C:\apache\cartellanuovohost
# Specificare la cartella dove ricercare il sito del nouvohost
ServerName www.nuovohost
# Specificare il nome DNS del sito
ErrorLog logs/error_nuovohost.log
# Specificare il nome ed il percorso del file log che raccoglierà
# gli errori del nuovo sito
TrasferLog logs/access_nuovohost.log
# Specificare il nome ed il percorso del file log che raccoglierà
# gli accessi al nuovo sito
......
<\VirtualHost>
Come avrete potuto notare, non abbiamo fatto altro che specificare alcune delle direttive già illustrate nelle lezioni
precedenti, per la configurazione del nostro server per la definizione dell'host principale. Ovviamente alle direttive
illustrate nel nostro esempio potremmo aggiungerne altre a nostro piacere.
Ora che avete compreso come realizzare il vostro nuovo host virtuale, ne potrete creare quanti volete, anche se non vi
posso assicurare il loro funzionamento su sistemi Win98, almeno che non siate degli hacker esperti o che non andiate a
registrare presso il NIC un DNS valido, questo è uno dei casi per il quale preferisco l'impiego di Linux, in modo da
potermi inventare tutti gli indirizzi IP e nomi DNS, d'adoperare in una Intranet locale.
Oltre all'utilizzo della direttiva <VirtuaHost> esistono anche altre direttive simili, capaci di limitare l'applicazione delle
altre direttive, e cioè:
<Directory>
<Files>
<Location>
Queste tre direttive sono state elencate in ordine crescente di importanza, infatti la direttiva <Directory> viene
scavalcata dalla direttiva <File>, a sua volta scavalcata dalla direttiva <Location>.
Lezione 22
<Directory> e <DirctoryMatch>
La direttiva <Directory> permette di implementare altre direttive soltanto all'interno della directory specificata.
Di default il file config viene configurato mediante la direttiva <Directory /> ... <\Directory>, riferendosi a tutte le directory
del nostro file system, ma voi potrete specificare tutte le directory che volete inserendo il percorso relativo alla cartella,
ammettendo quindi che vogliate specificare delle limitazioni alla cartella "prove", contenuta nella directory di root, non
dovrete far altro che impostare la seguente direttiva:
<Directory /prove>
....
</Directory>
Dove, al posto dei puntini, andrete ad inserire le direttive con le quali desiderate gestire il comportamento della cartella.
Oltre a specificare il nome della cartella è anche possibile utilizzare dei caratteri jolly, come il punto interrogativo "?" per
indicare un singolo carattere, oppure l'asterisco "*" per indicare una qualsiasi sequenza di caratteri, ed anche le
parentesi quadre"[ ]" per indicare una sequenza di caratteri, ad esempio [a-b-d] indica al server che la direttiva e rivolta a
tutte le directory contenenti nel loro nome il carattere "a" o "b" o "c" ed ovviamente anche tutti e tre, fate attenzione a non
confondere il carattere minuscoli con quelli maiuscoli, in quanto il Server Apache, essendo case sensitive, li considererà
come caratteri differenti.
La direttiva <DirectoryMatch>, corrisponde alla direttiva <Directory ~/>, e cioè, vuol dire che tale direttiva si aspetti
come parametro un espressione regolare. Ad esempio se andremo a scrivere una direttiva del tipo <DirectoryMatch /*>
chiederemo al server di riferirsi a qualsiasi cartella contenuta all'interno della nostra directory di root.
Lezione 23
<Files> <FilesMatch>
La direttiva <Files> limita l'applicazioni delle direttive contenute in un blocco, ai file specificati dalla direttiva stessa, nelle
esempio che segue, ci riferiremo al file prova.htm contenuto nella directory root/prove/
<Files /prova.htm>
....
</Files>
Dove, al posto dei puntini, andrete ad inserire le direttive con le quali desiderate gestire il comportamento del file
prova.htm. Oltre a specificare il nome del file è anche possibile utilizzare dei caratteri jolly, come il punto interrogativo "?"
per indicare un singolo carattere, oppure l'asterisco "*" per indicare una qualsiasi sequenza di caratteri, ed anche le
parentesi quadre"[ ]" per indicare una sequenza di caratteri, ad esempio [a-b-d] indica al server che la direttiva e rivolta a
tutti i file contenenti nel loro nome il carattere "a" o "b" o "c" ed ovviamente anche tutti e tre, fate attenzione a non
confondere il carattere minuscoli con quelli maiuscoli, in quanto il Server Apache, essendo case sensitive, li considererà
come caratteri differenti.
La direttiva <FilesMatch>, corrisponde alla direttiva <Files ~/>, e cioè, vuol dire che tale direttiva si aspetti come
parametro un espressione regolare. Ad esempio se andremo a scrivere una direttiva del tipo <FilesMatch /*>
chiederemo al server di riferirsi a qualsiasi file contenuta all'interno della nostra directory di root.
Lezione 24
<Location> <LocationMatch>
La direttiva <Location> limita l'applicazioni delle direttive contenute all'interno del suo blocco, alle URL specificate, nelle
esempio che segue, ci riferiremo alla URL http://tuohost/prove/prova.htm puntante al file prova.htm contenuto nella
directory root/prove/
<Location http://tuohost/prove/prova.htm>
....
</Location>
Al posto dei puntini, andrete ad inserire le direttive con le quali intendete gestire l’applicazione dell'URL.
Oltre a specificare l'URL è anche possibile utilizzare dei caratteri jolly ed espressioni regolari tramite il simbolo "~". Dalla
versione 1.3 di Apache, i simboli come il punto interrogativo "?" e l'asterisco "*", non sono più utilizzabili per indicare il
carattere "/".
La direttiva <LocationMatch>, corrisponde alla direttiva <Location ~/>, e cioè, vuol dire che tale direttiva si aspetti
come parametro un espressione regolare. Ad esempio se andremo a scrivere una direttiva del tipo <LocationMatch /*>
chiederemo al server di riferirsi a qualsiasi URL contenuta all'interno della nostra directory di root.
La maggior parte delle operazioni permesse all'interno di una direttiva di blocco <Directory> sono permesse anche nelle
direttive di blocco <Location> , con la differenza che la direttiva AllowOverride pur non causando alcun errore
all'interno del blocco <Location> verrebbe comunque ignorata.
Lezione 25
<IfDefine> </IfDefine>
La direttiva <IfDefine> abilita l'esecuzione di un blocco solamente se il flag -Dname è stato specificato
all'avvio d'Apache. In questo modo è possibile includere e gestire più configurazioni all'interno dello stesso
file config. Più che per la gestione di veri server, questa direttiva è indicata solo per gestire gli aspetti di test
e di distribuzione di siti dedicati. Nell’esempio che segue è riportato uno schema sintetico della direttiva
<IfDefinenome>
....
</IfDefine>
<IfModule> </IfModule>
La direttiva <IfModule> abilita il blocco solo a condizione che il modulo indicato sia stato compilato o caricato
dinamicamente in Apache, esempio:
<IfModule module-name>
....
</IfModule>
Se invece s’indica anche il carattere "!" il blocco sarà attivato solo a condizione che il modulo non sia
compilato o caricato dinamicamente. Esempio:
<IfModule [ ! ]module-name>
....
</IfModule>
I blocchi <IfModule> possono contenere a loro volta altri blocchi interni.
Lezione 26
AccessFileName .htaccess
In questa lezione cercherò di illustrarvi nel modo più semplice possibile che cosa sia e a che cosa possa servire un file
.htaccess all'interno del nostro sito Web. Prima di proseguire, comunque, voglio avvertirvi che tali file non sono
riconosciuti dai sistemi Windows, pertanto, in previsione di future lezioni, vi consiglio di procurarvi quanto prima una
versione di Linux, e d'istallarla insieme a Windows, a tutti coloro che si avvicinano per la prima volta al mondo Linux,
suggerisco di acquistare in edicola Inter.net di settembre, la quale, oltre ad essere un’ottima rivista, offre la nuovissima
versione 7.1 di Linux Mandrake, in quanto grazie alla sua semplicità d'installazione e configurazione, risulta la
distribuzione ideale per tutti i neofiti. L'.htaccess file, altro non è che un semplice file di testo, dove elencare una serie di
direttive specifiche del Server Apache, da inserire nelle cartelle del nostro sito Web. Come accade per il file di config,
anche il file .htaccess non deve contenere alcun elemento speciale di formattazione, e qualsiasi altra informazione non
inerente con le direttive, come ad esempio i promemoria, devono essere commentati con gli ormai noti caratteri #.
Grazie all'impiego di tali file, il WebMaster ottiene il controllo del suo spazio, senza che esso debba intervenire
direttamente sul file di config, dandoli inoltre la possibilità di modificarne le direttive contenute al suo interno senza dover
riavviare di volta in volta il server. Per rendere meglio l'idea, proseguiamo la lezione, facendo alcuni esempi pratici, per
tutti coloro che non hanno a disposizione una macchina Xnix suggerisco di procurarsi uno spazio server in internet che
possieda queste funzioni, sicuramente l'ideale sarebbe trovarne uno gratuito come quello offerto da www.f2s.com, solo
che al momento non accetta nuove iscrizioni. La prima cosa da fare, è quella di controllare che nel nostro file config sia
abilitata la funzione htaccess, dico controllare, in quanto essa viene applicata di default, qualunque sia il sistema
operativo scelto, durante l'installazione del WebServer Apache, quindi a noi non resta altro che controllarne l'esattezza
ed eventualmente modificarne alcune impostazioni a nostro piacimento.
Vediamo quindi come debba apparire il nostro file config:
<files .htaccess>
order allow,deny
deny from all
</files>
La prima direttiva indica il nome che si vuol dare a questo speciale file di configurazione della Web directory del nostro
sito, di default viene riportato ".htaccess" dalla quale prende il nome questa funzione, ma se ne può scegliere benissimo
un altro oppure più di uno, il punto prima del nome serve ad indicare ai sistemi Xnix che tale file deve risultare nascosto
agli occhi dei non addetti. Come avrete capito quindi, dato che questo file dovrà restare nascosto, è opportuno
restringerne i permessi di visualizzazione via web a tutti tramite l'impiego della seconda direttiva
<files .htaccess></files>. Accertata l'esistenza di tale funzione, vediamo subito un esempio semplicissimo:
Ammettiamo che il nostro fornitore di spazio, o che il nostro server, abbia settato il suo file di config in modo da
richiamare esclusivamente il file index.html come documento di default in caso di un’URL incompleta, a questo punto, se
il server non fosse implementato con file .htaccess, noi saremo costretti ad utilizzare coattivamente index.html per la
nostra homepage, ma dato che gli amministratori di server non sono così cattivi come si potrebbe credere, non
dobbiamo fare altro che aprire il nostro editor di testo preferito e scriverci dentro la seguente direttiva:
DirectoryIndex index.php3 index.html index.shtml
e salvare il tutto con il nome di ".htaccess", (consiglio di mettere anche le virgolette nello spazio nome file, altrimenti vi
ritroverete un file .htaccess.txt che non serve un gran che).
Fatto ciò non vi resta che pubblicarlo nella root directory del vostro sito, in modo che abbia effetto anche nelle
sottodirectory, per vedervi aprire come pagina di default del sito il vostro documento index.php3, al posto dell'ormai
superato index.html. E' d'obbligo comunque un invito alla cautela, a volte può capitare che esista già un file.htaccess
nella vostro Webroot, con al suo interno delle direttive già impostate dal vostro amministratore, se andate a sovrascrivere
tale file molto probabilmente alcune funzioni precedentemente attive andranno perse.
Continuando sullo stesso esempio, proseguiamo la lezione ammettendo di avere una sottodirectory, alla nostra root, di
nome \pippo, nella quale desideriamo che la pagina di default non sia una di quelle menzionate all'interno del file
.htaccess in root, ma che sia pippo.htm, a questo punto i più audaci avranno già intuito la semplice soluzione, e cioè
quella di preparare un nuovo file .htaccess, contenente la seguente direttiva:
DirectoryIndex pippo.htm
e di salvarla e pubblicarla all'interno della nostra \pippo directory. Operando in questo modo quando un client, attraverso
il suo browser, tenta di accedere all'URL www.nostrodominio.com/pippo il server andrà prima ad effettuare un parsing
del file .htaccess presente in root stabilendo che dovrà aprire per primo il file index.php3 o via di seguito, e poi si
sposterà nella directory \pippo dove troverà un altro file .htaccess da sottoporre a parsing nel quale le nuove direttive gli
imporranno di aprire il file pippo.htm e di ignorare le direttive trovate in root.
Da questa breve illustrazione avrete sicuramente notato come, pur senza riavviare il server, sia possibile modificare o
aggiungere nuove direttive di configurazioni presenti nel file .htaccess, in quanto, a differenza del file config di Apache
che viene letto una sola volta al suo avvio, viene analizzato ogni volta che il client accede nel nostro sito Web, con un
ovvio, se pur esiguo ritardo nel restituire il documento richiesto. A volte però, abusare delle funzionalità offerte dal file
.htaccess , significa assistere ad un considerevole calo di prestazioni, se è infatti teoricamente lecito inserire un file
.htaccess in ogni directory del sito, ognuno con le sue specifiche direttive, nella pratica tale intervento risulterebbe un
vero e proprio disastro in termini d'attesa, immaginiamo per un solo istante che da una macchina client parta la richiesta
per un documento posto alla seguente URL:
www.nostrodominio.com/home/amministrazione/contatti/fornitori/ufficio/conti.html
il server avvierà un parsing di tutti i file .htaccess nel seguente ordine:
www.nostrodominio.com/.htaccess
www.nostrodominio.com/home/.htaccess
www.nostrodominio.com/home/amministrazione/.htaccess
www.nostrodominio.com/home/amministrazione/contatti/.htaccess
www.nostrodominio.com/home/amministrazione/contatti/fornitori/.htaccess
www.nostrodominio.com/home/amministrazione/contatti/fornitori/ufficio/.htaccess
www.nostrodominio.com/home/amministrazione/contatti/fornitori/ufficio/conti/.htaccess
A questo punto risulta ovvio che più file vengono intercettati ed esaminati durante questo processo, più lunghi
risulteranno i tempi di accesso da parte del client al documento da lui richiesto. E nel caso in cui il client decidesse di
voler visualizzare un altro documento nella stessa posizione, tale processo di parsing verrà riattivato nuovamente,
nell'ipotesi che qualche direttiva possa essere stata modificata. Detto ciò, v’invito dunque a farne un uso ben ponderato,
e di utilizzare tale file la dove sia strettamente necessario. Credo che questi semplici esempi siano stati abbastanza
chiari per dare un idea generale sull'utilità di tale file. Nelle prossime lezioni illustreremo quali direttive siano possibili
elencare in tali file ed alcune particolari astuzie.
Lezione 27
Nella lezione precedente, abbiamo visto con quale semplicità è possibile ovviare ad alcune impostazioni del nostro
Server, mediante l'impiego, all'interno del nostro sito, del file .htaccess.
Ovviamente, DirectoryIndex è solo una delle direttive elencabili all'interno del file .htaccess, infatti ne abbiamo molte altre
per i più svariati ed interessanti impieghi, vediamone alcuni:
ridirigere gli accessi da un URL ad un altro
attivare/disattivare password o altri controlli di accesso
impostare i messaggi di errore per diverse operazioni
attivare e disattivare altri servizi del server come, ad es. i permessi sui file
impostare o cambiare un tipo di Mime
Ridirezione
Grazie all'impiego di questa direttiva è possibile forzare il browser client a caricare una pagina diversa da quella
richiesta, ad esempio, nel caso in cui abbiate riorganizzato il vostro sito Web.
Facendo un esempio pratico, è proprio una delle soluzioni utilizzate dal nostro staff per ridirigere tutti gli utenti
provenienti da www.apache3000.f2s.com sulla URL del nuovo server www.apache3000.com. Provare per credere.
Per ottenere questo risultato, non abbiamo fatto altro che spostarci nella rootdirectory del vecchio server su f2s.com,
tramite accesso ftp, ed inserire tra le direttive dell'.htaccess file la seguente riga:
Redirect /index.php3 http://www.apache3000.com/
Questo, comunque, è solo un esempio di come poter sfruttare questa interessante funzione, in quanto la stessa
potrebbe essere usata al posto della direttiva DirectoryIndex, in modo da far aprire index.php3 come pagina di default al
posto della più classica index.html, scrivendo la seguente riga:
Redirect /index.html http://www.apache3000.com/index.php3
L'unico inconveniente di questa soluzione, è che avrà effetto solo nella directory di root, e non in tutte le sottodirectory
del nostro sito, pertanto sarebbe meglio usarla per la directory \pippo (vedere lezione precedente).
Non è importante che il file richiesto dal client esista o meno, l'importante è far corrispondere ad esso una URl valida,
vediamo a tale proposito, un altro esempio pratico in cui abbiamo utilizzato la funzione di redirect, se provate a visitare
questa URl http://www.perl-it.org/pages/link.html potrete individuare un link al nostro sito ormai obsoleto e quindi
inesistente, tempo fa, infatti, al posto di quel link vi era un collegato ad uno dei nostri vecchi siti su Tiscalinet, man mano
che il nostro sito veniva modificato eravamo costretti, ogni volta, ad inviare al WebMaster di Perl-it.com le nuove
coordinate della pagina in modo che il link non risultasse mai interrotto, ma le nostre manovre e decisioni grafiche a volte
erano più rapide dell'aggiornamento dei link, pertanto al fine di non disturbare più perl-it.com, abbiamo deciso di
modificare, all'interno della root di f2s.com, il file .htaccess inserendo anche la seguente riga:
Redirect /learning/cgi.php3 http://www.apache3000.com/learning/scripting_cgi/index.php3
In questo modo, anche se a quella vecchia URl non corrisponde alcun file, siamo riusciti a mantenere funzionale il
collegamento ipertestuale. La soluzione di riportare quest'ultima direttiva sul file .htaccess di root, e stata del tutto
casuale, infatti, avremmo anche potuto inserire un nuovo file .htaccess direttamente all'interno della directory /learning
del Server f2s.com, al fine di ottenere lo stesso risultato, ecco come sarebbe apparsa la direttiva al suo interno:
Redirect /cgi.php3 http://www.apache3000.com/learning/scripting_cgi/index.php3
Forse in fin dei conti tale decisione non è stata poi tanto casuale, in quanto utilizzando l'.htaccess in root abbiamo
sicuramente fatto risparmiare un breve intervallo di tempo dovuto al parsing dei files .htaccess.
Controllo di accessi
Illustreremo adesso come restringere l'accesso alle pagine mediante l'impiego di "login" e "Password". Ciò è possibile
grazie al modulo htpasswd fornito insieme alla distribuzione del vostro WebServer Apache.
Supponiamo di voler restringere l'accesso ad una directory chiamata "istruzioni" in /rootdirectory/istruzioni,
all'utente ciccio con password pasticcio. Per prima cosa bisogna creare una directory dove conservare i files con l'elenco
dei nostri utenti e pass criptate, l'ideale sarebbe scegliere una directory al di fuori della Web directory, ma questo è
plausibile solo lavorando in locale, noi per brevità abbiamo scelto di conservare tale file all'interno della dir protetta
istruzioni. A questo punto possiamo iniziare ad editare il nostro file .htaccess scrivendo le seguenti righe:
# Assegniamo un nome alla nostra area protetta
AuthName “protected-dir”
# Tipo d’autenticazione, Basic o Digest
AuthType = Basic
# Path completa del nostro file pass
AuthUserFile = /home/site-utenti/utente1234/web/istruzioni/.pass
# Path completa del nostro file dei gruppi
#AuthGroupFile = /home/site-utenti/utente1234/web/istruzioni/.groups
# tipo di richiesta da accettare
Require valid-user
Ora non ci resta che creare il nostro file .pass in web/istruzioni in modo tale che al suo interno contenga la login ciccio e
la pass criptata pasticcio. Le vie per ottenere ciò sono due, a seconda che operiate in locale oppure in remoto, nel primo
caso, assicurandosi di lavorare come root oppure come utente privilegiato, basta aprire una shell di comando e digitare
quanto segue:
htpasswd -c /home/site-utenti/utente1234/web/istruzioni/.pass ciccio
Con questo comando chiedete al modulo htpasswd di Apache di creare all'interno della dir /istruzioni un nuovo file .pass
con un utente di nome ciccio, se il modulo è correttamente configurato sulla vostra macchina vi chiederà subito dopo
aver cliccato su invio di digitare due volte la vostra pass per il nuovo utente, voi scrivere pasticcio.
Ora se vi spostate all'interno della vostra directory istruzioni ed avendo l'accortezza di visualizzare i file nascosti dal
sistema, aprendo il nuovo file .pass potrete vedere qualcosa del genere:
ciccio:te4nc.6hcQxW6
dove ciccio è la nuova login di accesso alla directory e te4nc.6hcQxW6 è la pass pasticcio criptata dal sistema, pertanto
per ognuno di voi risulterà leggermente o totalmente differente.
Nel caso in cui vogliate creare nuovi utenti non sarà più necessario inserire il comando -c (crea) nella shell di comando
ma semplicemente:
htpasswd /home/site-utenti/utente1234/web/istruzioni/.pass tommaso
Vediamo adesso come sia possibile creare il nostro file .pass nel caso in cui ci si trovi in remoto, diciamo subito che è
quasi indispensabile avere accesso telnet al nostro server, o al limite conoscere la locazione del modulo htpasswd sul
server per un eventuale script Perl.
Noi illustreremo come creare il nostro file .pass tramite accesso telnet,Dopo esservi collegati al vostro Server, portatevi
in /usr/bin/htpasswd e cliccate su invio se tale modulo si trova li avrete come risultato un po' di info su tale modulo
altrimenti potrete cercare in altre possibili locazioni tipo /usr/sbin/htpasswd se anche in questo caso la ricerca fallisce
conviene contattare il vostro amministratore per maggiori delucidazioni.
Dato che nella maggior parte dei casi tale modulo si trova di default in queste due locazioni, noi ammettiamo che
l'abbiate trovato e proseguiamo con l'illustrazione, a questo punto quindi siete pronti per scrivere quanto segue:
/usr/sbin/htpasswd -c /home/site-utenti/utente1234/web/istruzioni/.pass ciccio
credo che a questo punto sia facile intendere che il tutto è praticamente identico al procedimento illustrato in
precedenza, ricordate che "/home/site-utenti/utente1234/web/istruzioni/.pass" è solo una pach di esempio voi dovrete
inserire la vostra.
il programma vi chiederà per due volte di digitare la password
Provate adesso con il vostro browser di collegarvi alla pagina istruzioni. Vi verrà chiesto di digitare ciccio e pasticcio
E' tutto. La documentazione originale si trova presso http://hoohoo.ncsa.uiuc.edu/docs/tutorials/user.html
Gestione degli errori
Vediamo ora come sia possibile implementare il nostro sito, o magari ogni dir dello stesso, di messaggi d'errore
personalizzati, diversi da quelli impostati di default dal nostro server, (vedere a tale proposito la lezione 9).
Questa opzione permette al WebDesigner di dare un vero e proprio tocco di professionalità al suo lavoro, facendo notare
di non aver tralasciato proprio nulla nel suo lavoro.
Come prima cosa da fare bisogna preparare una pag. html per ogni tipo di errore oppure di un uno script CGI o PHP
apposito, ma ciò esula da quanto ci accingiamo ad illustrare.
Ammettendo di aver pronte le nostre paginette html per ogni tipo di errore in una directory errors del nostro sito, queste
sono le righe d'aggiungere al nostro file .htaccess in rootdorectory:
ErrorDocument 401 /errors/pag401.htm
Dopo "ErrorDocument" specificate il codice d'errore, seguito da uno spazio, e quindi il percorso e il nome del file .htm
che desiderate venga mostrato quando viene generato lo specifico errore.
Se volete un esempio concreto provate a richiedere una URL inesistente nel nostro sito, vedrete che al posto del
classica pag. error 404 pagina non trovata vi apparirà un nostro messaggio personalizzato, ad esempio
http://www.apache3000.com/pag-di-esempio/ .
Attivare e disattivare servizi
Tra le varie direttive elencabili all'interno dell'htaccess file, possiamo definire alcune restrizioni di accesso a file e
directory, riprendendo l'esempio sulla protezione dei file, al fine di rendere più breve la spiegazione avevamo messo il
nostro file .pass nella stessa directory che volevamo proteggere, il fatto che il nostro file delle passwd sia nascosto al
sistema non toglie che sia possibile richiamarlo dal web pertanto sarà opportuno completare il file .htaccess presente
nella directory /istruzioni con le seguenti direttive:
<Files .pass>
order allow,deny
deny from all
</Files>
in questo modo negheremo l'accesso al file a tutti. Potremmo inoltre decidere di limitare gli accessi al nostro sito a
determinati host o groppi di host tramite le seguenti direttive:
<Limit GET>
order allow,deny
deny from 128.23.45.85
deny from 207.158.
allow from all
</Limit>
Oppure semplicemente a soli file o sole cartelle:
<Files page.html>
order allow,deny
deny from 128.23.45.85
deny from 207.158.
allow from all
</Files>
<Directory page.html>
order allow,deny
deny from 128.23.45.85
deny from 207.158.
allow from all
</Directory>
E' inoltre possibile specificare le Options per il nostro sito o directory, oppure gestire gli index virtuali, o aggiungere nuovi
tipi di mime, per maggiori informazioni su tali direttive si rimanda alle lezioni corrispondenti.
Come far girare Script CGI in Perl con Windows 95/98 e Apache
Lezione 28
Introduzione
Scopo di questo tutorial è offrire a tutti i neofiti del Perl la possibilità di installare e testare Script Perl sul proprio computer
senza dover essere collegati in rete. Chi ha provato a far girare uno script Perl magari prelevato in uno dei vari siti che li
mettono a dispozione come download gratuiti, sa quanto può essere comodo verificarne in tutta tranquillità il
funzionamento senza essere pressati da scatti telefonici, cadute di linea e lentezze di collegamento. Naturalmente
Windows 95/98 non può sostituirsi a Windows NT e tantomeno a Unix o Linux, i sitemi utilizzati dalla maggioranza di
host sul web. Alcuni comandi classici del Perl su Unix/Linux non sono attivi su Windows, mentre il fratello maggiore NT
offre opzioni non realizzabili su Win 95/98. Le limitazioni quindi sono tante, ma avere un web server in grado di eseguire
CGI è sempre meglio che affidarsi ai pur validi programmi di sviluppo integrati disponibili per questo sistema. Con questo
'espediente' non si puo supplire alla verifica dello script in rete sull' host in cui risiede il nostro sito, ma può essere un
valido aiuto e soprattutto un'ottima palestra. Inoltre il tutorial, prendendo le mosse da quello presente nel sito Clueless
Lou's, tenterà di simulare in locale il sito presente in rete in modo che gli script possano essere trasferiti sull'host senza
bisogno di effettuare modifiche troppo radicali.
Materiali occorrenti
Active Perl scaricabile dalla Active State
DCOM per Windows 95 prelevabile da questa pagina del sito Microsoft.
DCOM non è necessario in caso si abbia installato Windows 98.
Il Server Apache scaricabile dal sito www.apache.org
Nel caso si installi la versione 1.3.9 o succesiva di Apache sarà necessario anche Winsock2 prelevabile dalla area
download per Win95 di Microsoft
Winsock2 non è necessario se si usa Windows 98.
Tutti i programmi indicati sono freeware o Gnu public licensed e quindi liberamente scaricabili. Le dimensioni dei file
possono variare a seconda delle versioni. Si tratta comunque di file piuttosto leggeri che non richiedono, nell'insieme, più
di un'ora di collegamento per essere scaricati.
Attenzione alla versione di Windows 95
Prima di tutto diamo un'occhiata alla versione di Windows 95 installata.
Si apra risorse del computer / pannello di controllo / sistema / generale. A fianco del disegno con la bandiera di Windows
si trova il numero di versione, qualcosa del tipo 4.00.950a. Se dopo il numero di versione non compare nessuna lettera
(a,b,c..) si dovrà includere nel path di configurazione dello script Perl, la shebang line, l'estensione .exe in questa
maniera:
!#c:/usr/local/bin/perl.exe
oppure scaricare, sempre gratuitamente, il Server Pack 1 direttamente dall' area download per Win95 della Microsoft.
Installare l'interprete Perl
L'interprete serve a far girare gli script CGI in Perl come fossero dei veri e propri programmi.
In questo tutorial si è utilizzato l' interprete Active Perl per Win 32.
Se si usa Windows 95 è necessario installare precedentemente il supporto DCOM.
Basta cliccare sul file dcom95.exe per far partire l'autoinstallazione.
Cliccando sul file APi5xxe.exe si installa invece Active Perl. Quando il programma chiederà in quale directory essere
installato si potrà cambiare il percorso di default con quello dell'interprete Perl dell' host remoto. Per esempio se in
remoto l'interprete Perl si trova in /usr/bin, sull' hard-disk dovrà essere creata una cartella c:\usr in cui il programma
dovrà essere indirizzato. Active Perl creerà da solo la sottocartella \bin.
Durante l'esecuzione del'installazione il programma chiederà di scrivere una linea con il percorso di riferimento nel file
Autoexec.bat di Windows. Conviene lasciare invariate le impostazioni di default e permettere la modifica di Autoexec.bat.
Si può evitare invece di associare i file con estensione .pl a perl.exe. A differenza di Windows NT non si possono
eseguire script Perl semplicemente cliccandovi sopra.
Ad installazione terminata chiudere e riaccendere il computer.
Ora si può provare a testare l'interprete.
Da prompt di MS-DOS scrivendo perl -v e schiacciando invio si ottiene una scritta del tipo This is Perl....
Si può provare anche a creare un semplice script Perl. Con un editor di testo, il più semplice possibile che non formatti le
pagine, ad esempio Blocco Note di Windows, si scriva:
Si salvi il file da qualche parte e lo si rinomini .pl. Ad esempio: c:\windows\desktop\prova.pl.
Nuovamente da prompt di MS-DOS si scriva: perl c:\windows\desktop\prova.pl e si schiacci invio. Se la finestra
visualizzerà la scritta Ciao, Perl funziona! Active Perl sarà stato installato correttamente.
Installare e configurare Apache per Win 32
Questo tutorial si riferisce alla versione 1.3.6 di Apache.Per installare il programma basta cliccare sul file
Apache_1_3_6_win32.exe. La directory d'installazione predefinita dal programma va benissimo, bisogna accertarsi,
però, che sia sullo stesso drive in cui risiede l'interprete Perl.
Supponiamo che il percorso del sito sull'host Unix/Linux sia /usr/etc/htdocs/vostro_sito. Si deve creare quindi sull'harddisk una directory così strutturata C:\usr\etc\htdocs\vostro_sito in cui verranno salvate le pagine di prova. Tanto per
intenderci C:\usr\etc\htdocs\vostro_sito\index.html sarà la pagina di default che compare quando navigando in rete si
clicca su http://www.vostro_sito.com.
Per configurare Apache si deve aprire in Blocco Note il file httpd.conf, che si trova, se si è lasciato inalterato il percorso
di default dell'installazione, in C:\Programmi\Apache Group\Apache\conf\httpd.conf. I percorsi vanno sempre scritti in
Unix-style, usando, per separare le directory, gli slash / al posto dei backslash \ tipici del DOS e, possibilmente,
mantenendo i caratteri, maiuscoli o minuscoli, che si sono usati per nominare file e cartelle: Unix, a differenza di
Windows è case-sensitive.
Ecco le linee che devono essere modificate nel file httpd.conf:
•
•
•
•
•
•
•
•
[Linea 218]
ServerAdmin [email protected] in ServerAdmin webmaster@vostro_sito
Questa linea non ha una reale utilità. Serve per mostrare la vostra e-mail in caso di messaggi d'errore del
server.
[Linea 232]
Decommentare (cancellare il simbolo #) #ServerName new.host.name e modificarlo in ServerName 127.0.0.1
in alternativa si può modificarlo come ServerName vostro_sito.
Questa direttiva è molto importante. Se la si dimentica il server non girarerà mai.
[Linea 239]
DocumentRoot "C:/Programmi/Apache Group/Apache/htdocs" in DocumentRoot
"C:/usr/etc/htdocs/vostro_sito"
In questa maniera si setta la cartella che conterrà il sito.
[Linea 264]
<Directory "C:/Programmi/Apache Group/Apache/htdocs"> in <Directory
"C:/usr/etc/htdocs/vostro_sito">
Questa direttiva setta le opzioni e i permessi del sito.
[Linea 303]
DirectoryIndex index.html in DirectoryIndex index.html index.htm index.cgi index.pl index.shtml
Così facendo si impostano diverse estensioni e nomi di default per il sito.
[Linea 459]
ScriptAlias /cgi-bin/ "C:/Programmi/Apache Group/Apache/cgi-bin/" in ScriptAlias /cgi-bin/
"C:/usr/etc/htdocs/vostro_sito/cgi-bin/"
Con questa direttiva si stabilisce quale sarà la cartella cgi-bin del sito. Si dovrà quindi creare, all'interno della
directory del sito, una cartella di nome cgi-bin in cui andranno salvati gli script.
[Linea 466]
<Directory "C:/Programmi/Apache Group/Apache/cgi-bin"> in <Directory
"C:/usr/etc/htdocs/vostro_sito/cgi-bin">
Questa linea setta i permessi di accesso relativi alla cartella cgi-bin.
Ovviamente non è necessario che la cartella si chiami specificatamente cgi-bin. Si può scegliere un nome
qualsiasi. Bisognerà soltanto ricordarsi di modificare queste due linee con il nome scelto.
[Linee 273 e 610]
Se si vogliono far girare gli script Perl da qualsiasi directory e quindi anche al di fuori di quella prevista in
ScriptAlias si deve aggiungere alla <Directory "C:/usr/etc/htdocs/vostro_sito"> dove compaiono Options
Indexes FollowSymLinks anche ExecCGI e si deve decommentare AddHandler cgi-script .cgi.
Ora Apache dovrebbe funzionare. Cliccando su Start Apache as Console App. Si aprirà la finestra del Prompt di MSDOS. Dopo la prima esecuzione comparirà un messaggio del tipo:[Tue Nov 23 13:33:57 1999] [warn] pid file
c:/programmi/apache group/apache/logs/httpd.pid overwritten --Unclean shutdown of previous Apache run?. Non
bisogna preoccuparsene. Apache è vivo e vegeto e funziona.
Scrivendo "localhost" nella casella degli indirizzi del browser e schiacciando invio comparirà la pagina di default del sito
(la index.html salvata nella cartella settata come DocumentRoot in httpd.conf).
A questo punto si può provare a far girare uno script.
In Blocco Note si scriva:
!"
Lo si salvi nella cartella settata in ScriptAlias come CGI attiva (la cartella cgi-bin) con il nome di prova.cgi (o prova.pl) si
torni al browser e si digiti localhost/cgi-bin/prova.cgi. Comparirà una pagina con scritto Questo script CGI funziona!.
Attenzione alla Sh-bang line: deve contenere il path dell'interprete perl per intero, compreso il
drive!!
Cambiare "localhost" in "vostro_sito"
Si può fare in modo che Windows riconosca come indirizzo IP 127.0.0.1 al posto della URL localhost il nome del vostro
sito. In questo modo al posto di digitare localhost sul browser si potrà scrivere il nome del sito. Nella directory
C:\Windows si trova il file Hosts.sam. Aprendolo con blocco note si trova una riga:
127.0.0.1 localhost
Modificadola in
127.0.0.1 vostro_sito
si ottiene l'effetto desiderato.
Una volta modificato e salvato Hosts.sam deve venire rinominato sempilcemente Hosts senza aggiungere nessuna
estensione.
ATTENZIONE: Per accedere in remoto alle pagine del vostro sito si deve rinominare Hosts in Hosts.sam altrimenti il
browser visualizzerà quelle presenti sull' hard-disk e non quelle in rete.
Netscape e Explorer
Mentre con Navigator non ci sono problemi a far girare il server in locale, con Explorer 4.0 può essere necessario
modificare queste opzioni:
opzioni – connessione – connetti tramite rete locale. Fare sempre attenzione che Explorer sia “non in linea”.
Azzerare la chache dei browser. In fase di test le pagine vanno viste e riviste svariate volte nell'ultima versione prodotta.
SSI e PHP 3
SSI (Apache 1.3.6/1.3.9)
Per attivare i Server Side includes modificare in Httpd.conf :
[linea 273] in options includere Includes.
[linea 303] in Directory Index aggiungere index.shtml se si vuole questa estensione leggibile di default.
[linee 615/616] decommentare AddType text/html .shtml.
Decommentare AddHandler server-parsed .shtml .html (html va aggiunto se si voglio far girare ssi anche su pagine con
estensione html).
PHP3
Estrarre Php3 nella dir di default (C:\php3\)
In httpd.conf di Apache modificare:
[linea 458] aggiungere ScriptAlias /php3/ "C:/php3/"
[linee 506 e ss.] aggiungere AddType application/x-httpd-php3 .php3 e decommentare le altre: AddType application/xhttpd-php3 .phtml AddType application/x-httpd-php3-source .phps
[linea 643] aggiungere Action application/x-httpd-php3 "/php3/php.exe"
Nella dir PHP modificare:
rinominare il file php3-ini-dist in php3.ini e salvarlo in C:\windows.
In questo file modificare:
[linea 100 circa] extension_dir= C:\php3
Nella distribuzione PHP non sono presenti due file richiesti dall’installazione:
odbc32.dll
odbcint.dll
Si possono reperire, ad esempio, nel cd di Office 2000 e vanno copiate in C:\windows\system.
Settare host virtuali
Per aggiungere host virtuali ad Apache aggiungere le seguenti linee in Httpd.conf(lasciando intatte le linee commentate
di esempio già presenti):
<VirtualHost 127.0.0.2> (aggiungere numeri progressivi all’IP)
[linea 786] DocumentRoot "C:/usr/etc/htdocs/sito" (Dir in cui si trova il sito)
[linea 787 ] ServerName sitodue
[linea 788]ScriptAlias /cgi-bin/ "c:/usr/etc/htdocs/sitodue/cgi-bin/" (Directory CGI per il sito)
[linea 791] </VirtualHost>
I numeri di line varieranno, ovviamente, a seconda del numero di Host immessi.
Nel file hosts prcedentemente modificato
127.0.0.2
sitodue
127.0.0.3
sitotre
127.0.0.4
ecc.
Occorre riavviare Win dopo le modifiche.
Che noia!!!
C'è un semplice sistema per evitare che la fastidiosa finestra dos di Apache rimanga in bella vista sul desktop
interferendo con le nostre azioni sullo schermo. Tutte le volte che si attiva Apache bisognerebbe ridurre la finestra a
icona sulla barra di Win.
Per evitarlo basta creare un collegamento alla eseguibile di Apache e poi, da proprietà - collegamento, scegliere esegui:
ridotto a icona.
Se tutti i parametri sono stati settati esattamente non dovrebbere essere necessario neppure aggiungere C: alla sh-bang
line, cosa che facilita molto la trasposizione degli script su server Unix like.
Installare Moduli Perl
Active State necessita di un emulatore di make come nmake o dmake
Nmake si può trovare sul sito ftp della Microsoft
Per dmake, invece, si puo' vedere sui classici www.cpan.org - www.perl.com e www.perl.org
Qui si presume nmake.
Scompattare nmake ad es. in C:\usr\nmake
settare in autoexec.bat SET PATH=C:\USR\NMAKE;"%PATH%"
Riavviare il sistema.
Installazione Globale del modulo.
Scompattare il modulo.
Da linea di comando andare nella directory dove il modulo e' stato scompattato e usare makemaker, ovvero:
perl makefile.pl Invocando MAKEMAKER dal perl viene creato un file makefile (senza estensione) che verrà letto da
nmake.
nmake
nmake test
nmake install
Nmake installerà il modulo nella dir. specificata in @INC cioè usr/site/lib.
Installazione Locale. Scompattare il modulo.
Da linea di comando andare nella dir dove il modulo e' stato scompattato e usare makemaker, ovvero: perl makefile.pl
LIB=C:\dir\della\lib\locale
oppure:
perl makefile.pl PREFIX=C:\dir\della\lib\locale nmake...
Nmake in questo caso installa i file nella dir specificata. Generalmente usando LIB l'installazione avviene localmente,
cosa che non sempre accade con PREFIX (nmake installa il modulo in @INC).
E' anche vero che con alcuni moduli particolarmente complessi (Lib-www5.48 ad esempio), nonostante l'uso di lib,
nmake istalli tutto in @INC.
Nello script andrà poi indicato:
use lib "d:/dir/della/lib/locale/";
use modulo::modulo;
- Per leggere gli 'embedded documents' (POD) mei file .pm e .pl
perldoc <nome_modulo>
Es. perldoc LWP::Parallel
-Per ottenere schermate leggibili da linea di comando
<comando> <nome_file> (pipe) more
Es. perl req.pl -w | more
Apache e Active Server Pages (ASP)
Lezione 29
Come installare al volo un modulo ASP gia' compilato.
A completamento dello splendido contributo offerto da Paolo Bertaina (al quale vanno, credo anche a nome di molti altri,
sentiti ringraziamenti), desidero segnalare la possibilita' di implementare l'utilizzo di pagine ASP sul nostro web server
Apache.
Personalmente ho installato la versione Apache 1.3.9 (dopo aver usato con successo la 1.3.12) su win95.
Con il desiderio di utilizzare anche pagine ASP ho girovagato sulla rete alla ricerca di una soluzione. La piu' opportuna
sarebbe di aggiungere il modulo Apache::ASP, ma richiede l'installazione completa del modulo mod_perl, e
personalmente l'ho trovato scoraggiante.
Da un suggerimento dell'instancabile Apache postato sul forum (che vi invito a frequentare...) ho raggiunto il sito
http://www.activescripting.org/index.html ed ho scaricato una versione binaria per win32 della libreria apasp136.dll.
Seguendo alcuni suggerimenti all'interno del sito (ma forse e' il mio inglese che non va...) ho scaricato dapprima la dll
131, pensando che fosse piu' adatta alla versione 1.3.12 di Apache; ma al caricamento Apache mi rispondeva che non
era possibile caricare il modulo. Ho provato poi la dll 136 ed il caricamento ha avuto successo, seppur con la
segnalazione di un warning che mi suggeriva di ricompilare la dll in quanto poteva andare in crash con la versione di
Apache installata. Comunque l'ho testata un pochino e l'ho trovata funazionante. Nessun problema invece (e dunque
nessun warning...) da quando ho fatto l'upgrade alla versione 1.3.9. All'interno del file zip (solo 64kb!) si trovano la DLL
da copiare nella tua cartella \module e le istruzioni su come modificare il file di config, che riassumo brevemente per gli
utilizzatori di Apache:
1. Aggiungere al file httpd.conf la seguenti righe:
#$%$&$$'()*$
+$$,*
(correggete opportunamente il path alla dll se necessario...)
2. Aggiungere al file mime.types la seguente riga:
*
3. Nulla!!! E sì... voi non ci crederete ma avete installato il modulo ASP
Alla faccia di tutti quelli che non ci credevano, vi basta riavviare il WebServer Apache e richiamare una pagina in ASP
Ecco un semplice script in ASP da copiare ed incollare in Notepad di Windows:
<%
If Time >=#12:00:00 AM# And Time < #12:00:00 PM# Then
cSaluto = "Buon Giorno!"
Else
cSaluto = "Buona Sera!"
End If
%>

<%= cSaluto %>
 
Oggi e' il <%= date %> e sono le ore <%= Time %> 

<CODE>

<%
Response.Write("BENVENUTI SULLA PAGINA DI PROVA APACHE-ASP!")
%>
</CODE>
 
<CODE>
<%
If InStr(Request.ServerVariables("HTTP_USER_AGENT"),"MSIE") Then
Response.Write("Il tuo browser e' Internet Explorer!")
Else If InStr(Request.ServerVariables("HTTP_USER_AGENT"),"Mozilla") Then
Response.Write("Il tuo browser e' Netscape!")
Else
Response.Write("Il tuo browser non e' ne' Internet Explorer ne' Netscape.")
End If
End If
Response.Write(" " & "Sei collegato al server con Ip: " &
Request.ServerVariables("LOCAL_ADDR"))
Response.Write(" " & "Linguaggio Browser impostato: " &
Request.ServerVariables("HTTP_ACCEPT_LANGUAGE"))
Response.Write(" " & "Host Domain: " & Request.ServerVariables("HTTP_HOST"))
Response.Write(" " & "Host Domain: " & Request.ServerVariables("REMOTE_HOST"))
%>

</CODE>
Salvate la pagina con estensione .asp (es. test.asp) nella vostra root.
Naturalmente vi sono alcuni limiti, tra i quali il fatto di non supportare il file global.asa. Ma per questo ed ulteriori dettagli
piu' tecnici fate riferimento al file readme.txt che scaricherete, dove sono elencati anche oggetti, metodi e proprieta'
supportate.
Buon lavoro da Antonio Epifani
visita anche: http://www.madonnadipompei.org
Virtualhost e Alias
Lezione 30
Configurare i Virtualhost in ambiente Windows.
E' ormai un dato di fatto che la versione di Apache per Windows funziona. Forse non benissimo, ma funziona. Nel caso
di piccole reti, siano esse casalinghe o meno, per scopi non "esasperati" il server compie senza problemi il suo dovere.
Spesso però, ci si trova di fronte alla voglia o esigenza di volere più siti sulla stessa macchina. Facciamo un esempio. Su
quel santo del mio PC, a casa, sono installati Win98SE, Apache ecc. (il PHP c'azzecca poco, in questo caso); il server
Apache risponde agli indirizzi http://localhost e http://127.0.0.1, com'è ovvio; ma, essendo subnet il suo vero
"Servename" (nel file httpd.conf), è raggiungibile anche con http://subnet. Volendo, poi, si possono aggiungere degli
alias. Esempiuccio: se io aprissi il file
$*
che si trova nella cartella conf della directory di installazione di Apache, ed aggiungessi il rigo
+
avrei creato un indirizzo HTTP alias, che risponderebbe ad una chiamata del tipo
anche se la cartella principale del mio sito magari si trova su
---
spero di essermi spiegato. Comunque, fin qui, nulla di nuovo o di particolarmente difficile. Ma se volessi proprio un altro
sito sulla stessa macchina? Una cosa tipo, che sò...http://pippo? Dovrei creare un .
Un suggerimento ci arriva dal sito di Emmanuel Faivre, che ha il merito di aver pensato Easyphp.
Facciamo l'esempio sempre sul mio PC, ok. Dopo aver saggiamente fatto una copia del file httpd.conf (ed aver fermato il
server Apache), lo apro in un qualsiasi editor di testo e decommento (se commentato) il rigo dove si trova l'IP dell'host:
/01'23*4*4*'
quindi aggiungo
501
6
78---
9./
5016
5016
78
9./
5016
fatto questo, apro il file c:\windows\HOSTs ed aggiungo i due nomi dei virtualhost (localhost è già presente, ovviamente)
'23*4*4*'
'23*4*4*'
'23*4*4*'
sarà il caso di fare lo stesso anche con il file c:\windows\HOSTs.sam Tutto qui. Basterà riavviare il server Apache, e si
avranno due siti distinti e separati: http://subnet e http://pippo. Per ogni virtualhost sarà possibile assegnare differenti
direttive, tramite il file http.conf.
Lezione editata da Piero Mannelli
visita anche: http://subnet.free.fr/

Apache - 30 - Home Page di Andrea Leotardi

Transcript

Documenti analoghi

Curriculum Vitae - Borsa Merci Telematica Italiana

Apache Webserver

modulo di recesso_cartaIntestata

Sem inari gratuiti Sem inari gratuiti

Apache, PHP, MySQL, DRUPAL on Leopard (Mac Os X)

cura Oreal

CA Nimsoft Monitor per Apache

07/07/2009 Ontheroadnews.eu

Mise en page 1 (Page 1)