Linux WWW HOWTO
  di Wayne Leister, n3mtr@qis.net
  v0.82, 19 Novembre 1997

  Questo documento contiene informazioni sul settaggio e l'installazione
  di servizi WWW in Linux (sia server che client). Questo testo non
  vuole essere un manuale dettagliato, ma semplicemente una panoramica
  nonché un punto di partenza per successive ricerche. Traduzione di
  Silvio Porcellana <sporc at mbox.vol.it>.
  ______________________________________________________________________

  Indice Generale


  1. Introduzione
     1.1 Copyright
     1.2 Feedback
     1.3 Nuove versioni di questo documento

  2. Installazione di software client per WWW
     2.1 Panoramica

  3. Lynx
     3.1 Dove trovarlo

  4. Emacs-W3
     4.1 Dove trovarlo

  5. Netscape Navigator/Communicator
     5.1 Differenti versioni e opzioni.
     5.2 Dove trovarlo
     5.3 Installazione

  6. Installare dei server WWW
     6.1 Panoramica

  7. Apache
     7.1 Dove trovarlo
     7.2 Compilazione e installazione
     7.3 Configurazione
     7.4 Ospitare siti web virtuali
        7.4.1 Hosting basato sugli IP virtuali
        7.4.2 Hosting basato sugli indirizzi IP condivisi
     7.5 Script CGI
     7.6 Directory Web degli Utenti
     7.7 Daemon mode vs. Inetd mode
     7.8 Autorizzare i comandi put e delete
     7.9 Autenticazione dell'utente/Controllo d'accesso
     7.10 su-exec
     7.11 Imagemap
     7.12 SSI/XSSI
     7.13 Sistema modulare

  8. Web Server Add-ons
  9. FAQ
  10. Letture consigliate
     10.1 Libri della O'Reilly & Associates
     10.2 Internet Request For Comments (RFC)


  ______________________________________________________________________

  11..  IInnttrroodduuzziioonnee



  Molte persone usano Linux perché sono alla ricerca di un buon sistema
  operativo che sia anche _I_n_t_e_r_n_e_t _c_o_m_p_a_t_i_b_i_l_e. Inoltre, ci sono
  istituti, università, enti non-profit e piccole imprese che vogliono
  mettere on line dei siti Internet con un budget limitato. È qui che il
  WWW-HOWTO vuole inserirsi. Questo documento spiega come far funzionare
  dei client e server per la parte più consistente di Internet - il
  _W_o_r_l_d _W_i_d_e _W_e_b.

  Tutti i prezzi si intendono in dollari americani. Questo documento
  presuppone che si stia utilizzando Linux su una piattaforma Intel: le
  istruzioni e la disponibilità dei prodotti possono variare da
  piattaforma a piattaforma. Sono presenti inoltre molti link per il
  download del software: quando possibile, è preferibile utilizzare i
  siti mirror per ottenere un download più veloce e ridurre il traffico
  verso il server principale.

  Il governo americano probisce alle aziende statunitensi l'esportazione
  di algoritmi di crittografia che superino i 40 bit. Pertanto le
  compagnie americane offrono di solito due versioni del loro software:
  una per il mercato domestico solitamente a 128 bit e una solo per
  l'esportazione a 40 bit. Ciò si applica sia ai browser sia ai server
  che supportano le transazioni sicure, altrimenti note come Secure
  Socket Layer (SSL).


  11..11..  CCooppyyrriigghhtt


       Per motivi legati alla validità della licenza le note di
       copyright devono essere mantenute in lingua originale.


  This document is Copyright (c) 1997 by Wayne Leister.  The original
  author of this document was Peter Dreuw.(All versions prior to 0.8)


       This HOWTO is free documentation; you can redistribute it
       and/or modify it under the terms of the GNU General Public
       License as published by the Free Software Foundation; either
       version 2 of the License, or (at your option) any later ver­
       sion.



       This document is distributed in the hope that it will be
       useful, but without any warranty; without even the implied
       warranty of merchantability or fitness for a particular pur­
       pose.  See the GNU General Public License for more details.



       You can obtain a copy of the GNU General Public License by
       writing to the Free Software Foundation, Inc., 675 Mass Ave,
       Cambridge, MA 02139, USA.


  Trademarks are owned by there respective owners.


       ovvero:


  Questo documento è Copyright (c) 1997 di Wayne Leister.  L'autore
  originale è Peter Dreuw (Tutte le versioni prima della 0.8)

       Questo HOWTO è documentazione gratuita: si può redistribuire
       e/o modificare rispettando i termini della Licenza Pubblica
       GNU così come pubblicata dalla Free Software Foundation; sia
       la versione 2 della Licenza che (a vostra scelta) ogni altra
       versione più recente.



       Questo documento è distribuito con la speranza che possa
       risultare utile, ma senza alcuna garanzia, nemmeno quella di
       vendibilità o adeguatezza per scopi particolari. Per mag­
       giori dettagli, riferirsi comunque alla Licenza Pubblica
       GNU.



       È possibile ottenere una copia della Licenza Pubblica GNU
       scrivendo alla Free Software Foundation, Inc., 675 Mass Ave,
       Cambridge, MA 02139, USA.


  I marchi di fabbrica sono di proprietà dei rispettivi proprietari.


  11..22..  FFeeeeddbbaacckk

  Ogni forma di feedback è gradita. Non ho la pretesa di essere un
  esperto.  Alcune di queste informazioni sono state reperite da siti
  scritti male: ci possono essere errori o omissioni. Accertatevi
  comunque di avere l'ultima versione del documento prima di inviare
  correzioni: il problema potrebbe essere stato risolto nella release
  più recente (nella prossima sezione è spiegato dove trovare le ultime
  versioni del documento).  Ogni commento va inviato a: n3mtr@qis.net.


  11..33..  NNuuoovvee vveerrssiioonnii ddii qquueessttoo ddooccuummeennttoo

  Le nuove versioni di questo documento possono essere scaricate in
  formato testo da Sunsite a
  <http://sunsite.unc.edu/pub/Linux/docs/HOWTO/WWW-HOWTO> e da quasi
  qualunque altro sito mirror. È possibile vedere l'ultima versione HTML
  sul web a <http://sunsite.unc.edu/LDP/HOWTO/WWW-HOWTO.html>.  Ci sono
  inoltre versioni HTML presso Sunsite in archivi tar.



  22..  IInnssttaallllaazziioonnee ddii ssooffttwwaarree cclliieenntt ppeerr WWWWWW

  Il prossimo capitolo è dedicato all'installazione di web browser.  Se
  il vostro browser favorito non è menzionato, sentitevi liberi di
  contattarmi per farmelo sapere. In questa versione del documento, solo
  pochi browser hanno la loro sezione, ma ho cercato di includerli tutti
  (quelli che ho trovato...) nella sezione Panoramica. Nel futuro, quei
  browser che meritano una loro sezione l'avranno.

  La sezione Panoramica è pensata per aiutarvi a decidere quale browser
  utilizzare e per fornire informazioni di base su ogni singolo browser.
  La sezione Dettaglio serve invece per aiutare nell'installazione,
  settaggio e manutenzione del browser.

  Personalmente, preferisco Netscape: è l'unico browser che si mantiene
  aggiornato sulle ultime novità in fatto di HTML, quali frame, Java,
  Javascript, style sheet, transazioni sicure e layer. Non c'è niente di
  peggio che provare a visitare un sito e scoprire che non lo si può
  vedere perché il prorio browser non supporta alcune nuove
  caratteristiche.

  Comunque, utilizzo Lynx quando non ho voglia di lanciare il "mostro"
  X-Windows/Netscape.


  22..11..  PPaannoorraammiiccaa


     ````NNaavviiggaattoorr//CCoommmmuunniiccaattoorr''''
        Netscape Navigator è l'unico browser qui citato che sfrutti
        appieno le nuove caratteristiche di HTML avanzato. Alcune di
        queste sono i frame, Java, Javascript, update automatico e
        layer. Funge anche da client per la posta e per la lettura delle
        news.  È però un divoratore di risorse, sia di CPU che di
        memoria. Inoltre, crea una cache disco per ogni utente,
        sprecando un sacco di spazio.  Netscape è un prodotto
        commerciale: le imprese hanno un periodo di prova di 30 giorni,
        ma non c'è alcun limite per i privati.  Vorrei incoraggiare
        comunque tutti a registrarsi per supportare Netscape nella sua
        lotta contro Microsoft (e cosa sono poi 40 miseri dollari?). La
        mia paura è che se Microsoft vince, saremo tutti forzati ad
        usare Internet Explorer su una piattaforma Windows :(


     ````LLyynnxx''''
        Lynx è uno tra i più piccoli browser: è gratuito e il codice
        sorgente è disponibile sotto la Licenza GNU. È il re dei browser
        testuali, offrendo molte funzioni speciali pur avendo solo
        un'interfaccia a caratteri.


     KKffmm
        Kfm fa parte del K Desktop Environment (KDE). Si tratta di un
        sistema che funziona sotto X-Windows e che offre molte
        caratteristiche quali drag and drop, suoni, un cestino nonché un
        aspetto omogeneo. Kfm è una file manager, ma può essere
        utiizzato anche come browser. Non bisogna farsi ingannare dal
        nome, visto che, pur essendo un prodotto molto giovane, è molto
        comodo per navigare sul Web. Supporta i frame, le tabelle, il
        download ftp, la visualizzazione di archivi tar e molto altro.
        La versione corrente è la 1.39 ed è gratuita: è possibile
        utilizzarlo anche senza KDE, ma necessita comunque delle
        librerie che accompagnano questo windows manager. Maggiori
        informazioni possono essere reperite presso
        <http://www.kde.org>.


     ````EEmmaaccss''''
        Emacs è un "coltellino svizzero".  È un word processor, un
        client per la posta e un browser. È molto difficile da
        utilizzare all'inizio perché bisogna imparare tutti i comandi
        associati alla tastiera, ma la versione per X-Windows è più
        semplice dal momento che tutte le funzioni sono sui menu.
        Un'ulteriore controindicazione è che è sostanzialmente testuale,
        e dunque le immagini possono essere visualizzate solo nella
        versione per X-Windows.  Anche Emacs è gratuito e il codice
        sorgente è disponibile sotto la Licenza GNU.


     NNCCSSAA MMoossaaiicc
        Mosaic è un browser per X-Windows sviluppato dal Centro
        Nazionale delle Applicazioni per Supercomputer (NCSA)
        dell'Università dell'Illinois: NCSA ha impiegato quattro anni
        per completare il progetto e adesso si è rivolta verso altre
        possibilità.  La versione più recente è la 2.6, rilasciata il 7
        luglio 1995, il cui codice sorgente è disponibile per un uso non
        commerciale.  Spyglass Inc. <http://www.spyglass.com> ha tutti i
        diritti commerciali su Mosaic.  Questo è un browser per X-
        Windows molto solido, ma è carente per quanto riguarda le nuove
        caratteristiche dell'HTML. Per maggiori informazioni visitate la
        home page di Mosaic presso
        <http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/>.  Il software
        può essere scaricato presso
        <ftp://ftp.ncsa.uiuc.edu/Mosaic/Unix/binaries/2.6/Mosaic-
        linux-2.6.Z>.


     AArreennaa
        Arena è un browser per X-Windows concepito quando si stava
        testando l'HTML 3.0. Pertanto supporta tutte le caratteristiche
        di questa versione, dai fogli di stile alle tabelle. Lo sviluppo
        è stato portato avanti da Yggdrasil Computing con l'obiettivo di
        giungere alla creazione di un browser grafico gratuito e
        pienamente aggiornato. Nonostante ciò, lo sviluppo si è fermato
        nel febbraio del 1997 con la versione 0.3.11, che ha
        implementato solo una parte degli standard dell'HTML 3.2. Il
        codice sorgente è disponibile sotto la Licenza GNU. Informazioni
        presso <http://www.yggdrasil.com/Products/Arena/>.  Può essere
        scaricato da <ftp://ftp.yggdrasil.com/pub/dist/web/arena/>.


     AAmmaayyaa
        Amaya è il browser per X-Windows del W3C per HTML 3.2, di cui
        supporta tutti gli standard, nonché alcuni standard dell'HTML
        4.0. Sono previsti tabelle, form, mappe client side, put
        publishing nonché i formati grafici GIF, JPEG e PNG. Si tratta
        sia di un browser che di uno strumento di authoring, giunto
        adesso alla versione 1.0 beta per il pubblico mentre la 1.1 beta
        per il test e lo sviluppo interno sarà rilasciata al più presto.
        Per informazioni, visitate il sito di Amaya a
        <http://www.w3.org/Amaya/>.  Può essere scaricato presso
        <ftp://ftp.w3.org/pub/Amaya-LINUX-ELF-1.0b.tar.gz>.


     RReedd BBaarroonn
        Red Baron è un browser per X-Windows prodotto dalla Red Hat.  È
        distribuito insieme alla distribuzione di Linux della Red Hat:
        non dispongo di molte informazioni, ma so che supporta i frame,
        i form e i SSL.  Se usate Red Baron, per piacere aiutatemi a
        completare questa sezione.  Per maggiori informazioni, visitate
        il sito Red Hat presso <http://www.redhat.com>


     CChhiimmeerraa
        Chimera è un browser X-Windows basilare: l'ultima versione, la
        2.0 alfa 6, è stata rilasciata il 27 agosto del 1997 e supporta
        alcune caratteristiche dell'HTML 3.2. Per informazioni
        <http://www.unlv.edu/chimera/>.  Chimera può essere scaricato
        presso <ftp://ftp.cs.unlv.edu/pub/chimera-
        alpha/chimera-2.0a6.tar.gz>.


     QQwweebb
        Qweb è un altro browser X-Windows molto semplice. Supporta
        tabelle, form nonché mappe server side. L'ultima versione è la
        1.3.  Per informazioni: <http://sunsite.auc.dk/qweb/> Il codice
        sorgente è disponibile presso
        <http://sunsite.auc.dk/qweb/qweb-1.3.tar.gz> I file binari,
        disponibili come RPM Red Hat, possono essere scaricati da
        <http://sunsite.auc.dk/qweb/qweb-1.3-1.i386.rpm>
     GGrraaiill
        Grail è un browser X-Windows sviluppato dalla Corporation for
        National Research Initiatives (CNRI). È scritto interamente in
        Python, un linguaggio ad oggetti interpretato. L'ultima versione
        è la 0.3 rilasciata il 7 maggio 1997: supporta form, bookmark,
        hystory, frame, tabelle e altre funzionalità previste dall'HTML
        3.2.


     IInntteerrnneett EExxpplloorreerr
        Ci sono voci che annuncerebbero la Microsoft in procinto di
        portare Internet Explorer su svariate piattaforme Unix - tra cui
        forse Linux. Se è vero, ci stanno mettendo un sacco di tempo: se
        avete informazioni attendibili, fatevi vivi con un e-mail.

  Secondo me, la maggior parte del software menzionato è praticamente
  inutilizzabile per una navigazione approfondita sul Web. Non è mia
  intenzione criticare gli autori - so che hanno lavorato molto
  seriamente sui loro progetti: il punto è che se tutte queste persone
  avessero lavorato su un unico prodotto, probabilmente sarebbe venuto
  fuori un browser gratuito che avrebbe potuto competere con Netscape o
  Internet Exlorer.

  A mio parere, fra tutti i browser citati Netscape e Lynx sono i
  migliori.  A seguire Kfm, Emacs-W3 e Mosaic.



  33..  LLyynnxx

  Lynx è uno dei più piccoli (l'eseguibile è di 600 K) e più veloci
  browser disponibili. Non necessita di molta banda né di grandi risorse
  hardware dal momento che lavora solo in modalità testo. Può funzionare
  su qualunque console, terminale o xterm. Non necessita di un sistema _X
  _W_i_n_d_o_w_s né di memoria addizionale.


  33..11..  DDoovvee ttrroovvaarrlloo

  Sia la distribuzione Red Hat che la Slackware contengono Lynx.
  Pertanto non vi starò ad annoiare con i dettagli per compilare ed
  installare Lynx.

  La versione più recente è la 2.7.1 e puo essere scaricata da
  <http://www.slcc.edu/lynx/fote/> o da quasi tutti i server FTP per
  Linux, come ad esempio ftp://sunsite.unc.edu under
  /pub/Linux/apps/www/broswers/ o i siti mirror.

  Per maggiori informazioni su Lynx contattare:

     LLyynnxx LLiinnkkss
        <http://www.crl.com/~subir/lynx.html>

     LLyynnxx PPaaggeess
        <http://lynx.browser.org>

     LLyynnxx HHeellpp PPaaggeess
        <http://www.crl.com/~subir/lynx/lynx_help/lynx_help_main.html>
        (questa è la pagina che si ottiene lanciando lynx --help o
        premendo ? in Lynx)

  Nota: le pagine di help per Lynx sono state spostate di recente. Se
  avete una vecchia versione, dovrete cambiare lunx.cfg (in /usr/lib) e
  farlo puntare al nuovo indirizzo sopra menzionato.
  Penso che la funzione più interessante di Lynx - nei confronti degli
  altri browser -  sia la possibilità di scaricare in batch. È possibile
  scrivere uno script shell che scarica un documento, un file o
  qualunque altra cosa attraverso _h_t_t_p, _F_T_P, _g_o_p_h_e_r, _W_A_I_S, _N_N_T_P o
  _f_i_l_e_:_/_/ e lo salva su disco.  Inoltre, è possibile riempire
  questionari e form in modalità batch semplicemente ridirigendo lo
  standard input e utilizzando l'opzione _-_p_o_s_t___d_a_t_a.

  Per ulteriori funzioni speciali di Lynx, date un'occhiata ai file di
  help e alle pagine di manuale. Se utilizzate una caratteristica di
  Lynx che vorreste vedere aggiunta in questo documento, fatemelo
  sapere.



  44..  EEmmaaccss--WW33

  Ci sono diversi "gusti" di Emacs. I due più diffusi sono GNU Emacs e
  XEmacs.  Gnu Emacs è ditribuito dalla Free Software Foundation ed è
  quello originale.  È rivolto principalmente verso terminali testo, ma
  funziona anche sotto X-Windows. XEmacs (che una volta si chiamava
  Lucid Emacs) è una versione che gira solo sotto X-Windows sfruttandone
  molto le caratteristiche (menu migliori, ecc.)


  44..11..  DDoovvee ttrroovvaarrlloo


  Sia la distribuzione Red Hat che la Slackware includono GNU Emacs.

  La versione più recente è la 19.34. Non sembra esistere un sito web,
  mentre il sito FTP è <ftp://ftp.gnu.ai.mit.edu/pub/gnu/>.

  L'ultima versione di XEmacs è la 20.2. Il sito FTP è a
  <ftp://ftp.xemacs.org/pub/xemacs>.  Per maggiori informazioni si
  XEmacs, visitate <http://www.xemacs.org>.

  Entrambi sono comunque disponibili dall'archivio Linux presso
  ftp://sunsite.unc.edu under /pub/Linux/apps/editors/emacs/

  Se avete GNU Emacs o XEmacs, probabilmente avete anche il browser W3.

  Il modo W3 è un browser quasi completo scritto in Emacs Lisp.
  Principalmente tratta le informazioni in maniera testuale, ma può
  anche visualizzare immagini se utilizzato sotto X-Windows.

  Per far funzionare XEmacs in modalità W3, bisogna andare nel menu
  'apps' e selezionare 'browse the web'.

  Io non uso Emacs, perciò se qualcuno vuole spiegare come entrare nel
  modo W3 lo aggiungerò a questo documento. La maggior parte di queste
  informazioni provengono dall'autore originale: se qualcuna è
  sbagliata, fatemelo sapere.  Fatemi anche sapere se pensate che sia
  necessario aggiungere qualche altra informazione su Emacs.



  55..  NNeettssccaappee NNaavviiggaattoorr//CCoommmmuunniiccaattoorr


  55..11..  DDiiffffeerreennttii vveerrssiioonnii ee ooppzziioonnii..

  Netscape Navigator è il re dei browser WWW. Può fare quasi tutto:
  d'altro canto, però, è uno dei programmi più affamati di memoria e
  risorse che io abbia mai visto.

  Ci sono tre diverse versioni del programma:

  Netscape Navigator include il browser, Netcaster (un client push) e un
  semplice programma di posta.

  Netscape Communicator include il browser, l'editor, un programma di
  posta avanzato, un lettore di news, Netcaster e un'utility per le
  conferenze di gruppo.

  Netscape Communicator Pro include tutto ciò contenuto nella suite del
  Communicator, più un calendario di gruppo, emulazione di terminale IBM
  e la possibilità di amministrazione remota (gli amministratori possono
  aggiornare migliaia di copie di Netscape senza lasciare la proprio
  scrivania).

  Oltre alle tre versioni, ci sono altre due opzioni da scegliere.

  La prima è fra installazione completa o di base. La completa include
  tutto, mentre quella di base comprende abbastanza per cominciare a
  navigare. È possibile scaricare i componenti addizionali quando si
  vuole (ad esempio supporto multimediale e Netcaster). Questi
  componenti possono essere installati attraverso l'utility di Netscape
  "Smart Update" (dopo l'installazione, andare in help->software
  updates). Al momento non è però disponibile la versione completa per
  Linux.

  La seconda opzione è fra la versione per l'interno o per
  l'esportazione.  Se vivete in Canada o negli Stati Uniti dovete
  scegliere la prima, che offre la più forte crittografazione a 128 bit
  per le transazioni sicure (SSL). La versione per l'esportazione è
  invece solo a 40 bit ed è l'unica ad essere autorizzata al di fuori di
  Canada e USA.

  L'ultima versione di Netscape Navigator/Communicator/Communicator Pro
  è la 4.03. Ci sono due differenti versioni per Linux: uno per i vecchi
  kernel delle serie 1.2 e uno per i nuovi kernel 2.0. Se non avete
  ancora un kernel di questa serie, vi consiglio vivamente un upgrade:
  ci sono infatti molti miglioramenti.

  Sono inoltre disponibili delle versioni beta, ma di solito durano solo
  un mese o giù di lì.


  55..22..  DDoovvee ttrroovvaarrlloo


  Il miglior modo per ottenere il software Netscape è quello di
  scaricarlo dal loro sito web a  <http://www.netscape.com/download/>.
  Ci sono dei menu che guidano alla scelta: la domanda sulla versione di
  Linux si riferisce al kernel (la maggior parte delle persone dovrebbe
  avere il 2.0). Se non si è sicuri della versione del proprio kernel,
  basta lanciare il comando 'cat /proc/version'. La versione per
  l'interno è disponibile solo attraverso il sito web.

  Se invece volete la versione per l'esportazione, potete scaricarla
  direttamente dai server FTP della Netscape, che tra l'altro sono anche
  più aggiornati. Per esempio, quando ho scritto questo documento
  l'interfaccia web non aveva ancora la versione 4.03 non-beta per
  Linux, mentre il sito FTP sì. Ecco i link alle versioni esportabili
  per Linux:

  Netscape Navigator 4.03 è a
  <ftp://ftp.netscape.com/pub/communicator/4.03/shipping/english/unix/linux20/navigator_standalone/navigator-
  v403-export.x86-unknown-linux2.0.tar.gz>
  Netscape Communicator 4.03 per Linux 2.0 (kernel) è a
  <ftp://ftp.netscape.com/pub/communicator/4.03/shipping/english/unix/linux20/base_install/communicator-
  v403-export.x86-unknown-linux2.0.tar.gz>

  Communicator Pro 4.03 per Linux non era ancora disponibile quando ho
  scritto questo documento.

  Queste URL cambieranno quando usciranno nuove versioni: se i link non
  funzionano, potete trovare quelli giusti spulciando il sito FTP
  <ftp://ftp.netscape.com/pub/communicator/>.

  Questi server sono a volte molto trafficati: è dunque preferibile
  aspettare le ore morte o scegliere un sito mirror. Comunque,
  preparatevi ad una lunga attesa dal momento che questi archivi sono
  grossi: Navigator è quasi 8 mega, mentre la versione base di
  Communicator 10.


  55..33..  IInnssttaallllaazziioonnee

  Questa sezione spiega come installare la versione quattro di Netscape
  Navigator, Communicator e Communicator Pro.

  Per prima cosa, scompattate l'archivio in una directory temporanea.
  Poi, eseguite lo script ns-install (digitate ./ns-install).  In
  seguito, create un link simbolico dal file
  /usr/local/netscape/netscape a /usr/local/bin/netscape (digitate ln -s
  /usr/local/netscape/netscape /usr/local/bin/netscape).  Infine,
  impostate la variabile d'ambiente $MOZILLA_HOME a /usr/local/netscape,
  di modo che Netscape possa trovare i propri file. Se utilizzate bash
  come shell, modificate /etc/profile aggiungendo le linee:



       MOZILLA_HOME="/usr/local/netscape"
       export MOZILLA_HOME



  Dopo aver installato il software, esso si aggiornerà automaticamente
  con la "Smart Update". Basta lanciare Netscape come utente root e
  andare in help->software updates. È da qui, inoltre, che si installano
  gli altri componenti nel caso in cui abbiate la versione base.

  Nota: lo "Smart Update" non rimuove le vecchie versione di Netscape,
  che vanno eliminate manualmente cancellando il file binario di
  Netscape e il file delle classi Java (per la versione 3).



  66..  IInnssttaallllaarree ddeeii sseerrvveerr WWWWWW

  Questa sezione contiene informazioni sui differenti server http e su
  strumenti addizionali quali linguaggi di scripting per programmazione
  CGI ecc. Esistono sul mercato dozzine di server web, ed io ho
  analizzato solo quelli pienamente funzionanti: dal momento che alcuni
  sono prodotti commerciali, non ho la possibilità di provarli. Una
  buona parte delle informazioni è stata trovata su svariati siti web e
  pertanto, in caso incontraste delle imperfezioni, fatemelo sapere.

  Per una descrizione tecnica del meccanismo http, date un'occhiata agli
  RFC menzionati nel capitolo "Approfondimenti" di questo HOWTO.


  Personalmente preferisco utilizzare il server Apache. Ha quasi tutte
  le caratteristiche di cui uno ha bisogno, e in più è gratis. Devo
  ammettere che questa sezione è sbilanciata nei confronti di Apache, ma
  è stata una mia scelta quella di concentrare i miei sforzi su questo
  server piuttosto che disperderli su tutti quanti. È probabile che mi
  occupi più approfonditamente degli altri in futuro.



  66..11..  PPaannoorraammiiccaa


     CCeerrnn hhttttppdd
        Questo fu il primo web server in assoluto: sviluppato dal Centro
        Europeo di Ricerche Nucleari (CERN), non è comunque più
        supportato.  Sono noti alcuni gravi bug di questo server, nonché
        la sua lentezza e la "fame" di risorse. L'ultima versione è la
        3.0, ma per maggiori informazioni è possibile rivolgersi alla
        home page del server http CERN presso
        <http://www.w3.org/Daemon/Status.html>.  Si può scaricare presso
        <ftp://sunsite.unc.edu/pub/Linux/apps/www/servers/httpd-3.0.term.tpz>
        (non si tratta di un errore di battitura: l'estensione è
        veramente .tpz, ma probabilmente dovrebbe essere .tgz)


     NNCCSSAA HHTTTTPPdd
        Il NCSA HTTPd server è il padre di Apache (lo sviluppo si divise
        in due server differenti): a causa di ciò, i file di setup sono
        molto simili. NCSA HTTPd è gratuito e il suo codice sorgente è
        disponibile per chiunque lo voglia. Non ho analizzato questo
        server nel documento, ma leggere la sezione su Apache può
        sicuramente aiutare. Questo server era molto diffuso, ma adesso
        è sempre più spesso soppiantato da Apache, che lo sostituisce in
        maniera perfetta (ha gli stessi file di configurazione) e ne
        risolve numerosi problemi. (fonte Nov. 1997  Netcraft survey
        <http://www.netcraft.com/survey/>).  La versione piu recente è
        la 1.5.2a. Per maggiori informazioni, rivolgersi a
        <http://hoohoo.ncsa.uiuc.edu>.


     ````AAppaacchhee''''
        Apache è il re di tutti i web server, e in più è distribuito in
        forma gratuita sia come binario che come codice sorgente. È
        molto modulare ed è pertanto molto semplice aggiungere
        caratteristiche e opzioni fra le tante disponibili: è inoltre
        molto diffuso, tanto che al momento attuale copre ben il 44% di
        tutti i domini web (50% se si contano anche i suoi derivati).
        Ci sono più di 695.000 server Apache in funzione (fonte Novembre
        1997 Netcraft survey <http://www.netcraft.com/survey/>).

        La versione ufficiale di Apache non ha l'SSL, ma ci sono due
        derivati che risolvono il problema.

        Stronghold è un prodotto commerciale basato su Apache che costa
        $995 nella versione base e $495 in quella economica (basata su
        una vecchia versione di Apache).  Stronghold è il secondo server
        sicuro dopo Netscape (fonte C2 net
        <http://www.c2.net/products/stronghold> e Netcraft survey
        <http://www.netcraft.com/survey/>).  Per maggiori informazioni
        visitate il sito di Stronghold a
        <http://www.c2.net/products/stronghold/>. È stato sviluppato
        fuori dagli Stati Uniti e pertanto è disponibile in tutto il
        mondo nella versione a 128 bit.

        Apache-SSL è una implementazione gratuita di SSL ma non per un
        uso commerciale (RSA ha un brevetto americano sulla tecnologia
        SSL). È possibile utilizzarlo per scopi non commerciali negli
        Stati Uniti se ci si collega con la libreria RSAREF (gratuita).
        Per ulteriori informazioni <http://www.algroup.co.uk/Apache-
        SSL/>.


     NNeettssccaappee FFaasstt TTrraacckk SSeerrvveerr
        Fast Track è stato sviluppato da Netscape, ma la versione per
        Linux è distribuita da Caldera, sul cui sito web è possibile
        trovarlo come Fast Track per OpenLinux. Non so se funzioni solo
        su OpenLinux della Caldera o se giri su ogni distribuzione
        (scrivetemi se avete la risposta). I server Netscape contano per
        l'11,5% (percentuale in discesa) fra tutti i web server (fonte
        settembre 1997 <http://www.netcraft.com/survey/>).  Il server
        costa $295, ma è incluso nella distribuzione Caldera di
        OpenLinux, che costa $399 ($199.50 per le scuole).  La pagina
        web descrive una bella interfaccia da amministratore per un
        setup di soli 10 minuti. Il server supporta SSL a 40 bit, mentre
        per quello a 128 c'e bisogno del Netscape Enterprise Server:
        purtroppo, però, questo server non è ancora disponibile per
        Linux :( L'ultima versione di Fast Track è la 2.0 (la versione 3
        è in fase beta, ma non è stata ancora portata su Linux). Per
        comprarne una copia, basta andare sul sito Caldera a
        <http://www.caldera.com/products/netscape/netscape.html> Per
        maggiori informazioni, la pagina di Fast Track è
        <http://www.netscape.com/comprod/server_central/product/fast_track/>


     WWNN WN ha molte caratteristiche che lo rendono interessante. Per
        prima cosa, è più piccolo dei server CERN, NCSA HTTPd e Apache.
        Ha inoltre molte funzionalità senza le quali ci sarebbe bisogno
        di programmazione CGI, quali ad esempio ricerca sul sito,
        includes avanzati dal lato del server: offre inoltre la
        possibilità di scaricare solo una parte di file con la sua
        opzione "ranges". È rilasciato sotto la Licenza Pubblica GNU.
        Le versione corrente è la 1.18.3: per maggiori informazioni
        rivolgersi a <http://hopf.math.nwu.edu/>.


     AAOOLLsseerrvveerr
        AOLserver è prodotto da America On Line. Devo ammettere di
        essere rimasto sorpreso dalle potenzialità di un server web
        scritto da AOL. Oltre alle caratteristiche standard, è
        supportata infatti la connettività ai database: le pagine
        possono interrogare un database attraverso dei comandi SQL, e il
        database è accessibile attraverso la Open Database Connectivity
        (OBCD). Il server ha inoltre un motore di ricerca incorporato
        nonché il supporto per gli script TCL: se ciò non fosse
        abbastanza, è possibile aggiungere i propri moduli attraverso le
        API per il C. Quasi dimenticavo il supporto per le SSL a 40 bit:
        e tutto questo è gratuito!.  Per maggiori informazioni, visitate
        il sito di AOLserver presso <http://www.aolserver.com/server/>


     ZZeeuuss SSeerrvveerr
        Zeus Server è stato sviluppatod da Zeus Technology.  Affermano
        di aver prodotto il server più veloce, almeno stando ai
        risultati del benchmark WebSpec96. È possibile inoltre
        controllare e configurare l'applicazione da qualsiasi browser,
        nonché limitare l'utilizzo del processore o della memoria da
        parte dei programmi CGI ed eseguirli in un contesto sicuro
        (qualunque cosa questo voglia dire...). Supporta infine un
        numero illimitato di server virtuali. Il prezzo per la versione
        standard è di $999, che diventano $1699 se si vuole l'SSL: la
        società comunque ha sede fuori dagli Stati Uniti e dunque la
        versione a 128 bit è disponibile in ogni parte del mondo. Per
        informazioni, visitate <http://www.zeus.co.uk>.  Il sito
        americano è a <http://www.zeus.com>.  Vi devo avvisare che, pur
        essendo molto convinti delle loro prestazioni in termini di
        velocità, non sono elencati fra i primi dieci server nei
        Netcraft Surveys.


     CCLL--HHTTTTPP
        CL-HTTP significa Common Lisp Hypermedia Server. Se siete dei
        programmatori in Lisp, questo è il server che fa per voi, visto
        che potete scrivere i vostri CGI in questo linguaggio. Questo
        server funziona con un setup dal web e supporta tutte le
        funzionalità standard di un server.  CL-HTTP è gratuito e i
        sorgenti sono distribuiti pubblicamente. Il sito web è
        <http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html>
        (non si poteva fare un url un pò più lunga?)

  Se avete degli scopi commerciali (sito web aziendale, ISP) vi
  raccomando fortemente Apache. Se invece avete bisogno di un setup
  facile facile a discapito delle funzionalità più avanzate, allora Zeus
  Server fa per voi: ho anche sentito dire che è facile configurare il
  server Netscape. Se le vostre esigenze sono per un uso prettamente
  "interno", allora potete godere di maggiore flessibilità. Comunque, a
  meno che voi siate alla ricerca di qualche cosa di specifico, vi
  suggerisco ancora di utilizzare uno dei tre che ho menzionato.

  Questa è solo una lista parziale di tutti i server disponibili. Per un
  elenco più completo, visitate il sito Netcraft presso
  <http://www.netcraft.com/survey/servers.html> o Web Compare a
  <http://webcompare.internet.com>.



  77..  AAppaacchhee

  La versione corrente di Apache è la 1.2.4. La versione 1.3 è in fase
  beta.  Il sito principale di Apache è a  <http://www.apache.org/>.
  Un'altra buona fonte di informazioni è Apacheweek a
  <http://www.apacheweek.com/>.  La documentazione Apache è abbastanza
  buona, perciò non mi addentrerò nei dettagli della configurazione: i
  doc sono infatti sia sul sito web che inclusi con i sorgenti (in
  formato HTML: ci sono anche dei file di testo ma quelli in HTML sono
  meglio). Inoltre, la documentazione dovrebbe migliorare appena prende
  il via l'Apache Documentation Project. Fino ad oggi gran parte dei
  manuali sono scritti dagli sviluppatori: non per criticarli, ma
  obiettivamente i loro testi sono un pò difficili da capire se non si
  padroneggia la terminologia.


  77..11..  DDoovvee ttrroovvaarrlloo

  Apache è incluso nelle distribuzioni Red Hat, Slackware e OpenLinux:
  sebbene non siano magari le ultime versioni, sono comunque degli
  eseguibili molto affidabili. L'aspetto negativo, però, è che non si
  può cambiare la configurazione delle directory (che è totalmente
  diversa fra l'una e l'altra distribuzione nonché rispetto ai default
  Apache).

  I codici sono disponibili presso il sito web Apache
  <http://www.apache.org/dist/>.  I file binari si trovano nello stesso
  posto. È inoltre possibile scaricarli da SunSite a
  <ftp://sunsite.unc.edu/pub/Linux/apps/www/servers/>.  Per chi ha Red
  Hat, l'RPM con i più recenti eseguibili è di solito nella directory
  contrib a <ftp://ftp.redhat.com/pub/contrib/i386/>.

  Se il server sarà utilizzato per scopi commerciali, è molto meglio se
  vi scaricate i sorgenti dal sito Apache e lo compilate voi stessi.
  L'altra possibilità consiste nell'utilizzare gli eseguibili che
  vengono distribuiti con Slackware, Red Hat o OpenLinux, ma questi
  possono causare dei problemi di sicurezza: un eseguibile sconosciuto
  può avere delle backdoor per gli hacker, oppure una patch instabile
  potrebbe causare danni al sistema. Inoltre, scaricare i sorgenti vi dà
  più controllo sui moduli da compilare e sulle directory di default.
  Non è poì così difficile compilare Apache, e comunque sia non vi
  potete dire dei veri utilizzatori di Linux finché non compilerete da
  soli i vostri programmi ;)



  77..22..  CCoommppiillaazziioonnee ee iinnssttaallllaazziioonnee

  Per prima cosa bisogna fare un untar dell'archivio in una directory
  temporanea.  Poi, spostatevi nella directory src. Editate il file di
  configurazione per includere eventuali moduli speciali (la maggior
  parte dei più comuni è comunque già inclusa). Non c'è alcun bisogno di
  modificare le regole o i parametri del makefile per Linux. Eseguite
  poi lo script di configurazione (./Configure). Assicuratevi che dica
  "Linux platform" e che sia settato gcc come compilatore. È possibile
  editare adesso il file httpd.h per cambiare le directory di default.
  La directory home del server - dove vengono cioè mantenuti i file di
  configurazione -  è settata (se non altrimenti specificato) a
  /usr/local/etc/httpd/, ma potreste volerla cambiare in un più semplice
  /etc/httpd/.  La root del server (dove cioè vengono conservate le
  pagine HTML) è per default /usr/local/etc/httpd/htdocs/, ma io
  preferisco la directory /home/httpd/html (che tra l'altro è il default
  di Red Hat).  Se avete intenzione di utilizzare su-exec (cfr. sotto,
  funzioni speciali) potrebbe essere utile cambiare anche quella
  directory. La root del server può essere cambiata anche nei file di
  configurazione, ma è una buona idea compilarcelo dentro nell'evenienza
  in cui Apache non sia in grado di trovare o leggere il file di
  configurazione: tutto il resto dovrebbe essere modificato nei file di
  config. Infine, lanciate make per compilare Apache.

  Se avete problemi relativi alla mancanza di file include, assicuratevi
  delle seguenti cose: controllate di avere gli header del kernel (i
  file di include) installati per la vostra versione del kernel;
  assicuratevi inoltre di avere settati i seguenti link simbolici:


       /usr/include/linux link a /usr/src/linux/include/linux
       /usr/include/asm link a /usr/src/linux/include/asm
       /usr/src/linux link alla directory del sorgenti di Linux (es. linux-2.0.30)



  I links possono essere creati con ln -s, comando che funziona come cp
  con l'unica differenza che crea un link simbolico (ln -s directory-
  sorgente link-di-destinazione).

  Quando make ha finito, ci dovrebbe essere un eseguibile chiamato http
  nella directory. Questo file deve essere spostato in una directory
  binaria: /usr/sbin o /usr/local/sbin potrebbero essere delle buone
  scelte.

  Copiate poi le sub-directory di configurazione, di log e delle icone
  dai sorgenti alla directory home del server. Poi, bisogna rinominare 3
  file nella sub-directory conf per liberarsi dell'estensione -dist (es
  httpd.conf-dist diventa httpd.conf).
  Ci sono inoltre molti programmi di supporto inclusi con Apache. Si
  trovano nella directory support e devono essere copiati e installati
  separatamente. La maggior parte può essere creata usando il makefile
  in quella directory (che viene creato quando si lancia lo script
  principale Configure). Nessuno di questi programmi è indispensabile
  per usare Apache, ma alcuni facilitano il compito dell'amministratore.


  77..33..  CCoonnffiigguurraazziioonnee

  Adesso dovreste avere quattro file nella sub-directory conf (sotto la
  directory home del server).  httpd.conf configura il demone del server
  (numero di porta, utente, ecc.). Il srm.conf imposta la struttura di
  base dei documenti, gli handler speciali, ecc. Il access.conf si
  occupa invece della configurazione di base per l'accesso.  Infine
  mime.types comunica al server quale tipo MIME inviare al browser a
  seconda delle diverse estensioni.

  I file di configurazione hanno comunque una documentazione interna
  molto buona (sono pieni di commenti), sempre che si capisca il gergo.
  È consigliabile leggerli tutti almeno una volta prima di mettere su il
  server.  Ogni argomento sulla configurazione è coperto esaurientemente
  anche nella documentazione di Apache.

  Il file mime.types non è esattamente un file di configurazione. È
  infatti utilizzato dal server per tradurre le estensioni dei file in
  tipi MIME da inviare al browser e contiene già la maggior parte dei
  più comuni tipi di file cosicché poche persone hanno bisogno di
  modificarlo. Inoltre, col passare del tempo sempre nuovi tipi MIME
  saranno aggiunti e dunque la cosa migliore è scaricarsi un nuovo file
  (e magari anche una nuova versione del server).

  Ricordatevi sempre, quando cambiate i file di configurazione, di
  riavviare Apache o di inviargli il segnale SIGHUP con kill per fare in
  modo che le modifiche abbiano effetto. Assicuratevi comunque di
  mandare il segnale al processo padre e non ai figli: il padre ha di
  solito l'indicatore di processo più basso, ricavabile anche dal file
  httpd.pid nella directory di log. Se accidentalmente vi capita di
  inviare il segnale ad un processo figlio, questo verrà terminato e il
  processo padre lo riavvierà automaticamente.

  Non percorrerò qui tutti i passaggi nella configurazione di Apache: ho
  deciso invece di occuparmi di argomenti specifici, scelte da compiere
  e peculiarità del server.

  Raccomando comunque a tutti gli utenti di leggere i suggerimenti sulla
  sicurezza nella documentazione Apache, disponibile anche sul sito
  Apache a <http://www.apache.org/docs/mics/security_tips.html>.


  77..44..  OOssppiittaarree ssiittii wweebb vviirrttuuaallii

  Il Virtual Hosting si ha quando un solo computer ha più di un dominio.
  Il vecchio metodo consisteva nell'assegnare ad ogni host virtuale un
  differente indirizzo IP: col nuovo metodo, invece, si usa un solo
  indirizzo IP ma bisogna utilizzare un browser che supporti l'HTTP 1.1.

  Il mio suggerimento per le applicazioni commerciali è di utilizzare
  ancora il vecchio metodo (più indirizzi IP) finché la maggior parte
  delle persone disporranno di un browser compatibile con lo standard
  HTTP 1.1 (basta aspettare un annetto o due): in questo modo, inoltre,
  si avrà una più completa illusione di virtual hosting. Non bisogna
  dimenticare poi che, mentre tutti e due i metodi consentono la posta
  virtuale (qualcuno me lo può confermare?), solo il virtual hosting
  basato su differenti indirizzi IP consente l'FTP virtuale.

  Se si tratta invece di un server per un club o per una pagina
  personale, è forse meglio considerare l'hosting basato sugli IP
  condivisi: è più economico e si risparmia del prezioso spazio IP.

  È poi possibile realizzare un mix di IP condiviso e non sullo stesso
  server: per informazioni, visitate Apacheweek a
  <http://www.apacheweek.com/features/vhost>.


  77..44..11..  HHoossttiinngg bbaassaattoo ssuuggllii IIPP vviirrttuuaallii

  Con questo metodo ogni host virtuale ha il suo indirizzo IP:
  determinando l'indirizzo a cui è stata inviata la richiesta, Apache e
  gli altri programmi possono decidere quale dominio servire. Questo è
  comunque uno spreco incredibile di spazio. Prendete per esempio il
  server su cui si trova il mio dominio virtuale: ci sono circa 35.000
  account, e cioè 35.000 indirizzi.  Eppure, è probabile che i server
  effettivamente funzionanti non siano nemmeno una cinquantina.

  Per installare e far funzionare questo metodo si procede in due fasi
  distinte: prima si dice a Linux di accedere a più di un indirizzo IP e
  poi si setta Apache per servire gli host virtuali.

  Il primo passo per configurare Linux a supportare più indirizzi IP è
  ricreare il kernel, operazione che funziona meglio con i kernel della
  serie 2.0 (o più recenti): è necessario includere il networking IP
  nonché il supporto dell'aliasing IP. Per informazioni sulla
  compilazione del kernel, date un'occhiata al Kernel HowTo
  <http://sunsite.unc.edu/LDP/HOWTO/Kernel-HOWTO.html>.

  La fase successiva è la configurazione di ogni interfaccia al boot: se
  state usando la distribuzione Red Hat potete farlo dal Control Panel
  avviando X-Windows come utente di root, cliccando sulla configurazione
  della rete nel pannello di controllo e specificando nella scheda delle
  interfacce la propria scheda di rete. È poi necessario cliccare su
  Alias (dovrebbe trovarsi al fondo dello schermo) e completare le
  informazioni: bisogna compiere queste informazioni per ogni host
  virtuale/indirizzo IP.

  Se utilizzate invece delle altre distribuzioni, è probabile che
  dobbiate farlo a mano. Potete semplicemente mettere i comandi nel file
  rc.local che si trova in /etc/rc.d (in realtà dovrebbe essere tutto
  nelle cose collegate alla rete). Dovreste avere un comando ifconfig e
  route per ogni dispositivo. Viene così assegnato un sub-dispositivo ad
  ogni indirizzo alias: per esempio eth0 avrebbe gli alias eth0:0,
  eth0:1 ecc. Ecco un esempio di tutta la faccenda:


       ifconfig eth0:0 192.168.1.57
       route add -host 192.168.1.57 dev eth0:0



  È anche possibile aggiungere un indirizzo broadcast e una netmask al
  comando ifconfig: se avete un sacco di alias, si potrebbe creare un
  ciclo for per facilitare le cose. Leggete comunque l'IP alias mini
  howto <http://sunsite.unc.edu/LDP/HOWTO/mini/IP-Alias.html>.

  In seguito bisogna settare il domain name server (DNS) per coprire
  questi nuovi domini: se poi non avete ancora un dominio, allora vi
  dovete rivolgere alla Internic <http://www.internic.net> per
  registrarlo. Date comunque un'occhiata al DNS-HOWTO per creare il
  vostro DNS.


  Infine, è necessario configurare Apache per fargli gestire
  correttamente i domini virtuali: per far ciò è necessario modificare
  il file httpd.conf verso la fine di cui viene comunque fornito un file
  di esempio. Tutti i comandi specifici per quell'host virtuale sono
  posti fra la tag di direttiva virtualhost, dove è possibile inserire
  quasi tutti i comandi. Di solito si setta una diversa directory radice
  per i documenti, una directory per gli script e per i file di log. Si
  possono aggiungere infiniti host virtuali semplicemente aggiungendo
  più tag virtualhost.

  In rari casi potreste aver bisogno di lanciare server separati per
  specifici host: questo è necessario quando una direttiva è necessaria
  per un host virtuale ma non è fra quelle ammesse fra le tag per
  l'hosting virtuale.  In questo caso si deve utilizzare la direttiva
  bindaddress: ogni server avrà un nome e dei file di configurazione
  diversi, ed ogni server risponderà ad un indirizzo IP, specificato
  dalla direttiva bindaddress. Questo è comunque un incredibile spreco
  di risorse.


  77..44..22..  HHoossttiinngg bbaassaattoo ssuuggllii iinnddiirriizzzzii IIPP ccoonnddiivviissii

  Si tratta di un nuovo metodo per l'hosting virtuale: viene utilizzato
  un solo indirizzo IP, riservandolo solo alle macchine reali (non a
  quelle virtuali). Nell'esempio precedente, dei 35.000 host virtuali
  solo 50 avrebbero un indirizzo IP (uno per ogni macchina).  Tutto ciò
  è possibile sfruttando le caratteristiche dell'HTTP 1.1: è il browser
  che dice al server quale sito vuole. I problemi sorgono con quei
  browser che non supportano l'HTTP 1.1, perché questi leggeranno la
  pagina principale del server, che può comunque offrire una lista dei
  server virtuali a disposizione. Certo, questo rovina un po' l'intera
  illusione del hosting virtuale, e cioè quella di avere un proprio
  server.

  Il settaggio è molto più semplice che nell'hosting basato sui diversi
  indirizzi IP. È sempre necessario avere un proprio dominio dalla
  Internic nonché configurare il proprio DNS, e Apache è settato nella
  stessa maniera di prima. Dal momento però che si usa sempre lo stesso
  indirizzo IP nella tag virtualhost, il server si accorge
  automaticamente che si sta utilizzando l'hosting virtuale basato
  sull'IP condiviso.

  Ci sono molte soluzioni per i vecchi browser, e io adesso spiegherò
  quella che secondo me è la migliore. Per prima cosa è necessario
  trasformare la pagina principale in host virtuale (condiviso o no): in
  questo modo si libera la main page così da poterla utilizzare per una
  lista di link a tutti i virtual host presenti. Poi bisogna creare una
  backdoor per i vecchi browser utilizzando la direttiva ServerPath per
  ogni host virtuale all'interno della direttiva virtualhost. Per
  esempio, aggiungendo ServerPath /mysite/ a www.mysite.com i vecchi
  browser saranno in grado di accedere al sito attraverso
  www.mysite.com/mysite/. Infine si mette la pagina di default sul sito
  principale che dica gentilmente di scaricarsi un nuovo browser e che
  punti a tutte le backdoor per i siti ospitati sul server: quando un
  vecchio browser accede al sito, saranno automaticamente inviati alla
  pagina principale e riceveranno un menu con tutti i link disponibili.
  I nuovi browser, invece, non vedranno mai la pagina principale e
  andranno direttamente agli host virtuali. Bisogna ricordare però che
  si devono mantenere i link relativi al proprio sito web dal momento
  che le pagine saranno accessibili da due URL differenti
  (www.mysite.com e www.mysite.com/mysite/).

  Spero di non avervi confuso troppo, ma non è comunque una soluzione
  facile.  Magari potreste considerare l'hosting virtuale basato sugli
  indirizzi IP.  Comunque un trucchetto molto simile è spiegato sul sito
  Apache a <http://www.apache.org/manual/host.html>.
  Se mai qualcuno avesse una interessante fonte di informazioni per
  l'hosting basato sugli IP condivisi, mi farbbe piacere saperlo.
  Sarebbe anche simpatico sapere quanti e quali browser supportano
  l'HTTP 1.1.


  77..55..  SSccrriipptt CCGGII

  Ci sono due metodi diversi per consentire ai propri utenti di
  utilizzare script CGI: la prima è di considerare tutto ciò che finisce
  con .cgi uno script CGI, la seconda è quella di creare una directory
  per gli script (generalmente cgi-bin). Si possono anche utilizzare
  entrambi i metodi: in tutti e due i casi, comunque, gli script devono
  poter essere eseguiti da tutti (chmod 711). Nel concedere accesso agli
  script si apre una grande falla nella sicurezza: state bene attenti,
  drizzate le orecchie e cercate di minimizzare i rischi.

  Personalmente preferisco il primo metodo, specialmente quando gli
  script sono complessi: questo metodo consente infatti di mettere gli
  script in ogni directory, e a me piace metterli dove risiedono anche
  le pagine web che li utilizzano. Per i siti con un sacco di script, è
  molto più elegante che avere una directory piena zeppa di script.
  Questo metodo è poi molto facile da settare: per prima cosa, bisogna
  togliere il commento all'handler .cgi alla fine del file srm.conf.
  Assicuratevi poi che tutte le vostre directory abbiano l'opzione
  option ExecCGI oppure All nel file access.conf, e il gioco è fatto.

  Creare una directory apposita per gli script è però considerato più
  sicuro. Per farlo bisogna utilizzare la direttiva ScriptAlias nel file
  srm.conf, in cui il primo argomento è l'Alias ed il secondo la
  directory che sarà utilizzata quando qualcuno chiederà della directory
  /cgi-bin/: per esempio ScriptAlias /cgi-bin/ /usr/httpd/cgi-bin/
  abilita la directory /usr/httpd/cgi-bin ad eseguire degli script.  Per
  motivi di sicurezza sarebbe poi meglio cambiare anche le proprietà
  delle directory togliendo i commenti alle linee Options none,
  AllowOveride none nel file access.conf fornito come esempio. Inoltre,
  non bisogna creare le directory per gli script come sub-directory
  delle cartelle che contengono la pagina web: per esempio, se la
  directory con le pagine è /home/httpd/html/, non mettete gli script in
  /home/httpd/html/cgi-bin, bensì in /home/httpd/cgi-bin.

  Se volete consentire ai vostri utenti di avere le loro directory di
  script, potete usare più comandi ScriptAlias, che dovrebbero essere
  all'interno della direttiva virtualhost per ogni host virtuale. Se c'è
  qualcuno che conosce un metodo più semplice per permettere a tutti gli
  utenti di avere una propria directory di script senza ricorrere ogni
  volta al comando ScriptAlias me lo faccia sapere.



  77..66..  DDiirreeccttoorryy WWeebb ddeeggllii UUtteennttii

  Ci sono due metodi diversi per trattare le directory web degli utenti.
  Si può avere una sub-directory nella directory degli utenti (che di
  solito è public_html), oppure una directory specifica per le directory
  web.  Con entrambi i metodi bisogna assicurarsi comunque che queste
  directory siano settate in lettura e scrittura nel file access.conf.

  Il primo metodo è quello di default di Apache: quando arriva una
  richiesta per /~bob/, il server va a cercare la directory public_html
  nella cartella di bob. È possibile cambiare la directory con la
  direttiva UserDir nel file srm.conf: è comunque necessaria settarla in
  lettura ed esecuzione per tutti. Come si può vedere, questo metodo
  crea un potenziale rischio di sicurezza perché Apache può accedere
  alla directory solo se la directory home degli utenti è eseguibile per
  tutti.
  Il secondo metodo è molto facile da settare: bisogna cambiare la
  direttiva UserDir nel file srm.conf. Questa direttiva può assumere
  svariati formati e quindi è una buona idea dare un'occhiata alla
  documentazione Apache per chiarimenti.  Comunque, se volete che ogni
  utente abbia la propria directory in /home/httpd/, dovete usare
  UserDir /home/httpd.  In questo caso, quando viene richiesta /~bob/,
  viene tradotta in /home/httpd/bob/. Se poi volete una sub-directory
  nella cartella di bob, allora dovrete usare UserDir
  /home/httpd/*/html: questo infatti porta il server a tradurre in
  /home/httpd/bob/html/ e vi consente anche di avere una directory per
  gli script (ad esempio /home/httpd/bob/cgi-bin/).


  77..77..  DDaaeemmoonn mmooddee vvss.. IInneettdd mmooddee

  Apache può essere eseguito in due modalità: come demone ("daemon")
  sempre in funzione (modalità che Apache chiama 'standalone') oppure
  lanciato dal super server inetd.

  La modalità daemon è di gran lunga migliore rispetto a quella con
  inetd, ed è anche la modalità predefinita. L'unico caso in cui si
  potrebbe voler utilizzare quest'ultimo modo è in presenza di
  applicazioni poco frequenti: il test interno di alcuni script,
  l'Intranet di una piccola azienda.  Il modo Inetd salva infatti
  memoria perché il server è caricato solo quando effettivamente
  richiesto, e solo il demone inetd risiede permanentemente in memoria.

  Se non utilizzate Apache molto spesso, potreste utilizzarlo nella
  modalità daemon e lanciarlo solo quando vi serve, per poi ucciderlo
  una volta finito (assicuratevi di terminare il processo padre, e non
  uno dei figli).

  Per impostare la modalità inetd è necessario modificare un po' di
  file.  Per prima cosa, in /etc/services vedete se http è già presente:
  se non lo è, aggiungetelo:


       http    80/tcp



  Il posto migliore è dopo 79 (finger). Poi dovete modificare il file
  /etc/inetd.conf e aggiungerci le linee per Apache


       http    stream  tcp     nowait  root    /usr/sbin/httpd httpd



  Assicuratevi di cambiare il path se avete Apache in un altro posto: il
  secondo httpd non è un errore, dal momento che il demone inet lo
  richiede. Se non utilizzate questo demone, potreste voler togliere i
  commenti al resto delle linee nel file così da evitare l'attivazione
  di altri servizi (FTP, finger, telnet e molte altre cose che di solito
  funzionano con questo demone).

  Se già avete in esecuzione il demone inet (inetd), allora dovete solo
  inviargli il segnale SIGHUP (con kill; consultate la documentazione su
  kill per informazioni) o riavviare il computer perché le modifiche
  abbiano effetto: se invece non è già in esecuzione, dovete avviare il
  demone manualmente o metterlo nei file di inizializzazione così da
  caricarlo all'avvio (la scelta migliore è il file rc.local).


  77..88..  AAuuttoorriizzzzaarree ii ccoommaannddii ppuutt ee ddeelleettee

  I nuovi strumenti di authoring HTML supportano un nuovo metodo per
  inviare le pagine web al server utilizzando l'http invece dell'FTP:
  alcuni di questi prodotti nemmeno lo supportano più l'FTP. Apache è in
  grado di supportare questo metodo, ma manca lo script per gestire la
  richiesta: tale script, però, potrebbe aprire un serio buco nella
  sicurezza e perciò riflettete bene prima di scriverne o installarne
  uno.

  Se qualcuno è a conoscenza di uno script che funzioni bene me lo dica,
  e lo aggiungerò qui.

  Per informazioni, consultate Apacheweek
  <http://www.apacheweek.com/features/put>.


  77..99..  AAuutteennttiiccaazziioonnee ddeellll''uutteennttee//CCoonnttrroolllloo dd''aacccceessssoo

  Questa è una delle caratteristiche che preferisco: consente infatti di
  proteggere una directory o un file senza dover usare degli script CGI
  nonché consentire o negare l'accesso in base all'indirizzo IP o al
  dominio del client. Si tratta di un grande servizio per tenere lontani
  rompiscatole dalla message board o dal guest book (si ricava il loro
  indirizzo IP o il dominio dai file di log).

  Per attivare l'autenticazione dell'utente la directory deve avere
  AllowOverrides AuthConfig settato nel file access.conf.  Per
  consentire poi il controllo d'accesso (tramite dominio o indirizzo IP)
  bisogna poi impostare nella directory anche AllowOverrides Limit.

  Per configurare la directory è necessario mettervi un file .htaccess
  Per l'autenticazione dell'utente si usa invece di solito un file
  .htpasswd oppure .htgroup: questi file possono essere condivisi tra
  vari file .htaccess.

  Per ragioni di sicurezza raccomando vivamente a tutti di utilizzare le
  seguenti direttive nel file access.conf:



       <files ~ "/\.ht">
       order deny,allow
       deny from all
       </files>



  Se non siete ammnistratori del sistema, potete anche mettere nel
  vostro file .htaccess se AllowOverride Limit è impostato per la vostra
  directory. Questa direttiva impedirà agli altri di andare a curiosare
  dentro i vostri file per il controllo dell'accesso (.htaccess,
  .htpasswd, etc).

  Ci sono svariate opzioni e tipi di file che possono essere utilizzati
  col controllo dell'accesso: non è quindi negli scopi di questo
  documento descriverli. Per informazioni su come impostare la User
  Authentication date un'occhiata ad Apacheweek a
  <http://www.apacheweek.com/features/userauth> o le pagine NCSA a
  <http://hoohoo.ncsa.uiuc.edu/docs-1.5/tutorials/user.html>.



  77..1100..  ssuu--eexxeecc

  La funzione su-exec esegue degli script CGI come se l'esecutore ne
  fosse anche il proprietario: normalmente viene eseguito come l'utente
  del web server (di solito 'nobody'). In questa maniera si consente
  agli utenti di accedere ai propri script CGI senza doverli rendere
  leggibili a tutti (cosa che sarebbe un rischio per la sicurezza). Se
  non si sta attenti, è però possibile aprire un buco più grande di
  quello che si vorrebbe coprire dal momento che su-exec esegue dei
  controlli prima di eseguire gli script, ma se questi controlli non
  sono impostati bene sono problemi.

  Utilizzare su-exec non è un mestiere per principianti: se non sapete
  quello che state facendo, lasciate perdere. Potreste finire per
  consentire ai vostri utenti di acquisire accesso di root al vostro
  sistema, e non è quindi conveniente scherzarci. La codifica ed
  l'impostazione su-exec è difficile apposta, così che i principianti se
  ne tengano alla larga (tutto deve essere fatto a mano, niente file di
  make, niente script di installazione).

  Il codice per su-exec si trova nella directory support dei sorgenti.
  Dapprima bisogna modificare il file suexec.h per il proprio sistema:
  poi bisogna compilare il codice per su-exec con il comando


       gcc suexec.c -o suexec



  In seguito si deve copiare l'eseguibile su-exec nella directory
  giusta, che Apache preimposta a /usr/local/etc/httpd/sbin/, ma che può
  comunque essere cambiata modificando httpd.h nella directory dei sor­
  genti e ricompilando Apache. Ricordatevi che Apache guarderà solo in
  questa directory, e non nel path. È poi necessario cambiare il propri­
  etario del file e settarlo a root (chown root suexec) e settare il bit
  suid (chmod 4711 suexec).  Infine, riavviate Apache e dovrebbe
  apparire sullo schermo che si sta utilizzando su-exec.

  Gli script CGI dovrebbero essere in lettura per tutti come sempre:
  saranno eseguiti automaticamente da ogni utente come il proprietario
  del file. Se settate il bit SUID (set user id) sul CGI questo non
  verrà eseguito, così come non vengono eseguiti gli script posseduti
  dagli utenti di sistema (root, bin, ecc.). Per ulteriori informazioni
  sulle condizioni di sicurezza che devono essere rispettate,
  controllate la documentazione di su-exec: se poi avete problemi potete
  anche spulciare il file di log, che si chiama cgi.log.

  Su-exec non funziona se lanciate Apache da inetd: questo problema sarà
  risolto nelle prossime versioni dal momento che non ci sarà più un
  modo inetd. Se vi piace giocare col codice sorgente, potreste voler
  modificare il file http_main.c per liberarvi delle linee in cui Apache
  annuncia che sta utilizzando su-exec (lo stampa erroneamente prima di
  qualsiasi output).

  Assicuratevi infine di leggere la documentazione Apache riguardante
  su-exec: è inclusa con i sorgenti ed è anche disponibile sul sito di
  Apache a <http://www.apache.org/docs/suexec.html>


  77..1111..  IImmaaggeemmaapp

  Apache è in grado di gestire le imagemap dal lato del server: si
  tratta di immagini su una pagina web che portano l'utente in diverse
  locazioni a seconda del punto su cui si clicca. Per abilitarle è per
  prima cosa necessario assicurarsi che il modulo per le imagemap sia
  installato (è uno dei moduli di default). Poi, togliete i commenti
  all'handler .map alla fine del file srm.conf: così facendo, tutti i
  file con estensione .map saranno dei file per le imagemap, dove cioè
  vengono settati i diversi link a seconda del punto in cui si clicca.
  Apache utilizza i file di mappa seguento lo standard NCSA, di cui vi
  presento un esempio:


       <a href="/map/mapfile.map">
       <img src="picture.gif" ISMAP>
       </a>



  In questo esempio mapfile.map è il mapfile mentre picture.gif è
  l'immagine su cui cliccare.

  Esistono molti programmi che possono generare dei mapfile compatibili
  con lo standard NCSA, ma è anche possibile crearseli da soli. Per una
  discussione più approfondita sull'argomento, andate a
  <http://www.apacheweek.com/features/imagemaps>.


  77..1122..  SSSSII//XXSSSSII

  Il Server Side Includes (SSI) aggiunge contenuti dinamici - inseriti
  nella pagina - a documenti web altrimenti statici e non interattivi:
  il server, infatti, processa gli SSI e passa i risultati alla pagina.
  In questo modo, si possono aggiungere intestazioni e note di chiusura,
  la data di ultima modifica, eseguire comandi di sistema o degli script
  CGI. Con i nuovi eXtended Server Side Includes (XSSI) si può fare
  ancora di più, aggiungendo condizioni di controllo (if...else): è
  quasi come avere un linguaggio di programmazione.

  Processare tutti i file HTML per cercare comandi SSI sarebbe una
  perdita di tempo ed uno spreco di risorse: pertanto, è necessario
  distinguere le pagine che contengono HTML normale da quelle con i
  comandi SSI. Generalmente si ricorre per questi file a delle
  estensioni diverse: la più usata è .shtml.

  Per abilitare SSI/XSSI assicuratevi per prima cosa che il modulo per
  gli include sia installato: poi, modificate srm.conf e togliete i
  commenti alle direttive AddType e AddHandler per i file .shtml. Infine
  dovete settare Options Includes per tutte le directory dove volete
  eseguire file SSI/XSSI modificando il file access.conf. Fatto ciò,
  tutti i file con l'estensione .shtml saranno processati per
  controllare se contengono comandi SSI/XSSI.

  Un altro modo per abilitare le includes è quello di usare la direttiva
  XBitHack: se abilitata, controlla che il file sia eseguibile
  dall'utente generico e se per quella directory è settata Options
  Includes: nel caso in cui si verifichino entrambe le condizioni,
  allora il file viene trattato come SSI. Questo procedimento funziona
  solo per file con il tipo MIME text/html .html .htm): comunque, non è
  consigliabile usare questo metodo.

  Esiste poi un rischio di sicurezza nell'assicurare a file SSI di
  eseguire comandi di sistema e script CGI: è pertanto possibile
  bloccare questa funzione con la direttiva Option IncludesNOEXEC invece
  che Option Includes nel file access.conf. Tutti gli altri comandi SSI
  continueranno a funzionare.

  Per maggiori informazioni, leggete la documentazione Apache su
  mod_includes, distribuita con i sorgenti e disponibile a
  <http://www.apache.org/docs/mod/mod_include.html>.
  Per una discussione più dettagliata su SSI/XSSI, andate su Apacheweek
  a <http://www.apacheweek.com/features/ssi>.

  Informazioni sui comandi SSI si trovano anche alla NCSA a
  <http://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html>.

  Mentre per l'XSSI date un'occhiata a
  <ftp://pageplus.com/pub/hsf/xssi/xssi-1.1.html>.


  77..1133..  SSiisstteemmaa mmoodduullaarree

  Apache può essere ampliato per supportare quasi tutto attraverso i
  moduli, di cui ne esiste già un vasto numero in giro per il web. Solo
  i moduli di interesse più generale sono Distribuiti con Apache, ma
  link a tutti i moduli esistenti si possono trovare all'Apache Module
  Registry a <http://www.zyzzyva.com/module_registry/>.

  Per informazioni su come scrivere il proprio modulo andate a
  <http://www.zyzzyva.com/module_registry/reference/>



  88..  WWeebb SSeerrvveerr AAdddd--oonnss

  Ops, questa parte non l'ho ancora scritta...

  Prossimamente: mSQL, PHP/FI, cgiwrap, Fast-cgi, estensioni MS
  frontpage, e altro ancora.



  99..  FFAAQQ


  A dire il vero non ci sono state domande frequenti - per adesso...



  1100..  LLeettttuurree ccoonnssiigglliiaattee



  1100..11..  LLiibbrrii ddeellllaa OO''RReeiillllyy && AAssssoocciiaatteess

  Secondo me O'Reilly & Associates è la migliore casa per libri tecnici
  del pianeta. Si concentrano principalmente su Internet, Unix e
  programmazione e cominciano sempre con un bel po' di esempi fino a
  giungere ad argomenti molto avanzati: se si legge solo metà del libro
  si raggiunge già una conoscenza di tutto rispetto. In più, riescono ad
  aggiungere un po' di humor ad argomenti altrimenti un po' pallosi.

  Hanno degli ottimi libri su HTML, PERL, Programmazione CGI, Java,
  Javascript, C/C++, Sendmail, Linux e tanto altro. Gli argomenti più
  "caldi" vengono aggiornati circa ogni 6 mesi e così è altamente
  consigliato visitare il loro sito web O'Reilly & Associates
  <http://www.ora.com/> o recarsi nel più vicino negozio di libri.

  State attenti alle imitazioni: se non ha O'Reilly & Associates sulla
  copertina, probabilmente è stato scritto da qualcun'altro!

  1100..22..  IInntteerrnneett RReeqquueesstt FFoorr CCoommmmeennttss ((RRFFCC))


  ·  RFC1866 scritta da T. Berners-Lee e D. Connolly, "Hypertext Markup
     Language - 2.0", 11/03/1995

  ·  RFC1867 scritta da E. Nebel e L. Masinter, "Form-based File Upload
     in HTML", 11/07/1995

  ·  RFC1942 scritta da D. Raggett, "HTML Tables", 05/15/1996

  ·  RFC1945 di T. Berners-Lee, R. Fielding, H. Nielsen, "Hypertext
     Transfer Protocol -- HTTP/1.0", 05/17/1996.

  ·  RFC1630 di T. Berners-Lee, "Universal Resource Identifiers in WWW:
     A Unifying Syntax for the Expression of Names and Addresses of
     Objects on the Network as used in the World-Wide Web", 06/09/1994

  ·  RFC1959 di T. Howes, M. Smith, "An LDAP URL Format", 06/19/1996