Cette section pr�sente la migration d'un fichier de configuration du Serveur HTTP Apache version 1.3 en vue d'une utilisation par le Serveur HTTP Apache 2.0.
Lors d'une mise � niveau de la version 2.1 de Red Hat Enterprise Linux � Red Hat Enterprise Linux 4 il est important de noter que le nouveau fichier de configuration pour le paquetage du Serveur HTTP Apache 2.0 sera install� sous /etc/httpd/conf/httpd.conf.rpmnew et que la version originale 1.3 httpd.conf ne sera pas modifi�e. Bien s�r, il vous appartient enti�rement de choisir entre l'utilisation du nouveau fichier de configuration vers lequels les anciens param�tres seront migr�s et l'utilisation du fichier existant comme base et d'y apporter des modifications pour qu'il refl�te 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.
Cette commande soulignera toutes les modifications apport�es. Si une copie du fichier original n'est pas disponible, vous devrez l'extraire du paquetage RPM en utilisant les commandes rpm2cpio et cpio, comme dans l'exemple suivant�:
Enfin, il est utile de savoir que le Serveur HTTP Apache dispose d'un mode test qui permet de trouver les erreurs de configuration. Pour y acc�der, saisissez la commande suivante�:
10.2.1. Configuration de l'environnement global
La section intitul�e Environnement global (Global Environment) du fichier de configuration contient des directives qui modifient tout le fonctionnement du Serveur HTTP Apache, comme par exemple, le nombre de requ�tes simultan�es qu'il peut traiter et les emplacements des divers fichiers. Cette section n�cessite un grand nombre de changements et doit �tre bas�e sur le fichier de configuration du Serveur HTTP Apache version 2.0 vers lequel tous les anciens param�tres devront �tre migr�s.
10.2.1.1. Liaison des interfaces et des ports
Les directives BindAddress et Port n'existent plus�; leur fonctionnalit� est d�sormais fournie par une directive plus flexible nomm�e Listen.
Si Port 80 figurant dans les paramtres du fichier de configuration version 1.3, il est n�cessaire de le remplacer par Listen 80 dans le fichier de configuration version 2.0. Si Port avait une valeur autre que 80, il est n�cessaire d'ajouter le num�ro du port au contenu de la directive ServerName.
L'extrait ci-dessous repr�sente un exemple de directive du Serveur HTTP Apache version 1.3�:
Port 123
ServerName www.example.com |
Pour transf�rer ce param�tre vers le Serveur HTTP Apache 2.0, utilisez la structure suivante�:
Listen 123
ServerName www.example.com:123 |
Pour obtenir davantage d'informations sur le sujet, reportez-vous � la documentation de l'organisation Apache Software Foundation disponible sur le site Web �:
10.2.1.2. R�gulation de la taille de server-pool
Lorsque le Serveur HTTP Apache accepte les requ�tes, il envoie des processus enfants ou des threads pour les traiter. Ce groupe de processus enfants ou de threads (aussi appel�s fils) est appel� un server-pool (groupe de serveurs). Avec la version 2.0 du Serveur HTTP Apache, la responsabilit� de la cr�ation et de la maintenance de ces groupes d�pendait d'un groupe de modules appel�s Modules multitache (ou MPM, de l'anglais Multi-Processing Modules). Contrairement � d'autres modules, seul un module du groupe MPM peut �tre charg� par le Serveur HTTP Apache. Trois modules MPM sont inclus dans la version 2.0, � savoir, prefork, worker et perchild. Seuls les MPM prefork et worker sont actuellement disponibles, mais il se peut que le MPM perchild soit disponible dans le futur.
Le comportement original du Serveur HTTP Apache 1.3 a �t� d�plac� dans le MPM prefork. Ce dernier accepte les m�mes directives que le Serveur HTTP Apache version 1.3, il est donc possible de migrrer les directives suivantes�:
StartServers
MinSpareServers
MaxSpareServers
MaxClients
MaxRequestsPerChild
Le MPM worker impl�mente un serveur multit�che, multiprocessus offrant une modulabilit� plus importante. Lors de l'utiliseation de ce MPM, les requ�tes sont manipul�es par des threads (ou fils) �conomisant donc les ressources syst�me et permettant ainsi � un grand nombres de requ�tes d'�tre servi de fa�on efficace. Bien que certaines directives accept�es par le MPM worker soient les m�mes que celles accept�es par le MPM prefork, les valeurs de ces directives ne devraient pas �tre transf�r�es directement depuis une installation de Serveur HTTP Apache 1.3. Il vaut mieux utiliser les valeurs par d�faut comme des recommandations g�n�rale et d'exp�rimenter ensuite afin de d�terminer les valeurs qui fonctionnent le mieux dans votre situation particuli�re.
 | Important |
