10.2. Migrazione dei file di configurazione del Server HTTP Apache 1.3
Questa sezione si riferisce a coloro che desiderano eseguire una migrazione del file di configurazione del Server HTTP Apache 1.3, utilizzato da Server HTTP Apache 2.0.
Se avete aggiornato il server da Red Hat Enterprise Linux 2.1 a Red Hat Enterprise Linux 4, il nuovo file di configurazione per il pacchetto Server HTTP Apache 2.0 viene 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 vario è in genere la scelta migliore. I file di configurazione per entrambe le versioni 1.3 e 2.0 sono suddivisi in tre sezioni.
Se il file /etc/httpd/conf/httpd.conf è una versione modificata della nuova versione di default, e avete salvato una copia dell'originale, potrebbe essere più semplice richiamare il comando diff, come nell'esempio riportato di seguito (registrato come utente root):
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 |
10.2.1. Configurazione dell'ambiente globale
La sezione sull'ambiente globale del file di configurazione contiene le direttive che influiscono sul funzionamento globale del Server HTTP Apache, come il numero di richieste che può gestire e le posizioni dei vari file. Questa sezione richiede un grande numero di modifiche, e dovrebbe basarsi sul file di configurazione del Server HTTP Apache 2.0 durante la migrazione delle vecchie impostazioni all'interno di esso.
10.2.1.1. Interfaccia e Port binding
Le direttive BindAddress e Port non esistono più. La funzione relativa è 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 del Server HTTP Apache 1.3:
Port 123 ServerName www.example.com |
Per migrare questa impostazione sul 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:
10.2.1.2. Regolazione della dimensione del pool del server
Quando Server HTTP Apache accetta le richieste, esso invia i processi figlio o thread in modo da gestirli. Questo gruppo di processi figlio o thread è conosciuto come pool del server. Con Server HTTP Apache 2.0, la responsabilità per la creazione e il mantenimento di questi pool del server è stata riassunta in un gruppo di moduli chiamati Multi-Processing Modules (MPM). A differenza di altri moduli, solo un modulo del gruppo MPM può essere caricato dal Server HTTP Apache. Con la versione 2.0 sono disponibili tre moduli MPM: prefork, worker, e perchild. Attualmente sono solo disponibili gli MPM prefork e worker, anche se l'MPM perchild potrebbe essere reso disponibile in futuro.
La caratteristica originale del Server HTTP Apache 1.3 è stata spostata nell'MPM prefork. L'MPM prefork accetta le stesse direttive del Server HTTP Apache 1.3, di conseguenza le seguenti direttive possono essere migrate direttamente:
StartServers
MinSpareServers
MaxSpareServers
MaxClients
MaxRequestsPerChild
L'MPM worker implementa un server multi-process, multi-threaded che fornisce maggiore scalabilità. Quando si usa questo MPM, le richieste sono gestite dai thread, conservando le risorse del sistema e permettendo ad un gran numero di richieste di essere servite in modo efficiente. Anche se alcune delle direttive accettate dall'MPM worker sono le stesse di quelle accettate dall'MPM prefork, i valori per quelle direttive non dovrebbero essere trasferiti direttamente da una installazione Server HTTP Apache 1.3. È meglio invece usare i valori di default come guida, per poi provare a determinare quali valori funzionano meglio.
 | Importante | |
