10.2. Migration de fichiers de configuration Serveur HTTP Apache 1.3

Si vous effectuez une mise à niveau de la version 7.3 de Red Hat Linux ou d'une version précédente, sur laquelle Serveur HTTP Apache était déjà installé, le nouveau fichier de configuration pour le paquetage Serveur HTTP Apache 2.0 sera installé sous /etc/httpd/conf/httpd.conf.rpmnew et la version originale 1.3 httpd.conf ne sera pas modifiée. Bien sûr, il vous appartient entièrement de décider d'utiliser la nouvelle configuration et de migrer vos anciens paramètres vers celle-ci, ou d'utiliser le fichier existant comme base et de le modifier en fonction de vos besoins; cependant, certaines parties du fichier ayant été plus modifiées que d'autres, une approche mixte est généralement préférable. Les fichiers de configuration pour les versions 1.3 et 2.0 sont divisés en trois sections. L'objectif de ce guide est de suggérer la meilleure procédure à suivre.

Si le fichier /etc/httpd/conf/httpd.conf est une version modifiée de la version par défaut Red Hat Linux et qu'une copie sauvegardée de l'original est disponible, le plus simple serait d'appeler la commande diff comme dans l'exemple suivant:

diff -u httpd.conf.orig httpd.conf | less

Cette commande soulignera toutes les modifications apportées. Si une copie du fichier original n'est pas disponible, vous devez l'extraire du paquetage RPM en utilisant les commandes rpm2cpio et cpio, comme dans l'exemple suivant:

	  rpm2cpio apache-<version-number>.i386.rpm | cpio -i --make

Dans la commande ci-dessous, remplacez <numéro-version> par le numéro de version du paquetage apache.

Enfin, il est utile de savoir que Serveur HTTP Apache dispose d'un mode test qui permet de trouver les erreurs de configuration. Pour y accéder, entrez la commande suivante:

apachectl configtest

10.2.1. Configuration de l'environnement global

La section 'Environnement global' du fichier de configuration contient des directives qui modifient tout le fonctionnement d'Serveur HTTP Apache, comme par exemple, le nombre de requêtes simultanées qu'il peut traiter et les emplacements des divers fichiers qu'il utilise. Étant donné que cette section nécessite un grand nombre de changements, comparé aux autres, il est vivement recommandé de baser cette section sur le fichier de configuration Serveur HTTP Apache 2.0 et d'y incorporiez ensuite les anciens paramètres.

10.2.1.1. Sélection des interfaces et ports à relier

Les directives BindAddress et Port n'existent plus; leur fonctionnalité est désormais fournie par une directive plus flexible nommée Listen.

Si vous aviez mis Port 80 dans votre fichier de configuration version 1.3, vous devrez le remplacer par Listen 80 dans le fichier de configuration version 2.0. Si Port avait une valeur autre que 80, vous devez ajouter le numéro du port au contenu de la directive ServerName.

L'extrait ci-dessous, représente un exemple de la directive Serveur HTTP Apache 1.3:

Port 123
ServerName www.example.com

Pour migrer ce paramètre vers Serveur HTTP Apache 2.0, utilisez la structure suivante:

Listen 123
ServerName www.example.com:123 

Pour plus d'informations sur le sujet, reportez-vous à la documentation suivante sur le site Web d'Apache Software Foundation:

10.2.1.2. Régulation de la taille du Server-pool

Dans Serveur HTTP Apache 2.0, la responsabilité de l'autorisation des demandes et l'envoi des processus fils pour les traiter a été synthétisé dans un groupe de modules multi-tâches nommés 'Multi-Processing Modules' (ou MPM). Contrairement à d'autres modules, seul un module du groupe MPM peut être chargé par Serveur HTTP Apache. Trois modules MPM sont chargés dans la version 2.0, à savoir, prefork, worker et perchild.

Le comportement original d'Serveur HTTP Apache 1.3 a été déplacé dans le MPM prefork. Actuellement, seul le MPM prefork est disponible sur Red Hat Linux, bien que les autres MPM puissent être disponibles à une date ultérieure.

Étant donné que le MPM prefork accepte les mêmes directives que Serveur HTTP Apache 1.3, il est possible de transférer les directives suivantes:

  • StartServers

  • MinSpareServers

  • MaxSpareServers

  • MaxClients

  • MaxRequestsPerChild

Pour plus d'informations sur le sujet, reportez-vous à la documentation suivante sur le site Web d'Apache Software Foundation:

10.2.1.3. Prise en charge de DSO ('Dynamic Shared Object')

