Modules et Serveur HTTP Apache 2.0

Dans la version 2.0 du Serveur HTTP Apache, le système de modules a été modifié afin de per-mettre aux modules d’être désormais liés ensemble ou combinés de plusieurs manières différentes.

Les scriptsCGI(de l’anglaisCommon Gateway Interface) par exemple, sont capables de générer des documents HTML analysés par le serveur qui peuvent ensuite être traités parmod_include. Grâce à ce développement, il existe désormais de nombreuses possibilités de combinaison des modules afin d’atteindre un objectif spécifique.

Cette situation est possible car chaque requête est servie par un seul modulehandler, suivi d’aucun ou de plusieurs modulesfilter.

Sous la version 1.3 du Serveur HTTP Apache par exemple, un script Perl serait traité dans son inté-gralité par le module Perl (mod_perl). Sous la version 2.0 du Serveur HTTP Apache, en revanche, la requête est initialementtraitéepar le module principal— qui sert des fichiers statiques — et est ensuitefiltréeparmod_perl.

L’explication exacte de l’utilisation de cette fonction particulière et de toutes les autres nouvelles fonctions du 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 directivePATH_INFOpour un document traité par un module qui est désormais traité comme un filtre étant donné que chaque di-rective contient des informations de chemin peu importantes après le vrai nom de fichier. Le module mémoire, qui traite initialement la requête, ne comprend pas par défautPATH_INFOet renverra des erreurs de types404 Not Foundpour les requêtes qui contiennent de telles informations. Vous pou-vez également utiliser la directiveAcceptPathInfopour obliger le module mémoire à accepter les requêtes contenantPATH_INFO.

Ci-dessous figure un exemple de cette directive : AcceptPathInfo on

Pour obtenir davantage d’informations sur le sujet, reportez-vous à la documentation de l’organisation Apache Software Foundation disponible sur le site Web à :

• http://httpd.apache.org/docs-2.0/mod/core.html#acceptpathinfo

• http://httpd.apache.org/docs-2.0/handler.html

• http://httpd.apache.org/docs-2.0/filter.html 10.2.4.1. Modulesuexec

Dans la version du Serveur HTTP Apache 2.0, le module mod_suexec utilise la directive SuexecUserGroup (plutôt que les directives User et Group) pour la configuration des hôtes virtuels. Les directivesUseretGrouppeuvent toujours être utilisées d’une manière générale mais ne peuvent plus être utilisées pour la configuration des hôtes virtuels.

L’extrait ci-dessous représente un exemple de directive du Serveur HTTP Apache version 1.3 :

â VirtualHost vhost.example.com:80^ã User someone

Group somegroup

â /VirtualHost^ã

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

â VirtualHost vhost.example.com:80^ã SuexecUserGroup someone somegroup

â /VirtualHost^ã