|---|---|---|
Per usare l'MPM worker, creare il file /etc/sysconfig/httpd, ed aggiungere la seguente direttiva:
|
Per ulteriori informazioni sugli MPM, consultate la documentazione indicata di seguito nel sito Web di Apache Software Foundation:
10.2.1.3. Supporto DSO (Dynamic Shared Object)
Sono molte le modifiche necessarie in questo caso ed è consigliabile che chiunque tenti di modificare una configurazione Server HTTP Apache 1.3 per adeguarsi alla versione 2.0 (in contrapposizione alla migrazione delle modifiche nella configurazione della versione 2.0), copi questa sezione dal file di configurazione del 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 l'abilitazione dei moduli 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 righe LoadModule, in molti casi non è più importante.
Molti moduli sono stati aggiunti, rimossi, rinominati, suddivisi o incorporati in altri.
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 nei 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 é molto importante che httpd.conf contenga la seguente direttiva:
L'omissione di questa direttiva porta al fallimento di tutti i moduli contenuti nei propri RPM, (come mod_perl, php e mod_ssl). |
10.2.1.4. Altre modifiche all'ambiente globale
Le direttive riportate di seguito sono state rimosse dalla configurazione del 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 poichè 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, le 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 file conf/srm.conf e conf/access.conf.
10.2.2. Configurazione del server principale
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 sezione <VirtualHost> possiate definire.
Le direttive utilizzate in questa sezione sono state modificate in minima parte tra la versione 1.3 e 2.0 del Server HTTP Apache. Se la configurazione del vostro server principale è stata personalizzata in modo considerevole, potrebbe essere più semplice modificare la configurazione esistente per adattarsi a Server HTTP Apache 2.0. Solo gli utenti con sezioni del server principale in parte personalizzate, devono migrare le proprie modifiche nella configurazione di default 2.0.
10.2.2.1. Mappatura di UserDir
La direttiva UserDir è utilizzata per abilitare URL come http://example.com/~bob/ per mappare una sottodirectory all'interno della home directory dell'utente bob, come /home/bob/public_html. Un effetto collaterale di questa caratteristica può consentire a un potenziale aggressore di determinare se un determinato nome utente sia presente nel sistema. Pertanto la configurazione di default del 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:
10.2.2.2. Accesso
Le direttive di accesso riportate di seguito sono state rimosse:
AgentLog
RefererLog
RefererIgnore
Tuttavia i log referer ed agent 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:
10.2.2.3. Indicizzare le directory
La direttiva FancyIndexing è stata finalmente rimossa. La stessa funzionalità è disponibile attraverso l'option FancyIndexing all'interno della direttiva IndexOptions.
L'opzione VersionSort per la direttiva IndexOptions fa sì che i file contenenti i numeri della versione vengano ordinati in modo naturale. Per esempio, 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:
10.2.2.4. Negoziazione del contenuto
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:
10.2.2.5. Error Documents
Per utilizzare un messaggio hard-coded con la direttiva ErrorDocument, il messaggio deve essere compreso tra virgolette
Per esempio, quella riportata di seguito è una direttiva del Server HTTP Apache 1.3:
ErrorDocument 404 "The document was not found |
Per migrare una impostazione ErrorDocument al Server HTTP Apache 2.0, utilizzate la struttura riportata di seguito:
ErrorDocument 404 "The document was not found" |
Notare nell'esempio precedente della direttiva ErrorDocument, le virgolette alla fine.
Per ulteriori informazioni su questo argomento, consultate la documentazione indicata di seguito nel sito Web di Apache Software Foundation:
10.2.3. Configurazione dell'Host Virtuale
Il contenuto di tutte le sezioni <VirtualHost> deve essere migrato in modo simile alla sezione del server principale come descritto nella 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 del server securo HTTP di Apache nella Red Hat Enterprise Linux System Administration Guide e nella documentazione indicata nel seguente URL:
10.2.4. Moduli e Server HTTP Apache 2.0
Nel Server HTTP Apache 2.0 il sistema dei moduli è stato modificato per consentire agli stessi di essere collegati o combinati in modo diverso. 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.
Con il Server HTTP Apache 1.3, per esempio, uno script Perl sarebbe stato gestito completamente dal modulo Perl (mod_perl). Con il Server HTTP Apache 2.0 la richiesta viene inizialmente gestita dal modulo principale — il quale serve i file statici — e viene poi filtrata da mod_perl.
L'impiego dettagliato di questa e di altre nuove caratteristiche del Server HTTP Apache 2.0 va oltre lo scopo di questo documento, tuttavia, la modifica ha ramificazioni se viene usata la direttiva PATH_INFO, per un documento gestito da un modulo che viene ora implementato come filtro, in quanto ogni modulo contiene informazioni sul percorso dopo il nome del file vero. Il modulo principale, che gestisce inizialmente la richiesta, non comprende per default PATH_INFO e restituisce gli 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 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:
10.2.4.1. Il modulo suexec
In Server HTTP Apache 2.0, il modulo mod_suexec utilizza la direttiva SuexecUserGroup invece delle direttive User e Group, le quali vengono a loro volta usate per configurare gli host virtuali. Le direttive User e Group possono, in generale, essere ancora usate, ma sono sconsigliate per configurare gli host virtuali.
Per esempio, quella riportata di seguito è una direttiva del Server HTTP Apache 1.3:
<VirtualHost vhost.example.com:80>
User someone
Group somegroup
</VirtualHost> |
Per migrare questa impostazione sul Server HTTP Apache 2.0, utilizzate la struttura riportata di seguito:
<VirtualHost vhost.example.com:80>
SuexecUserGroup someone somegroup
</VirtualHost> |
10.2.4.2. Il modulo mod_ssl
La configurazione per mod_ssl è stata spostata dal file httpd.conf nel file /etc/httpd/conf.d/ssl.conf. Perchè questo file venga caricato e perchè mod_ssl funzioni correttamente, dovete disporre dell'istruzione Include conf.d/*.conf nel vostro file httpd.conf come descritto nella 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 del Server HTTP Apache 1.3:
<VirtualHost _default_:443>
# General setup for the virtual host
ServerName ssl.example.name
...
</VirtualHost> |
Per migrare questa impostazione sul 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> |
È importante notare anche che entrambe le direttive SSLLog e SSLLogLevel sono state rimosse. Il modulo mod_ssl ubbidisce ora alle direttive ErrorLog e LogLevel. Consultare la Sezione 10.5.35 e la Sezione 10.5.36 per maggiori informazioni su queste direttive.
Per ulteriori informazioni su questo argomento, consultate la documentazione indicata di seguito nel sito Web di Apache Software Foundation:
10.2.4.3. Il modulo mod_proxy
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_mem_cache
Questi moduli utilizzano in genere direttive simili alle versioni più vecchie del modulo mod_proxy, ma è consigliabile verificare ogni direttiva prima di migrare ogni impostazione della cache.
Per ulteriori informazioni su questo argomento, consultate la documentazione indicata di seguito nel sito Web di Apache Software Foundation:
10.2.4.4. Il modulo mod_include
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 del Server HTTP Apache 1.3:
AddType text/html .shtml AddHandler server-parsed .shtml |
Per migrare questa impostazione sul Server HTTP Apache 2.0, utilizzate la struttura riportata di seguito:
AddType text/html .shtml AddOutputFilter INCLUDES .shtml |
Da notare che 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:
10.2.4.5. I moduli mod_auth_dbm e mod_auth_db
Server HTTP Apache 1.3 supporta due moduli di autenticazione, mod_auth_db e mod_auth_dbm che utilizzavano rispettivamente i database Berkeley e DBM. Questi moduli sono stati combinati in un singolo modulo chiamato mod_auth_dbm in Server HTTP Apache 2.0, che è in grado di accedere a numerosi formati di database. Per migrare da mod_auth_db, i file di configurazione devono essere modificati sostituendo AuthDBUserFile e AuthDBGroupFile con gli equivalenti mod_auth_dbm, AuthDBMUserFile e AuthDBMGroupFile. Dovete inoltre aggiungere la direttiva AuthDBMType DB per indicare il tipo di file del database utilizzato.
L'esempio riportato di seguito mostra una configurazione mod_auth_db per il 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 del 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 i database dei nomi utente e password, è stato sostituito da htdbm nel Server HTTP Apache 2.0. Il programma htdbm offre funzionalità equivalenti e come mod_auth_dbm può operare un'ampia serie di formati del database. L'opzione -T può essere utilizzata nella riga di comando per specificare 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 la codifica 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:
10.2.4.6. Il modulo mod_perl
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 nella Sezione 10.2.1.3.
Le occorrenze di Apache:: in httpd.conf devono essere sostituite con ModPerl::. Inoltre è stato modificato il modo in cui vengono registrati gli handler.
Quella riportata di seguito è un esempio di configurazione Server HTTP Apache 1.3 mod_perl:
<Directory /var/www/perl>
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
</Directory> |
Quella riportata di seguito è il mod_perl equivalente per Server HTTP Apache 2.0:
<Directory /var/www/perl>
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
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 richiedere modifiche Makefile minori.
10.2.4.7. Il modulo mod_python
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 nella Sezione 10.2.1.3.
10.2.4.8. PHP
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 nella Sezione 10.2.1.3.
 | Nota Bene |