Un grand nombre de changements étant ici requis, il est vivement recommandé que quiconque essayant de modifier une configuration Serveur HTTP Apache 1.3 pour l'adapter à la version 2.0 (par opposition à la migration de vos changements vers la configuration, version 2.0) copie cette section du fichier de configuration Red Hat Linux Serveur HTTP Apache 2.0.

Les utilisateurs ne souhaitant pas copier la section de la configuration Serveur HTTP Apache 2.0 devraient prendre note des informations suivantes:

  • Les directives AddModule et ClearModuleList n'existent plus. Elles étaient utilisées pour assurer l'activation des modules dans la bon ordre. L'API Serveur HTTP Apache 2.0 API permet aux modules de préciser leur d'activation, éliminant ainsi la raison-d'être de ces deux directives.

  • L'ordre des lignes LoadModule ne se justifie plus.

  • De nombreux modules ont été ajoutés, supprimés, renommés, divisés ou incorporés les uns aux autres.

  • Les lignes LoadModule des modules intégrés dans leurs propres RPM (mod_ssl, php, mod_perl, et similaires) ne sont plus nécessaires puisque vous pouvez les trouver dans le fichier approprié dans le répertoire /etc/httpd/conf.d/.

  • Les diverses définitions HAVE_XXX ne sont plus définies.

ImportantImportant
 

Si vous décidez de modifier votre fichier original, notez qu'il est essentiel que le fichier httpd.conf contienne la directive suivante:

