Apache > Serveur HTTP > Documentation > Version 2.4

Mise � jour de la version 2.2 vers la version 2.4

Langues Disponibles:  en  |  fr 

Afin d'assister les utilisateurs lors de leurs op�rations de mise � jour, nous maintenons un document qui comporte des informations critiques � l'attention des personnes qui utilisent d�j� le serveur HTTP Apache. Ces informations ne sont que de br�ves notes, et vous trouverez plus d'informations dans le document Nouvelles fonctionnalit�s, ou dans le fichier src/CHANGES. Les d�veloppeurs d'applications et de modules trouveront un r�sum� des modifications de l'API dans la vue d'ensemble Mises � jour de l'API.

Ce document pr�sente les changements de comportement du serveur qui peuvent n�cessiter une modification de la configuration, et une m�thode pour utiliser la version 2.4 du serveur en parall�le avec la version 2.2. Pour tirer parti des nouvelles fonctionnalit�s de la version 2.4, reportez-vous au document "Nouvelles fonctionnalit�s".

Ce document ne d�crit que les modifications intervenues entre les versions 2.2 et 2.4. Si vous effectuez une mise � jour depuis la version 2.0, vous devez aussi consulter le document de mise � jour de 2.0 vers 2.2.

Support Apache!

Voir aussi

Modifications des param�tres de compilation

