10.2. Migrazione dei file di configurazione di Server HTTP Apache 1.3

Questa sezione si riferisce a coloro che desiderano effettuare una migrazione del file di configurazione Server HTTP Apache 1.3 al nuovo formato Server HTTP Apache 2.0.

Se avete aggiornato il server da Red Hat Enterprise Linux 2.1 a Red Hat Enterprise Linux 3, 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 variato è 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:

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 di 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, in confronto ad altre, ed è pertanto consigliabile basare questa sezione sul file di configurazione di Server HTTP Apache 2.0 e migrare in esso le vecchie impostazioni.

10.2.1.1. Interfaccia e Port binding

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:

10.2.1.2. Regolazione della dimensione del pool del server

Quando Server HTTP Apache accetta le richieste, invia processi figlio o thread per gestirli. Questo gruppo di processi figlio o thread è conosciuto come un pool di server. Sotto Server HTTP Apache 2.0, la responsabilità per la creazione e il mantenimento di questi pool di server è stata riassunta in un gruppo di moduli chiamati Multi-Processing Modules (MPMs). 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, and perchild. Attualmente sono solo disponibili gli MPM prefork e worker, anche se l'MPM perchild potrebbe essere reso disponibile in futuro.

La caratteristica originale di Server HTTP Apache 1.3 è stata spostata nell'MPM prefork. 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

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 abilitando 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 trasferite 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.

ImportanteImportante
 

Per usare l'MPM worker, creare il file /etc/sysconfig/httpd. Nel file aggiungere la seguente direttiva:

HTTPD=/usr/sbin/httpd.worker

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 di 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, 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.

ImportanteImportante
 

Se modificate il file originale, si prega di notare che é importante che httpd.conf contenga le seguenti direttive:

Include conf.d/*.conf

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 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, 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 "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 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 subdirectory 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 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:

10.2.2.2. Accesso

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:

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.

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:

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. Documenti degli errori

Per utilizzare un messaggio hard-coded con la direttiva ErrorDocument, il messaggio deve essere compreso tra virgolette doppie ["], invece che semplicemente preceduto dalle virgolette doppie come in Server HTTP Apache 1.3.

Per esempio, quella riportata di seguito è una direttiva di esempio di Server HTTP Apache 1.3:

ErrorDocument 404 "The document was not found

Per migrare un'impostazione ErrorDocument a 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 doppie 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 degli host virtuali

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.

ImportanteImportante
 

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 Red Hat Enterprise Linux System Administration Guide e nella documentazione indicata nel seguente URL:

10.2.4. Moduli e Server HTTP Apache 2.0

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.

Sotto Server HTTP Apache 1.3, per esempio, uno script Perl sarebbe stato gestito completamente dal modulo Perl (mod_perl). Sotto Server HTTP Apache 2.0 la richiesta viene inizialmente gestita dal modulo principale — il quale serve file statici — e viene poi filtrata da mod_perl.

L'impiego dettagliato di questa e di altre nuove caratteristiche di Server HTTP Apache 2.0 va oltre l'ambito 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 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, 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>

È 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.34 e la Sezione 10.5.35 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.2. 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.3. 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 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:

10.2.4.4. I moduli mod_auth_dbm e mod_auth_db

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.

Azionedbmmanage command (1.3)Equivalent htdbm command (2.0)
Aggiungere l'utente al database (mediante la password)dbmmanage authdb add username passwordhtdbm -b -TDB authdb username password
Aggiungere l'utente al database (richiesta della password)dbmmanage authdb adduser usernamehtdbm -TDB authdb username
Rimuovere l'utente dal databasedbmmanage authdb delete usernamehtdbm -x -TDB authdb username
Elencare gli utenti nel databasedbmmanage authdb viewhtdbm -l -TDB authdb
Verificare una passworddbmmanage authdb check usernamehtdbm -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:

10.2.4.5. 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 in la 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 è 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 richiedere modifiche Makefile minori.

10.2.4.6. 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 in la Sezione 10.2.1.3.

10.2.4.7. 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 in la Sezione 10.2.1.3.

PHP è 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 versione 4.2.0 e successive la serie di default 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 su 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:

10.2.4.8. Il modulo mod_authz_ldap

Red Hat Enterprise Linux contiene il modulo mod_authz_ldap per 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.

ImportanteImportante
 

Il modulo mod_authz_ldap non autentica l'utente su di una directory LDAP che usa una password hash cifrata. Questa funzionalità viene fornita dal modulo sperimentale mod_auth_ldap, il quale non è incluso con Red Hat Enterprise Linux. Consultate il sito web di Apache Software Foundation, disponibile su http://www.apache.org/ 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).