Include conf.d/*.conf

L'oubli de cette directive entraînerait l'échec de tous les modules contenus dans leurs propres RPM (tels que mod_perl, php, et mod_ssl).

10.2.1.4. Autres changements de l'environnement global

Les directives suivantes ont été supprimées de la configuration Serveur HTTP Apache 2.0:

  • ServerType — Serveur HTTP Apache ne peut être exécuté qu'en tant que ServerType standalone, rendant ainsi cette directive inutile.

  • AccessConfig et ResourceConfig — Ces directives ont été supprimées puisqu'elles reflétaient la fonctionnalité de la directive Include. Si les directives AccessConfig et ResourceConfig sont paramétrées, vous devez les remplacer par des directives Include.

    Pour obtenir l'assurance que les fichiers seront lus dans l'ordre désigné par les anciennes directives, vous devrez placer les directives Include à la fin du fichier httpd.conf, en prenant bien soin placer celui correspondant à ResourceConfig avant celui correspondant à AccessConfig. Si vous utilisez les valeurs par défaut, vous devez les inclure explicitement dans les fichiers conf/srm.conf et conf/access.conf.

10.2.2. Configuration du serveur principal

La section de la configuration du serveur principal du fichier de configuration installe le serveur principal, ce qui répond à toute requête non-traitée par une définition <VirtualHost>. Des valeurs par défaut sont aussi fournies ici pour tous les fichiers conteneurs <VirtualHost> définis.

Les directives utilisées dans cette section ont été légèrement modifiées entre Serveur HTTP Apache 1.3 et la version 2.0. Si la configuration de votre serveur principal est très personnalisée, vous trouverez peut-être plus simple de modifier votre configuration existante pour l'adapter à Serveur HTTP Apache 2.0. Les utilisateurs ayant une configuration peu personnalisée devront transférer leurs changements vers la configuration par défaut 2.0.

10.2.2.1. Mappage du fichier UserDir

La directive UserDir est utilisée pour permettre à des URL telles que http://example.com/~bob/ de se mapper dans un sous-répertoire, dans le répertoire courant de l'utilisateur bob, comme par exemple /home/bob/public_html. Cette particularité permettant à un éventuel agresseur de déterminer si un nom d'utilisateur donné est présent sur le système, la configuration par défaut pour Serveur HTTP Apache 2.0 désactive cette directive.

Pour activer le mappage de UserDir, changez la directive dans le fichier httpd.conf de:

UserDir disable

en ce qui suit:

UserDir public_html

Pour plus d'informations sur le sujet, reportez-vous à la documentation suivante sur le site Web d'Apache Software Foundation à l'adresse http://httpd.apache.org/docs-2.0/mod/mod_userdir.html#userdir.

10.2.2.2. Journalisation

Les directives de journalisation suivantes ont été supprimées:

  • AgentLog

  • RefererLog

  • RefererIgnore

Cependant, les journaux Agent et Referrer sont encore disponibles en utilisant les directives CustomLog et LogFormat.

Pour plus d'informations sur le sujet, reportez-vous à la documentation suivante sur le site Web d'Apache Software Foundation:

10.2.2.3. Indexation des répertoires

La directive désapprouvée FancyIndexing est désormais supprimée. La même fonctionnalité est disponible par le biais de l'option FancyIndexing à l'intérieur de la directive IndexOptions.

La nouvelle option VersionSort à la directive IndexOptions engendre le classement des fichiers contenant des numéros de version dans un ordre plus naturel. Par exemple, httpd-2.0.6.tar apparaît avant httpd-2.0.36.tar dans une page d'index de répertoires.

Les paramètres par défaut pour les directives ReadmeName et HeaderName ont été transférés des fichiers README et HEADER vers les fichiers README.html et HEADER.html.

Pour plus d'informations sur le sujet, reportez-vous à la documentation suivante sur le site Web d'Apache Software Foundation:

10.2.2.4. Négociation du contenu

La directive CacheNegotiatedDocs retient désormais les critères on ou off. Les cas existants de CacheNegotiatedDocs devront être remplacés par CacheNegotiatedDocs on.

Pour plus d'informations sur le sujet, reportez-vous à la documentation suivante sur le site Web d'Apache Software Foundation:

10.2.2.5. Documents d'erreur

Afin de pouvoir utiliser un message codé en dur avec la directive ErrorDocument, le message devrait apparaître entre guillemets (["]), plutôt que d'être seulement précédé par des guillemets, comme c'était Serveur HTTP Apache 1.3.

Pour transférer un paramètre ErrorDocument vers Serveur HTTP Apache 2.0, utilisez la structure suivante:

ErrorDocument 404 "The document was not found"

Notez bien la présence des guillemets à la fin de l'exemple de directive ErrorDocument ci-dessus.

Pour plus d'informations sur le sujet, reportez-vous à la documentation suivante sur le site Web d'Apache Software Foundation:

10.2.3. Configuration des hôtes virtuels

Le contenu de tous les répertoires <VirtualHost> devraient être migrés de la même manière que la section du serveur principal, comme cela est décrit à la Section 10.2.2 Configuration du serveur principal.

ImportantImportant
 

Notez que la configuration d'un hôte virtuel SSL/TLS a été supprimée du fichier de configuration du serveur principal et ajoutée dans le fichier /etc/httpd/conf.d/ssl.conf.

Pour plus d'informations sur le sujet, reportez-vous au chapitre intitulé Configuration du serveur sécurisé HTTP Apache du Guide de personnalisation de Red Hat Linux et à la documentation en ligne disponible à l'adresse:

10.2.4. Modules et Serveur HTTP Apache 2.0

Dans Serveur HTTP Apache 2.0, le système des modules a été modifié afin de permettre aux modules d'être liés ensemble ou combinés de façons nouvelles et intéressantes. Les scripts 'Common Gateway Interface' (CGI), par exemple, sont capables de générer des documents HTML analysés par le serveur qui peuvent ensuite être traités par mod_include. Grâce à ceci, il existe désormais un très grand nombre de possibilités quant à la façon dont les modules peuvent être combinés pour atteindre un objectif spécifique.

Cette opération est possible car chaque requête est servie par un seul module 'handler', suivi d'aucun ou de plusieurs modules filter.

Sous Serveur HTTP Apache 1.3, par exemple, un script PHP sera traité dans son intégralité par le module PHP. Sous Serveur HTTP Apache 2.0, en revanche, la requête est initialement traitée par le module mémoire ('core') — qui sert des fichiers statiques — et est ensuite filtré par le module PHP.

L'explication exacte de l'utilisation de cette fonction particulière et de toutes les autres nouvelles fonctions de Serveur HTTP Apache 2.0, va bien au-delà de la portée de ce document; toutefois, la conversion a des ramifications non-négligeables si vous avez utilisé la directive PATH_INFO pour un document traité par un module qui est désormais traité comme un filtre car chaque directive contient des informations de chemin non significatives après le vrai nom de fichier. Le module mémoire, qui traite initialement la requête, ne comprend pas par défaut PATH_INFO et renverra des erreurs de types 404 Not Found pour les requêtes qui contiennent de telles information. Vous pouvez également utiliser la directive AcceptPathInfo pour obliger le module mémoire à accepter les requêtes contenant PATH_INFO.

Ci-dessous figure un exemple de cette directive:

AcceptPathInfo on

Pour plus d'informations sur le sujet, reportez-vous à la documentation suivante sur le site Web d'Apache Software Foundation:

10.2.4.1. Module mod_ssl

La configuration de mod_ssl a été transférée du fichier httpd.conf au fichier /etc/httpd/conf.d/ssl.conf. Pour que ce dernier soit chargé et permette ainsi à mod_ssl de fonctionner correctement, la déclaration Include conf.d/*.conf doit figurer dans le fichier httpd.conf, comme le décrit la Section 10.2.1.3 Prise en charge de DSO ('Dynamic Shared Object').

Dans les hôtes virtuels, les directives ServerName doivent explicitement spécifier le numéro de port.

Ci-dessous figure un exemple de la directive Serveur HTTP Apache 1.3:

<VirtualHost _default_:443>
    # General setup for the virtual host
    ServerName ssl.example.name
    ...
</VirtualHost>

Pour transférer ce paramètre vers Serveur HTTP Apache 2.0, utilisez la structure suivante:

<VirtualHost _default_:443>
    # General setup for the virtual host
    ServerName ssl.host.name:443
    ...
</VirtualHost>

Pour plus d'informations sur le sujet, reportez-vous à la documentation suivante sur le site Web d'Apache Software Foundation:

10.2.4.2. Module mod_proxy

Les instructions de contrôle d'accès proxy sont maintenant placées dans un bloc <Proxy> plutôt que dans un répertoire <Directory proxy:>.

La fonctionnalité de stockage temporaire de l'ancien mod_proxy a été divisée dans les trois modules suivants:

  • mod_cache

  • mod_disk_cache

  • mod_file_cache

Ceux-ci utilisent généralement les mêmes directives ou des directives similaires aux versions plus anciennes du module mod_proxy.

Pour plus d'informations sur le sujet, reportez-vous à la documentation suivante sur le site Web d'Apache Software Foundation:

10.2.4.3. Module mod_include

Le module mod_include fonctionne désormais comme un filtre et, pour cette raison, est activé d'une façon différente. Reportez-vous à Section 10.2.4 Modules et Serveur HTTP Apache 2.0 pour obtenir de plus amples informations sur les filtres.

Ci-dessous figure un exemple de la directive Serveur HTTP Apache 1.3:

AddType text/html .shtml
AddHandler server-parsed .shtml

Pour transférer ce paramètre vers Serveur HTTP Apache 2.0, utilisez la structure suivante:

AddType text/html .shtml
AddOutputFilter INCLUDES .shtml

Notez que, comme auparavant, la directive Options +Includes est toujours nécessaire pour la section <Directory>, répertoire-conteneur, ou dans un fichier .htaccess.

Pour plus d'informations sur le sujet, reportez-vous à la documentation suivante sur le site Web d'Apache Software Foundation:

10.2.4.4. Modules mod_auth_dbm et mod_auth_db

Serveur HTTP Apache 1.3 prenait en charge deux modules d'authentification, à savoir, mod_auth_db et mod_auth_dbm, qui utilisaient respectivement les bases de données Berkeley et DBM. Ces modules ont été rassemblés dans un seul module nommé mod_auth_dbm dans Serveur HTTP Apache 2.0, pouvant accéder à plusieurs formats de base de données différents. Pour migrer à partir du fichier mod_auth_db, fichiers de configuration devront être adaptés en remplaçant AuthDBUserFile et AuthDBGroupFile par les équivalents de mod_auth_dbm: AuthDBMUserFile et AuthDBMGroupFile. La directive AuthDBMType DB doit également être ajoutée pour préciser le type de de fichier de base de données utilisé.

Ci-dessous figure un exemple de la configuration mod_auth_db pour Serveur HTTP Apache 1.3:

<Location /private/>
  AuthType Basic
  AuthName "My Private Files"
  AuthDBUserFile /var/www/authdb
  require valid-user
</Location>

Pour transférer ce paramètre vers la version 2.0 d'Serveur HTTP Apache, utilisez la structure suivante:

<Location /private/>
  AuthType Basic
  AuthName "My Private Files"
  AuthDBMUserFile /var/www/authdb
  AuthDBMType DB
  require valid-user
</Location>

Notez que la directive AuthDBMUserFile peut également être utilisée dans des fichiers .htaccess.

Dans Serveur HTTP Apache 2.0, le script Perl dbmmanage utilisé pour manipuler des bases de données avec nom d'utilisateur et mot de passe, a été remplacé par htdbm. Le programme htdbm offre des fonctionnalités équivalentes et, tout comme le module mod_auth_dbm peut exploiter une grande variété de formats de bases de données; l'option -T peut être utilisée sur la ligne de commande pour spécifier le format à utiliser.

Table 10-1 montre comment migrer d'un format de base de données DBM vers htdbm, un format utilisant dbmmanage.

ActionCommande dbmmanage (1.3)Équivalent de la commande htdbm (2.0)
Ajoute l'utilisateur à la base de données (en utilisant le mot de passe donné)dbmmanage authdb add username passwordhtdbm -b -TDB authdb username password
Ajoute l'utilisateur à la base de données (invite à fournir le mot de passe)dbmmanage authdb adduser usernamehtdbm -TDB authdb username
Retire l'utilisateur de la base de donnéesdbmmanage authdb delete usernamehtdbm -x -TDB authdb username
Répertorie les utilisateur s dans la base de donnéesdbmmanage authdb viewhtdbm -l -TDB authdb
Vérifie un mot de passedbmmanage authdb check usernamehtdbm -v -TDB authdb username

Table 10-1. Migration de dbmmanage vers htdbm

Les options -m et -s fonctionnent avec dbmmanage et htdbm, permettant d'utiliser les algorithmes MD5 ou SHA1 respectivement, pour hacher des mots de passe.

Quand vous créez une nouvelle base de données avec htdbm, l'option -c doit être utilisée.

Pour plus d'informations sur le sujet, reportez-vous à la documentation suivante sur le site Web d'Apache Software Foundation:

10.2.4.5. Module mod_perl Module

La configuration du module mod_perl a été transférée du fichier httpd.conf vers le fichier /etc/httpd/conf.d/perl.conf. Pour que ce fichier soit chargé et permette ainsi à mod_perl de fonctionner correctement, la déclaration Include conf.d/*.conf doit figurer dans le fichier httpd.conf, comme le décrit la Section 10.2.1.3 Prise en charge de DSO ('Dynamic Shared Object').

Les occurrences de Apache:: contenues dans votre fichier httpd.conf doivent être remplacées par ModPerl::. En outre, la façon dont les pilotes ('handlers') sont enregistrés a été modifiée.

Ci-dessous figure un exemple de la configuration Serveur HTTP Apache 1.3 pour le module mod_perl:

<Directory /var/www/perl>
    SetHandler perl-script
    PerlHandler Apache::Registry
    Options +ExecCGI
</Directory>

Ci-après se trouve l'équivalent pour le module mod_perl sous Serveur HTTP Apache 2.0:

<Directory /var/www/perl>
    SetHandler perl-script
    PerlModule ModPerl::Registry
    PerlHandler ModPerl::Registry::handler
    Options +ExecCGI
</Directory>

La plupart des modules pour mod_perl 1.x devraient fonctionner sans modification avec mod_perl 2.x. Les modules XS doivent être recompilés et des modifications mineures de Makefile seront peut-être également nécessaires.

10.2.4.6. Module mod_python

La configuration du module mod_python a été transférée du fichier httpd.conf vers le fichier /etc/httpd/conf.d/python.conf. Pour que ce dernier soit chargé et permette ainsi à mod_python de fonctionner correctement, la déclaration Include conf.d/*.conf doit figurer dans le fichier httpd.conf comme le décrit la Section 10.2.1.3 Prise en charge de DSO ('Dynamic Shared Object').

10.2.4.7. PHP

La configuration de PHP a été transférée du fichier httpd.conf vers le fichier /etc/httpd/conf.d/php.conf. Pour que celui-ci soit chargé, la déclaration Include conf.d/*.conf doit figurer dans le fichier httpd.conf, comme le décrit la Section 10.2.1.3 Prise en charge de DSO ('Dynamic Shared Object').

PHP fonctionne désormais comme un filtre et doit, par conséquent, être activé d'une manière différente. Reportez-vous à la Section 10.2.4 Modules et Serveur HTTP Apache 2.0 pour plus d'informations sur les filtres.

Sous Serveur HTTP Apache 1.3, PHP était exécuté en utilisant les directives suivantes:

AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps

Sous Serveur HTTP Apache 2.0, utilisez plutôt les directives suivantes:

<Files *.php>
    SetOutputFilter PHP
    SetInputFilter PHP
</Files>

Dans PHP 4.2.0 et les versions postérieures, l'ensemble des variables prédéfinies par défaut et ayant généralement une portée globale a changé. L'entrée individuelle et les variables serveur ne sont plus directement placées par défaut dans la portée globale. Ce changement risque d'interrompre les scripts. Vous devrez peut-être revenir à l'ancien comportement en réglant register_globals sur On dans le fichier /etc/php.ini.

Pour plus d'informations sur le sujet et pour obtenir des détails sur les changements au niveau de la portée globale, reportez-vous à l'adresse suivante: