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.