10.2.4.2. Modulemod_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 que mod_ssl puisse fonctionner, la déclaration Include conf.d/*.confdoit figurer dans le fichier httpd.conf, comme l’explique la Section 10.2.1.3.

Les directivesServerNamedans les hôtes virtuels avec SSLdoivent explicitement spécifier le numéro de port.

L’extrait ci-dessous représente un exemple de directive du Serveur HTTP Apache version 1.3 :

â VirtualHost _default_:443^ã

# General setup for the virtual host ServerName ssl.example.name

...

â /VirtualHost^ã

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

â VirtualHost _default_:443^ã

# General setup for the virtual host ServerName ssl.host.name:443 ...

â /VirtualHost^ã

Il est également important de noter que les deux directivesSSLLogetSSLLogLevelont été suppri-mées. Le modulemod_sslobéit désormais aux directivesErrorLogetLogLevel. Reportez-vous à la Section 10.5.35 et à la Section 10.5.36 pour obtenir de plus amples informations sur ces directives.

Pour obtenir davantage d’informations sur le sujet, reportez-vous à la documentation de l’organisation Apache Software Foundation disponible sur le site Web à :

• http://httpd.apache.org/docs-2.0/mod/mod_ssl.html

• http://httpd.apache.org/docs-2.0/vhosts/

10.2.4.3. Modulemod_proxy

Les instructions relatives au contrôle de l’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’ancienmod_proxya été divisée en trois modules, à savoir :

• mod_cache

• mod_disk_cache

• mod_mem_cache

Ceux-ci utilisent généralement des directives similaires aux versions plus anciennes du module mod_proxy. Il est cependant conseillé de vérifier chaque directive avant de migrer tout paramètre de cache.

Pour obtenir davantage d’informations sur le sujet, reportez-vous à la documentation de l’organisation Apache Software Foundation disponible sur le site Web à :

• http://httpd.apache.org/docs-2.0/mod/mod_proxy.html

10.2.4.4. Modulemod_include

Le modulemod_includefonctionnant désormais comme un filtre, il est activé d’une façon différente.

Reportez-vous à la Section 10.2.4 pour obtenir de plus amples informations sur les filtres.

L’extrait ci-dessous représente un exemple de directive du Serveur HTTP Apache version 1.3 : AddType text/html .shtml

AddHandler server-parsed .shtml

Pour transférer ce paramètre vers le Serveur HTTP Apache 2.0, utilisez la structure suivante : AddType text/html .shtml

AddOutputFilter INCLUDES .shtml

Notez que, comme auparavant, la directiveOptions +Includesest toujours nécessaire pour le conteneur^ä Directory^å ou dans un fichier.htaccess.

Pour obtenir davantage d’informations sur le sujet, reportez-vous à la documentation de l’organisation Apache Software Foundation disponible sur le site Web à :

• http://httpd.apache.org/docs-2.0/mod/mod_include.html

10.2.4.5. Modulesmod_auth_dbmetmod_auth_db

Le Serveur HTTP Apache 1.3 prenait en charge deux modules d’authentification, à savoir, mod_auth_dbetmod_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_dbmdans la version 2.0 du Serveur HTTP Apache, pouvant accéder à plusieurs formats de base de données différents.

Pour effectuer une migration depuis le fichiermod_auth_db, il est nécessaire de modifier les fichiers de configuration en remplaçant AuthDBUserFileet AuthDBGroupFile par les équivalents de mod_auth_dbmà savoirAuthDBMUserFileetAuthDBMGroupFile. Il est également nécessaire d’ajouter la directiveAuthDBMType DBpour préciser le type de fichier de base de données utilisé.

Ci-dessous figure un exemple de configurationmod_auth_dbpour le 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 du 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 directiveAuthDBMUserFilepeut également être utilisée dans des fichiers.htaccess. Dans la version 2.0 du Serveur HTTP Apache, le script Perldbmmanageutilisé pour manipuler les bases de données des noms d’utilisateur et mots de passe a été remplacé parhtdbm. Le programme htdbmoffre des fonctionnalités équivalentes et, tout comme le modulemod_auth_dbm, peut exploiter une grande variété de formats de bases de données ; l’option-Tpeut être utilisée sur la ligne de commande pour spécifier le format à utiliser.

Le Tableau 10-1 montre comment migrer d’un format de base de données DBM vershtdbmen utili-santdbmmanage.

Action Commande 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 password

htdbm -b -TDB authdb username password Ajoute l’utilisateur à la base de

données (invite à fournir le mot de passe)

dbmmanage authdb adduser username

htdbm -TDB authdb username

Retire l’utilisateur de la base de

données dbmmanage authdb delete

username

htdbm -x -TDB authdb username

Répertorie les utilisateurs dans

la base de données dbmmanage authdb view htdbm -l -TDB authdb

Action Commande dbmmanage

(1.3) Équivalent de la

commande htdbm (2.0) Vérifie un mot de passe dbmmanage authdb check

username

htdbm -v -TDB authdb username

Tableau 10-1. Migration de^dbmmanagevers^htdbm

Les options-met-sfonctionnant avecdbmmanageethtdbm, il est possible d’utiliser les algorithmes MD5 ou SHA1 respectivement, pour le hachage des mots de passe.

Lors de la création d’une nouvelle base de données avechtdbm, il est nécessaire d’utiliser l’option -c.

Pour obtenir davantage d’informations sur le sujet, reportez-vous à la documentation de l’organisation Apache Software Foundation disponible sur le site Web à :

• http://httpd.apache.org/docs-2.0/mod/mod_auth_dbm.html

10.2.4.6. Modulemod_perl

La configuration du module mod_perl a été transférée du fichier httpd.conf au fichier /etc/httpd/conf.d/perl.conf. Pour que ce fichier soit chargé et permette ainsi àmod_perlde fonctionner correctement, la déclaration Include conf.d/*.confdoit figurer dans le fichier httpd.conf, comme le décrit la Section 10.2.1.3.

Les occurrences deApache::contenues dans votre fichierhttpd.confdoivent être remplacées par ModPerl::. En outre, la façon dont les gestionnaires de signaux (ou handlers) sont enregistrés a été modifiée.

Ci-dessous figure un exemple de la configuration du 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 le modulemod_perléquivalent pour la version 2.0 du Serveur HTTP Apache :

ç Directory /var/www/perl^è SetHandler perl-script

PerlResponseHandler ModPerl::Registry Options +ExecCGI

ç /Directory^è

La plupart des modules pourmod_perl1.x devraient fonctionner sans modification, avecmod_perl 2.x. Les modules XS nécessitent une recompilation et des modifications mineures de Makefile seront peut-être également nécessaires.

10.2.4.7. Modulemod_python

La configuration du module mod_python a été transférée du fichier httpd.conf au fichier /etc/httpd/conf.d/python.conf. Pour que ce dernier soit chargé et permette ainsi à mod_pythonde fonctionner correctement, la déclaration Include conf.d/*.confdoit figurer dans le fichierhttpd.confcomme le décrit la Section 10.2.1.3.

10.2.4.8. PHP

La configuration de PHP a été transférée du fichier httpd.conf au fichier /etc/httpd/conf.d/php.conf. Pour que celui-ci soit chargé, la déclaration Include conf.d/*.confdoit figurer dans le fichierhttpd.conf, comme le décrit la Section 10.2.1.3.

Remarque

Toutes les directives de configuration de PHP utilisées avec le Serveur HTTP Apache 1.3 sont dé-sormais entièrement compatibles, lors de la migration vers le Serveur HTTP Apache 2.0 sur Red Hat Enterprise Linux 4.

Dans PHP 4.2.0 et les versions postérieures, l’ensemble des variables par défaut qui sont prédéfinies et ont généralement une portée globale, a changé. Les variables d’entrée individuelle et les variables de serveur ne sont plus, par défaut, directement placées dans la portée globale. Ce changement risque d’interrompre les scripts. Revenez à l’ancien comportement en réglantregister_globalssurOn dans le fichier/etc/php.ini.

Pour obtenir davantage d’informations sur le sujet et pour obtenir des renseignements détaillés sur les changements au niveau de la portée globale, reportez-vous à l’URL suivante :

• http://www.php.net/release_4_1_0.php

10.2.4.9. Modulemod_authz_ldap

Red Hat Enterprise Linux est fournit avec le module mod_authz_ldappour le Serveur HTTP Apache. Ce module utilise le nom raccourci du nom distinct (ou distinguished name) d’un sujet et de l’émetteur du certificat SSL client afin de déterminer le nom distinct de l’utilisateur au sein d’un répertoire LDAP. Il est également à même d’effectuer les tâches suivantes : autoriser un utilisateur en fonction des attributs de l’entrée du répertoire LDAP de cet utilisateur, déterminer l’accès aux ressources en fonction des privilèges octroyés aux utilisateurs et aux groupes quant à ces ressources et peut également refuser l’accès aux utilisateurs dont le mot de passe a expiré. Le modulemod_ssl est nécessaire lorsque le modulemod_authz_ldapest utilisé.

Important

Le modulemod_authz_ldapn’effectue pas l’authentification d’un utilisateur par rapport à un réper-toire LDAP au moyen d’un hachage de mots de passe cryptés. Cette fonctionnalité est fournie par le module expérimentalmod_auth_ldapqui ne fait pas partie de Red Hat Enterprise Linux. Pour obtenir de plus amples informations sur le statut de ce module, reportez-vous au site Web de l’organisation Apache Software Foundation qui se trouve à l’adresse suivante : http://www.apache.org/.

Le fichier/etc/httpd/conf.d/authz_ldap.confconfigure le modulemod_authz_ldap. Pour obtenir de plus amples informations sur la configuration du module tiersmod_authz_ldap, reportez-vous au fichier/usr/share/doc/mod_authz_ldap-^é version^ê /index.html(en pre-nant soin de remplacer^ë version^ì par le numéro de version du paquetage).

Dans le document Red Hat Enterprise Linux 4. Guide de référence (Page 166-172)