Le processus de compilation est tr�s similaire � celui de la version 2.2. Dans la plupart des cas, vous pourrez utiliser votre ancienne ligne de commande configure (telle qu'elle est enregistr�e dans le fichier build/config.nice situ� dans le r�pertoire de compilation du serveur). Voici certains changements intervenus dans la configuration par d�faut :

Modifications de la configuration � l'ex�cution

Des changements significatifs dans la configuration de l'autorisation, ainsi que quelques changements mineurs, peuvent n�cessiter une mise � jour des fichiers de configuration de la version 2.2 avant de les utiliser sous la version 2.4.

Autorisation

Tout fichier de configuration qui g�re des autorisations devra probablement �tre mis � jour.

Vous devez vous reporter au document Authentification, autorisation et contr�le d'acc�s, et plus particuli�rement � la section Pour aller plus loin qu'une simple autorisation qui explique les nouveaux m�canismes permettant de contr�ler l'ordre dans lequel les directives d'autorisation sont appliqu�es.

Les directives qui contr�lent la mani�re dont les modules d'autorisation r�agissent lorsqu'ils ne reconnaissent pas l'utilisateur authentifi� ont �t� supprim�es : elles comprennent les directives AuthzLDAPAuthoritative, AuthzDBDAuthoritative, AuthzDBMAuthoritative, AuthzGroupFileAuthoritative, AuthzUserAuthoritative et AuthzOwnerAuthoritative. Ces directives ont �t� remplac�es par les directives plus explicites RequireAny, RequireNone, et RequireAll.

Si vous utilisez mod_authz_dbm, vous devez mettre � jour votre configuration en rempla�ant les directives du style Require group ... par des directives du style Require dbm-group ....

Contr�le d'acc�s

Dans la version 2.2, le contr�le d'acc�s bas� sur le nom d'h�te du client, son adresse IP, ou d'autres caract�ristiques de la requ�te �tait assur� via les directives Order, Allow, Deny, et Satisfy.

Dans la version 2.4, ce contr�le d'acc�s est assur�, comme tout contr�le d'autorisation, par le nouveau module mod_authz_host. Bien que le module mod_access_compat soit fourni � des fins de compatibilit� avec les anciennes configurations, les anciennes directives de contr�le d'acc�s devront �tre remplac�es par les nouveaux m�canismes d'authentification.

M�langer anciennes et nouvelles directives

M�langer d'anciennes directives comme Order, Allow ou Deny avec des nouvelles comme Require est techniquement possible mais d�conseill�. En effet, mod_access_compat a �t� con�u pour supporter des configurations ne contenant que des anciennes directives afin de faciliter le passage � la version 2.4. Les exemples ci-dessous vous permettront de vous faire une meilleure id�e des probl�mes qui peuvent survenir.

Voici quelques exemples de contr�le d'acc�s avec l'ancienne et la nouvelle m�thode :

Dans cet exemple, il n'y a pas d'authentification et toutes les requ�tes sont rejet�es :

version 2.2 :

Order deny,allow
Deny from all

version 2.4 :

Require all denied

Dans cet exemple, il n'y a pas d'authentification et toutes les requ�tes sont accept�es :

version 2.2 :

Order allow,deny
Allow from all

version 2.4 :

Require all granted

Dans l'exemple suivant, il n'y a pas d'authentification et tous les h�tes du domaine example.org ont l'autorisation d'acc�s, tous les autres �tant rejet�s :

version 2.2 :

Order Deny,Allow
Deny from all
Allow from example.org

version 2.4 :

Require host example.org

Dans l'exemple suivant, tous les h�tes du domaine example.org ont l'autorisation d'acc�s, tous les autres sont rejet�s :

version 2.2 :

Order Deny,Allow
Deny from all
Allow from example.org

version 2.4 :

Require host example.org

Dans l'exemple suivant, le m�lange d'anciennes et de nouvelles directives produit des r�sultats inattendus.

M�lange d'anciennes et de nouvelles directives : RESULTAT INATTENDU

DocumentRoot "/var/www/html"
<Directory "/">
    AllowOverride None
    Order deny,allow
    Deny from all
</Directory>
<Location "/server-status">
    SetHandler server-status
    Require local
</Location>
access.log - GET /server-status 403 127.0.0.1
error.log - AH01797: client denied by server configuration: /var/www/html/server-status

Pourquoi httpd interdit l'acc�s � server-status alors que la configuration semble l'autoriser ? Parce que dans ce sc�nario de fusion de configuration, les directives de mod_access_compat sont prioritaires par rapport � celles de mod_authz_host.

L'exemple suivant quant � lui produit un r�sultat conforme :

M�lange d'anciennes et de nouvelles directives : RESULTAT CONFORME

DocumentRoot "/var/www/html"
<Directory "/">
    AllowOverride None
    Require all denied
</Directory>
<Location "/server-status">
    SetHandler server-status
    Order deny,allow
    Deny from all
    Allow From 127.0.0.1
</Location>
access.log - GET /server-status 200 127.0.0.1

En conclusion, m�me si une configuration hybride peut fonctionner, essayez de l'�viter lors de la mise � jour : soit conservez les anciennes directives, puis migrez-les vers les nouvelles ult�rieurement, soit effectuez une migration imm�diate de toutes les anciennes directives vers les nouvelles.

Dans de nombreuses configurations avec authentification o� la directive Satisfy �tait d�finie � sa valeur par d�faut ALL, les lignes de configuration qui d�sactivent le contr�le d'acc�s bas� sur l'h�te sont maintenant omises :

Version 2.2 :

Order Deny,Allow
Deny from all
AuthBasicProvider File
AuthUserFile /example.com/conf/users.passwd
AuthName secure
Require valid-user

Version 2.4 :

# Pas besoin de remplacer les directives Order et deny
AuthBasicProvider File
AuthUserFile /example.com/conf/users.passwd
AuthName secure
Require valid-user

Dans les configurations o� l'authentification et le contr�le d'acc�s se combinaient dans un but pr�cis, les directives de contr�le d'acc�s doivent �tre migr�es. Dans l'exemple suivant, les requ�tes qui correspondent aux deux crit�res sont accept�es :

Version 2.2 :

Order allow,deny
Deny from all
# ALL est la valeur par d�faut de Satisfy
Satisfy ALL
Allow from 127.0.0.1
AuthBasicProvider File
AuthUserFile /example.com/conf/users.passwd
AuthName secure
Require valid-user

Version 2.4 :

AuthBasicProvider File
AuthUserFile /example.com/conf/users.passwd
AuthName secure
<RequireAll>
  Require valid-user
  Require ip 127.0.0.1
</RequireAll>

Dans les configurations o� l'authentification et le contr�le d'acc�s se combinaient dans un but pr�cis, les directives de contr�le d'acc�s doivent �tre migr�es. Dans l'exemple suivant, les requ�tes qui correspondent � au moins un crit�re sont accept�es :

Version 2.2 :

Order allow,deny
Deny from all
Satisfy any
Allow from 127.0.0.1
AuthBasicProvider File
AuthUserFile /example.com/conf/users.passwd
AuthName secure
Require valid-user

Version 2.4 :

AuthBasicProvider File
AuthUserFile /example.com/conf/users.passwd
AuthName secure
# Implicite : <RequireAny>
Require valid-user
Require ip 127.0.0.1

Autres changements dans la configuration

D'autres ajustements mineurs peuvent s'av�rer n�cessaires pour certaines configurations particuli�res, comme d�crit ci-dessous.

Changements divers

Modules tiers

Tous les modules tiers doivent �tre recompil�s pour la version 2.4 avant d'�tre charg�s.

De nombreux modules tiers con�us pour la version 2.2 fonctionneront sans changement avec le serveur HTTP Apache version 2.4. Certains n�cessiteront cependant des modifications ; se reporter � la vue d'ensemble Mise � jour de l'API.

Probl�mes de mise � jour courants

Langues Disponibles:  en  |  fr 

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.