|---|---|
Quando si esegue una migrazione su Server HTTP Apache 2.0 su Red Hat Enterprise Linux 4, qualsiasi direttiva di configurazione PHP usata nel Server HTTP Apache 1.3, è completamente compatibile. |
In PHP versione 4.2.0 e successive, la serie di variabili predefinite di defaultdisponibili 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 su On nel file /etc/php.ini.
Per ulteriori informazioni su questo argomento, consultate l'URL indicato di seguito per dettagli relativi alle modifiche:
10.2.4.9. Il modulo mod_authz_ldap
Red Hat Enterprise Linux contiene il modulo mod_authz_ldap per il Server HTTP Apache. Questo modulo usa la forma abbreviata del distinguished name per il soggetto, e l'emittente del certificato SSL del client per determinare il distinguished name dell'utente all'interno della directory LDAP. È altresì in grado di abilitare gli utenti in base agli attributi della entry della directory LDAP dell'utente stesso, determinando un accesso alle risorse in base ai privilegi dell'utente o del gruppo, negando tale accesso agli utenti che possiedono una password scaduta. È necessario il modulo mod_ssl, quando si usa il modulo mod_authz_ldap.
| Importante |
|---|---|
Il modulo mod_authz_ldap non esegue l'autenticazione dell'utente su di una directory LDAP che usa una password cifrata. Questa funzionalità viene fornita dal modulo sperimentale mod_auth_ldap. Consultate la documentazione del modulo mod_auth_ldap disponibile su http://httpd.apache.org/docs-2.0/mod/mod_auth_ldap.html per ottenere maggiori informazioni. |
Il file /etc/httpd/conf.d/authz_ldap.conf configura il modulo mod_authz_ldap.
Per maggiori informazioni su come configurare il modulo mod_authz_ldap, consultare /usr/share/doc/mod_authz_ldap-<version>/index.html (sostituendo <version> con il numero della versione del pacchetto) o http://authzldap.othello.ch/.