10.2. Migration des fichiers de configuration du Serveur HTTP Apache version 1.3
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.
Si le fichier /etc/httpd/conf/httpd.conf est une version modifiée de la version par défaut nouvellement installée et qu'une copie sauvegardée du fichier original est disponible, il sera peut-être plus simple d'invoquer la commande diff comme dans l'exemple suivant (en étant connecté en tant que super-utilisateur) :
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 devrez 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 <version-number> par le numéro de version du paquetage apache.
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 :
apachectl configtest |
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 :
|
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 http://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 :
UserDir disable |
à :
UserDir public_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.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 (
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.3. Configuration des hôtes virtuels
Le contenu de tous les répertoires <VirtualHost> devrait être migré de la même manière que celle utilisée pour la section du serveur principal reportez-vous à la Section 10.2.2 pour obtenir des instructions sur le sujet..
| Important |
|---|---|
Notez que la configuration d'un hôte virtuel SSL/TLS a été supprimée du fichier de configuration du serveur principal pour être ajoutée dans le fichier /etc/httpd/conf.d/ssl.conf. |
Pour obtenir de plus d'informations sur le sujet, reportez-vous au chapitre intitulé Configuration du serveur sécurisé HTTP Apache du Guide d'administration système de Red Hat Enterprise Linux et à la documentation en ligne disponible à l'adresse suivante :
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 :
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 à :
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 : http://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).