Se avete aggiornato il vostro server da Red Hat Linux 7.3 o una versione precedente in cui Server HTTP Apache era già installato, il nuovo file di configurazione per il pacchetto Server HTTP Apache 2.0 verrà installato come /etc/httpd/conf/httpd.conf.rpmnew e il file della versione 1.3 originale httpd.conf rimarrà invariato. Dipende da voi se utilizzare il nuovo file di configurazione e migrare le vecchie impostazioni oppure utilizzare il file esistente come base e modificarlo secondo le necessità. Tuttavia, alcune parti del file sono state modificate più di altre e un approccio variato è in genere la scelta migliore. I file di configurazione per entrambe le versioni 1.3 e 2.0 sono suddivisi in tre sezioni. L'obiettivo di questa guida è quello di suggerire il metodo più semplice.
Se il vostro /etc/httpd/conf/httpd.conf è una versione modificata della versione predefinita di Red Hat Linux e avete salvato una copia dell'originale, potrebbe essere più semplice chiamare il comando diff, come nell'esempio riportato di seguito:
diff -u httpd.conf.orig httpd.conf | less |
Questo comando evidenzia le modifiche effettuate. Se non disponete di una copia del file originale, estraetela da un pacchetto RPM mediante i comandi rpm2cpio e cpio come nell'esempio riportato di seguito:
rpm2cpio apache-<version-number>.i386.rpm | cpio -i --make |
Nel comando precedentemente riportato, sostituire <numero-versione> con il numero della versione per il pacchetto apache.
È infine utile sapere che Server HTTP Apache dispone di una modalità di verifica degli errori all'intero della configurazione. Per accedervi, digitate il comando riportato di seguito:
apachectl configtest |
La sezione sull'ambiente globale del file di configurazione contiene le direttive che influiscono sul funzionamento globale di Server HTTP Apache, come il numero di richieste simultanee che può gestire e i percorsi dei vari file che utilizza. Questa sezione richiede un grande numero di modificate in confronto ad altre ed è pertanto consigliabile che vi basiate sul file di configurazione di Server HTTP Apache 2.0 ed eseguiate la migrazione delle vecchie impostazioni.
Le direttive BindAddress e Port non esistono più. La relativa funzione è ora fornita da una direttiva più flessibile Listen.
Se avete impostato Port 80 nel file di configurazione della versione 1.3, dovete modificare l'opzione in Listen 80 nel file di configurazione 2.0. Se avete impostato Port a un valore diverso da 80 dovete anche aggiungere il numero di porta al contenuto della direttiva ServerName.
Per esempio, quella riportata di seguito è una direttiva di esempio di Server HTTP Apache 1.3:
Port 123 ServerName www.example.com |
Per migrare questa impostazione a Server HTTP Apache 2.0, utilizzate la struttura riportata di seguito:
Listen 123 ServerName www.example.com:123 |
Per ulteriori informazioni su questo argomento, consultate la documentazione indicata di seguito nel sito Web di Apache Software Foundation:
In Server HTTP Apache 2.0 la responsabilità di accettare richieste e inviare processi secondari per gestirle è stata riassunta in un gruppo di moduli denominato MPM (Multi-Processing Modules). A differenza di altri moduli, solo un modulo del gruppo MPM può essere caricato da Server HTTP Apache. Con la versione 2.0 sono disponibili tre moduli MPM: prefork, worker, e perchild.
Il comportamento originale di Server HTTP Apache 1.3 è stato spostato nel modulo MPM prefork. Attualmente solo prefork è disponibile in Red Hat Linux, anche se altri moduli MPM potranno essere disponibili successivamente.
L'MPM prefork accetta le stesse direttive di Server HTTP Apache 1.3, di conseguenza le seguenti direttive possono essere migrate direttamente:
StartServers
MinSpareServers
MaxSpareServers
MaxClients
MaxRequestsPerChild
Per ulteriori informazioni su questo argomento, consultate la documentazione indicata di seguito nel sito Web di Apache Software Foundation:
Sono molte le modifiche necessarie in questo caso ed è consigliabile che chiunque tenti di modificare una configurazione Apache 1.3 perché si adegui ad Apache 2.0 (in contrapposizione alla migrazione delle modifiche nella configurazione di Apache 2.0), copi questa sezione dal file di configurazione di Red Hat Linux Server HTTP Apache 2.0.
Per coloro che non desiderano copiare la sezione dalla configurazione Server HTTP Apache 2.0, dovrebbero tener presente di quanto segue:
Le direttive AddModule ClearModuleList non esistono più. Queste direttive erano utilizzate per garantire che i moduli potevano essere abilitati nell'ordine corretto. L'API di Apache 2.0 consente ai moduli di specificare l'ordine, eliminando la necessità di queste due direttive.
L'ordine delle linee LoadModule non è più importante.
Molti moduli sono stati aggiunti, rimossi, rinominati, suddivisi o incorporati l'uno nell'altro.
Le linee LoadModule per i moduli dei pacchetti dei loro RPM (mod_ssl, php, mod_perl e simili) non sono più necessarie perché possono essere disponibili nel file della directory /etc/httpd/conf.d/.
Le varie definizioni di HAVE_XXX non sono più definite.
![]() | Importante | |
|---|---|---|
Se modificate il file originale, si prega di notare che é importante che httpd.conf contenga le seguenti direttive:
L'omissione di questa direttiva porta al fallimento di tutti i moduli contenuti nel pacchetto di RPM, come mod_perl, php e mod_ssl). |
Le direttive riportate di seguito sono state rimosse dalla configurazione di Server HTTP Apache 2.0:
ServerType — Server HTTP Apache può essere eseguito solo come ServerType standalone rendendo inutile questa direttiva.
AccessConfig e ResourceConfig — queste direttive sono state rimosse dato che rispecchiano la funzione della direttiva Include. Se avete impostato le direttive AccessConfig e ResourceConfig dovete sostituirle con le direttive Include.
Per garantire che i file vengano letti nell'ordine stabilito dalle vecchie direttive, Include devono essere collocate alla fine del file httpd.conf, con la direttiva corrispondente a ResourceConfig che precede quella corrispondente a AccessConfig. Se avete utilizzato i valori predefiniti, dovete includerli in modo esplicito come conf/srm.conf e conf/access.conf.
La sezione relativa alla configurazione del server principale del file di configurazione consente di impostare il server principale, che risponde a qualsiasi richiesta che non venga gestita da una definizione <VirtualHost>. I valori in questo caso forniscono inoltre valori predefiniti per qualsiasi "cotainer" <VirtualHost> possiate definire.
Le direttive utilizzate in questa sezione sono state modificate in minima parte tra la versione 1.3 e 2.0 di Server HTTP Apache. Se la configurazione del vostro server principale è stata personalizzata notevolmente potrebbe essere più semplice modificare la configurazione esistente perché si adatti ad Server HTTP Apache 2.0. Solo gli utenti con sezioni del server principale in parte personalizzate, devono migrare le proprie modifiche nella configurazione predefinita 2.0.
La direttiva UserDir è utilizzata per abilitare URL come http://example.com/~bob/ per mappare una sottodirectory all'interno della directory home dell'utente bob, come /home/bob/public_html. Un effetto collaterale di questa caratteristica può consentire a un potenziale malintenzionato di determinare se un determinato nome utente sia presente nel sistema, pertanto la configurazione predefinita di Server HTTP Apache 2.0 disabilita questa direttiva.
Per abilitare la mappatura di UserDir, modificate la direttiva in httpd.conf da:
UserDir disable |
a quanto riportato di seguito:
UserDir public_html |
Per ulteriori informazioni su questo argomento, consultate la documentazione indicata di seguito nel sito Web di Apache Software Foundation: http://httpd.apache.org/docs-2.0/mod/mod_userdir.html#userdir.
Le direttive di accesso riportate di seguito sono state rimosse:
AgentLog
RefererLog
RefererIgnore
Tuttavia i log agent e referer sono ancora disponibili mediante l'utilizzo delle direttive CustomLog e LogFormat.
Per ulteriori informazioni su questo argomento, consultate la documentazione indicata di seguito nel sito Web di Apache Software Foundation:
La direttiva FancyIndexing è stata finalmente rimossa. La stessa funzionalità è disponibile attraverso l'option FancyIndexing all'interno della direttiva IndexOptions.
La nuova opzione VersionSort della direttiva IndexOptions fa sì che i file contenenti i numeri di versione vengano ordinati in modo naturale, cosicché httpd-2.0.6.tar viene visualizzato prima di httpd-2.0.36.tar nella pagine dell'indice delle directory.
I valori predefiniti per le direttive ReadmeName e HeaderName sono stati modificati da README e HEADER a README.html e HEADER.html.
Per ulteriori informazioni su questo argomento, consultate la documentazione indicata di seguito nel sito Web di Apache Software Foundation:
La direttiva CacheNegotiatedDocs richiede ora l'argomento on o off. Le istanze esistenti di CacheNegotiatedDocs devono essere sostituite con CacheNegotiatedDocs on.
Per ulteriori informazioni su questo argomento, consultate la documentazione indicata di seguito nel sito Web di Apache Software Foundation:
Per utilizzare un messaggio hard-coded con la direttiva
ErrorDocument, il messaggio deve essere compreso
tra virgolette doppie
Per migrare un'impostazione ErrorDocument a Server HTTP Apache 2.0, utilizzate la struttura riportata di seguito:
ErrorDocument 404 "The document was not found" |
Nell'esempio della direttiva ErrorDocument si trovano virgolette doppie alla fine.
Per ulteriori informazioni su questo argomento, consultate la documentazione indicata di seguito nel sito Web di Apache Software Foundation:
Il contenuto di tutti i contenitori <VirtualHost> deve essere migrato nello stesso modo della sezione del server principale come descritto in la Sezione 10.2.2.
![]() | Importante |
|---|---|
La configurazione dell'host virtuale SSL/TLS è stata spostata all'esterno del file di configurazione del server principale nel file /etc/httpd/conf.d/ssl.conf. |
Per ulteriori informazioni su questo argomento, consultate il capitolo intitolato Configurazione server secure HTTP di Apache nella documentazione indicata di seguito Red Hat Linux Customization Guide nel sito Web:
In Server HTTP Apache 2.0 il sistema di moduli è stato modificato per consentire ai moduli di essere collegati o combinati in modo nuovo. Gli script Common Gateway Interface (CGI), per esempio, possono generare documenti HTML analizzati dal server che possono poi essere elaborati da mod_include. In questo modo si apre una vasta gamma di possibilità in relazione al modo in cui i moduli possono essere combinati per raggiungere un obiettivo specifico.
Questo sistema funziona in base al fatto che ciascuna richiesta viene servita da esattamente un modulo handler seguito da zero o più moduli filtro.
In Server HTTP Apache 1.3, per esempio, uno script PHP sarebbe stato gestito completamente dal modulo PHP. In Apache 2.0 la richiesta viene inizialmente gestita dal modulo principale — relativo ai file statici — e viene poi filtrata dal modulo PHP.
L'impiego dettagliato di questa e di altre nuove caratteristiche di & 2.0 va oltre l'ambito di questo documento. Tuttavia, la modifica ha ramificazioni se è stato utilizzato PATH_INFO, che contiene informazioni sul percorso finale dopo il nome di file true in un documento che è gestito da un modulo che viene ora implementato come filtro. Il modulo principale, che gestisce inizialmente la richiesta, non comprende per default PATH_INFO e restituirà errori 404 Not Found per le richieste che contengono tali informazioni. Potete utilizzare la direttiva AcceptPathInfo per obbligare il modulo principale ad accettare le richieste con PATH_INFO. Di seguito è riportato un esempio di questa direttiva:
Di seguito viene riportato un esempio di questa direttiva:
AcceptPathInfo on |
Per ulteriori informazioni su questo argomento, consultate la documentazione indicata di seguito nel sito Web di Apache Software Foundation:
La configurazione per mod_ssl è stata spostata da httpd.conf nel file /etc/httpd/conf.d/ssl.conf. Perché questo file venga caricato e perché mod_ssl funzioni, dovete disporre dell'istruzione Include conf.d/*.conf nel vostro file httpd.conf come descritto in la Sezione 10.2.1.3.
Le direttive ServerName negli host virtuali SSL devono specificare in modo esplicito il numero di porta.
Per esempio, quella riportata di seguito è una direttiva di esempio di Server HTTP Apache 1.3:
<VirtualHost _default_:443>
# General setup for the virtual host
ServerName ssl.example.name
...
</VirtualHost> |
Per migrare questa impostazione a Server HTTP Apache 2.0, utilizzate la struttura riportata di seguito:
<VirtualHost _default_:443>
# General setup for the virtual host
ServerName ssl.host.name:443
...
</VirtualHost> |
Per ulteriori informazioni su questo argomento, consultate la documentazione indicata di seguito nel sito Web di Apache Software Foundation:
Le istruzioni di controllo dell'accesso proxy sono ora collocate nel blocco <Proxy> invece di <Directory proxy:>.
La funzionalità di caching del vecchio file mod_proxy è stata suddivisa nei tre moduli riportati di seguito:
mod_cache
mod_disk_cache
mod_file_cache
Questi moduli utilizzano in genere direttive uguali o simili come le versioni più vecchie del modulo mod_proxy.
Per ulteriori informazioni su questo argomento, consultate la documentazione indicata di seguito nel sito Web di Apache Software Foundation:
Il modulo mod_include è ora implementato come filtro (per ulteriori informazioni sui filtri, consultate la Sezione 10.2.4) ed è pertanto abilitato in modo diverso.
Per esempio, quella riportata di seguito è una direttiva di esempio di Server HTTP Apache 1.3:
AddType text/html .shtml AddHandler server-parsed .shtml |
Per migrare questa impostazione a Server HTTP Apache 2.0, utilizzate la struttura riportata di seguito:
AddType text/html .shtml AddOutputFilter INCLUDES .shtml |
Come in precedenza, la direttiva Options +Includes è ancora necessaria per la sezione <Directory> o in un file .htaccess.
Per ulteriori informazioni su questo argomento, consultate la documentazione indicata di seguito nel sito Web di Apache Software Foundation:
Server HTTP Apache 1.3 supportava due moduli di autenticazione, mod_auth_db e mod_auth_dbm, che utilizzavano rispettivamente database Berkeley e DBM. Questi moduli sono stati combinati in un singolo modulo denominato mod_auth_dbm in Server HTTP Apache 2.0, che è in grado di accedere a numerosi formati diversi di database. Per migrare da mod_auth_db alla versione 1.3, i file di configurazione devono essere modificati sostituendo AuthDBUserFile e AuthDBGroupFile con gli equivalenti mod_auth_dbm: AuthDBMUserFile and AuthDBMGroupFile. Dovete inoltre aggiungere la direttiva AuthDBMType DB per indicare il tipo di file di database utilizzato.
L'esempio riportato di seguito mostra una configurazione mod_auth_db per Server HTTP Apache 1.3:
<Location /private/> AuthType Basic AuthName "My Private Files" AuthDBUserFile /var/www/authdb require valid-user </Location> |
Per migrare questa impostazione alla versione 2.0 di Server HTTP Apache, utilizzate la struttura riportata di seguito:
<Location /private/> AuthType Basic AuthName "My Private Files" AuthDBMUserFile /var/www/authdb AuthDBMType DB require valid-user </Location> |
La direttiva AuthDBMUserFile può anche essere utilizzata nei file .htaccess.
Lo script Perl dbmmanage, utilizzato per manipolare database di nomi e utenti e password, è stato sostituito da htdbm in Server HTTP Apache 2.0. Il programma htdbm offre funzionalità equivalenti e come mod_auth_dbm può supportare un'ampia serie di formati di database. L'opzione -T può essere utilizzata nella riga di comando per specificate il formato da utilizzare.
La Tabella 10-1 mostra come migrare da un database in formato DBM al formato htdbm mediante dbmmanage.
| Azione | dbmmanage command (1.3) | Equivalent htdbm command (2.0) |
|---|---|---|
| Aggiungere l'utente al database (mediante la password) | dbmmanage authdb add username password | htdbm -b -TDB authdb username password |
| Aggiungere l'utente al database (richiesta della password) | dbmmanage authdb adduser username | htdbm -TDB authdb username |
| Rimuovere l'utente dal database | dbmmanage authdb delete username | htdbm -x -TDB authdb username |
| Elencare gli utenti nel database | dbmmanage authdb view | htdbm -l -TDB authdb |
| Verificare una password | dbmmanage authdb check username | htdbm -v -TDB authdb username |
Tabella 10-1. Migrazione da dbmmanage a htdbm
Le opzioni -m e -s funzionano con dbmmanage e htdbm, attivando l'utilizzo degli algoritmi MD5 o SHA1 per l'hashing delle password.
Quando create un nuovo database con htdbm, deve essere utilizzata l'opzione -c.
Per ulteriori informazioni su questo argomento, consultate la documentazione indicata di seguito nel sito Web di Apache Software Foundation:
La configurazione per mod_perl è stata spostata da httpd.conf nel file /etc/httpd/conf.d/perl.conf. Perché questo file venga caricato e perché mod_perl funzioni, dovete disporre dell'istruzione Include conf.d/*.conf nel file httpd.conf come descritto in la Sezione 10.2.1.3.
Le occorrenze di Apache:: nel file httpd.conf devono essere sostituite con ModPerl::. È stato inoltre modificato il modo in cui vengono registrati gli handler.
Quella riportata di seguito è una configurazione Server HTTP Apache 1.3 mod_perl di esempio:
<Directory /var/www/perl>
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
</Directory> |
Quella riportata di seguito è l'equivalente mod_perl per Server HTTP Apache 2.0:
<Directory /var/www/perl>
SetHandler perl-script
PerlModule ModPerl::Registry
PerlHandler ModPerl::Registry::handler
Options +ExecCGI
</Directory> |
La maggior parte dei moduli per mod_perl 1.x deve funzionare senza alcuna modifica con mod_perl 2.x. I moduli XS richiedono la ricompilazione e possono necessitare di modifiche Makefile minori.
La configurazione per mod_python; è stata spostata da httpd.conf nel file /etc/httpd/conf.d/python.conf. Perché questo file venga caricato e perché mod_python; funzioni, dovete disporre dell'istruzione Include conf.d/*.conf nel file httpd.conf come descritto in la Sezione 10.2.1.3.
La configurazione per PHP è stata spostata da httpd.conf nel file /etc/httpd/conf.d/php.conf. Perché questo file venga caricato, dovete disporre dell'istruzione Include conf.d/*.conf nel file httpd.conf come descritto in la Sezione 10.2.1.3.
Il modulo PHP verrà ora implementato come filtro e dovrà pertanto essere abilitato in modo diverso. Per ulteriori informazioni sui filtri, consultate la Sezione 10.2.4.
In Server HTTP Apache 1.3 PHP è stato implementato mediante le direttiva riportate di seguito:
AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps |
In Server HTTP Apache 2.0 utilizzate invece le seguenti direttive:
<Files *.php>
SetOutputFilter PHP
SetInputFilter PHP
</Files> |
In PHP 4.2.0 e versioni successive la serie prestabilita di variabili predefinite che sono disponibili nell'ambito globale è stata modificata. Il singolo input e le variabili del server non sono più, per default, collocate direttamente in questo punto. Questa modifica può fare in modo che gli script si interrompano. Potete tornare al comportamento precedente impostando register_globals a On nel file /etc/php.ini.
Per ulteriori informazioni su questo argomento, consultate l'URL indicato di seguito per dettagli relativi alle modifiche di ambito globale: