Introduzione:
Apache, il cui sviluppo (ricordiamo che il team è formato da volontari, noti come l'Apache Group) è arrivato alla versione 1.3.12, è nato come rimpiazzo per il webserver httpd 1.3 sviluppato dal NCSA (National Center for Supercomputing Applications), inglobandone le carrateristiche, risolvendone i problemi ed implementando nuove features.
Come sopra accennato, Apache è un webserver per il protocollo HTTP, designato per poter girare come un processo standalone, senza ciò chiedere l'appoggio ad altre applicazioni o direttamente all'utente. Per poter fare ciò, Apache, una volta che sia stato avviato, crea dei sottoprocessi (comunemente e meglio detti "children processes") per poter gestire le richieste: questi processi, comunque, non potranno mai interferire con il processo maggiore, ma può succedere l'opposto: mandando un segnale di stop a questo, anche i children saranno terminati.
Un tipico albero dei processi di Apace potrebbe essere qualcosa di simile a:

Ricordiamo inoltre che Apache è distribuito come free software, per esplicito desiderio del team che lo sviluppa: questi, infatti, ritengono che strumenti di questo genere debbano essere accessibili a tutti, e che le software house debbano guadagnarci solo producendo addons o simili di valore, o magari personalizzati per alcune categorie di utenti. Inoltre, lasciando il software in mano di chiunque nonchè completo di sorgenti, è possibile che costoro contribuiscano, sia tramite feedback sia tramite vere e proprie patch, a migliorare il prodotto finale. Date le loro premesse, come dare loro torto?

Vediamo brevemente alcune tra le moltissime modifiche introdotte nella versione 1.3 rispetto alla 1.2:

• Supporto DSO (Dynamic shared objects): i moduli possono essere caricati si richiesta, in modo da utilizzare una minore quantità di memoria. Questa caratteristica è supportata su: FreeBSD, OpenBSD, NetBSD, Linux, Solaris, SunOS, Digital UNIX, IRIX, HP/UX, UnixWare, AIX, ReliantUnix e le altre piattaforme SVR4.
  
  
• Supporto per Windows 9x/NT: le versioni precedenti non potevano infatti essere installate su questi sistemi. Al momento, il supporto è sperimentale ma, dalle prove effettuate, si comporta assai bene sebbene non sia ancora in grado di garantire performances pari a quelle riscontrabili su sistemi Unix.
  
  
• Migliore gestione dei VirtualHost.
  
  
• Miglior gestione dei proxy server.
  
  
• Migliore gestione degli script CGI.
  
  
• Compatibilità con l'anno 2000 (è un po' tardi per dirlo, ma gli autori se n'erano ricordati per tempo!)

Ovviamente non è tutto qui; quelle qui riportate sono le modifiche "umanamente intelleggibili", ossia quelle che un utente medio capisce senza troppi problemi. Per chi voglia approfondire l'argomento, consiglio la pagina "new_features_1_3.html" presente nella documentazione di Apache stesso.

Per coloro che non l'abbiano ancora fatto, ricordo che l'argomento è stato precedentemente affrontato nella guida ai CGI nonchè in un articolo a parte per quanto riguarda l'installazione su piattaforma Win32. Inoltre, moltissima documentazione la potete trovare nei vostri hard-disk dopo avere installato Apache sulle vostre macchine o ancora alla pagina http://www.apache.org, sito ufficiale del progetto Apache. Per chi intenda installare o comunque approfondire le proprie conoscienze su Apache in relazione a sistemi Windows, ricordo la pagina "windows.html" presente nel manuale HTML che vi verrà installato a supporto del server.

Porte:
Iniziamo con la porta su cui mettere in listening il webserver (non nel caso in cui esso sia chiamato da inet): il numero specificabile per la porta varia da un range da 0 a 65535, di cui le prime 1024 sono riservate per determinati protocolli; la porta riservata per il protocollo http è comunque, di efault, la 80. Per chi volesse saperne di più sulle porte ed il relativo protocollo associato, maggiori informazioni possono essere trovate nel file /etc/services (sistemi Unix). Un'altra particolarità della porta 80 ed in generale delle porte al di sotto della 1024 è che sono "di sistema", nel senso che i normali utenti non possono farne uso. Quindi, è necessario che apache sia fatto partire dall'utente root nel caso si utilizzi la porta 80 (che è comunque consigliato); in seguito, prima di essere pronto ad accettare le richieste, l'esecuzione di Apache sarà "spostata" all'utente definito poco oltre nel file httpd.conf (lo vedremo in seguito): in questo modo, tutti i processi children saranno su porte il cui numero è maggiore di 1024.

Utenti:
Abbiamo parlato poco sopra degli utenti con i privilegi dei quali Apache è fatto girare: la direttiva che ci interessa è "User". Per utilizzare tale direttiva, è necessario che l'utente che ha avviato Apache SIA root. Il nome dell'utente può essere specificato come il nome a caratteri (ad esempio, nome_utente) oppure tramite il suo ID numerico preceduto dal simbolo # (ad esempio, # 1002). Questo utente non dovrebbe avere troppi provilegi sul sistema, come ad esempio la possibilità di leggere importanti file di sistema, lanciare eseguibili che non hanno a che fare con httpd e simili. La cosa migliore da fare è quella di creare un nuovo utente ad hoc per l'esecuzione di Apache, visto che anche scegliere l'utente "nobody" può non essere la scelta migliore. Ovviamente, inoltre, è fortemente sconsigliato specificare "root" nella direttiva "User". Il perchè mi sembra chiarissimo. Assieme ad "User", inoltre, dovrete specificare anche un nome di gruppo per la direttiva "Group": se avete creato un nuovo utente (supponiamo "prova") per far girare Apache, potrete inserire "prova" anche per il gruppo, a meno che abbiate la necessità di utilizzare un Group differente.

Directory:
Vediamo qui le directory che interesseranno Apache: parleremo qui sia delle directory di configurazione sia di quelle utilizzate per contenere le pagine che daranno forma ad uno o più siti web.
Scorrendo il file httpd.conf, ci imbatteremo presto nella direttiva "ServerRoot": in questa directory saranno contenuti i file di configurazione di Apache, gli errori ed i log, se non specificato differentemente. Evitate che tale directory sia visibile dal web, piuttosto scegliete una directory come /etc/apache oppure /var/log/apache. Bisognerà anche fare attenzione ai permessi da dare a questa directory: i file che essa contiene, infatti, sono alquanto importanti e possono modificare radicalmente il comportamento del server: evitate quindi che altri utenti al di fuori dell'amministratore possano leggere e scrivere al suo interno. Inoltre, per lo stesso discorso, fate lo stesso anche con le directory ed i file di log.
Passiamo poi alla direttiva "DocumentRoot": in questa directory saranno presenti i documenti visualizzabili dal web, in poche parole il sito principale associato al webserver. Per essere ancora più chiaro, se il nome del vostro host è "www.server.it", se un utente digiterà dal browser l'indirizzo "www.server.it" appariranno proprio le pagine presenti in "DocumentRoot".
Poco sotto a DocumentRoot c'è la direttiva "DirectoryIndex": a cosa serve è presto detto. Provate a digitare nel browser l'indirizzo di un qualsiasi server e notate che non inserite alcun nome del file che abbia estensione html, eppure il 90% dei file visibili in rete sono in html! Se questo accade, è grazie alla direttiva "DirectoryIndex": specificando ad esempio "index.html" come valore della direttiva, saremo sicuri che, se in una directory è presente un file chiamato "index.html", Apache farà in modo che non sia necessario digitare nomedirectory/index.html perchè sia visualizzato tale file, ma solamente nomedirectory. Facciamo un esempio: sul server "www.server.com" è presente una directory chiamata, ad esempio, prova, nella quale è presente un file chiamato index.html: per vedere tale file, non sarà necessario digitare "www.server.com/prova/index.html" ma soltanto "www.server.com/prova". Avrete capito così perchè quando si chiama dal browser qualcosa come "www.html.it" non è mai necessario inserire anche "index.html": in fondo, anche www.html.it è una directory su un server! Un'ultima cosa relativa a DirectoryIndex è il fatto di poter indicare diversi nomi di pagine, non solo index.html: i più significativi possono essere "index.shtml", "index.htm" ecc, l'importante è che questi siano separati da spazi.
Veniamo ora alla directory UserDir, impostata di default su /home/*/public_html. Già quel "public_html" dovrebbe avervi fatto capire qualcosa: infatti, i file presenti nella directory /home/nomeutente/public_html sono visualizzati quando, dopo il nome di dominio, sia specificato anche ~nomeutente: se ad esempio sulla macchina "www.server.com" è presente un utente "test", la cui home directory è "/home/test" contenente una sottodirectory chiamata "public_html", se dal browser sarà digitato "www.server.com/~test" appariranno proprio i file presenti nella directory "/home/test/public_html".
Ovviamente, ogni utente deve avere un account sulla macchina. E avete capito così per sommi capi anche come funzionano le comunità virtuali su internet.

Avvio su Unix:
L'avvio di Apache puù essere fatto in due modi: al boot della macchina oppure tramite il demone inetd ogni volta che ci sia la richiesta di una connessione HTTP. La seconda possibilità è comunque poco raccomandata, in quanto è sempre meglio avere il server attivo e pronto a ricevere le richieste.
Quindi ipotizzeremo qui che Apache sia avviato al boot della macchina e terminato al suo spegnimento: se parliamo di un server web, capirete che tra i due momenti passerà molto tempo (visto l'uptime di questi tipi di macchine), e quindi Apache resterà attivo per tutto il tempo durante il quale la macchina è accesa e, ovviamente, connessa in rete, locale o remota che sia.
L'avvio al boot è determinato da un semplice script presente in /etc/init.d : il nome dello script è, fantasiosamente, apache! Leggendolo, molti si potebbero spaventare: sapendo scremare tutto quanto è superfluo ai nostri scopi, possiamo ridurci a considerare solo le chiamate che ci interessano, senza curarci di cosa effettivamente avviene per ognuna.
La prima è "start": come apparirà chiaro, con questa chiamata Apache viene attivato, in modo che si crei il processo padre che sarà seguito dai processi children per gestire le chiamate. La chiamata start è quella che viene fatta al boot della macchina e, per accertarcene, sarà sufficiente controllare che, al boot, appaia una riga simile a:
Starting web server: apache.
Se ciò avviene, possiamo stare sicuri che Apache sia già in ascolto sulla porta 80 del server ma, se proprio vogliamo essere pignoli, possiamo controllare tra la lista dei processi se appare (e deve apparire) anche Apache con i suoi processi children. Per la prova del nove, se l'avete già configurato anche sommariamente, potete digitare dal browser l'indirizzo "http://localhost" per controllare che Apache vi risponda.


Riavvio e stop su Unix:
Il riavvio ha un ruolo alquanto importante: supponete di avere una macchina impiegata a tempo pieno come server, e di effettuare alcune modifiche alla configurazione dell'Apache che gira su di essa; cosa fareste per rendere attive le modifiche?
Coloro che, ricordando che Apache viene avviato all'avvio e pensando che sia necessario riavviare la macchina perchè le modifiche abbiano effetto si sbagliano: come esiste la chiamata "start", esiste anche la chiamata "restart", solo che questa deve essere data a mano tramite il comando:

/etc/init.d/apache restart

Ma a cosa serve il riavvio di Apache?
Ipotizzate di gestire un server e che decidiate di includere il supporto per lo scripting PHP: dovrete fare in modo che apache riconosca questi tipi di script, caricando l'apposito modulo (libphp3.so).
Come fare è presto detto: nel file httpd.conf, basterà decommentare la linea:

#LoadModule php3_module /usr/lib/apache/1.3/libphp3.so

Ricordiamo però che, essendo questa una modifica in run-time, Apache non potrà attuare la modifica a meno che sia riavviato. E la chiamata restart serve proprio a questo: se dovessimo riavviare il server completamente (senza dubbio anche questa soluzione funzionerebbe), rischieremmo un downtime del server troppo lungo: non stiamo parlando solamente di Apache, ma di tutte le funzioni a cui il server è preposto: servizi FTP, POP, SMTP ecc.
Con la chiamata restart, invece, andremo a riavviare solamente Apache, limitando il downtime al solo server HTTP, e tra l'altro il downtime risulterà molto più breve di un reboot della macchina, sull'ordine di una decina di secondi.
Capirete quindi l'utilità della chiamata restart.

L'ultima chiamata è stop: sarà senza dubbio chiaro che tramite stop fermeremo Apache del tutto.
La chiamata di stop può essere fatta in due modi: il primo è in automatico, allo spegnimento della macchina, quando cioè init manderà un SIGTERM a tutti i procesi attivi; per Apache, dovremmo veder comparire qualcosa del tipo:

Stopping web server: apache.

Se per qualche motivo abbiate bisogno di fermare apache a mano, ad esempio in caso di problemi non risolvibili all'istante, oppure di upgrade del pacchetto stesso (magari con un altro server in clustering per tenere attive le richieste!), la procedura sarà sempre la solita: basterà lanciare:

/etc/init.d/apache stop

e sarete sicuri che apache dopo pochi istanti smetterà di girare.


Avvio, riavvio e stop su NT:
Per questa breve sezione ci baseremo fortemente su NT, visto che far girare un webserver su un sistema win9x è impresa ardua, mancando a questo molte delle caratteristiche proprie di NT.

I modi per avviare Apache sono due:

• il primo è come servizio (solo per WinNT): questo è il metodo migliore per assicurarci che Apache venga avviato al boot della macchina e continui ad essere attivo anche in caso di logoff;
• da una console, peraltro unica opzione con Win9x.

Per avviare Apache come un servizio, è prima becessario che questo sia effettivamente installato come un servizio sula macchina: dal menu d'avvio, scegliete l'opzione "Install Apache as Service"; fatto questo, apache potrà essere avviato aprendo la finestra dei servizi (dal pannello di controllo), scegliendo Apache e successivamente su "start". Nel caso si volesse fermarlo, ovviamente, basterà cliccare su "stop".

In alternativa, Apache può essere avviato dalla linea di comando tramite i comandi:

NET START APACHE
NET STOP APACHE

rispettivamente per avviarlo e fermarlo.

Per avviare invece Apache da console, e non come un servizio, basterà cliccare l'opzione "Apache Server" dal menu d'avvio: verrà quindi aperta una finestra dos che restarà aperta durante tutto il funzionamento del webserver.
Per il restart o lo stop, sarà sufficiente aprire un'altra finestra e digitare, rispettivamente:

apache -k restart

oppure:

apache -k shutdown

Entrambe sono altamente preferibili ad un brutale "Ctrl+c", che chiuderebbe Apache invece di arrestarlo, con tutte le conseguenze del caso.

Apache per Windows:
Come avviene per i sistemi Unix, anche una normale installazione sotto Windows comprende una directory nella quale è presente una ricca documentazione per il webserver; questa è, solitamente, ./htdocs/manual, sottodirectory della directory principale definita durante l'installazione. Tutto il manuale è in formato HTML, ed è a grandi linee l'equivalente del manuale online leggibile all'indirizzo http://www.apache.org. In questo sito, è inoltre possibile leggere delle note specifiche alla distribuzione Windows alla pagina http://www.apache.org/docs/windows.html
Essendo Apache un webserver sviluppato su piattaforma Unix, ed essendo la versione per Windows un porting, apparirà chiaro che la versione di Apache per Windows non è completamente ottimizzata per offrire le migliori performances, come avviene invece per la versione Unix. Per dire ciò, l'Apache Group si basa su prove comparative del software su differenti piattaforme.
Il risultato del lavoro di porting, come loro stessi dicono, è un "ottimo codice ancora in beta", visto che il funzionamento è garantito per differenti gradi di utenza ma non è ancora al livello raggiunto sulle piattaforme per le quali Apache è stato originariamente pensato. Quindi funzionamento e performances garantite, anche se non ai massimi livelli.

Vediamo ora una rapida carrellata dei maggiori problemi (noti) di Apache utilizzato sotto Windows.

• La direttiva "User" non è ancora sopportata (questa direttiva, insieme a "Group", specifica l'utente che fa partire il servizio httpd).
• Nel caso di server carico di richieste, quando un processo children esce, qualunque richiesta fatta a quel processo che non sia stata precedentemente accettata non viene eseguita.
• Le password, nel file htpasswd, sono conservate in un file di testo e non crittate, mancando in Windows una funziona crypt().
• Il "suexec" non funziona; il suexec è la funzione che permette ad Apache di eseguire script CGI e SSI con un UID (User ID) differente dall'ID dell'utente sotto i permessi del quale Apache gira.
• La direttiva "IdentityCheck" non funziona; tale direttiva permette il logging nel file access.log dei nomi degli utenti remoti per ogni richiesta.

Messaggi d'errore personalizzati:
Vedremo in queste pagine come personalizzare i messaggi d'errore di Apache. I responsi personalizzati del webserver possono servire ai webmaster per far meglio capire agli utenti ciò che succede quando il loro browser esce con un messaggio d'errore in seguito ad una richiesta impossibile da soddisfare per i più svariati motivi (errori nell'esecuzione di script, richiesta id pagine inesistenti ecc.). I risultati della peronsonalizzazione possono essere fondamentalmente di due tipi: semplici messaggi di testo che spiegano sommariamente l'accaduto e redirezioni verso URL interne o esterne al nostro host.
Per impostare Apache in modo che riesca a produrre dei messaggi d'errore personalizzati bisognerà andare ad agire sul file srm.conf nella rootdir del webserver; in esso leggeremo infatti qualcosa del tipo:

# Customizable error response (Apache style)
# these come in three flavors
#
# 1) plain text
#ErrorDocument 500 "The server made a boo boo.
# n.b. the (") marks it as text, it does not get output
#
# 2) local redirects
#ErrorDocument 404 /missing.html
# to redirect to local url /missing.html
#ErrorDocument 404 /cgi-bin/missing_handler.pl
# n.b. can redirect to a script or a document using
# server-side-includes.
#
# 3) external redirects
#ErrorDocument 402 http://some.other_server.com/subscription_info.html

La sintassi base per i messaggi d'errore personalizzati è quindi:

ErrorDocument XXX azione

dove "ErrorDocument" è la direttiva, XXX è un numero di tre cifre corrispondente al codice d'errore del server (ad esempio 404, 500 ecc.) e "azione" è quello che il server deve fare in caso si riscontrino questi errori.

Soffermiamoci su "azione" prima di vedere alcuni esempi: questa può essere:

• del semplice testo da visualizzare, preceduto dallle virgolette (") ma non dalle stesse chiuso; queste, inoltre, non verranno visualizzate nel messaggio d'errore (primo caso riportato dal file srm.conf);
• un'URL locale (secondo caso riportato);
• un'URL esterna a cui redirigere il visitatore (terzo caso).

E' consigiato non abusare troppo delle redirezioni, soprattutto di quelle esterne: a molti potrebbe dare fastidio trovarsi inspiegabilmente in un sito differente dal vostro per motivi che non si riescono a spiegare.

Vediamo ora qualche esempio per chiarire le cose:

• ErrorDocument 500 "Lo script richiesto non ha potuto essere eseguito per problemi interni.
  
  In questo caso, in presenza di un "Error 500" avverte il visitatore che lo script chiamato dal suo browser ha avuto dei problemi nell'esecuzione e l'output non può essere visualizzato. Questo è un tipico esempio di messaggio d'errore in forma semplicemente testuale.
  
  
• ErrorDocument 500 http://www.altro_server/cgi-bin/script.cgi
  
  In questo secondo caso ci troviamo di fronte ad una redirezione esterna, che porterà il visitatore (in maniera totalmente trasparente, a parte l'indirizzo nel browser) ad un host esterno dove verrà eseguito lo stesso script che questi avrebbe voluto veder eseguito sull'host originario. Questo esempio può essere utile per dimostrare come può essere fatto un uso intelligiente delle redirezioni esterne: sarebbe buona norma, però, controllare (a livello di codice dello script CGI) l'URL dalla quale proviene il visitatore e, nel caso questa combaci con quella dell'host originario (quello in cui egli ha tentato di eseguire lo script) mandare in output un messaggio che lo avverta di cosa è avvenuto e del perchè la sua richiesta è stata spostata su un diverso host. Questioni di cortesia verso gli utenti smarriti.
  
  
• ErrorDocument 404 /missing.html
  
  Se preparate una pagina chiamata "missing.html", per ogni errore 404 (Url not found) verrà visualizzata questa pagina, dove potrete personalizzare nel modo che vi sembra più opportuno. E' chiaro che siamo anche qui di fronte ad una redirezione interna. E' da notare, inoltre, che è possibile redirigere il visitatore a qualsiasi tipo di pagina, sia un plain text che in html, sia contenete uno script che contenente degli includes: se la pagina predefinita (missing.html) è corretamente scritta, non ci sarà alcun problema per il server ad interpretarla in quanto essa è vista come una semplice pagina da inviare al browser dell'utente.
  
  

  ---

  
  

  Impostazione dei files di LOG:
  Prima di tutto, è necessario istruire Apache sulla locazione dove conservare i file di log. Una buona idea è quella di creare una sottodirectory di /var/log chiamata "apache", nella quale esso potrà scrivere quanto necessario.
  Ma come indirizzare i log di apache in tale directory? Ancora una volta, ci viene incontro il file httpd.conf, vero fulcro di Apache.
  
  Scorriamo il file fino a giungere alla riga
  
  # ErrorLog: The location of the error log file
  
  Come essa stessa specifica, la locazione sotto indicata è quella in cui Apache terrà i suoi logs; nelle ipotesi fatte sopra, la specificazione della directory deve essere fatta come:
  
  ErrorLog /var/log/apache/error.log
  
  in modo da essere sicuri che il log degli errori sia proprio all'interno della directory /var/log/apache con il nome (arbitrario) di error.log
  
  Oltre che agli errori, ci interesseremo anche degli accessi, loggato nel file access.log. Qui valgono tutte le considerazioni fatte sopra: la directory sarà la stessa (/var/log/apache) ma il file si chiamerà access.log. Per specificarlo, basterà avere una riga simile a:
  
  CustomLog /var/log/apache/access.log
  
  Se non l'avete già fatto, avviate Apache, giocateci un po' ed andate a vedere i file appena creati: se non avete sbagliato niente, in /var/log/apache avrete due nuovi file che vedremo in seguito come leggere.
  
  

  Tipologia dei files di LOG:
  Oltre a impostare quali debbano essere i file di log di Apache, possiamo anche determinare come devono essere composti, che informazioni devono contenere, quanto completi devono essere ecc.
  Vediamo come.
  
  Continuando a scorrere il file httpd.conf, noteremo una serie di righe (sotto a ErrorLog) che iniziano con
  
  # LogLevel: Control the number of messages logged to the error_log.
  
  Tramite questa direttiva, possiamo decidere il livello di verbosity dei messaggi che vengono scritti nei file error_log; abbiamo diverse possibilità:
  
  

  • debug: messaggi utili al debug;
  • info: informazioni generali;
  • notice: condizioni normali ma significative;
  • warn: warning;
  • error: errori generali (del tipo "Premature end of script headers", utili per il debugging degli script CGI);
  • crit: condizioni critiche;
  • alert: bisogna provvedere immediatamente;
  • emerg: emergenze, il sistema è inutilizzabile.
  
  

  Le possibilità sopraelencate sono riportate in ordine di importanza crescente: quindi un LogLevel impostato su "debug" darà molte meno informazioni che non settato su "emerg". Inolte, se scegliete un livello di verbosity elevato, anche i livelli inferiori saranno in esso inclusi: ad esempio, scegliendo il livello "crit", anche i messaggi normalmente riportati in "debug", "info", "notice", warn" ed "error" saranno riportati nel file di log.
  Sta a voi decidere il livello di importanza dei mesaggi di log, sebbene una scelta abbastanza standard potrebbe essere "error" oppure "crit".
  
  Scorrendo di qualche riga il file, noterete anche la direttiva "LogFormat", che specifica i formati dei file.
  Vediamo quali possono essere i più significativi:
  
  %b --> Byte inviati, esclusi gli headers HTTP;
  
  %f --> Il Filename
  %{VAR}e --> Il contenuto della variabile d'ambiente {VAR}
  %h --> L'host remoto
  %a --> L'indirizzo IP remoto
  %l --> Il logname remoto, se specificato
  %p --> La porta dalla quale il server esegue la richiesta
  %P --> L'ID del processo che esegue la richiesta
  %r --> La prima riga della richiesta
  %s --> Lo stato della richiesta
  %t --> L'orario delle richiesta
  %T --> Il tempo in secondi per eseguire la richiesta
  %u --> Il nome dell'utente remoto
  %U --> L'url richiesta
  
  Una riga standard per determinare i tipi di log potrebbe comunque essere:
  
  "%h %l %u %t \"%r\" %s %b";
  
  

  Leggere dei files di LOG:
  Saper leggere i log, specialmente se si stanno sperimentando nuove soluzioni, può essere molto utile per la risoluzione di alcuni problemi, nonchè per altri controlli che un buon sysadmin deve saper fare.
  
  Ad esempio, in access.log potremo andare a controllare gli accessi in un determinato giorno ad un deterninato script o ad una determinata pagina: prendete ad esempio la righe:
  
  127.0.0.1 - - [17/Feb/2000:17:07:38 +0100] "POST /cgi-bin/ml/mail-admin.pl HTTP/1.0" 200 1522
  127.0.0.1 - - [17/Feb/2000:17:08:41 +0100] "GET /cgi-bin/ml/subscribe.html HTTP/1.0" 403 223
  127.0.0.1 - - [17/Feb/2000:17:08:48 +0100] "GET /cgi-bin/ml/subscribe.html HTTP/1.0" 500 514
  127.0.0.1 - - [17/Feb/2000:17:09:15 +0100] "GET /cgi-bin/ml/subscribe.html HTTP/1.0" 500 514
  
  Il primo campo è l'indirizzo del server (è un server standalone, quindi con indirizzo 127.0.0.1!), viene poi la data, il metodo di richiesta, il nome della pagina o dello sciript richiesto ed il protocollo utilizzato per la richiesta; seguono poi i PID dei processi.
  
  Andiamo a vedere invece come si può presentare error.log:
  
  [Thu Feb 17 17:08:41 2000] [error] [client 127.0.0.1] file permissions
  deny server execution: /usr/lib/cgi-bin/ml/admin.pl
  [Thu Feb 17 18:05:40 2000] [notice] httpd: child pid 215 exit signal Segmentation fault (11)
  [Fri Feb 18 10:39:18 2000] [error] [client 127.0.0.1] File does not exist: /var/www/pino
  [Fri Feb 18 10:41:49 2000] [notice] httpd: caught SIGTERM, shutting down
  
  Ho qui preso quattro righe per poter evidenziare vari casi (che comunque non sono i soli).
  La prima indica un errore nei permessi di un file, e l'incapacità del server di eseguirlo: probabilmente (anzi, sicuramente visto che l'ho fatto apposta!!) si tratta di uno script CGI con i permessi non impostati correttamente.
  La seconda è una semplice notizia: un child process è andato in Segmentation fault, lasciando insoddisfatta una richiesta.
  La terza è un errore che mi avverte che la directory /var/www/pino non esiste: avevo infatti cercato di raggiungere la directory "www.mio_server.it/pino".
  La quarta invece è il risultato di un restart di Apache (mentre facevo delle prove): al riavvio, vengo avvertito che Apache ha ripreso la normale attività.
  
  Il consiglio, a questo punto, è semplice: se volete imparare a leggere correttamente i file di log, oltre ad un certo intuito e ad una conoscienza del proprio sistema, è necessario fare delle prove, magari compiendo di proposito degli errori per vedere come il server risponde.
  
  

  ---

  
  

  Con questo breve testo analizzaremo qualcosa che a molti sembrerà impensabile: vedremo come utilizzare documenti ASP con Apache.
  Le active Server Pages (ASP) sono un'applicazione che ha avuto origine con l'introduzione del server IIS di Microsoft, e che normalmente non si trovano nei sistemi Unix che fanno girare un webserver differente da IIS.
  Ma se è vero che a tutto c'è una soluzione, ebbene ... qui presentiamo la migliore per coloro che vogliano utilizzare documenti scritti in ASP anche con Apache. Basterà solamente avere un po' di pazienza nella fase di configurazione di Apache per l'interazione con il modulo, non immediata ma ben documentata.
  Vista poi la grande diffusione di questa tecnologia, è certamente interessante il progetto di rendere questa tecnologia indipendente dalla piattaforma utilizzata
  
  Come fare con ASP:
  Molto semplicemente, basterà procurarsi un modulo, Apache::ASP, reperibile come tutti gli altri su CPAN.
  
  Non spiegheremo certo in questa sede come si programma in ASP, anche perchè molto probabilmente coloro che stanno leggendo queste righe lo sapranno già fare: in caso contrario, vi consigliamo di leggere la documentazione presentata su www.html.it. Vedremo invece come utilizzare il modulo affinchè ci permetta di utilizzare la tecnoligia ASP su un webserver Apache.
  
  Continuiamo con la descrizione del modulo di cui qui ci occuperemo; Apache::ASP, dicevamo, è la soluzione ideale per chi abbia la necessità di utilizzare pagine scritte in ASP anche sotto Apache, ad esempio per un cambio di server o occasioni simili, oppure per semplice curiosità! Il risultato sarà di massima equivalente a quello che si ottiene caricando una pagina ASP direttamente da IIS, sebbene si lavori ancora sul modulo perchè i risultati siano del tutto identici a quelli che si possono ottenere con IIS.
  
  Tramite il modulo, in pratica, Apache opportunamente istruito interpreterà il documento ASP e visualizzerà il normale output HTML. Con quell' "opportunamente istruito" intendiamo che bisognerà configurare Apache con determinate direttive affinchè interagisca con il modulo e dia a questo la possibilità di interpretare correttamente i documenti ASP. Per la configurazione, rimandiamo alla documentazione del modulo Apache::ASP, che presenta una lista di direttive da includere nel file "access.conf" nella root directory di Apache: questa è alquanto dettagliata e spiegata fin nei minimi particolari.
  
  Vediamo ora gli oggetti utilizzabili tramite il modulo: per chi conosca già la programmazione ASP, questi non saranno una novità e si potrà inoltre notare l'analogia con quelli utilizzabili tramite IIS; insomma, sebbene il modulo abbia dei lati negativi che vedremo in seguito, la mancanza di compatibilità con gli strumenti di IIS non è certo uno di questi.
  
  In breve, gli oggetti sono:
  
  $Session
  $Response
  $Request
  $Application
  $Server
  
  Ognuno di essi, poi, ha dei metodi che possono essere utilizzati dal programmatore a seconda delle sue esigenze; anche per essi, non mancherà una nutrita lista con tanto di esempi su come utilizzare ogni metodo.
  
  
  Ci sono però dei piccoli problemi:
  Ebbene sì, dobbiamo qui ridimensionare il discorso lodevole fatto a proposito del modulo: non comunque a livello di potenzialità dello stesso che, come abbiamo visto poco sopra, permette una piena utilizzazione di documenti scritti con tecnologia ASP in modo completamente trasparente per l'utente che li richiami.
  
  Le "pecche" a cui faremo qui riferimento sono fondamentalmente due.
  
  La prima è una certa difficoltà di installazione e, soprattutto, di configurazione del webserver per l'interazione con il modulo: sebbene la documentazione cerchi di venire incontro quanto più possibile all'utente, con tanto di esempi, essa non è particolarmente indicata per coloro che non abbiano troppa familiarità con il webserver Apache: saranno infatti necessarie pesanti modifiche al file access.conf affinchè l'interazione fra webserver, modulo e pagine ASP sia efficiente: cito comunque dalla documentazione che "(a proposito delle direttive da impostare) Don't set the optional ones if you don't want, the defaults are fine...". Certamente, quindi, basterà molto poco perchè il tutto funzioni, ma per una completa e minuziosa ottimizzazione bisigna sapere cosa impostare e come impostarlo: ma specialmente per macchine utilizzate come server web con carichi di lavoro elevati l'ottimizzazione globale del sistema non è solo una cosa consigliata, ma una vera e propria necessità.
  
  Il secondo lato negativo su cui ci dobbiamo fermare è l'alta richiesta di risorse di sistema utilizzate dal modulo: capirete che con IIS il webserver va direttamente ad interpretare i documenti ASP, su una macchina Unix invece le parti in causa non sono più solamente due, ma al webserver ed ai documenti si frappongono il modulo Apache::ASP e, ovviamente, l'interprete Perl; se questo vi sembra ancora poco, riporto le prime righe del modulo:
  
  use Apache();
  use MLDBM;
  use SDBM_File;
  use Data::Dumper;
  use File::stat;
  use File::Basename;
  use FileHandle;
  use Fcntl qw( O_RDWR O_CREAT );
  use MD5;
  use HTTP::Date;
  
  Un'altra decina di moduli che Apache: ASP deve andarsi a leggere per poter interpretare i documenti ASP e visualizzarne l'output.
  
  E' da sperare che, con le prossime releases del modulo, siano apportati miglioramenti anche in fatto di leggerezza dello stesso, evitando così carichi troppo elevati per le macchine.
  
  
  

  ---

  
  

  In questo tutorial ci occuperemo di un problema che a molti è caro: rendere protette alcune pagine del nostro sito: la presenza di documenti riservati, aree ristrette ai soli membri, zone a pagamento ... tutti questi possono essere buoni motivi per vietare ad occhi indiscreti la visione di determinate pagine.
  Questo si svolgerà in due fasi: nella prima, vedremo come configurare Apache perchè riesca a limitare l'accesso alle directory che ci interessano; nella seconda, come automatizzare l'operazione della creazione degli account tramite l'uso di script o delle utility scritte apposta per questo scopo
  
  
  

  Configurare Apache:
  Solitamente Apache, così com'è, non è configurato affinchè possa proibire o permettere l'accesso alle directory: avremo quindi bisogno di tre strumenti: due modifiche ad altrettanti file di configurazione ed un file .htaccess.
  
  La prima modifica che dobbiamo fare è nel file "srm.conf": scorriamolo fino ad arrivare alla linea che inizia con "AccessFileName": questa direttiva indica il nome del file da utilizzare per leggere gli attributi che dobbiamo dare alle directory nelle quali tale file è presente. Teoricamente, la direttiva dovrebbe essere seguita da ".htaccess", che è un nome standard (ma utilizzabilissimo!) per i server Apache. Forse qualcuno si chiederà a cosa serva il puntino prima del nome: ebbene, negli Unix tutti i file che iniziano con un punto sono dei file nascosti, che non sono visibili tramite il comando "ls", equivalente del "dir" del dos. Rendere nascosto un file così importante può sempre essere utile.
  Vediamo come Apache interpreta tale direttiva: una volta che avrete deciso il nome del file che conterrà le istruzioni e che avrete riavviato Apache per rendere efettive le modifiche, Apache andrà a cercare per ogni directory richiamata da un browser questo file, dal quale leggerà le istruzioni. Ovviamente, se questo non è presente, Apache agirà come di norma; se invece il file esiste, Apache lo leggerà e agirà di conseguenza: se abbiamo impostato delle protezioni tramite password, Apache farà in modo che il browser visualizzi una maschera nella quale vengono richiesti username e password, tramite i quali Apache può verificare o meno l'autenticità del richiedente.
  
  La seconda modifica da attuare è nel file access.conf: scorrete anche questo file fino ad arrivare alla riga "AllowOverride": inserendo un "AuthConfig" Apache richiederà l'autentificazione. Le possibilità, oltre a questa sono molte, in modo da poter affinare il processo di protezione: se volete saperne di più, leggete il file manual/mod/core.html#allowoverride, presente nella directory locale della documentazione di Apache.
  
  Riavviato Apache, saremo pronti a preparare il file che servirà a proteggere le directory che ci interessano, che supporremo essere ".htaccess".
  
  Immaginiamo di voler proteggere la directory remota "http://localhost/prova", corrispondente alla directory locale "/var/www".
  
  Prima di tutto, creiamo un file ".htaccess" all'interno di questa directory, e scriviamoci:
  
  AuthName "prova"
  AuthType Basic
  AuthUserFile /etc/apache/passwd
  require valid-user
  
  Vediamo le caratteristiche del file:
  
  La prima riga indica il nome della protezione: nella maschera che il browser ci mostrerà leggeremo infatti: "Enter username for prova at localhost". Il discorso, a dire la verità, sarebbe molto più ampio: sappiate comunque che, qualsiasi altro file o directory protetto con lo stesso nome in AuthName sarà accessibile senza la necessità di eseguire ulteriori autorizzazioni. La seconda riga indica il tipo di autorizzazione da eseguire: al momento, solamente l'autorizzazione del tipo "Basic" è implementata, sebbene sia già in lavorazione un'autorizzazione "digest". La terza riga indica il file che Apache andrà a leggere per verificare se l'username e la password inseriti sono corretti: approfondiremo a breve questo discorso.
  La quarta riga, infine, controlla gli username: con "require valid-user" Apache accetterà qualsiasi username presente nel file specificato in AuthUserFile. Si potrebbe invece limitare maggiormente l'accesso, inserendo gli username ai quali (e solo ai quali, indipendentemente dalle entries presenti in AuthUserFile) l'accesso è consentito: quindi potrete scrivere
  
  require user nome1 nome2 nome3 ecc.
  
  E' possibile inoltre far riferimento ai gruppi, specialmente quando il numero di utenti cresce troppo. I gruppi funzionano come quelli dei sistemi Unix ed ogni utente può far parte di più gruppi. Si potrà quindi scrivere qualcosa del tipo:
  
  require group nome_del_gruppo
  
  Come con gli utenti, anche in questo caso possono essere specificati più nomi di gruppo da utilizzare. Se invece si usa "require group" insieme a "require user" succede una cosa del genere: qualunque utente membro di uno dei gruppi indicati può avere accesso, così come ogni utente esplicitamente specificato.
  
  Come per gli utenti avevamo creato il file /etc/apache/passwd, dovremo creare anche un file per i gruppi: questo, semplicemente, sarà formato da linee del tipo:
  
  nome_del_gruppo:nome1 nome2
  
  Ancora, come con il file passwd, dovremo specificare ad Apache dove andare a leggere i gruppi ed i suoi appartenenti: utilizzeremo
  
  AuthGroupFile /etc/apache/group
  
  In definitiva, quindi, il file .htaccess completo potrebbe essere:
  
  AuthName "prova"
  AuthType Basic
  AuthUserFile /etc/apache/passwd
  AuthGroupFile /etc/apache/group
  require valid-user
  require group admin
  
  
  

  Creazione degli utenti:
  Adesso che sappiamo come concedere e vietare l'accesso a determinate directory nei server, preoccupiamoci di come creare il file. Questo, a differenza del file dei gruppi, conterrà delle righe nella quali è specificato l'username e la password crittata, nella forma:
  
  username:password
  
  Ma come creare le coppie utente-password? I metodi sono due.
  
  Il primo nonchè il più complesso è quello di creare uno script del tipo:
  
  #!/usr/bin/perl
  
  print "Inserisci un username:\n";
  chomp($name=<STDIN>);
  print "\nInserisci la password per $name:\n";
  chomp($pwd=<STDIN>);
  print "\nConferma la password per $name\n";
  chomp($pwd_confirm=<STDIN>);
  if ($pwd ne $pwd_confirm) {
  # Le due password digitate non sono uguali
  print "Conferma password per $nome non riuscita\n";
  exit;
  } else {
  open(PASSWD, ">> /etc/apache/passwd")
  || die "Non riesco ad aprire il file. $!\n";
  
  # Critta la passord
  $crypted_pwd = crypt($pwd,'aa');
  #Scrive la coppia username:pwd nel file
  print PASSWD "$name:$crypted_pwd";
  close PASSWD;
  print "\nOperazione riuscita!\n";
  }
  
  Vediamo in dettaglio cosa fa lo script: dopo aver chiesto un nome e la password, chiede conferma per la password: se la conferma ha esito negativo, avverte della differenza fra le password digitate ed esce; in caso contrario, apre il file che contiene le coppie username-password, critta la password inserita e scrive nel file "nomeutente-password". Ad operazione conclusa, chiude il file e avverte del successo dell'operazione.
  Lo script, soprattutto per chi si intende di programmazione, non è certo un gioiello ma serve a svolgere il suo lavoro: se volete utilizzarlo, sappiate che è necessario apportargli alcune modifiche come ad esempio il controllo che un username non sia già presente nel file, un'istruzione che in caso di fallimento della conferma della password faccia in modo che lo script riparta dall'inizio ecc.
  
  Il secondo metodo, invece, è quello di utilizzare l'utility htpasswd, che crea ed aggiorna i file di autentificazione utilizzati da Apache.
  
  La sintassi è assai semplice:
  
  htpasswd -c file username password
  
  Il flag "-c" dice all'utility di creare il file delle password nel caso questo non esista; ATTENZIONE che se il file esiste, verrà sovrascritto con la conseguente perdita dei dati precedenti.
  Vediamo un paio di esempi:
  
  htpasswd -c /etc/apache/passwd user
  
  creerà il file "/etc/apache/passwd" ed inserirà l'username "user" e chiederà la password (con conferma, anche in questo caso) per l'utente
  
  htpasswd /etc/apache/passwd user
  
  si può comportare in due modi: se l'utente non esiste, inserisce l'username e chiede la password; se invece l'utente esiste, htpasswd capirà che vogliamo cambiare la password all'utente specificato, chiedendocela.
  
  E con questo, spero, avrete capito come utilizzare le autorizzazioni di accesso con Apache per vietare ai non addetti l'accesso a determinate directory del server della vostra rete o del server remoto.
  
  

  ---

  
  

  Meglio Linux o Nt?
  I benchmark sono test di confronto che intendono mostrare le performance di un prodotto con software e hardware. Diversi produttori e riviste si sono avventurati in benchmark su Linux ed NT, creando non poca confusione. HTML.it tenta di fare luce mettendo a confronto gli stessi benchmark
  
  
  

  Scegliere NT o Unix?
  I due webserver maggiormente diffusi sulla rete sono, senza dubbio alcuno, IIS della Microsoft e l'avversario Apache, sviluppato sulle ceneri di un precedente progetto e da un team di volontari.
  
  La differenza principale fra i due applicativi è la piattaforma per la quale sono stati pensati: IIS per server basati su sistemi Windows, Apache per la grande famiglia degli Unix; un punto a favore di Apache può comunque essere lo sforzo (in parte anche riuscito) di portare il webserver su piattaforme non native, quali ad esempio i sistemi Windows: ovviamente, le migliori performances si ottengono su piattaforma nativa, anche se, si mormora, Apache sulle altre piattaforme non si comporta poi male.
  
  La "lotta" fra questi due webserver è sempre stata aperta, facendo conseguire anche un forte dualismo fra i due sistemi operativi che li supportano: Windows da una parte, gli Unix dall'altra. E, come tutti i dualismi, ognuno afferma, dati alla mano, che il proprio prodotto è migliore del concorrente.
  
  Ma ci si può fidare dei dati che ci vengono, per così dire, propinati? Se la Microsoft dicesse che IIS supera Apache in performances in tutti i campi, ci credereste a priori? E se avvenisse il contrario? Spesso, poi, anche degli esterni ai progetti si sono lanciati in selvaggi benchmark, con risultati a volte accettabili altre assolutamente inaccettabili: se un applicativo è testato su un sistema dell'ultima generazione e l'altro su una vecchia macchina da soffitta, chi credete che possa vincere l'ipotetica sfida?
  
  La rete, questa sorta bacheca di informazioni, mette a disposizione moltissime pagine con i risultati dei benchmark fra IIS e Apache: nella stragrande maggioranza dei casi, comunque, questi risultano fortemente di parte.
  
  Vedendo i risultati dei test nella pagine delle compagnia "x" che si dichiara partner di Microsoft, oppure quelli della compagnia "y" partner di Apache, sareste disposti a credere che i risultati siano veritieri? Magari lo sono, ed i dati risultanti non sono stati manipolati, ma chi ci assicura che un test è stato fatto su un 486 e l'altro su una macchina quadriprocessore? Ad esempio, Netcraft afferma che la coppia Linux/Apache è la più utilizzata come server web; Mindcraft, invece, afferma che è esattamente il contrario, anche per il fatto che NT/IIS è circa tre volte più veloce di Linux/Apache ...
  Insomma, anche qui ci sarebbe molto da discutere senza, purtroppo, arrivare ad alcuna conclusione. A meno di volersi fare i test in casa da soli, a qualcuno bisognerà pur credere.
  
  Navigando per l'intricata rete, mi sono imbattuto in due pagine con gli amati-odiati benchmark, che sembrano essere stati condotti con sufficiente serietà e senza voler portare l'acqua al mulino di nessuno: ovviamente mi posso sbagliare, ma fa anche questo parte del gioco.
  
  Inoltre, non aspettatevi alcun tipo di commento personale : quello che leggerete è solo un estratto delle due pagine.
  
  Prima di passare ai benchmark, ricordo che si sentirà spesso parlare di NT e Linux, che stanno ad indicare il comportamento, rispettivamente, fra NT/IIS e Linux/Apache.
  
  
  

  Alcuni test:
  Questa pagina mi ha subito stupito per una frase: "Server benchmarks comparing Linux and NT are in. Mostly, however, they try to make headlines by breaking records in unrealistic benchmark scenarios. In c't's test lab, a comparison between NT/IIS and the freeware duo Linux/Apache focused on practice-oriented tasks."
  
  Insomma, si afferma che moltissimi test di benchmark sono condotti senza criterio; quelli condotti da loro, invece, sono basati sulla pratica.
  Vero o no, facciamo finta che lo sia.
  
  Intanto, le parti in gioco:
  
  1) windows NT con service pack 4 e IIS 4;
  2) linux suse 6.1, kernel 2.2.9 e apache 1.3.6
  
  Entrambi, ovviamente sulle stesse macchine. I client invece erano macchine di fascia bassa (i server erano equipaggiati con quattro processori Pentium II Xeon a 450 Mhz, due Gb di RAM ed una scheda di rete), alcuni Linux altri Windows (9x e NT), simulando così qualcosa come 1024 richieste in simultanea.
  
  Il primo test è stato effettuato facendo richiedere a tutti i client la stessa pagina HTML da 4Kb: il risultato è una sostanziale parità di performances fra i due webserver.
  
  Il secondo, invece, si basa su una richiesta casuale da parte dei client di una pagina fra le 10.000 (ovviamente della stessa grandezza) presenti in una directory del server. In questo test, Linux/Apache è risultato circa il 15% più veloce.
  
  Il terzo test, che inizia ad essere impegnativo per le macchine, si basa sulla richiesta di una quantità di file di due volte superiore a quella della RAM dei server (quindi qualcosa come 4 GB di pagine richieste). NT/IIS sembra non riuscire a sopportare più di 30 richieste al secondo, mentre Linux/Apache arriva a 166. La differenza, si commenta, può essere principalmente dovuta la tipo di partizione utilizzata dai sistemi (in termine di grandezza dei cluster o inode) che non alle capacità degli stessi.
  
  Il quarto test si basa non più su pagine statiche come nei precedenti tre test, ma su pagine dinamiche: la scelta è ricaduta sui CGI, non essendo le tecnologie ASP e VBscript direttamente portabli ad altri sistemi. Su NT è stato installato ApcivePerl 517.3, equivalente al Perl 5.005_3 presente sul server Linux. Il risultato è palese: NT/IIS soffrono della "non-natività" del linguaggio Perl utilizzato per l'interpretazione dei CGI, riscontrabile come un'eccessiva lentezza nell'invio delle pagine create dinamicamente. Ma per questo test, avvertono, il risultato era scontato dall'inizio, e quindi poco significativo. Ricordiamo infatti che il Perl, linguaggio più largamente utilizzato per scrivere script CGI, è nato in ambiente Unix e, sebbene il porting di Activestate per le piattaforme Windows sembra essere molto ben riuscito, ancora una volta la non-natività del linguaggio di interpretazione si fa sentire.
  
  L'ultimo test è quello di servire sedici macchine tramite due schede di rete. Qui NT/IIS riesce a prevalere sull'avversario Linux/Apache anche con una potenza di calcolo minore, ossia con un processore in meno. La velocità con cui NT/IIS invia le pagine ai client ha fatto addirittura pensare che le performances non sarebbero peggiorate significativamente neanche con quattro schede di rete al posto di due.
  Questo dimostra che NT, quando ci si attiene alle sue "regole", può essere veramente veloce.
  
  Le conclusioni degli autori del test sono le seguenti: per una rete mista, formata cioè da richieste differenti ed indipendentemente dal volume delle stesse, l'accoppiata Linux/Apache risulta migliore. Per un server con più schede di rete e con prestazioni medio-alte, NT/IIS è l'accoppiata ideale.
  Ovviamente, poi, sottolineano il fatto che le necessità possono essere anche altre, ad esempio il linguaggio di scripting da adottare (CGI, ASP, VBscript ecc.), la potenza della macchina da utilizzare (sembra infatti che Linux/Apache riesca a "spremere" maggiormente le CPU, sebbene NT/IIS appaia sempre più performante per ogni CPU aggiunta) ecc.
  
  Insomma, tennisticamente parlando il risultato è un "40-30" a favore di Linux/Apache: la non netta supremazia dell'uno o dell'altro mi ha fatto scegliere questa pagina, considerata imparziale nei giudizi.
  
  

  Conclusioni:
  Avevo detto all'inizio che non mi sarei sbilanciato su conclusioni che potrebbero (anzi, sarebbero state!!) personali: ebbene, non mi rimangio tutto ma voglio solo fare alcune considerazioni che considero oggettive.
  
  In primo luogo, l'hardware utilizzato per le prove è determinante per gli esiti dei benchmark: ovviamente si parla a parità di macchine, ma è ovvio che se un sistema è ottimizzato per avere le migliori prestazioni su una macchina configurata in un determinato modo e con determinato hardware installato, per le altre c'è poco scampo.
  Se NT è ottimizzato per lavorare con il processore1 sulla scheda Ethernet1 , il processore2 sulla 2 e via dicendo, ovviamente le prestazioni a confronto con quelle di Linux che non impiega un procesore per ogni scheda sono migliori; inoltre, in un caso come quello appena visto, non impegnando direttamente Linux un processore per ogni scheda, si sarebbe dovuta (o almeno potuta!) misurare la capacità dei due sistemi, a parità di carico, di gestire altre applicazioni. Così come Linux su sistemi "poveri" si comporta meglio di NT, visto il minor impiego di risorse di questo sistema. E questi sono solo due casi che si possono ipotizzare.
  
  Inoltre, per quanto riguarda sia Linux che NT, c'è un discorso da fare a livello di software:
  
  1) per Linux, la versione del kernel c'entra molto: ogni nuova versione è un miglioramento della precedente, ed è quindi matematico che una versione del kernel più aggiornata garantisca migliori prestazioni di una vecchia versione;
  2) Per NT è la stessa cosa a livello di Service Pack: purtroppo non tutti i benchmark riportano la versione di SP utilizzata, ma anche qui è ovvio che una versione aggiornata comporta una crescita di prestazioni; altrimenti, a cosa servirebbero le patch??
  
  A questo punto ognuno può pensare quello che vuole, i dati sono questi e sono forniti da società presumibilmente serie. Le differenze ci sono, ed ho cercato anche di motivarle per quanto mi fosse possibile: sta ad ognuno, se interessato, provare se questi siano veritieri o meno.
  
  Ricordatevi sempre che, comunque, un tecnico windows riuscirà sempre a far prevalere (anche in buona fede) un sistema NT su un sistema Linux e viceversa! Credo che anche le competenze software siano un buon elemento per poter giudicare i test proposti!
  
  

  ---

  
  

  Il protocollo HTTPS
  Quello che qui tratteremo sarà il rapporto fra il webserver Apache ed il protocollo HTTPS, ossia il protocollo HTTP con il supporto SSL. Vedremo quindi dove reperire i sorgenti, come compilarli, come creare dei certificati e come configurare al meglio il server per abilitare il supporto HTTPS.
  
  Quello di cui tratteremo in queste pagine sarà riferito ai soli sistemi Unix, visto che l'implementazione del protocollo SSL su altre piattaforme non è ancora stata realizzata
  
  
  

  Il codice sorgente:
  Ovviamente, prima di iniziare abbiamo bisogno del giusto codice sorgente di Apache, reperibile all'homepage del progetto Apache-SSL, http://www.apache-ssl.org/. Alternativamente, è possibile trovare una versione di Apache con supporto SSL già nei pacchetti del proprio sistema: ad esempio, nella Debian 2.2 che sto al momento utilizzando è presente il pacchetto "apache-ssl-1.3.9.12+1.deb" che, una volta installato, ci farà avere un webserver Apache già compilato con il supporto SSL built-in. Per chi non abbia tale pacchetto, il download dei sorgenti da compilare è l'unica strada da seguire.
  
  A questo punto, ci servirà anche una libreria per la crittatura dei dati da utilizzare per il "secure HTTP": stiamo parlando di "SSLeay", reperibile via FTP al sito ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/; scaricata e spostata in qualche directory come, ad esempio, /usr/local, non ci resterà che decomprimerla ed entrare nella risultante sottodirectory SSLeay-xxx (dove "xxx" è il numero di versione della libreria). Dopo aver letto il file INSTALL, siamo pronti per installare la libreria: lanciando ./Configure ci verrà fornita una serie di sistemi operativi fra cui scegliere: troviamo il nostro e lanciamo nuovamente "./Configure nostrosistema".
  
  Fatto questo, potremo scaricare dal sito FTP ftp://ftp.ox.ac.uk/pub/crypto/SSL/ la patch per Apache: applichiamola ai sorgenti come descritto nel file README.SSL ed iniziamo a compilare Apache: se il processo di patching è andato a buon fine, dovremo vedere, nei sorgenti di Apache, che la riga
  
  SSL_BASE=
  
  punti esattamente alla directory dove è presente la libreria SSLeay, nel nostro caso /usr/local/SSLeay-xxx. Se tutto è a posto, non ci resta che lanciare lo script "./configure" che creerà il Makefile seguito da un "make" per compilare i sorgenti. Se tutto va per il verso giusto, dovremo veder apparire l'eseguibile "httpsd", che sarà proprio il demone che supporterà il protocollo HTTPS.
  
  

  Il primo certificato:
  Adesso che abbiamo il demone httpsd, possiamo creare il nostro certificato: le informazioni che servono sono tutte contenute nel Makefile creato dal "./configure" lanciato dalla directory dei sorgenti di Apache, quindi potremo lanciare il comando
  
  make certificate
  
  che compilerà quello che serve, creando la chiave RSA a 1024 bit e ponendoci alcune domande sul nostro server, ad esempio:
  
  

  • Country Name (2 letter code);
  • State or Province Name;
  • Locality Name (eg, city);
  • Organization Name;
  • Organization Unit Name;
  • Common Name (eg, ssl.domain.com; required!);
  • Email Address;
  
  

  Fornendo tali informazioni, verrà creata la nostra chiave privata RSA ed il nostro certificato: è da notare che la maggior parte delle domande che ci verranno fatte sono opzionali, e che solo "Common Name" è richiesta, per ovvie ragioni.
  
  La chiave RSA che risulterà sarà qualcosa di simile a:
  
  -----BEGIN RSA PRIVATE KEY-----
  MIICXAIBAAKBgQDBpDjpJQxvcPRdhNOflTOCyQp1Dhg0kBruGAHiwxYYHdlM/z6k
  pi8EJFvvkoYdesTVzM+6iABQbk9fzvnG5apxy8aB+byoKZ575ce2Rg43i3KNTXY+
  ...
  C5VTb4CUF7d6ukDVMT2d0/SiAVHBEI2dR8Vw0G7hJPY=
  -----END RSA PRIVATE KEY-----
  
  mentre il certificato sarà qualcosa tipo:
  
  -----BEGIN CERTIFICATE-----
  MIICvTCCAiYCAQAwDQYJKoZIhvcNAQEEBQAwgaYxCzAJBgNVBAYTAlVTMQ8wDQYD
  VQQIEwZOZXZhZGExFTATBgNVBAcTDEhvcGVmdWwgQ2l0eTEZMBcGA1UEChMQQnV0
  ...
  7kM1LoxQjZL0bg61Av3WG/TtuGqYshpE09eu77ANLngp
  -----END CERTIFICATE-----
  
  Ovviamente, per non riportare inutili linee piene di simboli, non è stato riportato il certificato per intero, ma è stato "virtualmente" tagliato con l'uso dei "..."; ovviamente, quando creerete la vostra chiave ed il certificato non vedrete i puntini ma una serie di righe formate da una sequenza di caratteri. Ricordiamo, inoltre, che l'output di tutto il lavoro fatto per la creazione della chiave RSA e del certificato è nel file "httpsd.pem".
  
  
  

  Il file di configurazione:
  A questo punto siamo a posto per quanto riguarda il demone httpds, la chiave RSA ed il nostro certificato: quello che ci manca è un file di configurazione che dica al webserver come comportarsi quando è stabilita una connessione SSL; un esempio di file di configurazione è reperibile, sempre fra i sorgenti di Apache, alla directory ../apache/SSLconf/conf. Tale file si occupa di creare due "siti", uno sicuro sulla porta 8888 ed uno "normale" (semplice protocollo HTTP) sulla porta 8887. Vediamo le voci del file che ci interessano: noterete che molte sono simili a quelle incontrate per i normali file di configurazione di Apache.
  
  User webuser
  Group webgroup
  # L'utente ed il gruppo, come per il file httpd.conf
  
  Loglevel debug
  # Il livello di dettaglio dei file di log
  
  ServerType standalone
  # A differenza di httpd.conf, in una connessione SSL il server deve
  # essere di tipo standalone, e non lanciato da inetd.
  
  Port 8887
  # La porta nella quale il server è in ascolto: di default, questa
  # sarebbe la 443 (da /etc/services:
  # https 443/udp)
  # ma scegliamo la 8888 per non dover essere root.
  
  Listen 8887
  Listen 8888
  # Le porte nelle quali il server è messo in listen: notate che ne
  # abbiamo specificate due, una per il normale protocollo HTTP l'altra per
  # il protocollo HTTPS.
  
  DocumentRoot /usr/www/site.ssl/htdocs
  # La document root
  
  SSLRequireSSL
  # Questa direttiva serve a proteggere una directory negando l'accesso
  # quando non si è connessi con protocollo SSL: l'utilità delle direttiva
  # è quella di non permettere a chiunque di accedere ai documenti ai
  # quali normalmente si accederebbe con SSL
  
  TransferLog logs/transfer_log
  # Il file di log.
  
  SSLDisable
  # Con questa direttiva disabiliteremo il protocollo SSL per i
  # virtualhosts; se si vuole fare il contrario, sarà necessario
  # sostituire "SSLDisable" con "SSLEnable".
  
  SSLCACertificateFile /usr/www/site.ssl/conf/thawte.cert
  # Il path per il certificato CA
  
  SSLVerifyClient 0
  # Se impostata su "0", non si richiede un certificato; su "1" il client
  # può presentare un certificato valido; su "2" il client deve presentare
  # un certificato valido; su "3" il client può presentare un certificato
  # valido anche se questo non è richiesto per il certificato CA. Un
  # tipico messaggio del server quando un client non presenta un
  # certificato potrebbe essere:
  # "No User Certificate.
  # The site 'www.sito.com' has requested client
  # authentication, but you don't have a Personal Certificate
  # to autenthicate yourself. The site may choose not to give you access
  # without one."
  
  SSLCACertificateFile /usr/www/site.ssl/conf/cert.pem
  # Il path per il certificato che abbiamo creato all'inizio del capitolo.
  
  CustomLoglogs/ssl_log "%t %{version}c %{cipher}c %{clientcert}c"
  # Il file di log "custom", come quello visto per Apache senza supporto
  # SSL.
  
  

  ---

  
  

  Virtualhosts
  Quello di cui ci occuperemo in questa guida saranno i virtualhosts. Cosa sono i virtualhosts? Supponete di avere due hosts sulla stessa macchina: il primo è quello che siamo abituati a chiamare "il server", il secondo è il virtual host. In pratica, quindi, due o più server sulla stessa macchina, come www.server1.com, www.server2.com ecc. Entrambi, comunque, saranno visto come veri e propri "server separati".
  I virtualhost, come potrete benissimo immaginare, sono altamente utilizzati nel webhosting, quando un utente, oltre ad acquistare dello spazio sul server, registra anche un nome di dominio, al quale il server deve rispondere.
  Apache, dalla versione 1.1, supporta sia i virtualhosts basati sul numero di IP sia quelli basati sul nome; questi ultimi vengono anche chiamati "basati sull' host" (host-based) oppure "non-IP virtual hosts".
  Vedremo nei prossimi capitoli come creare e configurare entrambi
  
  
  

  IP-Based Virtual Hosts:
  Il primo tipo di configurazione che vedremo è quello basato sull'IP: ovviamente, per rendere il tutto possibile, avrete necessariamente bisogno di più di un IP, rispettivamente uno per ogni host virtuale.
  
  Sicuri di avere quanto necessario, si pone davanti a noi un'altra scelta: configurare Apache in modo che un singolo processo httpd sia eseguito per ogni singolo host, oppure utilizzare un solo processo httpd per tutti gli host.
  Scegliere fra queste due possibilità non sarà comunque un problema: se avete problemi di memoria RAM, utilizzate un singolo processo, se invece avete bisogno di differenti configurazioni per ogni host e sulla vostra macchina la RAM abbonda, utilizzate più processi.
  
  1. Utilizzazione di più processi httpd.
  
  per lavorare con più demoni httpd, basterà semplicemente utilizzare una direttiva "listen" per ognuno, ad esempio:
  
  Listen www.sito1.com:80 (oppure Listen 123.456.7.8:80)
  Listen www.sito2.com:81
  
  e via dicendo. 2. Utilizzare un solo processo con i virtual hosts. In questo caso, utilizzeremo un solo processo httpd per tutti gli host virtuali; la configurazione di ogni host può partire dall'esempio riportato nel file httpd.conf:
  
  <VirtualHost host.some_domain.com>
  ServerAdmin webmaster@host.some_domain.com
  DocumentRoot /var/www/host.some_domain.com
  ServerName host.some_domain.com
  ErrorLog /var/log/apache/host.some_domain.com-error.log
  TransferLog /var/log/apache/host.some_domain.com-access.log
  </VirtualHost>
  
  Poniamo di voler creare l'host virtuale www.virtuale.com, la cui DocumentRoot sia /www/virtuale ed il file di log degli errori in /var/log/virtuale/error.log; quello che dovremo scrivere sarà:
  
  <VirtualHost www.virtuale.com>
  ServerAdmin admin@virtuale.com
  DocumentRoot /www/virtuale
  ErrorLog /var/log/virtuale/error.log
  </VirtualHost>
  
  Per ogni host virtuale che vorremo creare, ovviamente, sarà necessario inserire un altro blocco di istruzioni fra i "tags" <VirtualHost> e </VirtualHost>
  
  
  

  Name-based virtual hosts:
  Utilizzare una configurazione del genere per i virtual hosts è un'ottima maniera di implementare un bel numero di host su un solo server. Il piccolo contro, è che i browser devono supportare il protocollo HTTP/1.1, che praticamente tutti i browser recenti supportano.
  
  Configurare degli host in questo modo non è troppo dissimile dalla configurazione degli IP-based virtual hosts: l'unica differenza è l'utilizzo della direttiva NameVirtualHost.
  Se ad esempio www.server1.com e www.server2.com sono legati all'indirizzo IP 123.456.7.8, possiamo impostare due virtual host come segue:
  
  NameVirtualHost 123.456.7.8
  
  <VirtualHost 123.456.7.8>
  ServerName www.server1.com
  DocumentRoot /www/server1
  </VirtualHost>
  
  <VirtualHost 123.456.7.8>
  ServerName www.server2.com
  DocumentRoot /www/server2
  </VirtualHost>
  
  Quindi, sulla macchina con IP 123.456.7.8, saranno presenti due host, ognuno con le proprie caratteristiche e, soprattutto, nome. Ricordate inoltre che fra <VirtualHost> e </VirtualHost> potrete inserire tutte le istruzioni che vi servono, differenti per l'uno e per l'altro host: in questo caso abbiamo cercato di semplificare al massimo la configurazione degli host ma, per un esempio, potete rifarvi all'esempio riportato poco sopra.
  
  
  

  Prima di chiudere:
  Prima di terminare, poniamo l'accento su una cosa che per alcuni potrebbe essere utile: ad esempio, volete che a "http://server.it" corrisponda anche "www.server.it". Questo può essere fatto con semplicità tramite:
  
  ServerAlias server.it www.server.it
  
  oppure
  
  ServerAlias server.it *.server.it
  
  Per chi volesse approfondire l'argomento dei virtual hosts, soprattutto per quanto riguarda le differenti configurazioni, consiglio una lettura degli esempi forniti con la documentazione di Apache, presenti nella directory ../apache/manual/vhosts/examples.html
  
  

  ---

  
  

  Un server sicuro
  Sappiamo tutti l'importanza di un servizio di webserver, specialmente in questi ultimi periodi nei quali sembra che la rete sia un nuovo Eldorado; un servizio del genere, comunque, non può che implicare dei rischi, vista la potenziale insicurezza dei webserver; se poi a questi, oltre al normale onere di inviare pagine web, diamo anche altre mansioni come ad esempio eseguire file (soprattutto script) e cose del genere, il potenziale rischio di creare un servizio non solo poco efficiente ma anche pericoloso cresce esponenzialmente.
  
  Un webserver ben configurato, da mani esperte con anni di esperienza alle spalle e miriadi di macchine preparate a questo scopo, è certamente un ottimo punto di partenza; l'altra faccia della medaglia è, comunque, la possibilità purtroppo non così remota di compiere degli errori anche banali in fase di configurazione che si possono trasformare in veri e propri eventi drammatici. Un esempio su tutti è un errore di assegnazione di qualche permesso, in modo che qualcuno senza autorizzazione si veda avere accesso a zone vietate della macchina.
  
  Vedremo qui le cose più importanti da non tralasciare quando si configura un server web, nella fattispecie, ovviamente, Apache.
  
  
  

  5 cose da tenere sotto controllo:
  
  

  • Disabilitare i SSI (Server Side Includes) ogni volta che questi non siano strettamente necessari; si utilizzi la direttiva "Options" in ogni directory oppure in ogni file .htaccess per abilitarli dove serva; inoltre, sarebbe da disailitare la funzione "exec", potenzialmente dannosa se utilizzata per secondi fini.
    
    
  • Si utilizzi la direttiva "AllowOverride None" ogni volta che questo sia possibile. Tale direttiva serve a questo: se il webserver trova, ad esempio, un file ".htaccess" o comunque un file il cui nome sia specificato nella direttiva "AccessFileName", deve sapere quali valori presenti in questo file possono bypassare quelli di default del server. Quindi, potenzialmente, un file ".htaccess" potrebbe far comportare il webserver in maniera totalmente differente da quella definita nel suo file di configurazione. Ovviamente, con la direttiva "AllowOverride None" non si corrono di questi rischi: a monte di tutto c'è, comunque, un solido e curato file di configurazione principale di Apache.
    
    
  • Proteggete le home directory degli utenti, specialmente nel caso in cui facciate dell'hosting remoto. Questo può essere fatto tramite la direttiva "<Directory> </Directory>", che specifica delle direttiva da applicare ad una determinata directory ed alle sue sottodirectory. Ad esempio, supponendo che tutti i vostri utenti abbiano le loro home in /usr/home, il minimo che potete scrivere è:
    
    <Directory /usr/home>
    AllowOverride None
    Options Indexes
    SymLinksIfOwnerMatch
    </Directory>
    
    Ovviamente, potrete poi specificare altre opzioni che ritenete utili per ognuno dei vostri utenti separatamente o, perchè no, tutti.
    
    
  • Non abusate della direttiva "AddHandler". Sebbene questa possa essere utile a farci perdere meno tempo in configurazioni, copia dei file in determinate directory ecc, può essere pericolosa per il semplice fatto che qualsiasi estensione passata alla direttiva può diventare uno script eseguibile sul server con conseguenza imprevedibili. Puntate piuttosto su una cgi-bin di sistema ed, eventualmente, su una directory cgi-bin per ogni utente (che dev'essere comunque controllata) senza specificare, ad esempio, che qualsiasi file con estensione .pl o .cgi sia eseguito dal server.
    E' senza dubbio migliore perdere qualche minuto a spostare gli script nella directory cgi-bin che non lasciare che qualsiasi file sia indiscriminatamente eseguito da qualunque posizione (ovviamente "web-visible").
    
    
  • Fate attenzione all'assegnazione dei permessi: di regola, un utente, specialmente in hosting, non dovrebbe mai avere la possibilità di uscire dalla propria home directory, sia in lettura che soprattutto in scrittura; questo per diversi motivi: intanto, per non andare a leggere o modificare lavori di altri utenti e, in secondo luogo, per non andare a zonzo nel sistema trovando magari qualche eseguibile da lanciare o dati riservati da leggere. LA cosa migliore sarebbe quella di creare un gruppo (potrebbe essere "users" o "remote_users" o qualunque cosa vogliate) nel quale ogni nuovo utente viene inserito, in modo che si veda già alla creazione limitato nelle azioni da compiere sul sistema ospitante.