|---|
| | Pour utiliser le MPM worker, cr�ez le fichier /etc/sysconfig/httpd et ajoutez-y la directive suivante�: HTTPD=/usr/sbin/httpd.worker |
|
Pour obtenir davantage d'informations sur le sujet, reportez-vous � la documentation de l'organisation Apache Software Foundation disponible sur le site Web �:
10.2.1.3. Prise en charge de DSO (Dynamic Shared Object)
Un grand nombre de changements �tant n�cessaire ici, il est vivement recommand� � toute personne essayant de modifier une configuration du Serveur HTTP Apache version 1.3 pour l'adapter � la version 2.0 (au lieu de migrer les changements vers la configuration version 2.0) de copier cette section du fichier de configuration Serveur HTTP Apache 2.0.
Les utilisateurs ne souhaitant pas copier la section de la configuration du Serveur HTTP Apache version 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 du 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 de LoadModule n'est d�sormais plus important dans la plupart des cas.
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 autres) ne sont plus n�cessaires puisqu'elles se trouvent dans leur fichier propre inclus dans le r�pertoire /etc/httpd/conf.d/.
Les diverses d�finitions HAVE_XXX ne sont plus d�finies.
| Important |
|---|
| | Lors de la modification du fichier original, notez que le fichier httpd.conf doit absolument contenir la directive suivante�: 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 li�s � l'environnement global
Les directives suivantes ont �t� supprim�es de la configuration du Serveur HTTP Apache 2.0�:
ServerType — Le 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 d�finies, il est n�cessaire de les remplacer par des directives Include.
Pour obtenir l'assurance que les fichiers seront lus dans l'ordre d�sign� par les anciennes directives, il est n�cessaire de placer les directives Include � la fin du fichier httpd.conf, en prenant bien soin de placer celle correspondant � ResourceConfig avant celle correspondant � AccessConfig. Si les valeurs par d�faut sont utilis�es, elles doivent �tre incluses explicitement dans les fichiers conf/srm.conf et conf/access.conf.
10.2.2. Configuration du serveur principal
La section relative � la configuration du serveur principal du fichier de configuration installe le serveur principal qui r�pond � toute les requ�tes non-trait�es par un h�te virtuel d�finit dans un conteneur <VirtualHost>. Des valeurs sp�cifi�es ici offrent aussi des valeurs par d�faut pour tous les fichiers conteneurs <VirtualHost> d�finis.
Les directives utilis�es dans cette section ont �t� l�g�rement modifi�es entre la version 1.3 du Serveur HTTP Apache et la version 2.0. Si la configuration du serveur principal a un niveau �lev� personnalisation, il sera peut-�tre plus simple de modifier le fichier de configuration existant pour l'adapter au Serveur HTTP Apache 2.0. Les utilisateurs ayant une configuration peu personnalis�e devraient migrer leurs changements vers la configuration 2.0 par d�faut.
10.2.2.1. Mappage de UserDir
La directive UserDir est utilis�e pour permettre � des URL telles que https://example.com/~bob/ de se mapper � un sous-r�pertoire au sein du r�pertoire personnel 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 le Serveur HTTP Apache 2.0 d�sactive cette directive.
Pour activer le mappage de UserDir, changez la directive figurant dans le fichier httpd.conf de�:
�:
Pour obtenir davantage d'informations sur le sujet, reportez-vous � la documentation de l'organisation Apache Software Foundation disponible sur le site Web �:
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 obtenir davantage d'informations sur le sujet, reportez-vous � la documentation de l'organisation Apache Software Foundation disponible sur le site Web �:
10.2.2.3. Indexation des r�pertoires
La directive FancyIndexing �tant d�sormais obsol�te a �t� supprim�e. Cette m�me fonctionnalit� est toutefois encore disponible par le biais de l'option FancyIndexing � l'int�rieur de la directive IndexOptions.
La nouvelle option VersionSort appliqu�e � la directive IndexOptions permet de classer dans un ordre plus naturel les fichiers contenant des num�ros de version. 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 obtenir davantage d'informations sur le sujet, reportez-vous � la documentation de l'organisation Apache Software Foundation disponible sur le site Web �:
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 obtenir davantage d'informations sur le sujet, reportez-vous � la documentation de l'organisation Apache Software Foundation disponible sur le site Web �:
10.2.2.5. Documents d'erreur
Afin de pouvoir utiliser un message cod� en dur avec la directive ErrorDocument, le message doit appara�tre entre guillemets (["]), plut�t que d'�tre seulement pr�c�d� par des guillemets, comme c'�tait la cas avec le Serveur HTTP Apache 1.3.
L'extrait ci-dessous repr�sente un exemple de directive du Serveur HTTP Apache version 1.3�:
ErrorDocument 404 "The document was not found |
Pour transf�rer un param�tre ErrorDocument vers le 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 reproduit ci-dessus.
Pour obtenir davantage d'informations sur le sujet, reportez-vous � la documentation de l'organisation Apache Software Foundation disponible sur le site Web �:
10.2.4. 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 permettre aux modules d'�tre d�sormais li�s ensemble ou combin�s de plusieurs mani�res diff�rentes. Les scripts CGI(de l'anglais Common Gateway Interface) 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 � 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 module handler, suivi d'aucun ou de plusieurs modules filter.
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 initialement trait�e par le module principal— qui sert des fichiers statiques — et est ensuite filtr�e par mod_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 directive PATH_INFO pour un document trait� par un module qui est d�sormais trait� comme un filtre �tant donn� que chaque directive 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�faut PATH_INFO et renverra des erreurs de types 404 Not Found pour les requ�tes qui contiennent de telles informations. 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�:
Pour obtenir davantage d'informations sur le sujet, reportez-vous � la documentation de l'organisation Apache Software Foundation disponible sur le site Web �:
10.2.4.1. Module suexec
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 directives User et Group peuvent 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. 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 que mod_ssl puisse fonctionner, la d�claration Include conf.d/*.conf doit figurer dans le fichier httpd.conf, comme l'explique la Section 10.2.1.3.
Les directives ServerName dans 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 directives SSLLog et SSLLogLevel ont �t� supprim�es. Le module mod_ssl ob�it d�sormais aux directives ErrorLog et LogLevel. 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 �:
10.2.4.3. Module mod_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'ancien mod_proxy a �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 �:
10.2.4.4. Module mod_include
Le module mod_include fonctionnant 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 directive Options +Includes est 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 �:
10.2.4.5. Modules mod_auth_dbm et mod_auth_db
Le 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 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 fichier mod_auth_db, il est n�cessaire de modifier les fichiers de configuration en rempla�ant AuthDBUserFile et AuthDBGroupFile par les �quivalents de mod_auth_dbm � savoir AuthDBMUserFile et AuthDBMGroupFile. Il est �galement n�cessaire d'ajouter la directive AuthDBMType DBpour pr�ciser le type de fichier de base de donn�es utilis�.
Ci-dessous figure un exemple de configuration mod_auth_db pour 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 directive AuthDBMUserFile peut �galement �tre utilis�e dans des fichiers .htaccess.
Dans la version 2.0 du Serveur HTTP Apache, le script Perl dbmmanage utilis� pour manipuler les bases de donn�es des noms d'utilisateur et mots 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.
Le Tableau 10-1 montre comment migrer d'un format de base de donn�es DBM vers htdbm en utilisant dbmmanage.
| 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 |
| V�rifie un mot de passe | dbmmanage authdb check username | htdbm -v -TDB authdb username |
Tableau 10-1. Migration de dbmmanage vers htdbm
Les options -m et -s fonctionnant avec dbmmanage et htdbm, 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 avec htdbm, 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 �:
10.2.4.6. Module mod_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_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.
Les occurrences de Apache:: contenues dans votre fichier httpd.conf doivent �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 module mod_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 pour mod_perl 1.x devraient fonctionner sans modification, avec mod_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. Module mod_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_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.
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/*.conf doit figurer dans le fichier httpd.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�glant register_globals sur On 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�:
10.2.4.9. Module mod_authz_ldap
Red Hat Enterprise Linux est fournit avec le module mod_authz_ldap pour 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 module mod_ssl est n�cessaire lorsque le module mod_authz_ldap est utilis�.
| Important |
|---|
| | Le module mod_authz_ldap n'effectue pas l'authentification d'un utilisateur par rapport � un r�pertoire LDAP au moyen d'un hachage de mots de passe crypt�s. Cette fonctionnalit� est fournie par le module exp�rimental mod_auth_ldap qui 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�: https://www.apache.org/. |
Le fichier /etc/httpd/conf.d/authz_ldap.conf configure le module mod_authz_ldap.
Pour obtenir de plus amples informations sur la configuration du module tiers mod_authz_ldap, reportez-vous au fichier /usr/share/doc/mod_authz_ldap-<version>/index.html (en prenant soin de remplacer <version> par le num�ro de version du paquetage).
