From 36197b5e7414ac805979482c305f24a03d698782 Mon Sep 17 00:00:00 2001 From: André Malo Date: Sat, 30 Dec 2017 19:34:11 +0000 Subject: update transformation git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1819675 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/howto/reverse_proxy.html | 4 + docs/manual/howto/reverse_proxy.html.en | 6 +- docs/manual/howto/reverse_proxy.html.es | 6 +- docs/manual/howto/reverse_proxy.html.fr | 357 +++++ docs/manual/misc/perf-scaling.html | 4 + docs/manual/misc/perf-scaling.html.en | 6 +- docs/manual/misc/perf-scaling.html.es | 6 +- docs/manual/misc/perf-scaling.html.fr | 1649 ++++++++++++++++++++++++ docs/manual/mod/event.html.es | 4 + docs/manual/mod/event.html.fr | 2 + docs/manual/mod/mod_allowhandlers.html.fr | 120 ++ docs/manual/mod/mod_authnz_fcgi.html.fr | 589 +++++++++ docs/manual/mod/mod_brotli.html.fr | 353 +++++ docs/manual/mod/mod_crypto.html.fr | 319 +++++ docs/manual/mod/mod_filter.html.en | 8 +- docs/manual/mod/mod_firehose.html.fr | 316 +++++ docs/manual/mod/mod_http2.html.fr | 1043 +++++++++++++++ docs/manual/mod/mod_journald.html.fr | 148 +++ docs/manual/mod/mod_policy.html.fr | 742 +++++++++++ docs/manual/mod/mod_proxy_hcheck.html.fr | 299 +++++ docs/manual/mod/mod_proxy_http2.html.fr | 154 +++ docs/manual/mod/mod_proxy_wstunnel.html.fr | 157 +++ docs/manual/mod/mod_ssl_ct.html.fr | 672 ++++++++++ docs/manual/mod/mod_syslog.html.fr | 99 ++ docs/manual/mod/mod_systemd.html.fr | 118 ++ docs/manual/mod/mod_version.html.fr | 176 +++ docs/manual/mod/mod_watchdog.html.fr | 108 ++ docs/manual/programs/ctlogconfig.html | 4 + docs/manual/programs/ctlogconfig.html.en | 6 +- docs/manual/programs/ctlogconfig.html.fr | 259 ++++ docs/manual/programs/firehose.html | 4 + docs/manual/programs/firehose.html.en | 6 +- docs/manual/programs/firehose.html.fr | 110 ++ docs/manual/programs/log_server_status.html | 4 + docs/manual/programs/log_server_status.html.en | 6 +- docs/manual/programs/log_server_status.html.fr | 89 ++ docs/manual/programs/other.html | 4 + docs/manual/programs/other.html.en | 2 + docs/manual/programs/other.html.fr | 70 + docs/manual/programs/other.html.ko.euc-kr | 2 + docs/manual/programs/other.html.tr.utf8 | 2 + docs/manual/programs/split-logfile.html | 4 + docs/manual/programs/split-logfile.html.en | 6 +- docs/manual/programs/split-logfile.html.fr | 92 ++ docs/manual/programs/suexec.html | 4 + docs/manual/programs/suexec.html.en | 2 + docs/manual/programs/suexec.html.fr | 96 ++ docs/manual/programs/suexec.html.ko.euc-kr | 2 + docs/manual/programs/suexec.html.tr.utf8 | 2 + docs/manual/sections.html.fr | 10 +- docs/manual/vhosts/mass.html.fr | 12 +- 51 files changed, 8230 insertions(+), 33 deletions(-) create mode 100644 docs/manual/howto/reverse_proxy.html.fr create mode 100644 docs/manual/misc/perf-scaling.html.fr create mode 100644 docs/manual/mod/mod_allowhandlers.html.fr create mode 100644 docs/manual/mod/mod_authnz_fcgi.html.fr create mode 100644 docs/manual/mod/mod_brotli.html.fr create mode 100644 docs/manual/mod/mod_crypto.html.fr create mode 100644 docs/manual/mod/mod_firehose.html.fr create mode 100644 docs/manual/mod/mod_http2.html.fr create mode 100644 docs/manual/mod/mod_journald.html.fr create mode 100644 docs/manual/mod/mod_policy.html.fr create mode 100644 docs/manual/mod/mod_proxy_hcheck.html.fr create mode 100644 docs/manual/mod/mod_proxy_http2.html.fr create mode 100644 docs/manual/mod/mod_proxy_wstunnel.html.fr create mode 100644 docs/manual/mod/mod_ssl_ct.html.fr create mode 100644 docs/manual/mod/mod_syslog.html.fr create mode 100644 docs/manual/mod/mod_systemd.html.fr create mode 100644 docs/manual/mod/mod_version.html.fr create mode 100644 docs/manual/mod/mod_watchdog.html.fr create mode 100644 docs/manual/programs/ctlogconfig.html.fr create mode 100644 docs/manual/programs/firehose.html.fr create mode 100644 docs/manual/programs/log_server_status.html.fr create mode 100644 docs/manual/programs/other.html.fr create mode 100644 docs/manual/programs/split-logfile.html.fr create mode 100644 docs/manual/programs/suexec.html.fr diff --git a/docs/manual/howto/reverse_proxy.html b/docs/manual/howto/reverse_proxy.html index 6f59820f9c..a0d9e9d84d 100644 --- a/docs/manual/howto/reverse_proxy.html +++ b/docs/manual/howto/reverse_proxy.html @@ -7,3 +7,7 @@ Content-type: text/html; charset=ISO-8859-1 URI: reverse_proxy.html.es Content-Language: es Content-type: text/html; charset=ISO-8859-1 + +URI: reverse_proxy.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 diff --git a/docs/manual/howto/reverse_proxy.html.en b/docs/manual/howto/reverse_proxy.html.en index 692e63f605..089367a52b 100644 --- a/docs/manual/howto/reverse_proxy.html.en +++ b/docs/manual/howto/reverse_proxy.html.en @@ -24,7 +24,8 @@ Apache > HTTP Server > Documentation > Version 2.5 > How-To / Tutorials

Reverse Proxy Guide

Available Languages:  en  | - es 

+ es  | + fr 

In addition to being a "basic" web server, and providing static and @@ -306,7 +307,8 @@ ProxyPassReverse "/images/" "balancer://myset/"

Available Languages:  en  | - es 

+ es  | + fr 

top

Comments

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.
+ + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+

Guide de configuration d'un mandataire inverse

+
+

Langues Disponibles:  en  | + es  | + fr 

+
+ +

En plus de ses fonctions de serveur web "basique", à savoir fournir du + contenu statique et dynamique à l'utilisateur, Apache httpd (comme la + plupart des autres serveurs web) peut aussi assurer les fonctions de serveur + mandataire inverse, connu aussi sous le nom de serveur "passerelle".

+ +

Dans un tel scénario, httpd ne génère et n'héberge pas lui-même les + données, le contenu étant en général obtenu à partir d'un ou plusieurs serveurs + d'arrière-plan qui n'ont normalement aucune connexion directe avec le réseau + externe. Lorsque httpd reçoit une requête en provenance d'un client, la + requête proprement dite est mandatée vers un de ces serveurs + d'arrière-plan qui traite la requête, génère le contenu et l'envoie à httpd, + ce dernier générant la véritable réponse HTTP à destination du client.

+ +

De nombreuses raisons peuvent vous motiver à utiliser cette + fonctionnalité, mais elles sont souvent du domaine de la sécurité, de + la haute disponibilité, de la répartition de charge et de + l'authentification/autorisation centralisée. Il est alors indispensable que + l'organisation, la conception et l'architecture de l'infrastructure + d'arrière-plan (les serveurs qui traitent au sens propre les requêtes) soient + isolées et protégées de l'extérieur ; vu du client, le serveur mandataire + inverse est le seul serveur accessible pouvant lui fournir du + contenu.

+ +

Voici un exemple typique d'implémentation de cette fonctionnalité :

+

reverse-proxy-arch

+ +
+ +
top
+
+

Mandataire inverse

+ +
Modules ApparentésDirectives Apparentées
+
top
+
+

Mandatement inverse simple

+ + +

+ La directive ProxyPass permet de + rediriger les requêtes entrantes vers un serveur d'arrière-plan (ou un + cluster de serveurs plus connu sous le nom de groupe + Balancer). Dans cet exemple le plus simple, toutes les + requêtes ("/") sont redirigées vers un serveur d'arrière-plan + unique : +

+ + 
ProxyPass "/"  "http://www.example.com/"
+ + +

+ Pour être sur que cette redirection soit effectuée et que les en-têtes + Location: générés par le serveur d'arrière-plan soient + modifiés pour pointer vers le mandataire inverse, et non vers le serveur + d'arrière-plan, la directive ProxyPassReverse est souvent requise : +

+ + 
ProxyPass "/"  "http://www.example.com/"
+ProxyPassReverse "/"  "http://www.example.com/"
+ + +

Seules des URIs spécifiques peuvent être mandatées, comme le montre + l'exemple suivant :

+ + 
ProxyPass "/images"  "http://www.example.com/"
+ProxyPassReverse "/images"  "http://www.example.com/"
+ + +

Dans l'exemple précédent, si le chemin d'une requête commence par + /images, elle sera redirigée vers le serveur d'arrière-plan + spécifié ; dans le cas contraire, elle sera traitée localement. +

+
top
+
+

Clusters et Balancers

+ + +

+ Utiliser un serveur d'arrière-plan unique n'est cependant pas une solution + idéale car ce dernier peut devenir indisponible ou surchargé, et le + mandatement inverse vers ce serveur ne présente alors plus aucun avantage. + La solution réside dans la définition d'un groupe de serveurs + d'arrière-plan qui vont se partager le traitement des requêtes via un + mécanisme de répartition de charge et de gestion des indisponibilités pris + en charge par le mandataire. Ce groupe de répartition est plus connu sous le nom de + cluster, mais dans la terminologie d'Apache httpd, on utilise + plutôt le terme de balancer. Un balancer se définit en + utilisant les directives <Proxy> et BalancerMember comme suit : +

+ + 
<Proxy balancer://myset>
+    BalancerMember http://www2.example.com:8080
+    BalancerMember http://www3.example.com:8080
+    ProxySet lbmethod=bytraffic
+</Proxy>
+
+ProxyPass "/images/"  "balancer://myset/"
+ProxyPassReverse "/images/"  "balancer://myset/"
+ + +

+ Le protocole balancer:// indique à httpd que l'on souhaite + créer un balancer nommé myset. Ce balancer comporte deux serveurs + d'arrière-plan référencés dans la terminologie httpd sous le nom de + BalancerMembers. Avec cet exemple, toute requête dont le chemin + commence par /images sera mandatée vers un des deux + serveurs d'arrière-plan. La directive ProxySet définit ici pour le balancer + myset un algorithme de + répartition de charge basé sur le trafic entrées/sorties. +

+ +

Remarque

+

+ Les BalancerMembers sont aussi souvent référencés sous le terme + workers. +

+
+ +
top
+
+

Configuration du Balancer et des BalancerMembers

+ + +

+ Vous pouvez configurer de manière détaillée les balancers et + workers via les nombreux paramètres de la directive ProxyPass. Par exemple, si vous souhaitez + que http://www3.example.com:8080 traite avec un facteur 3 le + trafic avec un timeout d'une seconde, utilisez la configuration suivante : +

+ + 
<Proxy balancer://myset>
+    BalancerMember http://www2.example.com:8080
+    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+    ProxySet lbmethod=bytraffic
+</Proxy>
+
+ProxyPass "/images"  "balancer://myset/"
+ProxyPassReverse "/images"  "balancer://myset/"
+ + +
top
+
+

Gestion des indisponibilités (Failover)

+ + +

+ Vous pouvez aussi définir finement des scénarios pour les cas + d'indisponibilité d'un ou plusieurs serveurs d'arrière-plan en spécifiant + quels serveurs doivent alors prendre le relai. Dans l'exemple suivant, + deux scénarios sont envisagés : dans le premier, seul + http://hstandby.example.com:8080 se voit envoyer du trafic si + tous les autres membres du balancer myset sont indisponibles. + Dans le second, si http://hstandby.example.com:8080 est + lui-même indisponible, http://bkup1.example.com:8080 et + http://bkup2.example.com:8080 deviennent les deux seuls + membres du groupe de répartition de charge actifs : +

+ + 
<Proxy balancer://myset>
+    BalancerMember http://www2.example.com:8080
+    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+    BalancerMember http://hstandby.example.com:8080 status=+H
+    BalancerMember http://bkup1.example.com:8080 lbset=1
+    BalancerMember http://bkup2.example.com:8080 lbset=1
+    ProxySet lbmethod=byrequests
+</Proxy>
+
+ProxyPass "/images/"  "balancer://myset/"
+ProxyPassReverse "/images/"  "balancer://myset/"
+ + +

+ Le point central de cet exemple de gestion des indisponibilités est la + configuration du serveur d'arrière-plan + http://hstandby.example.com:8080 avec le drapeau + +H qui le place en mode hot standby, et + l'inscription des deux serveurs bkup# dans le groupe de + répartition de charge avec un niveau 1 (le niveau par défaut étant 0) ; en + effet, les serveurs en mode hot standby, s'il existent, sont + utilisés en premier en cas d'indisponibilité de tous les autres serveurs + d'arrière-plan, et ce sont toujours les serveurs de niveau le plus bas qui + sont utilisés en premier. +

+ +
top
+
+

Gestion du répartiteur de charge

+ + +

+ L'application balancer-manager fournie avec le mandataire inverse + d'Apache httpd en est un des outils les plus utiles. Comme + mod_status, balancer-manager affiche la + configuration et l'activité actuelles des balancers actifs. L'affichage de + ces informations n'est cependant pas sa seule fonction ; il permet aussi de + modifier la plupart d'entre elles et même d'ajouter des membres au groupe + de répartition de charge en temps réel. Pour activer ces fonctionnalités, + vous devez ajouter les lignes suivantes à votre fichier de configuration : +

+ + 
<Location "/balancer-manager">
+    SetHandler balancer-manager
+    Require host localhost
+</Location>
+ + +

Avertissement

+

N'activez le balancer-manager que si vous avez déjà sécurisé votre serveur. + Assurez-vous en particulier que l'accès à l'URL soit fortement restreint.

+
+ +

+ Lorsque vous accédez au serveur mandataire avec une adresse du style + http://rproxy.example.com/balancer-manager/, la page suivante + s'affiche : +

+

balancer-manager page

+ +

+ Ce formulaire permet à l'administrateur de modifier certains paramètres, + de désactiver ou d'ajouter certains serveurs d'arrière-plan, et de + modifier les règles de répartition de charge. Par exemple, si on clique + sur le répartiteur, la page suivante s'affiche : +

+

balancer-manager page

+ +

+ Si on clique sur un membre du groupe de répartition de charge, la page + suivante s'affiche : +

+

balancer-manager page

+ +

+ Si vous souhaitez que ces modifications soient conservées après un + redémarrage du serveur, assurez-vous que la directive BalancerPersist soit définie à On. +

+ +
top
+
+

Vérification dynamique du bon fonctionnement d'un serveur + d'arrière-plan

+ + +

+ Avant que le mandataire httpd ne fasse appel à un serveur d'arrière-plan, il + peut "tester" si ce dernier est disponible en définissant le + paramètre ping de ce serveur via la directive ProxyPass. Cependant, il est souvent plus + judicieux de vérifier le bon fonctionnement d'un serveur hors + bande et de manière dynamique via le module + mod_proxy_hcheck d'Apache httpd. +

+ +
top
+
+

Drapeaux d'état d'un membre du groupe de répartition de charge

+ + +

+ balancer-manager permet d'afficher et de modifier l'état d'un + membre du groupe de répartition de charge. Les différents états et leurs + significations sont les suivants : +

+ + + + + + + + + + + +
DrapeauSigleDescription
 OkLe serveur est disponible
 InitLe serveur a été initialisé
DDisLe serveur est + désactivé et n'accepte aucune requête ; il sera retesté automatiquement.
SStopLe serveur a été + arrêté par l'administrateur ; il n'accepte aucune requête et il ne sera + pas retesté automatiquement.
IIgnLes erreurs + concernant ce serveur sont ignorées et il sera donc toujours considéré + comme disponible.
HStbyLe serveur est en + mode hot-standby et ne sera donc utilisé que si aucun autre serveur + n'est disponible.
EErrLe serveur est en + erreur, en général suite à un test préalable à une requête ; aucune + requête ne lui sera soumise, mais il sera retesté en fonction de la + valeur de son paramètre retry.
NDrnLe serveur est en + mode drain ; il n'acceptera de requêtes que dans le cadre des sessions + persistantes qui lui sont réservées et ignorera toutes les autres.
CHcFlLe serveur a échoué + au test dynamique de bon fonctionnement et ne sera utilisé que lorsqu'il + aura réussi un test ultérieur.
+
+
+

Langues Disponibles:  en  | + es  | + fr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/misc/perf-scaling.html b/docs/manual/misc/perf-scaling.html index 18a3e56d88..b103febd85 100644 --- a/docs/manual/misc/perf-scaling.html +++ b/docs/manual/misc/perf-scaling.html @@ -7,3 +7,7 @@ Content-type: text/html; charset=ISO-8859-1 URI: perf-scaling.html.es Content-Language: es Content-type: text/html; charset=ISO-8859-1 + +URI: perf-scaling.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 diff --git a/docs/manual/misc/perf-scaling.html.en b/docs/manual/misc/perf-scaling.html.en index cfb95c71ff..40c0c57ef4 100644 --- a/docs/manual/misc/perf-scaling.html.en +++ b/docs/manual/misc/perf-scaling.html.en @@ -24,7 +24,8 @@ Apache > HTTP Server > Documentation > Version 2.5 > Miscellaneous Documentation

Performance Scaling

Available Languages:  en  | - es 

+ es  | + fr 

@@ -1448,7 +1449,8 @@ CacheMaxExpire 21600

Available Languages:  en  | - es 

+ es  | + fr 

top

Comments

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.
+ + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+

Amélioration des performances

+
+

Langues Disponibles:  en  | + es  | + fr 

+
+ + +

Il est dit dans la documentation d'Apache 1.3 + à propos de l'amélioration des performances : +

+

+ "Apache est un serveur web à vocation générale, conçu pour + être non seulement efficace mais aussi rapide. Dans sa + configuration de base, ses performances sont déjà + relativement satisfaisantes. La plupart des sites possèdent + une bande passante en sortie inférieure à 10 Mbits que le + serveur Apache peut mettre pleinement à profit en utilisant un serveur à base + de processeur Pentium bas de gamme."

+
+

Cette phrase ayant été écrite il y a plusieurs années, + entre temps de nombreuses choses ont changé. D'une part, les + serveurs sont devenus beaucoup plus rapides. D'autre part, de + nombreux sites se voient maintenant allouée une bande passante + en sortie bien supérieure à 10 Mbits. En outre, les applications + web sont devenues beaucoup plus complexes. Les sites classiques + ne proposant que des pages du style brochure sont toujours + présents, mais le web a souvent évolué vers une plateforme + exécutant des traitements, et les webmasters peuvent maintenant + mettre en ligne des contenus dynamiques en Perl, PHP ou Java, + qui exigent un niveau de performances bien supérieur. +

+

C'est pourquoi en dépit des progrès en matière de bandes passantes + allouées et de rapidité des serveurs, les performances + des serveurs web et des applications web sont toujours un sujet + d'actualité. C'est dans ce cadre que cette documentation s'attache à + présenter de nombreux points concernant les performances des + serveurs web. +

+ +
+ +
top
+
+

Ce qui sera abordé et ce qui ne le sera pas

+ +

Ce document se concentre sur l'amélioration des performances + via des options facilement accessibles, ainsi que sur les outils + de monitoring. Les outils de monitoring vous permettront de + surveiller le fonctionnement de votre serveur web afin de + rassembler des informations à propos de ses performances et des + éventuels problèmes qui s'y rapportent. Nous supposerons + que votre budget n'est pas illimité ; c'est pourquoi les + améliorations apportées le seront sans modifier l'infrastructure + matérielle existante. Vous ne souhaitez probablement pas + compiler vous-même votre serveur Apache, ni recompiler le noyau + de votre système d'exploitation ; nous supposerons cependant que + vous possédez quelques notions à propos du fichier de + configuration du serveur HTTP Apache. +

+ +
top
+
+

Monitoring de votre serveur

+ +

Si vous envisagez de redimensionner ou d'améliorer les performances + de votre serveur, vous devez tout d'abord observer la manière dont il + fonctionne. En observant son fonctionnement en conditions réelles ou + sous une charge créée artificiellement, vous serez en mesure + d'extrapoler son fonctionnement sous une charge accrue, par exemple dans + le cas où il serait mentionné sur Slashdot.

+ + +

Outils de monitoring

+ + +

top +

+ +

L'outil top est fourni avec Linux et FreeBSD. Solaris + quant à lui, fournit prstat(1). Cet outil + permet de rassembler de nombreuses données statistiques + à propos du système et de chaque processus en cours + d'exécution avant de les afficher de manière + interactive sur votre terminal. Les données affichées + sont rafraîchies toutes les secondes et varient en + fonction de la plateforme, mais elles comportent en + général la charge moyenne du système, le nombre de + processus et leur état courant, le pourcentage de temps + CPU(s) passé à exécuter le code système et utilisateur, + et l'état de la mémoire virtuelle système. Les données + affichées pour chaque processus sont en général + configurables et comprennent le nom et l'identifiant du + processus, sa priorité et la valeur définie par nice, + l'empreinte mémoire, et le pourcentage d'utilisation CPU. + L'exemple suivant montre plusieurs processus httpd (avec + les MPM worker et event) s'exécutant sur un système + Linux (Xen) : +

+ + 
top - 23:10:58 up 71 days,  6:14,  4 users,  load average: 0.25, 0.53, 0.47
+Tasks: 163 total,   1 running, 162 sleeping,   0 stopped,   0 zombie
+Cpu(s): 11.6%us,  0.7%sy,  0.0%ni, 87.3%id,  0.4%wa,  0.0%hi,  0.0%si,  0.0%st
+Mem:   2621656k total,  2178684k used,   442972k free,   100500k buffers
+Swap:  4194296k total,   860584k used,  3333712k free,  1157552k cached
+
+  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
+16687 example_  20   0 1200m 547m 179m S   45 21.4   1:09.59 httpd-worker
+15195 www       20   0  441m  33m 2468 S    0  1.3   0:41.41 httpd-worker
+    1 root      20   0 10312  328  308 S    0  0.0   0:33.17 init
+    2 root      15  -5     0    0    0 S    0  0.0   0:00.00 kthreadd
+    3 root      RT  -5     0    0    0 S    0  0.0   0:00.14 migration/0
+    4 root      15  -5     0    0    0 S    0  0.0   0:04.58 ksoftirqd/0
+    5 root      RT  -5     0    0    0 S    0  0.0   4:45.89 watchdog/0
+    6 root      15  -5     0    0    0 S    0  0.0   1:42.52 events/0
+    7 root      15  -5     0    0    0 S    0  0.0   0:00.00 khelper
+   19 root      15  -5     0    0    0 S    0  0.0   0:00.00 xenwatch
+   20 root      15  -5     0    0    0 S    0  0.0   0:00.00 xenbus
+   28 root      RT  -5     0    0    0 S    0  0.0   0:00.14 migration/1
+   29 root      15  -5     0    0    0 S    0  0.0   0:00.20 ksoftirqd/1
+   30 root      RT  -5     0    0    0 S    0  0.0   0:05.96 watchdog/1
+   31 root      15  -5     0    0    0 S    0  0.0   1:18.35 events/1
+   32 root      RT  -5     0    0    0 S    0  0.0   0:00.08 migration/2
+   33 root      15  -5     0    0    0 S    0  0.0   0:00.18 ksoftirqd/2
+   34 root      RT  -5     0    0    0 S    0  0.0   0:06.00 watchdog/2
+   35 root      15  -5     0    0    0 S    0  0.0   1:08.39 events/2
+   36 root      RT  -5     0    0    0 S    0  0.0   0:00.10 migration/3
+   37 root      15  -5     0    0    0 S    0  0.0   0:00.16 ksoftirqd/3
+   38 root      RT  -5     0    0    0 S    0  0.0   0:06.08 watchdog/3
+   39 root      15  -5     0    0    0 S    0  0.0   1:22.81 events/3
+   68 root      15  -5     0    0    0 S    0  0.0   0:06.28 kblockd/0
+   69 root      15  -5     0    0    0 S    0  0.0   0:00.04 kblockd/1
+   70 root      15  -5     0    0    0 S    0  0.0   0:00.04 kblockd/2
+ +

Top est un merveilleux outil, même s'il est + relativement gourmand en ressources (lorsqu'il + s'exécute, son propre processus se trouve en général + dans le top dix des consommations CPU). Il est + indispensable pour déterminer la taille d'un processus + en cours d'exécution, information précieuse lorsque vous + voudrez déterminer combien de processus httpd vous + pourrez exécuter sur votre machine. La méthode pour + effectuer ce calcul est décrite ici : calculer MaxClients. Top + est cependant un outil interactif, et l'exécuter de + manière continu présente peu ou pas d'avantage. +

+ +

free +

+ +

Cette commande n'est disponible que sous Linux. Elle + indique la mémoire vive et l'espace de swap utilisés. + Linux alloue la mémoire inutilisée en tant que cache du + système de fichiers. La commande free montre + l'utilisation de la mémoire avec et sans ce cache. On + peut utiliser la commande free pour déterminer la + quantité de mémoire utilisée par le système, comme + décrit dans le paragraphe calculer MaxClients. + L'affichage de la sortie de la commande free ressemble à + ceci : +

+ + 
sctemme@brutus:~$ free
+              total       used     free   shared    buffers    cached
+Mem:        4026028    3901892   124136         0    253144    841044
+-/+ buffers/cache:     2807704  1218324
+Swap:       3903784      12540  3891244
+ + +

vmstat +

+ +

Cette commande est disponible sur de nombreuses + plateformes de style Unix. Elle affiche un grand nombre + de données système. Lancée sans argument, elle affiche + une ligne d'état pour l'instant actuel. Lorsqu'on lui + ajoute un chiffre, la ligne d'état actuelle est ajoutée à + intervalles réguliers à l'affichage existant. + Par exemple, la commande + vmstat 5 ajoute la ligne d'état actuelle + toutes les 5 secondes. La commande vmstat affiche la + quantité de mémoire virtuelle utilisée, la quantité de + mémoire échangée avec l'espace de swap en entrée et en + sortie à chaque seconde, le nombre de processus + actuellement en cours d'exécution ou inactifs, le nombre + d'interruptions et de changements de contexte par + seconde, et le pourcentage d'utilisation du CPU. +

+

+ Voici la sortie de la commande vmstat + pour un serveur inactif : +

+ + + 
[sctemme@GayDeceiver sctemme]$ vmstat 5 3
+   procs                      memory     swap         io    system        cpu
+ r b w     swpd   free   buff cache si so       bi    bo in     cs us  sy id
+ 0 0 0        0 186252   6688 37516    0    0   12     5 47    311  0   1 99
+ 0 0 0        0 186244   6696 37516    0    0    0    16 41    314  0   0 100
+ 0 0 0        0 186236   6704 37516    0    0    0     9 44    314  0   0 100
+ +

Et voici cette même sortie pour un serveur en charge + de cent connexions simultanées pour du contenu statique : +

+ + 
[sctemme@GayDeceiver sctemme]$ vmstat 5 3
+   procs                      memory     swap    io      system       cpu
+ r b w     swpd   free   buff cache si so     bi bo   in     cs us sy  id
+ 1 0 1        0 162580   6848 40056    0    0 11  5 150     324  1  1  98
+ 6 0 1        0 163280   6856 40248    0    0  0 66 6384 1117   42 25  32
+11 0 0        0 162780   6864 40436    0    0  0 61 6309 1165   33 28  40
+ +

La première ligne indique des valeurs moyennes depuis + le dernier redémarrage. Les lignes suivantes donnent des + informations d'état à intervalles de 5 secondes. Le + second argument demande à vmstat de générer 3 lignes + d'état, puis de s'arrêter. +

+ + +

Boîte à outils SE +

+ +

La boîte à outils SE est une solution de supervision + pour Solaris. Son langage de programmation est basé sur + le préprocesseur C et est fourni avec de nombreux + exemples de scripts. Les informations fournies + peuvent être exploitées en mode console ou en mode + graphique. Cette boîte à outils peut aussi être programmée pour + appliquer des règles aux données système. Avec l'exemple + de script de la Figure 2, Zoom.se, des voyants verts, + oranges ou rouges s'allument lorsque certaines valeurs + du système dépassent un seuil spécifié. Un autre script + fourni, Virtual Adrian, permet d'affiner les + performances en tenant compte de ces valeurs. +

+

Depuis sa création, de nombreux propriétaires se sont + succédés à la tête de la boîte à outils SE, et elle a de + ce fait largement évolué. Il semble qu'elle ait + maintenant trouvé sa place chez Sunfreeware.com d'où + elle peut être téléchargée gratuitement. Il n'y a qu'un + seul paquet pour Solaris 8, 9 et 10 sur SPARC et x86, et + il inclut le code source. Le concepteur de la boîte à + outils SE, Richard Pettit, a fondé une nouvelle sociéte, + Captive Metrics4, et a l'intention de mettre sur le + marché un outil de supervision multiplateforme en Java basé sur + les mêmes principes que la boîte à outils SE. +

+ + + +

DTrace +

+ +

Etant donné que DTrace est disponible sous Solaris, + FreeBSD et OS X, il serait intéressant de l'étudier. Il + y a aussi le module mod_dtrace pour httpd. +

+ + + +

mod_status +

+ +

Le module mod_status donne un aperçu des performances + du serveur à un instant donné. Il génère une page HTML + comportant, entre autres, le nombre de processus Apache + en cours d'exécution avec la quantité de données qu'ils + ont servies, ainsi que la charge CPU induite par httpd + et le reste du système. L'Apache Software Foundation + utilise elle-même mod_status pour son + propre site + web. Si vous ajoutez une directive + ExtendedStatus On à votre fichier + httpd.conf, la page de + mod_status vous fournira d'avantage + d'informations, au prix d'une consommation de ressources + légèrement supérieure par requête. +

+ + + + +

Les journaux du serveur web +

+ +

Le moyen le plus efficace pour vérifier la bonne santé et + le niveau de performance de votre serveur consiste à + surveiller et analyser les journaux écrits par httpd. La + surveillance du journal des erreurs vous permet de + déterminer les sources d'erreurs, de détecter des attaques + ou des problèmes de performance. L'analyse du journal des + accès vous indique le niveau de charge de votre serveur, + quelles sont les ressources les plus populaires, ainsi que + la provenance de vos utilisateurs. Une analyse historique des + données de journalisation peut vous fournir des informations + précieuses quant aux tendances d'utilisation de votre + serveur au cours du temps, ce qui vous permet de prévoir les + périodes où les besoins en performance risquent de dépasser + les capacités du serveur. +

+ + +

Journal des erreurs +

+ +

Le journal des erreurs peut indiquer que le nombre + maximum de processus actifs ou de fichiers ouverts + simultanément a été atteint. Le journal des erreurs + signele aussi le lancement de processus supplémentaires selon un + taux supérieur à la normale en réponse à + une augmentation soudaine de la charge. Lorsque le + serveur démarre, le descripteur de fichier stderr est + redirigé vers le journal des erreurs, si bien que toute + erreur rencontrée par httpd après avoir ouvert ses + fichiers journaux apparaîtra dans ce journal. Consulter + fréquemment le journal des erreurs est donc une bonne + habitude. +

+

Lorsque Apache httpd n'a pas encore ouvert ses + fichiers journaux, tout message d'erreur sera envoyé + vers la sortie d'erreur standard stderr. Si vous + démarrez httpd manuellement, ces messages d'erreur + apparaîtront sur votre terminal, et vous pourrez les + utiliser directement pour résoudre les problèmes de + votre serveur. Si httpd est lancé via un script de + démarrage, la destination de ces messages d'erreur + dépend de leur conception. + /var/log/messages est alors le premier fichier à + consulter. Sous Windows, ces messages d'erreur précoces + sont écrits dans le journal des évènements des + applications, qui peut être visualisé via l'observateur + d'évènements dans les outils d'administration. +

+

+ Le journal des erreurs est configuré via les + directives de configuration ErrorLog et LogLevel. Le journal des + erreurs de la configuration du serveur principal de + httpd reçoit les messages d'erreur concernant + l'ensemble du serveur : démarrage, arrêt, crashes, + lancement de processus supplémentaires excessif, + etc... La directive ErrorLog peut aussi être + utilisée dans les blocs de configuration des + serveurs virtuels. Le journal des erreurs d'un + serveur virtuel ne reçoit que les messages d'erreur + spécifiques à ce serveur virtuel, comme les erreurs + d'authentification et les erreurs du style 'File not + Found'. +

+

Dans le cas d'un serveur accessible depuis Internet, + attendez-vous à voir de nombreuses tentatives + d'exploitation et attaques de vers dans le journal des + erreurs. La plupart d'entre elles ciblent des serveurs + autres qu'Apache, mais dans l'état actuel des choses, + les scripts se contentent d'envoyer leurs attaques vers + tout port ouvert, sans tenir compte du serveur web + effectivement en cours d'exécution ou du type + des applications installées. Vous pouvez bloquer ces + tentatives d'attaque en utilisant un pare-feu ou le + module mod_security, + mais ceci dépasse la portée de cette discussion. +

+

+ La directive LogLevel permet de définir + le niveau de détail des messages enregistrés dans + les journaux. Il existe huit niveaux de + journalisation : +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

Niveau

+ 		+

Description

+
+

emerg

+ 		+

Urgence - le système est inutilisable.

+
+

alert

+ 		+

Une action doit être entreprise + immédiatement.

+
+

crit

+ 		+

Situations critiques.

+
+

error

+ 		+

Situations d'erreur.

+
+

warn

+ 		+

Situations provoquant un avertissement.

+
+

notice

+ 		+

Evènement normal, mais important.

+
+

info

+ 		+

Informations.

+
+

debug

+ 		+

Messages de débogage.

+
+

Le niveau de journalisation par défaut est warn. Un + serveur en production ne doit pas s'exécuter en mode + debug, mais augmenter le niveau de détail dans le + journal des erreurs peut s'avérer utile pour résoudre + certains problèmes. A partir de la + version 2.3.8, la directive LogLevel peut être définie au + niveau de chaque module : +

+ + 
LogLevel debug mod_ssl:warn
+ + +

+ Dans cet exemple, l'ensemble du serveur est en mode + debug, sauf le module mod_ssl + qui a tendance à être très bavard. +

+ + + +

Journal des accès +

+ +

Apache httpd garde la trace de toutes les requêtes + qu'il reçoit dans son journal des accès. En plus de + l'heure et de la nature d'une requête, httpd peut + enregistrer l'adresse IP du client, la date et l'heure + de la requête, le résultat et quantité d'autres + informations. Les différents formats de journaux sont + documentés dans le manuel. Le fichier concerne par + défaut le serveur principal, mais il peut être configuré + pour chaque serveur virtuel via les directives de + configuration TransferLog ou + CustomLog. +

+

De nombreux programmes libres ou commerciaux + permettent d'analyser les journaux d'accès. Analog et + Webalyser sont des programmes d'analyse libres parmi les + plus populaires. L'analyse des journaux doit s'effectuer + hors ligne afin de ne pas surcharger le serveur web avec + le traitement des fichiers journaux. La plupart des + programmes d'analyse des journaux sont compatibles avec le format + de journal "Common". Voici une description des + différents champs présents dans une entrée du journal : +

+ + + 
195.54.228.42 - - [24/Mar/2007:23:05:11 -0400] "GET /sander/feed/ HTTP/1.1" 200 9747
+64.34.165.214 - - [24/Mar/2007:23:10:11 -0400] "GET /sander/feed/atom HTTP/1.1" 200 9068
+60.28.164.72 - - [24/Mar/2007:23:11:41 -0400] "GET / HTTP/1.0" 200 618
+85.140.155.56 - - [24/Mar/2007:23:14:12 -0400] "GET /sander/2006/09/27/44/ HTTP/1.1" 200 14172
+85.140.155.56 - - [24/Mar/2007:23:14:15 -0400] "GET /sander/2006/09/21/gore-tax-pollution/ HTTP/1.1" 200 15147
+74.6.72.187 - - [24/Mar/2007:23:18:11 -0400] "GET /sander/2006/09/27/44/ HTTP/1.0" 200 14172
+74.6.72.229 - - [24/Mar/2007:23:24:22 -0400] "GET /sander/2006/11/21/os-java/ HTTP/1.0" 200 13457
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

Champ

+ 		+

Contenu

+ 		+

Explication

+
+

Adresse IP client

+ 		+

195.54.228.42

+ 		+

Adresse IP d'où provient la requête

+
+

Identité RFC 1413

+ 		+

-

+ 		+

Identité de l'utilisateur distant renvoyée + par son démon identd

+
+

Nom utilisateur

+ 		+

-

+ 		+

Nom de l'utilisateur distant issu de + l'authentification Apache

+
+

Horodatage

+ 		+

[24/Mar/2007:23:05:11 -0400]

+ 		+

Date et heure de la requête

+
+

Requête

+ 		+

"GET /sander/feed/ HTTP/1.1"

+ 		+

La requête proprement dite

+
+

Code d'état

+ 		+

200

+ 		+

Code d'état renvoyé avec la réponse

+
+

Contenu en octets

+ 		+

9747

+ 		+

Total des octets transférés sans les + en-têtes

+
+ + +

Rotation des fichiers journaux +

+ +

Il y a de nombreuses raisons pour mettre en oeuvre la + rotation des fichiers journaux. Même si pratiquement + plus aucun système d'exploitation n'impose une limite de + taille pour les fichiers de deux GigaOctets, avec le + temps, les fichiers journaux deviennent trop gros pour + pouvoir être traités. En outre, toute analyse de journal + ne doit pas être effectuée sur un fichier dans lequel le + serveur est en train d'écrire. Une rotation périodique + des fichiers journaux permet de faciliter leur analyse, + et de se faire une idée plus précise des habitudes + d'utilisation. +

+

Sur les systèmes unix, vous pouvez simplement + effectuer cette rotation en changeant le nom du fichier + journal via la commande mv. Le serveur continuera à + écrire dans le fichier ouvert même s'il a changé de nom. + Lorsque vous enverrez un signal de redémarrage + "Graceful" au serveur, il ouvrira un nouveau fichier + journal avec le nom configuré par défaut. Par exemple, + vous pouvez écrire un script de ce style pour cron : +

+ + +

+ APACHE=/usr/local/apache2
+ HTTPD=$APACHE/bin/httpd
+ mv $APACHE/logs/access_log + $APACHE/logarchive/access_log-`date +%F`
+ $HTTPD -k graceful +

+ +

Cette approche fonctionne aussi sous Windows, mais + avec moins de souplesse. Alors que le processus httpd de + votre serveur sous Windows continuera à écrire dans le + fichier journal une fois ce dernier renommé, le service + Windows qui exécute Apache n'est pas en mesure + d'effectuer un redémarrage graceful. Sous Windows, le + redémarrage d'un service consiste simplement à l'arrêter + et à le démarrer à nouveau, alors qu'avec un redémarrage + graceful, les processus enfants terminent + le traitement des requêtes en cours avant de s'arrêter, + et le serveur httpd est alors immédiatement à + nouveau disponible pour traiter les nouvelles requêtes. + Sous Windows, le processus d'arrêt/redémarrage du + service interrompt les traitements de requêtes en cours, + et le serveur demeure indisponible jusqu'à ce qu'il ait + terminé son redémarrage. Vous devez donc tenir compte de + toutes ces contraintes lorsque vous planifiez un + redémarrage. +

+

+ Une seconde approche consiste à utiliser la + redirection des logs. Les directives CustomLog, + TransferLog ou + ErrorLog + permettent de rediriger les données de journalisation + vers tout programme via le caractère pipe + (|) comme dans cet exemple : +

+ +

CustomLog "|/usr/local/apache2/bin/rotatelogs + /var/log/access_log 86400" common +

+ +

Le programme cible de la redirection recevra alors les + données de journalisation d'Apache sur son entrée + standard stdin, et pourra en faire ce qu'il voudra. Le + programme rotatelogs fourni avec Apache effectue une + rotation des journaux de manière transparente en + fonction du temps ou de la quantité de données écrites, + et archive l'ancien fichier journal en ajoutant un + suffixe d'horodatage à son nom. Cependant, si cette + méthode fonctionne de manière satisfaisante sur les + plateformes de style unix, il n'en est pas de même sous + Windows. +

+ + + +

Journalisation et performances +

+ +

L'écriture d'entrées dans les fichiers journaux est + consommatrice de ressources, mais l'importance de ces + données est telle qu'il est fortement déconseillé de + désactiver la journalisation. Pour optimiser les + performances, vous devez enregistrer vos journaux sur un + disque physique différent de celui où se situe votre + site web car les modes d'accès sont très différents. La + lecture de données sur un disque possède un caractère + essentiellement aléatoire, alors que l'écriture dans les + fichiers journaux s'effectue de manière séquentielle. +

+

+ Ne définissez jamais la directive LogLevel à debug pour un + serveur en production. En effet, lorsque ce niveau de + journalisation est défini, une grande quantité de + données est écrite dans le journal des erreurs, y + compris, dans le cas d'un accès SSL, toutes les + opérations de lecture/écriture de la négociation de la + connexion. Les implications en matière de performances + sont donc importantes et vous devez plutôt utiliser le + niveau de journalisation warn. +

+

Si votre serveur possède plus d'un serveur virtuel, + il est conseillé d'attribuer un journal des accès séparé à + chacun d'entre eux, ce qui a pour effet de faciliter son + exploitation ultérieure. Par contre, si votre serveur + possède un grand nombre de serveurs virtuels, le nombre + de fichiers journaux à ouvrir va représenter une + consommation de ressources importante pour votre + système, et il sera peut-être alors plus judicieux + d'utiliser un seul fichier journal avec l'aménagement + suivant : utiliser l'élément de format %v + en tête de votre directive LogFormat (et de + votre directive ErrorLog depuis la version + 2.3.8) afin que httpd enregistre le nom du serveur + virtuel qui traite la requête ou l'erreur au début de + chaque entrée du journal. Un simple script Perl peut + alors éclater le journal en fichiers spécifiques à + chaque serveur virtuel après sa rotation ; Apache + fournit un tel script dans le répertoire + support/split-logfile. +

+

+ Vous pouvez aussi utiliser la directive BufferedLogs + pour qu'Apache conserve en mémoire plusieurs entrées + de journal avant de les écrire sur disque. Gardez + cependant à l'esprit que si les performances peuvent + s'en trouver améliorées, la chronologie des + évènements enregistrés peut quant à elle s'en + trouver affectée. +

+ + + + +

Mise en oeuvre d'une charge de test +

+ +

Il est interessant de mettre en oeuvre une charge de test + afin d'évaluer les performances du système en conditions + réelles de fonctionnement. A cet effet, il existe des + paquets commerciaux comme LoadRunner, mais + aussi de nombreux outils libres permettant de générer une + charge de test pour votre serveur web. +

+
    +
  • Apache est fourni avec un programme de test nommé ab + (initiales de Apache Bench). Ce dernier peut générer une + charge de serveur web consistant à demander le même + fichier de manière répétitive à un rythme rapide. Vous + pouvez spécifier le nombre de connexions simultanées, et + choisir entre une durée de fonctionnement ou un nombre + de requêtes. +
    • +
  • http load11 est un autre exemple de générateur de + charge libre. Ce programme fonctionne avec un ficher + d'URLs et peut être compilé avec le support SSL. +
    • +
  • L'Apache Software Foundation propose un outil nommé + flood12. Flood est un programme assez sophistiqué que + l'on configure via un fichier XML. +
    • +
  • Pour finir, JMeter13, un sous-projet de Jakarta, est + un outil de test en charge entièrement en Java. Alors + que les premières versions de cette application étaient + lentes et difficiles d'utilisation, la version 2.1.1 + actuelle semble être plus souple d'utilisation et + efficace. +
    • +
  • +

    Des projets externes à l'ASF et réputés + relativement corrects : grinder, httperf, tsung, FunkLoad. +

    +
    • +
+

Lorsque vous appliquez une charge de test à votre serveur + web, gardez à l'esprit que si ce dernier est en production, + la charge de test peut en affecter négativement les + performances. En outre, le transfert de données + supplémentaires induit peut être comptabilisé dans le + quota mensuel qui vous a été éventuellement alloué. +

+ + + +
top
+
+

Configuration dans une optique de performances +

+ + + +

Configuration de httpd +

+ +

httpd version 2.2 est par défaut un serveur web avec des + processus enfants lancés au préalable. Au démarrage du + serveur, le processus parent lance un certain nombre de + processus enfants et ce sont eux qui seront chargés de traiter les + requêtes. Mais avec httpd version 2.0 est apparu le concept + de module multi-process (MPM). Les développeurs purent alors + écrire des MPMs qui pouvaient fonctionner avec l'architecture + à base de processus ou de threads de leur système + d'exploitation spécifique. Apache 2 est fourni avec des MPMs + spécifiques pour Windows, OS/2, Netware et BeOS. Pour les + plateformes de style unix, les deux MPMS les plus connus + sont Prefork et Worker. Le MPM Prefork offre le même modèle + de processus enfants prélancés que celui d'Apache 1.3. Le + MPM Worker quant à lui, lance un nombre de processus enfants + moins important, mais attribue à chacun d'entre eux un + certain nombre de threads pour traiter les requêtes. Avec la + version 2.4, le MPM n'est plus défini à la compilation, + mais peut être chargé à l'exécution via la directive + LoadModule. Le MPM par + défaut pour la version 2.4 est le MPM event. +

+

Le nombre maximum de process, à savoir le nombre de processus + enfants prélancés et/ou de threads, donne une approximation + du nombre de requêtes que votre serveur peut traiter + simultanément. Ce n'est cependant qu'une estimation car le + noyau peut mettre en file d'attente des tentatives de + connexion à votre serveur. Lorsque votre site approche de la + saturation et si le nombre maximum de process est atteint, la + machine n'impose pas de limite absolue au + delà de laquelle les clients se verront refuser l'accès. + Cependant, lorsque les requêtes commencent à être mises en + file d'attente, les performances du système se dégradent + rapidement. +

+

Enfin, si le serveur httpd en question n'exécute aucun + code tiers via mod_php, mod_perl, + etc..., nous recommandons l'utilisation de + mpm_event. Ce MPM est idéal pour les + situations où httpd sert d'intermédiaire entre les clients + et des serveurs d'arrière-plan qui accomplissent le travail + proprement dit (par exemple en mode mandataire ou cache). +

+ + +

MaxClients +

+ +

La directive MaxClients permet de + spécifier le nombre maximum de process que votre serveur + pourra créer. Deux autres directives lui sont associées + : MinSpareServers et + MaxSpareServers, qui permettent d'encadrer + le nombre de process que httpd garde en réserve pour + traiter les requêtes. Le nombre total de process que + httpd peut créer peut + être défini via la directive ServerLimit. +

+ + + +

Rotation des threads +

+ +

Les directives ci-dessus suffisent pour définir les + limites des nombres de process dans le cas du MPM Prefork. + Cependant, si vous utilisez un MPM à base de threads, la + situation est un peu plus compliquée. Les MPMs à base de + threads supportent la directive + ThreadsPerChild. httpd impose le fait que + MaxClients doit être divisible par + ThreadsPerChild. Si les valeurs que vous + attribuez à ces deux directives ne respectent pas cette + règle, httpd affichera un message d'erreur et corrigera + la valeur de la directive ThreadsPerChild + en la diminuant jusqu'à ce que la valeur de la directive + MaxClients soit divisible par elle. +

+ + + +

Choix de la valeur de MaxClients +

+ +

Idéalement, le nombre maximum de processus devrait + être choisi de façon à ce que toute la mémoire système + soit utilisée, sans la dépasser. En effet, si votre + système est surchargé au point de devoir faire appel de + manière intensive au swap (utilisation de la mémoire + disque), les performances vont se dégrader rapidement. + La formule permettant de déterminer la valeur de + MaxClients + est assez simple : +

+ +

+ MaxClients = (RAM totale − RAM système − RAM pour + les programmes externes) divisé par la RAM nécessaire pour + chaque processus enfant. +

+ +

L'observation est la meilleure manière de déterminer + les différentes quantités de mémoire allouées au + système, aux programmes externes et aux processus httpd + : à cet effet, vous pouvez utiliser les commandes top et + free décrites plus haut pour étudier l'empreinte mémoire + du système lorsque le serveur web n'est pas en cours + d'exécution. Vous pouvez aussi étudier l'empreinte d'un + processus type du serveur web via la commande top ; en + effet, la plupart des implémentations de cette commande + présentent une colonne Mémoire résidente (RSS - Resident + Size) et Mémoire partagée (Shared Memory). +

+

La différence entre ces deux colonnes est la + quantité de mémoire par processus. Le segment de mémoire + partagée n'existe effectivement qu'une seule fois, et + est utilisé par le code et les bibliothèques chargées et + la concurrence inter-processus (ou tableau de résultat - + scoreboard) géré par Apache. La quantité de mémoire + utilisée par chaque processus dépend fortement du nombre + et du type de modules utilisés. La meilleure façon d'en + déterminer les besoins consiste à générer une charge + type pour votre site web et à observer l'importance que + prennent les processus httpd. +

+

La RAM pour les programmes externes comprend + principalement la mémoire utilisée pour les programmes + CGI et les scripts qui s'exécutent indépendamment des + processus httpd. Par contre, si vous utilisez une + machine virtuelle Java qui exécute Tomcat sur le même + serveur, cette dernière va aussi nécessiter une quantité + de mémoire significative. En conséquence, la formule + ci-dessus qui sert à calculer la valeur maximale de + MaxClients permet d'effectuer une première approche, + mais ne constitue en aucun cas une science exacte. En + cas de doute, soyez pragmatique et utilisez une valeur assez + basse pour MaxClients. Le noyau Linux + réserve une certaine quantité de mémoire pour la mise en + cache des accès disque. Sous Solaris par contre, il faut disposer + de suffisamment de mémoire RAM pour créer un processus, + et si ce n'est pas le cas, httpd va démarrer avec un + message d'erreur du style "No space left on device" dans + le journal des erreurs, et sera incapable de créer + d'autres processus httpd enfants ; une valeur trop + élevée pour MaxClients constituera alors + réellement un désavantage. +

+ + +

Choisir votre MPM +

+ +

La commutation entre threads est plus + aisée pour le système, et ceux-ci consomment moins de + ressources que les processus ; c'est la raison + principale pour laquelle il est recommandé de choisir un + MPM threadé. Et + ceci est encore plus flagrant pour certains systèmes + d'exploitation que pour d'autres. Par exemple, sous + Solaris ou AIX, la manipulation des processus est assez + lourde en termes de ressources système ; l'utilisation + d'un MPM threadé est donc tout à fait indiquée pour ces + systèmes. Sous Linux en revanche, l'implémentation des + threads utilise en fait un processus par thread. Les + processus Linux sont assez légers, mais cela signifie qu'un + MPM threadé présentera ici un gain en performance + moindre que sous d'autres systèmes. +

+

Dans certaines situations cependant, l'utilisation + d'un MPM threadé peut induire des problèmes de + stabilité. Par exemple, si un processus enfant du MPM + prefork se crashe, au plus une connexion client sera + affectée ; par contre, si un processus enfant threadé se + crashe, ce sont tous les threads de ce processus qui + vont se crasher à leur tour, ce qui signifie que tous + les clients qui étaient servis par ce processus verront + leur connexion interrompue. De plus, certains problèmes + de sécurité des threads ("thread-safety") + peuvent apparaître, particulièrement avec les + bibliothèques tierces. Avec les applications threadées, + les différents threads peuvent avoir accès aux mêmes + variables sans distinction, sans savoir si une variable + n'a pas été modifiée par un autre thread. +

+

Ce problème a fait l'objet d'un point sensible au + sein de la communauté PHP car Le processeur PHP repose + fortement sur des bibliothèques tierces, et il n'est pas + garanti que la totalité d'entre elles soient + "thread-safe". Bonne nouvelle cependant : si vous + exécutez Apache sous Linux, vous pouvez utiliser PHP + avec le MPM prefork sans craindre une diminution de + performance trop importante par rapport à une option + threadée. +

+ + + +

Verrous tournants

+ +

Apache httpd maintient un verrou inter-processus du + point de vue de son écoute du réseau. Dans les faits, + cela signifie qu'un seul processus httpd enfant à la + fois peut recevoir une requête. Ainsi, soient les autres + processus en profitent alors pour traiter les requêtes + qu'ils ont déjà reçues, soient ils attendent de pouvoir + à leur tour récupérer le verrou et ainsi écouter le + réseau pour recevoir une nouvelle requête. Ceci peut se + voir comme une porte tournante par laquelle un seul + processus peut passer à la fois. Sur un serveur web + fortement chargé où les requêtes arrivent constamment, + la porte tourne rapidement et les requêtes sont + acceptées à un rythme soutenu. Sur un serveur faiblement + chargé en revanche, le processus qui "détient" + le verrou est suceptible de garder sa porte ouverte un + certain temps durant lequel tous les autres processus + seront inactifs, attendant de pouvoir s'approprier le + verrou. Dans une telle situation, le processus parent + pourra décider d'arrêter quelques processus enfants en + fonction de la valeur de la directive + MaxSpareServers.

+ + +

L'assaut de la foule +

+ +

La fonction de l'"accept mutex" (c'est le nom donné au + verrou inter-processus) consiste à gérer la réception + des requêtes de manière ordonnée. Si ce verrou est + absent, le syndrome de l'"assaut de la foule" peut + apparaître. +

+

Imaginez une équipe de football américain en attente + devant la ligne de remise en jeu. Si les joueurs se + comportaient comme des processus Apache, ils se + précipiteraient tous à la fois pour récupérer la balle au + signal de la reprise. Un seul d'entre eux y + parviendrait, et tous les autres n'auraient plus qu'à se + regrouper à nouveau sur la ligne jusqu'à la reprise + suivante. Dans cette métaphore, c'est le quaterback qui + va jouer le rôle d'"accept mutex" en donnant la balle + au joueur approprié. +

+

La transmission d'une telle quantité d'informations + représente naturellement beaucoup de travail et, comme + une personne intelligente, un serveur intelligent + tentera d'éviter cette surcharge dans la mesure du + possible, d'où l'idée de la porte tournante. Dans les + dernières années, de nombreux systèmes d'exploitation, + comme Linux et Solaris, ont développé du code pour + éviter le syndrome de l'"assaut de la foule". Apache + reconnaît ce code, et si vous n'effectuez qu'une seule + écoute du réseau, autrement dit si vous n'utilisez que + le serveur principal ou un seul serveur virtuel, Apache + n'utilisera pas d'"accept mutex" ; par contre, si vous + effectuez plusieurs écoutes du réseau (par exemple si + un serveur virtuel sert les requêtes SSL), Apache + utilisera un "accept mutex" afin d'éviter les conflits + internes. +

+

Vous pouvez manipuler l'"accept mutex" via la + directive AcceptMutex. Cette dernière + permet en particulier de fermer l'"accept mutex", mais + aussi de sélectionner le mécanisme de verrouillage. Les + mécanismes de verrouillage courants comprennent fcntl, + les sémaphores System V et le verrouillage par threads. + Tous ne sont pas supportés par toutes les plateformes, + et leur disponibilité dépend aussi des options de + compilation. Les différents mécanismes de verrouillage + peuvent avoir des exigences particulières en matière de + ressources système ; il est donc recommandé de les + utiliser avec précautions. +

+

Il n'existe aucune raison particulière pour + désactiver l'"accept mutex". Apache détermine + automatiquement s'il doit utiliser ou non mutex sur + votre plateforme en fonction du nombre d'écoutes réseau + de votre serveur, comme décrit précédemment. +

+ + + +

Optimisation du système d'exploitation +

+ +

Souvent, les utilisateurs recherchent le paramètre magique qui va + multiplier par quatre les performances de leur système. En + fait, les systèmes de type Unix actuels sont déjà optimisés + à l'origine, et il n'y a plus grand chose à faire pour + améliorer leurs performances. L'administrateur peut + cependant encore effectuer quelques modifications qui + permettront de peaufiner la configuration. +

+ + +

RAM et swap +

+ +

Le leitmotiv en matière de mémoire est souvent "plus + on en a, mieux c'est". En effet, comme nous avons dit + plus haut, la mémoire inutilisée peut être + avantageusement utilisée comme cache du système de + fichiers. Plus vous chargez de modules, plus les processus + Apache grossissent, et ceci d'autant plus si vous + utilisez des modules qui génèrent des contenus + dynamiques comme PHP et mod_perl. Un gros fichier de + configuration - avec de nombreux serveurs virtuels - a + aussi tendance à augmenter l'empreinte mémoire des + processus. Une quantité de mémoire importante vous + permettra d'exécuter Apache avec plus de processus + enfants, et donc de traiter d'avantage de requêtes + simultanément. +

+

Même si les différentes plateformes traitent leur + mémoire virtuelle de différentes manières, il est + déconseillé de configurer un espace disque de swap + inférieur à la mémoire RAM. En effet, le système de mémoire + virtuelle a été conçu de manière à prendre le relai + lorsque la mémoire RAM fait défaut, et lorsque l'espace + disque, et donc l'espace de swap vient à manquer, votre + serveur risque de s'arrêter. Vous devrez alors + redémarrer physiquement votre serveur, et votre + hébergeur pourra vous facturer le service. +

+

Evidemment, ce genre problème survient au moment le + plus défavorable : lorsque le monde vient découvrir votre + site web et se présente avec insistance à votre porte. + Si votre espace de swap est suffisant, même si la + machine sera de plus en plus surchargée et deviendra + très très lente car le système devra swapper les pages + entre la mémoire et le disque, lorsque la charge diminuera à + nouveau, le système reviendra dans son mode de + fonctionnement normal. Rappelez-vous que vous disposez + de la directive MaxClients pour garder le contrôle. +

+

La plupart des systèmes de type Unix utilisent des + partitions dédiées au swap. Au démarrage du système, + celui-ci enregistre toutes les partitions de swap du ou + des disques en fonction du type de la partition ou du + contenu du fichier /etc/fstab et les + active de manière automatique. Lorsque vous ajoutez un + disque, ou lorsque vous installez le système + d'exploitation, assurez-vous d'allouer suffisamment + d'espace de swap afin de rester en adéquation avec une + éventuelle augmentation de la mémoire RAM. La + réallocation d'espace disque sur un système en + production est en effet pénible et fastidieuse. +

+

Prévoyez un espace de swap de deux fois la taille de + votre mémoire RAM, et même jusqu'à quatre fois lorsque + les surcharges peuvent s'avérer fréquentes. Assurez-vous + de réajuster ces valeurs lorsque vous augmentez la + quantité de mémoire RAM de votre système. En secours, + vous pouvez aussi utilisez un fichier comme espace de + swap. Pour ce faire, vous trouverez les instructions + dans les pages de manuel de mkswap et + swapon, ou dans celles des programmes de + swap. +

+ + + +

ulimit: fichiers et processus +

+ +

Supposons que vous disposiez d'une machine possédant + une énorme quantité de mémoire RAM et un processeur aux + performances astronomiques ; vous pourrez alors exécuter + des centaines de processus Apache selon vos besoins, + mais tout en restant en deçà des limites imposées par le + noyau de votre système. +

+

Considérez maintenant une situation où plusieurs + centaines de serveurs web sont en cours d'exécution ; si + certains d'entre eux doivent à leur tour lancer des + processus CGI, le nombre maximum de processus autorisé + par le noyau sera vite atteint. +

+

Dans ce cas, vous pouvez modifier cette limite avec + la commande : +

+ +

+ ulimit [-H|-S] -u [nouvelle valeur] +

+ +

Cette modification doit être effectuée avant le + démarrage du serveur, car la nouvelle valeur ne sera + prise en compte que dans le shell courant et pour les + programmes lancés depuis ce dernier. Dans les derniers + noyaux Linux, la valeur par défaut a été fixée à 2048. + Sous FreeBSD, ce nombre semble être limité à la valeur + inhabituelle de 513. Dans le shell par défaut de ce + système, csh, la commande équivalente est + limit et possède une syntaxe analogue à + celle de la commande de style Bourne ulimit : +

+ +

+ limit [-h] maxproc [newvalue] +

+ +

En outre, le noyau peut limiter le nombre de fichiers + ouverts par processus. Ce n'est généralement pas un + problème pour les serveurs dont les processus sont lancés + à l'avance, et où chacun de ceux-ci ne traite qu'une + requête à la fois. Les processus des serveurs threadés, + quant à eux, traitent plusieurs requêtes simultanément, + et sont d'avantage susceptibles de dépasser la limite du + nombre de descripteurs de fichiers. Vous pouvez alors + augmenter cette valeur limite du nombre de fichiers + ouverts avec la commande : +

+ +

ulimit -n [newvalue] +

+ +

Là encore, cette modification doit être effectuée + avant le démarrage du serveur Apache. +

+ + + +

Définition des limites en fonction de l'utilisateur ou du + groupe au démarrage du système +

+ +

Sous Linux, vous pouvez définir les paramètres de + ulimit au démarrage en éditant le fichier + /etc/security/limits.conf. Ce fichier vous + permet de définir des limites "soft" et "hard" + en fonction de l'utilisateur ou du groupe ; + vous y trouverez aussi des commentaires explicatifs des + différentes options. Pour que ce fichier soit pris en + compte, le fichier /etc/pam.d/login doit + contenir la ligne : +

+ +

session required /lib/security/pam_limits.so +

+ +

Chaque item peut posséder une valeur "soft" et + "hard" : la première est la valeur + par défaut, et la seconde la valeur maximale de cet + item. +

+

Dans le fichier /etc/login.conf de + FreeBSD, ces valeurs peuvent être limitées ou étendues à + tout le système de manière analogue au fichier + limits.conf. Les limites "soft" sont + spécifiées via le paramètre -cur, et les + limites "hard" via le paramètre -max. +

+

Solaris possède un mécanisme similaire pour manipuler + les valeurs limites au démarrage du système : dans le + fichier /etc/system, vous pouvez définir au + démarrage des paramètres du noyau valables pour + l'ensemble du système. Ce sont les mêmes paramètres que + ceux définis à l'exécution par le débogueur de noyau + mdb. Les commandes équivalentes à ulimit -u + pour définir les limites hard et soft seront du style : +

+ +

+ set rlim_fd_max=65536
+ set rlim_fd_cur=2048 +

+ +

Solaris calcule le nombre maximal de processus + autorisé par utilisateur (maxuprc) en + fonction de la mémoire système disponible + (maxusers). Vous pouvez obtenir ces valeurs + avec la commande : +

+ +

sysdef -i | grep maximum +

+ +

Il est cependant déconseillé de les modifier. +

+ + + +

Désactiver les services et modules non utilisés +

+ +

Dans la plupart des distributions Unix et Linux, de + nombreux services sont activés par défaut, et vous n' + avez probablement besoin que d'une minorité d'entre eux. + Par exemple, votre serveur web n'a pas besoin de + sendmail, de fournir le service NFS, etc... Désactivez + les tout simplement. +

+

Pour ce faire, sous RedHat Linux, vous + disposez de l'utilitaire chkconfig en ligne de commande. + Sous Solaris, les commandes svcs et + svcadm vous permettent respectivement + de lister les services activés et de désactiver ceux + dont vous n'avez pas besoin. +

+

Vous devez aussi prêter attention aux modules Apache + chargés par défaut. La plupart des distributions binaires + d'Apache httpd et des versions préinstallées fournies + avec les distributions de Linux chargent les modules + Apache via la directive + LoadModule. +

+

Les modules inutilisés peuvent être désactivés : si + vous n'avez pas besoin de leurs fonctionnalités et des + directives de configuration qu'ils implémentent, + désactivez-les en commentant les lignes + LoadModule correspondantes. Vous + devez cependant lire la documentation relative à ces + modules avant de les désactiver, et garder à l'esprit que + la désactivation d'un module très peu gourmand en + ressources n'est pas absolument nécessaire. +

+ + + + +
top
+
+

Mise en cache des contenus +

+ +

Les requêtes impliquant des contenus dynamiques nécessitent + en général d'avantage de ressources que les + requêtes pour des contenus statiques. Les contenus statiques + consistent en simples pages issues de documents ou images + sur disque, et sont servis très rapidement. En outre, de + nombreux systèmes d'exploitation mettent automatiquement en + cache en mémoire les contenus des fichiers fréquemment accédés. +

+

Comme indiqué précédemment, le traitement des requêtes dynamiques peut + nécessiter beaucoup plus de ressources. L'exécution de scripts + CGI, le transfert de requêtes à un serveur d'applications + externe, ou les accès à une base de données peuvent impliquer + des temps d'attente et charges de travail significatifs pour un + serveur web fortement sollicité. Dans de nombreuses + circonstances, vous pourrez alors améliorer les performances en + transformant les requêtes dynamiques courantes en requêtes + statiques. Pour ce faire, deux approches seront discutées dans + la suite de cette section. +

+ + +

Transformation des pages courantes en contenus + statiques +

+ +

En générant à l'avance les réponses pour les requêtes les + plus courantes de votre application, vous pouvez améliorer + de manière significative les performances de votre serveur + sans abandonner la flexibilité des contenus générés + dynamiquement. Par exemple, si votre application est un + service de livraison de fleurs, vous aurez tout intérêt à + générer à l'avance les pages de votre catalogue concernant + les roses rouges dans les semaines précédant le jour de la + Saint Valentin. Lorsqu'un utilisateur cherchera des roses + rouges, il téléchargera alors les pages générées à + l'avance. Par contre, les recherches de roses jaunes seront + quant à elles traitées directement via une requête vers la + base de données. Pour effectuer ces aiguillages de requêtes, + vous disposez d'un outil particulièrement approprié fourni + avec Apache : le module mod_rewrite. +

+ + +

Exemple : un blog servi statiquement +

+ + + +

Blosxom est un programme CGI de journalisation web + léger. Il est écrit en Perl et utilise des fichiers + texte pour ses entrées. Outre sa qualité de programme + CGI, Blosxom peut être exécuté en ligne de commande pour + générer à l'avance des pages de blog. Lorsque votre blog + commence à être lu par un grand nombre de personnes, la + génération à l'avance de pages en HTML satique peut + améliorer de manière significative les performances de + votre serveur. +

+

Pour générer des pages statiques avec blosxom, éditez + le script CGI selon la documentation. Définissez la + variable $static dir à la valeur de + DocumentRoot de votre serveur + web, et exécutez le script en ligne de commande comme + suit : +

+ +

$ perl blosxom.cgi -password='whateveryourpassword' +

+ +

Vous pouvez exécuter ce script périodiquement via + cron, à chaque fois que vous ajoutez un nouveau contenu. Pour + faire en sorte qu'Apache substitue les pages + statiques au contenu dynamique, nous + utiliserons mod_rewrite. Ce module est fourni avec le + code source d'Apache, mais n'est pas compilé par défaut. + Pour le compiler avec la distribution d'Apache, vous + pouvez utiliser l'option de la commande configure + --enable-rewrite[=shared]. De nombreuses + distributions binaires d'Apache sont fournies avec + mod_rewrite inclus. Dans l'exemple + suivant, un serveur virtuel Apache utilise les pages de + blog générées à l'avance : +

+ +
Listen *:8001
+  <VirtualHost *:8001>
+      ServerName blog.sandla.org:8001
+      ServerAdmin sander@temme.net
+      DocumentRoot "/home/sctemme/inst/blog/httpd/htdocs"
+      <Directory "/home/sctemme/inst/blog/httpd/htdocs">
+          Options +Indexes
+          Require all granted
+          RewriteEngine on
+          RewriteCond "%{REQUEST_FILENAME}" "!-f"
+          RewriteCond "%{REQUEST_FILENAME}" "!-d"
+          RewriteRule "^(.*)$" "/cgi-bin/blosxom.cgi/$1" [L,QSA]
+      </Directory>
+      RewriteLog "/home/sctemme/inst/blog/httpd/logs/rewrite_log"
+      RewriteLogLevel 9
+      ErrorLog "/home/sctemme/inst/blog/httpd/logs/error_log"
+      LogLevel debug
+      CustomLog "/home/sctemme/inst/blog/httpd/logs/access_log common"
+      ScriptAlias "/cgi-bin/" "/home/sctemme/inst/blog/bin/"
+      <Directory "/home/sctemme/inst/blog/bin">
+          Options +ExecCGI
+          Require all granted
+      </Directory>
+  </VirtualHost>
+ + +

+ Si les directives RewriteCond + indiquent que la ressource demandée n'existe ni en tant que + fichier, ni en tant que répertoire, son + chemin sera redirigé par la directive + RewriteRule vers le programme + CGI Blosxom qui va générer la réponse. Blosxom + utilise Path Info pour spécifier les entrées de blog + en tant que pages d'index, et si un chemin dans + Blosxom existe en tant que fichier statique dans le système de + fichiers, c'est ce dernier qui sera par conséquent privilégié. + Toute requête dont la réponse n'a pas été générée à + l'avance sera traitée par le programme CGI. Cela + signifie que les entrées individuelles comme les + commentaires seront toujours servies par le + programme CGI, et seront donc toujours visibles. + Cette configuration permet aussi de ne pas faire + apparaître le programme CGI Blosxom dans l'URL de la barre + d'adresse. Enfin, mod_rewrite est un module extrêmement + souple et puissant ; prenez le temps de bien + l'étudier afin de parvenir à la configuration qui + correspondra le mieux à votre situation. +

+ + + + +

Mise en cache du contenu avec mod_cache +

+ +

Le module mod_cache implémente une mise en cache + intelligente des réponses HTTP : il tient compte des délais + de péremption et des contraintes en matière de contenu + inhérentes à la spécification HTTP. Le module mod_cache met + en cache les URL des contenus des réponses. Si un contenu envoyé au + client peut être mis en cache, il est sauvegardé sur disque. + Les requêtes ultérieures pour cette URL seront alors servies + directement depuis le cache. Le module fournisseur pour + mod_cache, mod_disk_cache, détermine la manière dont les + contenus sont stockés sur disque. La plupart des systèmes de + serveur possèdent plus d'espace disque que de mémoire, et il + est bon de garder à l'esprit que certains noyaux système mettent en + cache de manière transparente en mémoire les contenus sur + disque fréquemment accédés ; il n'est donc pas très utile de + répéter cette opération au niveau du serveur. +

+

Pour mettre en oeuvre une mise en cache de contenu + efficace et éviter de présenter à l'utilisateur un contenu + invalide ou périmé, l'application qui génère le contenu à + jour doit envoyer les en-têtes de réponse corrects. En + effet, en l'absence d'en-têtes comme Etag:, + Last-Modified: ou Expires:, + mod_cache ne sera pas en mesure de décider + de manière appropriée + s'il doit mettre le contenu en cache, s'il doit le servir + directement depuis ce dernier, ou s'il doit tout simplement + ne rien faire. Lorsque vous testerez la mise en cache, vous + devrez peut-être modifier votre application ou, en cas + d'impossibilité, désactiver de manière sélective la mise en + cache des URLs qui posent problème. Les modules mod_cache ne + sont pas compilés par défaut ; pour ce faire, vous devez + utiliser l'option --enable-cache[=shared] du + script configure. Si vous utilisez une distribution binaire + d'Apache httpd, ou si elle fait partie de votre portage ou + de votre sélection de paquets, mod_cache + sera probablement déjà inclus. +

+ + +

Exemple : wiki.apache.org +

+ + +

+ Le Wiki de l'Apache Software Foundation est servi + par MoinMoin. MoinMoin est écrit en Python et + s'exécute en tant que programme CGI. A l'heure + actuelle, toute tentative pour l'exécuter via + mod_python s'est soldée par un échec. Le programme + CGI induit une charge inacceptable sur le serveur, + particulièrement lorsque le Wiki est indexé par des + moteurs de recherche comme Google. Pour alléger la + charge de la machine, l'équipe d'infrastructure + d'Apache s'est tournée vers mod_cache. Il s'est + avéré que MoinMoin + nécessitait un petit patch pour adopter un + comportement approprié en aval du serveur de mise + en cache : certaines requêtes ne pouvaient jamais + être mises en cache, et les modules Python + concernés ont été mis à jour pour pouvoir envoyer + les en-têtes de réponse HTTP corrects. Après cette + modification, la mise en cache en amont du Wiki a + été activée via l'insertion des lignes suivantes + dans le fichier de configuration + httpd.conf : +

+ +
CacheRoot /raid1/cacheroot
+CacheEnable disk /
+# Une page modifiée il y a 100 minutes expirera dans 10 minutes
+CacheLastModifiedFactor .1
+# Dans tous les cas, vérifier la validité des pages après 6 heures
+CacheMaxExpire 21600
+ + +

Cette configuration essaie de mettre en cache tout + contenu de son serveur virtuel. Elle ne mettra jamais en + cache un contenu plus vieux que 6 heures (voir la + directive CacheMaxExpire). Si + l'en-tête Expires: est absent de la + réponse, mod_cache va calculer une date + d'expiration en fonction du contenu de l'en-tête + Last-Modified:. Le principe de ce calcul + qui utilise la directive CacheLastModifiedFactor + se base sur l'hypothèse que si une page a été modifiée + récemment, il y a de fortes chances pour qu'elle le soit + à nouveau dans un futur proche et devra donc être remise + en cache. +

+

+ Notez qu'il peut s'avérer payant de + désactiver l'en-tête ETag: : + pour les fichiers inférieurs à 1 ko, le serveur + doit calculer la somme de vérification checksum (en + général MD5) et envoyer une réponse 304 Not + Modified, ce qui utilise des ressources CPU + et réseau pour le transfert (1 paquet TCP). Pour les + ressources supérieures à 1 ko, les ressources CPU + consommées peuvent devenir importantes car l'en-tête + est calculé à chaque requête. Malheureusement, il + n'existe actuellement aucun moyen pour mettre en + cache ces en-têtes. +

+
<FilesMatch "\.(jpe?g|png|gif|js|css|x?html|xml)">
+    FileETag None
+</FilesMatch>
+ + +

+ Dans l'exemple précédent: la génération d'un en-tête + ETag: sera désactivée pour la plupart + des ressources statiques. Le serveur ne génère pas + ces en-têtes pour les ressources dynamiques. +

+ + + + +
top
+
+

Pour aller plus loin +

+ +

Armés du savoir-faire pour personnaliser un système afin + qu'il affiche les performances désirées, nous découvrirons vite + qu'1 sytème à lui seul peut constituer un goulot + d'étranglement. A ce sujet, la page du Wiki PerformanceScalingOut + décrit comment adapter un système à mesure qu'il prend de + l'ampleur, ou comment personnaliser plusieurs systèmes dans leur + ensemble. +

+
+
+

Langues Disponibles:  en  | + es  | + fr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/mod/event.html.es b/docs/manual/mod/event.html.es index f9e4cb6829..1850f318b2 100644 --- a/docs/manual/mod/event.html.es +++ b/docs/manual/mod/event.html.es @@ -30,6 +30,10 @@  es  |  fr 

+
Esta traducción podría estar + obsoleta. Consulte la versión en inglés de la + documentación para comprobar si se han producido cambios + recientemente.
diff --git a/docs/manual/mod/event.html.fr b/docs/manual/mod/event.html.fr index bf8cd3b3e8..6846040ae2 100644 --- a/docs/manual/mod/event.html.fr +++ b/docs/manual/mod/event.html.fr @@ -30,6 +30,8 @@  es  |  fr 

+
Cette traduction peut être périmée. Vérifiez la version + anglaise pour les changements récents.
Descripción:Una variante del MPM worker con el objetivo de consumir hilos sólo para conexiones con procesamiento activo
diff --git a/docs/manual/mod/mod_allowhandlers.html.fr b/docs/manual/mod/mod_allowhandlers.html.fr new file mode 100644 index 0000000000..21168242bf --- /dev/null +++ b/docs/manual/mod/mod_allowhandlers.html.fr @@ -0,0 +1,120 @@ + + + + + +mod_allowhandlers - Serveur Apache HTTP Version 2.5 + + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+
+Apache > Serveur HTTP > Documentation > Version 2.5 > Modules
+
+

Module Apache mod_allowhandlers

+
+

Langues Disponibles:  en  | + es  | + fr 

+
+
Description:Une variante du MPM worker conçue pour ne mobiliser des threads que pour les connexions en cours de traitement
Statut:MPM
+ + +
Description:Facilite la définition de la liste des gestionnaires HTTP +qui peuvent être utilisés pour le serveur
Statut:Expérimental
Identificateur de Module:allowhandlers_module
Fichier Source:mod_allowhandlers.c
+

Sommaire

+ +

Ce module facilite la définition de la liste des gestionnaires HTTP +qui peuvent être utilisés pour une requête. Voici un exemple de ligne de +configuration :

+ +
<Location "/">
+  AllowHandlers not server-info server-status balancer-manager ldap-status
+</Location>
+ + +

Il implémente aussi un gestionnaire nommé forbidden qui +ne fait que renvoyer la réponse "403 FORBIDDEN" au client. Ce +gestionnaire peut être spécifié par des directives comme AddHandler.

+ + +

Directives

+ +

Traitement des bugs

Voir aussi

+
+ +
top
+

Directive AllowHandlers

+ + + + + + + +
Description:Restreint l'accès aux gestionnaires spécifiés
Syntaxe:AllowHandlers [not] none|nom-gestionnaire +[none|nom-gestionnaire]...
Défaut:AllowHandlers all
Contexte:répertoire
Statut:Expérimental
Module:mod_allowhandlers
+ +

Les noms de gestionnaires sont sensibles à la casse. Le nom réservé +none peut être utilisé dans le cas où aucun gestionnaire +n'a été défini. Le nom réservé all, quant à lui, peut être +utilisé pour autoriser à nouveau tous les gestionnaires dans une section +de configuration ultérieure, même si certains en-têtes ont été interdits +en aval :

+ +
<Location "/server-status">
+  AllowHandlers all
+  SetHandler server-status
+</Location>
+ + + +
+ +
+

Langues Disponibles:  en  | + es  | + fr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_authnz_fcgi.html.fr b/docs/manual/mod/mod_authnz_fcgi.html.fr new file mode 100644 index 0000000000..406011ad67 --- /dev/null +++ b/docs/manual/mod/mod_authnz_fcgi.html.fr @@ -0,0 +1,589 @@ + + + + + +mod_authnz_fcgi - Serveur Apache HTTP Version 2.5 + + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+
+Apache > Serveur HTTP > Documentation > Version 2.5 > Modules
+
+

Module Apache mod_authnz_fcgi

+
+

Langues Disponibles:  en  | + fr 

+
+ + + + +
Description:Permet à une application d'autorisation FastCGI de gérer +l'authentification et l'autorisation httpd.
Statut:Extension
Identificateur de Module:authnz_fcgi_module
Fichier Source:mod_authnz_fcgi.c
Compatibilité:Disponible à partir de la version 2.4.10 du serveur HTTP +Apache
+

Sommaire

+ +

Ce module permet aux applications d'autorisation FastCGI + d'authentifier les utilisateurs et de contrôler leur accès aux + ressources. Il supporte les systèmes d'autorisation FastCGI + génériques qui participent en une seule phase à l'authentification + et à l'autorisation, ainsi que les processus d'authentification et + d'autorisation spécifiques à Apache httpd qui interviennent en une + ou plusieurs phases.

+ +

Les processus d'autorisation FastCGI peuvent authentifier un + utilisateur via son identificateur et son mot de passe comme dans le + processus d'authentification basique, ou via un mécanisme + arbitraire.

+
+ +
top
+
+

Modes d'invocation

+ +

Les modes d'invocation des processus d'autorisation FastCGI que + ce module supporte se distinguent par deux caractéristiques : le + type et le mécanisme d'authentification.

+ +

Le Type est simplement authn pour + l'authentification, authz pour l'autorisation et + authnz l'authentification et l'autorisation.

+ +

Le mécanisme d'authentification fait référence aux + mécanismes d'authentification et aux phases de traitement de la + configuration de Apache httpd, et peut être + AuthBasicProvider, Require, ou + check_user_id. Les deux premiers mécanismes + correspondent aux directives utilisées pour participer aux phases de + traitement appropriées.

+ +

Description de chaque mode:

+ +
+
Type authn, mechanism + AuthBasicProvider
+ +
Dans ce mode, la variable FCGI_ROLE est définie à + AUTHORIZER, et la variable + FCGI_APACHE_ROLE à AUTHENTICATOR. + L'application doit être spécifiée en tant que fournisseur de type + authn via la directive AuthnzFcgiDefineProvider, et + activée via la directive AuthBasicProvider. Lorsqu'elle + est invoquée, l'application est censée authentifier le client à + l'aide de l'identifiant et du mot de passe de l'utilisateur. + Exemple d'application : + +
#!/usr/bin/perl
+use FCGI;
+my $request = FCGI::Request();
+while ($request->Accept() >= 0) {
+    die if $ENV{'FCGI_APACHE_ROLE'} ne "AUTHENTICATOR";
+    die if $ENV{'FCGI_ROLE'}        ne "AUTHORIZER";
+    die if !$ENV{'REMOTE_PASSWD'};
+    die if !$ENV{'REMOTE_USER'};
+
+    print STDERR "This text is written to the web server error log.\n";
+
+    if ( ($ENV{'REMOTE_USER' } eq "foo" || $ENV{'REMOTE_USER'} eq "foo1") &&
+        $ENV{'REMOTE_PASSWD'} eq "bar" ) {
+        print "Status: 200\n";
+        print "Variable-AUTHN_1: authn_01\n";
+        print "Variable-AUTHN_2: authn_02\n";
+        print "\n";
+    }
+    else {
+        print "Status: 401\n\n";
+    }
+}
+ + + Exemple de configuration httpd : +
AuthnzFcgiDefineProvider authn FooAuthn fcgi://localhost:10102/
+<Location "/protected/">
+  AuthType Basic
+  AuthName "Restricted"
+  AuthBasicProvider FooAuthn
+  Require ...
+</Location>
+ +
+ +
Type authz, mechanism + Require
+
Dans ce mode, la variable FCGI_ROLE est définie à + AUTHORIZER et FCGI_APACHE_ROLE à + AUTHORIZER. L'application doit être spécifiée en tant + que fournisseur de type authz via la directive AuthnzFcgiDefineProvider. + Lorsqu'elle est invoquée, l'application est censée contrôler les + accès du client à l'aide de l'identifiant utilisateur et d'autres + données contenues dans la requête. Exemple d'application : +
#!/usr/bin/perl
+use FCGI;
+my $request = FCGI::Request();
+while ($request->Accept() >= 0) {
+    die if $ENV{'FCGI_APACHE_ROLE'} ne "AUTHORIZER";
+    die if $ENV{'FCGI_ROLE'}        ne "AUTHORIZER";
+    die if $ENV{'REMOTE_PASSWD'};
+
+    print STDERR "This text is written to the web server error log.\n";
+
+    if ($ENV{'REMOTE_USER'} eq "foo1") {
+        print "Status: 200\n";
+        print "Variable-AUTHZ_1: authz_01\n";
+        print "Variable-AUTHZ_2: authz_02\n";
+        print "\n";
+    }
+    else {
+        print "Status: 403\n\n";
+    }
+}
+ + + Exemple de configuration httpd : +
AuthnzFcgiDefineProvider authz FooAuthz fcgi://localhost:10103/
+<Location "/protected/">
+  AuthType ...
+  AuthName ...
+  AuthBasicProvider ...
+  Require FooAuthz
+</Location>
+ +
+ +
Type authnz, mechanism + AuthBasicProvider + Require
+ +
Dans ce mode qui supporte le protocole d'autorisation web + server-agnostic FastCGI, la variable FCGI_ROLE est + définie à AUTHORIZER et FCGI_APACHE_ROLE + n'est pas définie. L'application doit être spécifiée en tant que + fournisseur de type authnz via la directive AuthnzFcgiDefineProvider. + L'application est censée assurer l'authentification et + l'autorisation au cours d'une même invocation à l'aide de + l'identifiant et du mot de passe de l'utilisateur et d'autres + données contenues dans la requête. L'invocation de l'application + intervient au cours de la phase d'authentification de l'API Apache + httpd. Si l'application renvoie le code 200, et si le même + fournisseur est invoqué au cours de la phase d'autorisation (via + une directive Require), mod_authnz_fcgi + renverra un code de type success pour la phase d'autorisation sans + invoquer l'application. Exemple d'application : +
#!/usr/bin/perl
+use FCGI;
+my $request = FCGI::Request();
+while ($request->Accept() >= 0) {
+    die if $ENV{'FCGI_APACHE_ROLE'};
+    die if $ENV{'FCGI_ROLE'} ne "AUTHORIZER";
+    die if !$ENV{'REMOTE_PASSWD'};
+    die if !$ENV{'REMOTE_USER'};
+
+    print STDERR "This text is written to the web server error log.\n";
+
+    if ( ($ENV{'REMOTE_USER' } eq "foo" || $ENV{'REMOTE_USER'} eq "foo1") &&
+        $ENV{'REMOTE_PASSWD'} eq "bar" &&
+        $ENV{'REQUEST_URI'} =~ m%/bar/.*%) {
+        print "Status: 200\n";
+        print "Variable-AUTHNZ_1: authnz_01\n";
+        print "Variable-AUTHNZ_2: authnz_02\n";
+        print "\n";
+    }
+    else {
+        print "Status: 401\n\n";
+    }
+}
+ + + Exemple de configuration httpd : +
AuthnzFcgiDefineProvider authnz FooAuthnz fcgi://localhost:10103/
+<Location "/protected/">
+  AuthType Basic
+  AuthName "Restricted"
+  AuthBasicProvider FooAuthnz
+  Require FooAuthnz
+</Location>
+ +
+ +
Type authn, mechanism + check_user_id
+ +
Dans ce mode, la variable FCGI_ROLE est définie à + AUTHORIZER et FCGI_APACHE_ROLE à + AUTHENTICATOR. L'application doit être spécifiée en + tant que fournisseur de type authn via une directive + AuthnzFcgiDefineProvider. La + directive AuthnzFcgiCheckAuthnProvider + permet de l'invoquer. Exemple d'application : +
#!/usr/bin/perl
+use FCGI;
+my $request = FCGI::Request();
+while ($request->Accept() >= 0) {
+    die if $ENV{'FCGI_APACHE_ROLE'} ne "AUTHENTICATOR";
+    die if $ENV{'FCGI_ROLE'} ne "AUTHORIZER";
+
+    # This authorizer assumes that the RequireBasicAuth option of
+    # AuthnzFcgiCheckAuthnProvider is On:
+    die if !$ENV{'REMOTE_PASSWD'};
+    die if !$ENV{'REMOTE_USER'};
+
+    print STDERR "This text is written to the web server error log.\n";
+
+    if ( ($ENV{'REMOTE_USER' } eq "foo" || $ENV{'REMOTE_USER'} eq "foo1") &&
+        $ENV{'REMOTE_PASSWD'} eq "bar" ) {
+        print "Status: 200\n";
+        print "Variable-AUTHNZ_1: authnz_01\n";
+        print "Variable-AUTHNZ_2: authnz_02\n";
+        print "\n";
+    }
+    else {
+        print "Status: 401\n\n";
+        # If a response body is written here, it will be returned to
+        # the client.
+    }
+}
+ + + Exemple de configuration httpd : +
AuthnzFcgiDefineProvider authn FooAuthn fcgi://localhost:10103/
+<Location "/protected/">
+  AuthType ...
+  AuthName ...
+  AuthnzFcgiCheckAuthnProvider FooAuthn \
+                               Authoritative On \
+                               RequireBasicAuth Off \
+                               UserExpr "%{reqenv:REMOTE_USER}"
+  Require ...
+</Location>
+ +
+ +
+ +
top
+
+

Exemples supplémentaires

+ +
    +
  1. Si votre application supporte séparément les rôles + d'authentification et d'autorisation (AUTHENTICATOR et + AUTHORIZER), vous pouvez définir des fournisseurs + séparés comme suit, même s'ils correspondent à la même application : + +
    AuthnzFcgiDefineProvider authn  FooAuthn  fcgi://localhost:10102/
+AuthnzFcgiDefineProvider authz  FooAuthz  fcgi://localhost:10102/
    + + + Spécifie le fournisseur authn via la directive + AuthBasicProvider + et le fournisseur authz via la directive + Require: + +
    AuthType Basic
+AuthName "Restricted"
+AuthBasicProvider FooAuthn
+Require FooAuthz
    + +
    2. + +
  2. Si votre application supporte le rôle générique + AUTHORIZER (authentification et autorisation en une + seule invocation), vous pouvez définir un fournisseur unique comme + suit : + +
    AuthnzFcgiDefineProvider authnz FooAuthnz fcgi://localhost:10103/
    + + + Spécifie le fournisseur authnz via les directives + AuthBasicProvider et + Require : + +
    AuthType Basic
+AuthName "Restricted"
+AuthBasicProvider FooAuthnz
+Require FooAuthnz
    + +
    3. +
+
top
+
+

Limitations

+ +

Les fonctionnalités suivantes ne sont pas encore implémentées :

+ +
+
Vérificateur d'accès d'Apache httpd
+
La phase access check de l'API Apache httpd est + distincte des phases d'authentification et d'autorisation. + Certaines autres implémentations de FastCGI supportent cette phase + et lorsque c'est le cas, la variable FCGI_APACHE_ROLE + est définie à ACCESS_CHECKER.
+ +
Redirections (pipes) ou sockets locaux (Unix)
+
Seuls les sockets TCP sont actuellement supportés.
+ +
Support de mod_authn_socache
+
Le support de l'interaction avec mod_authn_socache pour les + applications qui interviennent dans le processus + d'authentification d'Apache httpd serait souhaitable.
+ +
Support de l'authentification de type digest à l'aide de AuthDigestProvider
+
Cette limitation ne sera probablement jamais franchie car il + n'existe aucun flux de données d'autorisation capable de lire dans + un condensé de type hash.
+ +
Gestion des processus applicatifs
+
Cette fonctionnalité restera probablement hors de portée de ce + module. Il faudra donc gérer les processus applicatifs d'une autre + manière ; par exemple, fcgistarter permet de + les démarrer.
+ +
AP_AUTH_INTERNAL_PER_URI
+
Tous les fournisseurs sont actuellement enregistrés en tant + que AP_AUTH_INTERNAL_PER_CONF, ce qui signifie que les + vérifications ne sont pas effectuées pour les + sous-requêtes internes avec la même configuration de contrôle + d'accès que la requête initiale.
+ +
Conversion du jeu de caractères des données de protocole
+
Si mod_authnz_fcgi s'exécute dans un environnement de + compilation EBCDIC, toutes les données de protocole FastCGI sont + écrites en EBCDIC et doivent être disponibles en EBCDIC.
+ +
Plusieurs requêtes pour une connexion
+
Actuellement, la connexion au fournisseur d'autorisation + FastCGI est fermée après chaque phase de traitement. Par exemple, + si le fournisseur d'autorisation gère séparément les phases + authn et authz, deux connexions seront + nécessaires.
+ +
Redirection de certains URIs
+
Les URIs en provenance des clients ne peuvent pas être + redirigés selon une table de redirection, comme avec la directive + ProxyPass utilisée avec les répondeurs + FastCGI.
+ +
+ +
top
+
+

Journalisation

+ +
    +
  1. Les erreurs de traitement sont journalisées à un niveau + error ou supérieur.
    2. +
  2. Les messages envoyés par l'application sont journalisés au + niveau warn.
    3. +
  3. Les messages de deboguage à caractère général sont + journalisés au niveau debug.
    4. +
  4. Les variables d'environnement transmises à l'application + sont journalisées au niveau trace2. La valeur de la + variable REMOTE_PASSWD sera occultée, mais + toute autre donnée sensible sera visible dans le + journal.
    5. +
  5. Toutes les entrées/sorties entre le module et l'application + FastCGI, y compris les variables d'environnement, seront + journalisées au format imprimable et hexadécimal au niveau + trace5. Toutes les données sensibles seront + visibles dans le journal.
    6. +
+ +

La directive LogLevel permet + de configurer un niveau de journalisation spécifique à + mod_authnz_fcgi. Par exemple :

+ +
LogLevel info authnz_fcgi:trace8
+ + +
+
top
+

Directive AuthnzFcgiCheckAuthnProvider

+ + + + + + + + +
Description:Permet à une application FastCGI de gérer l'accroche +d'authentification check_authn.
Syntaxe:AuthnzFcgiCheckAuthnProvider provider-name|None +option ...
Défaut:none
Contexte:répertoire
AllowOverride:FileInfo
Statut:Extension
Module:mod_authnz_fcgi
+

Cette directive permet de confier à une application FastCGI la + gestion d'une phase spécifique du processus d'authentification ou + d'autorisation.

+ +

Certaines fonctionnalités des fournisseurs d'autorisation FastCGI + nécessitent cette directive en lieu et place de + AuthBasicProvider pour pouvoir être activées :

+ +
    +
  • L'authentification de type autre que basique ; en général, + détermination de l'identifiant utilisateur et renvoi de sa valeur + depuis le fournisseur d'autorisation ; voir l'option + UserExpr ci-dessous
    • +
  • Sélection d'un code de réponse personnalisé ; en cas de + code de réponse autre que 200 en provenance du fournisseur + d'autorisation, c'est ce code qui sera utilisé comme code d'état + de la réponse
    • +
  • Définition du corps d'une réponse autre que 200 ; si le + fournisseur d'autorisation renvoie un corps de réponse avec un + code autre que 200, c'est ce corps de réponse qui sera renvoyé au + client ; la longueur du texte est limitée à 8192 octets
    • +
+ +
+
provider-name
+
C'est le nom du fournisseur défini au préalable via la + directive AuthnzFcgiDefineProvider.
+ +
None
+
Spécifiez None pour désactiver un fournisseur + activé avec cette même directive dans une autre portée, par + exemple dans un répertoire parent.
+ +
option
+
Les options suivantes sont supportées : + +
+
Authoritative On|Off (par défaut On)
+
Cette option permet de définir si l'appel à d'autres + modules est autorisé lorsqu'un fournisseur d'autorisation FastCGI a + été configuré et si la requête échoue.
+ +
DefaultUser id utilisateur
+
Lorsque le fournisseur d'autorisation donne son accord, et + si UserExpr est défini et correspond à une chaîne + vide, (par exemple, si le fournisseur d'autorisation ne renvoie + aucune variable), c'est cette valeur qui sera utilisée comme id + utilisateur par défaut. Cela se produit souvent lorsqu'on se trouve dans + un contexte d'invité, ou d'utilisateur non authentifié ; + les utilisateurs et invités se voient alors attribué un id + utilisateur spécifique qui permettra de se connecter et + d'accéder à certaines ressources.
+ +
RequireBasicAuth On|Off (par défaut Off)
+
Cette option permet de définir si l'authentification + basique est requise avant de transmettre la requête au + fournisseur d'autorisation. Dans l'affirmative, le fournisseur + d'autorisation ne sera invoqué qu'en présence d'un id + utilisateur et d'un mot de passe ; si ces deux éléments ne sont + pas présents, un code d'erreur 401 sera renvoyé
+ +
UserExpr expr (pas de valeur par défaut)
+
Lorsque le client ne fournit pas l'authentification basique + et si le fournisseur d'autorisation détermine l'id utilisateur, + cette expression, évaluée après l'appel au fournisseur + d'autorisation, permet de déterminer l'id utilisateur. Cette + expression se conforme à la syntaxe + ap_expr et doit correspondre à une chaîne de caractères. + Une utilisation courante consiste à référencer la définition + d'une Variable-XXX renvoyée par le + fournisseur d'autorisation via une option du style + UserExpr "%{reqenv:XXX}". Si cette option + est spécifiée, et si l'id utilisateur ne peut pas être définie + via l'expression après une authentification réussie, la requête + sera rejetée avec un code d'erreur 500.
+ +
+
+
+ +
+
top
+

Directive AuthnzFcgiDefineProvider

+ + + + + + + +
Description:Définit une application FastCGI en tant que fournisseur +d'authentification et/ou autorisation
Syntaxe:AuthnzFcgiDefineProvider type provider-name +backend-address
Défaut:none
Contexte:configuration du serveur
Statut:Extension
Module:mod_authnz_fcgi
+

Cette directive permet de définir une application FastCGI en tant + que fournisseur pour une phase particulière d'authentification ou + d'autorisation.

+ +
+
type
+
Les valeurs de ce paramètre sont authn pour + l'authentification, authz pour l'autorisation, ou + authnz pour un fournisseur d'autorisation générique + FastCGI qui effectue les deux vérifications.
+ +
provider-name
+
Ce paramètre permet d'associer un nom au fournisseur ; ce nom + pourra être utilisé dans des directives comme AuthBasicProvider et + Require.
+ +
backend-address
+
Ce paramètre permet de spécifier l'adresse de l'application + sous la forme fcgi://hostname:port/. Le ou les processus + de l'application doivent être gérés indépendamment comme avec + fcgistarter.
+
+ +
+
+
+

Langues Disponibles:  en  | + fr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_brotli.html.fr b/docs/manual/mod/mod_brotli.html.fr new file mode 100644 index 0000000000..2c784185dd --- /dev/null +++ b/docs/manual/mod/mod_brotli.html.fr @@ -0,0 +1,353 @@ + + + + + +mod_brotli - Serveur Apache HTTP Version 2.5 + + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+
+Apache > Serveur HTTP > Documentation > Version 2.5 > Modules
+
+

Module Apache mod_brotli

+
+

Langues Disponibles:  en  | + fr 

+
+ + + + +
Description:Compression du contenu via Brotli avant sa livraison au client
Statut:Extension
Identificateur de Module:brotli_module
Fichier Source:mod_brotli.c
Compatibilité:Disponible à partir de la version 2.4.26 du serveur HTTP Apache
+

Sommaire

+ +

Le module mod_brotli fournit le filtre en sortie + BROTLI_COMPRESS qui permet de compresser un contenu avant sa + livraison au client en utilisant la bibliothèque brotli. Ce filtre est + implémenté en utilisant la bibliothèque Brotli que l'on peut trouver à https://github.com/google/brotli.

+
+ +
top
+
+

Exemples de configurations

+

Compression et TLS

+

Certaines applications web sont vulnérables à une attaque de type vol + d'informations lorsqu'une connexion TLS transmet des données + compressées. Pour plus d'informations, étudiez en détail la famille + d'attaques "BREACH".

+
+

Voici une configuration simple qui compresse des types de contenus + courants au format texte :

+ +

Compression de certains types seulement

AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/xml text/css text/javascript application/javascript
+
+ +
top
+
+

Activation de la compression

+

Compression et TLS

+

Certaines applications web sont vulnérables à une attaque de type vol + d'informations lorsqu'une connexion TLS transmet des données + compressées. Pour plus d'informations, étudiez en détail la famille + d'attaques "BREACH".

+
+ +

Compression en sortie

+

La compression est implémentée par le filtre BROTLI_COMPRESS. La + directive suivante active la compression pour les documents correspondant + au conteneur dans lequel elle est placée :

+ + 
SetOutputFilter BROTLI_COMPRESS
+SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-brotli
+ + +

Si vous voulez restreindre la compression à certains types MIME + particuliers, vous pouvez utiliser la directive AddOutputFilterByType. Dans l'exemple + suivant, l'activation de la compression est restreinte aux fichiers html + de la documentation d'Apache :

+ + 
<Directory "/your-server-root/manual">
+    AddOutputFilterByType BROTLI_COMPRESS text/html
+</Directory>
+ + +

Note

+ Le filtre BROTLI_COMPRESS est toujours inséré après les + filtres RESOURCE comme PHP ou SSI. Il n'affecte jamais les sous-requêtes + internes. +
+

Note

+ Définie via SetEnv, la variable + d'environnement no-brotli permet de désactiver la + compression brotli pour une requête particulière, et ceci même si elle + est supportée par le client. +
+ + + +
top
+
+

Interaction avec les serveurs mandataires

+ +

Le module mod_brotli envoie un en-tête de réponse HTTP + Vary:Accept-Encoding pour indiquer aux mandataires qu'une + réponse mise en cache ne doit être envoyée qu'aux clients qui envoient + l'en-tête de requête Accept-Encoding approprié. Ceci permet + d'éviter d'envoyer du contenu compressé à un client qui ne sera pas en + mesure de le décompresser.

+ +

Si vous utilisez des exclusions spéciales dépendant, par exemple, de + l'en-tête User-Agent, vous devez faire un ajout manuel à + l'en-tête Vary afin d'informer les mandataires des restrictions + supplémentaires. Par exemple, dans une configuration typique où l'addition + du filtre BROTLI_COMPRESS dépend de l'en-tête User-Agent, + vous devez ajouter :

+ + 
Header append Vary User-Agent
+ + +

Si votre décision d'utiliser la compression ou non dépend d'autres + informations que le contenu d'en-têtes de requêtes (par exemple la version + HTTP), vous devez affecter la valeur * à l'en-tête + Vary. Ceci permet d'éviter que des mandataires qui le + supportent n'effectuent une mise en cache intégrale.

+ +

Exemple

Header set Vary *
+
+
top
+
+

Servir un contenu pré-compressé

+ +

comme mod_brotli compresse systématiquement un contenu + pour chaque requête le concernant, il est possible d'obtenir un gain en + performance en pré-compressant le contenu et en disant à mod_brotli de le + servir sans le recompresser. Pour cela, vous pouvez utiliser une + configuration du style :

+ + 
<IfModule mod_headers.c>
+    # Sert des fichiers CSS et JS compressés par brotli, s'ils existent
+    # et si le client supporte brotli.
+    RewriteCond "%{HTTP:Accept-encoding}" "br"
+    RewriteCond "%{REQUEST_FILENAME}\.br" "-s"
+    RewriteRule "^(.*)\.(js|css)"              "$1\.$2\.br" [QSA]
+
+    # Sert des types de contenu corrects, et évite la double compression.
+    RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-brotli:1]
+    RewriteRule "\.js\.gz$"  "-" [T=text/javascript,E=no-brotli:1]
+
+
+    <FilesMatch "(\.js\.br|\.css\.br)$">
+      # Sert un type d'encodage correct.
+      Header append Content-Encoding br
+
+      # Force les mandataires à mettre en cache séparément les fichiers css/js
+      # compressés ou non par brotli.
+      Header append Vary Accept-Encoding
+    </FilesMatch>
+</IfModule>
+ + +
+
top
+

Directive BrotliAlterETag

+ + + + + + + +
Description:Comment l'en-tête de réponse ETag doit être modifié au cours de la +compression
Syntaxe:BrotliAlterETag AddSuffix|NoChange|Remove
Défaut:BrotliAlterETag AddSuffix
Contexte:configuration du serveur, serveur virtuel
Statut:Extension
Module:mod_brotli
+

La directive BrotliAlterETag permet d'indiquer + comment l'en-tête ETag doit être modifié lorsqu'une réponse est compressée.

+
+
AddSuffix
+

Ajoute la méthode de compression à la fin de l'en-tête ETag, ce qui + implique que les représentations compressées et non compressées possèderont + des en-têtes ETag uniques. C'était le comportement par défaut depuis la + version 2.4.0 avec un autre module de compression dynamique, + mod-deflate. Ce paramètre permet d'éviter l'envoi de messages + "HTTP Not Modified" (304) en réponse aux requêtes conditionnelles pour des + contenus compressés.

+
NoChange
+

Ne modifie pas l'en-tête ETag d'une réponse compressée. C'était le + comportement par défaut depuis la version 2.4.0 avec un autre module de + compression dynamique, mod-deflate. Ce paramètre ne respecte pas la + propriété HTTP/1.1 selon laquelle toutes les représentations d'une même + ressource ont des en-têtes ETag uniques.

+
Remove
+

Supprime l'en-tête ETag des réponses compressées, ce qui rend + impossibles certaines requêtes conditionnelles, mais évite les inconvénients + des options précédentes.

+
+ +
+
top
+

Directive BrotliCompressionMaxInputBlock

+ + + + + + + +
Description:Taille maximale du bloc de données en entrée
Syntaxe:BrotliCompressionMaxInputBlock value
Défaut:(automatic)
Contexte:configuration du serveur, serveur virtuel
Statut:Extension
Module:mod_brotli
+

La directive BrotliCompressionMaxInputBlock permet + de spécifier la taille maximale du bloc de données en entrée entre 16 et 24, + sachant que plus cette taille sera grande, plus grande sera la quantité de + mémoire consommée.

+ +
+
top
+

Directive BrotliCompressionQuality

+ + + + + + + +
Description:Qualité de la compression
Syntaxe:BrotliCompressionQuality value
Défaut:BrotliCompressionQuality 5
Contexte:configuration du serveur, serveur virtuel
Statut:Extension
Module:mod_brotli
+

La directive BrotliCompressionQuality permet de + spécifier la qualité de la compression (une valeur entre 0 et + 11). Les valeurs les plus hautes correspondent à une compression de + meilleure qualité mais plus lente. +

+ +
+
top
+

Directive BrotliCompressionWindow

+ + + + + + + +
Description:Taille de la fenêtre de compression glissante brotli
Syntaxe:BrotliCompressionWindow value
Défaut:BrotliCompressionWindow 18
Contexte:configuration du serveur, serveur virtuel
Statut:Extension
Module:mod_brotli
+

La directive BrotliCompressionWindow permet de + spécifier la taille de la fenêtre de compression glissante brotli (une + valeur comprise entre 10 et 24). Une taille de fenêtre plus grande peut + améliorer la qualité de la compression mais consomme d'avantage de mémoire.

+ +
+
top
+

Directive BrotliFilterNote

+ + + + + + +
Description:Enregistre le taux de compression dans une note à des fins de +journalisation
Syntaxe:BrotliFilterNote [type] notename
Contexte:configuration du serveur, serveur virtuel
Statut:Extension
Module:mod_brotli
+

La directive BrotliFilterNote permet d'indiquer + qu'une note à propos du taux de compression doit être attachée à la + requête. L'argument notename permet de spécifier le nom de la + note. Vous pouvez utiliser cette note à des fins de statistiques en ajoutant + l'information correspondante à votre access + log.

+ +

Exemple

BrotliFilterNote ratio
+
+LogFormat '"%r" %b (%{ratio}n) "%{User-agent}i"' brotli
+CustomLog "logs/brotli_log" brotli
+
+ +

Si vous souhaitez que l'information enregistrée dans vos journaux soit + plus pertinente, vous pouvez renseigner l'argument optionnel type + afin de spécifier le type de données à enregistrer dans la note à + journaliser. L'argument type accepte les valeurs suivantes :

+ +
+
Input
+
Enregistre dans la note le nombre d'octets contenus dans le flux + d'entrée du filtre.
+ +
Output
+
Enregistre dans la note le nombre d'octets contenus dans le flux + de sortie du filtre.
+ +
Ratio
+
Enregistre dans la note le taux de compression (output/input * + 100). Il s'agit de l'option par défaut si l'argument + type est omis.
+
+ +

Vous pouvez alors configurer vos journaux de la manière suivante :

+ +

Journalisation spécifique

BrotliFilterNote Input instream
+BrotliFilterNote Output outstream
+BrotliFilterNote Ratio ratio
+
+LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' brotli
+CustomLog "logs/brotli_log" brotli
+
+ +

Voir aussi

+ +
+
+
+

Langues Disponibles:  en  | + fr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_crypto.html.fr b/docs/manual/mod/mod_crypto.html.fr new file mode 100644 index 0000000000..3c805aff98 --- /dev/null +++ b/docs/manual/mod/mod_crypto.html.fr @@ -0,0 +1,319 @@ + + + + + +mod_crypto - Serveur Apache HTTP Version 2.5 + + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+
+Apache > Serveur HTTP > Documentation > Version 2.5 > Modules
+
+

Module Apache mod_crypto

+
+

Langues Disponibles:  en  | + fr 

+
+ + + + +
Description:Support du chiffrement/déchiffrement symétrique
Statut:Extension
Identificateur de Module:crypto_module
Fichier Source:mod_crypto.c
Compatibilité:Disponible à partir de la version 2.5 du serveur HTTP Apache
+

Sommaire

+ +

Ce module permet de chiffrer et déchiffrer les données au + niveau des piles de filtrage en entrée et en sortie.

+ +

En particulier, il permet d'effectuer un chiffrement HLS à la + volée comme décrit dans le document draft-pantos-http-live-streaming-19.

+ +

Mais il peut aussi assurer la livraison sécurisée de données via un CDN + non sécurisé aux clients qui le supportent.

+ +

Selon les besoins, on peut ajouter le filtre crypto à la pile de filtrage + en entrée ou en sortie via les directives SetInputFilter, SetOutputFilter, AddOutputFilter ou AddOutputFilterByType.

+ +
+ +
top
+
+

Format du flux de données

+ + +

Le flux de données chiffrées comporte un bloc IV optionnel suivi des + données chiffrées avec l'algorithme de chiffrement choisi. Le bloc final est + éventuellement complété par bourrage avant d'être écrit. La taille des blocs + est déterminée par l'algorithme de chiffrement choisi.

+ +

Lorsque le bloc IV est spécifié via la directive CryptoIV, il est utilisé, mais n'est pas + injecté dans le flux d'entrée/sortie.

+ +
top
+
+

Clés et blocs IV

+ + +

Les directives CryptoKey et + CryptoIV acceptent comme + arguments des valeurs binaires qui peuvent être spécifiées comme indiqué + ci-après. Les bits les plus significatifs de ces valeurs sont utilisés, et + si les valeurs sont trop petites, elles sont complétées par bourrage avec + des bits à 0 par la gauche. +

+ +
+
file:
La valeur est lue directement depuis le fichier spécifié.
+
hex:
Interprète l'expression en tant que valeur hexadécimale qui + peut contenir des caractères ':' comme séparateurs.
+
decimal:
Interprète l'expression en tant que valeur décimale.
+
base64:
Interprète l'expression en tant que valeur codée en + base64.
+
none
Aucune valeur n'est spécifiée.
+
+ +

Si le IV n'est pas spécifié, un IV aléatoire sera généré au cours du + chiffrement et écrit comme premier bloc. Lors du déchiffrement, le premier + bloc sera interprété en tant que IV. +

+ +

A l'exception du format file:, les directives CryptoKey et CryptoIV supportent la syntaxe des expressions qui fournit plus de + flexibilité pour définir les valeurs. Les clés et IVs peuvent ainsi être + initialisées aléatoirement via des valeurs disponibles au niveau du serveur + web comme REMOTE_USER ou l'URL. +

+ +
top
+
+

Gestionnaire de clé de chiffrement

+ + +

Le gestionnaire crypto-key permet de fournir la clé aux + clients autorisés qui le supportent sans avoir à stocker cette dernière dans + l'arborescence du serveur web. La même syntaxe + d'expression peut ainsi être utilisée afin d'obtenir la clé pour les + clients et pour le contenu chiffré.

+ +

Gestionnaire de clé de chiffrement avec un fichier

+ <Location /key>
+ + SetHandler crypto-key
+ CryptoCipher aes128
+ CryptoKey file:/path/to/file.key
+ AuthType basic
+ ...
+ + </Location>
+

+ +
top
+
+

HTTP Live Streaming (HLS)

+ + +

Le protocole HLS supporte les flux chiffrés qui utilisent l'algorithme de + chiffrement AES-128 et une clé correspondante. On autorise l'accès au flux + en partageant la clé avec le client HLS en général via une connexion + sécurisée.

+ +

Le IV utilisé pour le chiffrement de chaque segment de media est spécifié + dans HLS de deux manières :

+ +
    +
  • + Spécifié explicitement via un attribut IV dans le tag EXT-X-KEY sous + la forme d'une valeur hexadécimale. +
    • +
  • + Spécifié implicitement en interprétant la valeur + décimale du tag EXT-X-MEDIA-SEQUENCE. +
    • +
+ +

La valeur de la séquence de media est en générale incorporée dans les + noms de segment de média et peut être recherchée en utilisant des + expressions rationnelles nommées comme dans l'exemple ci-dessous. +

+ +

Exemple HLS - IV de la séquence de média

+ <LocationMatch (?<SEQUENCE>[\d]+)[^\d^/]+$>
+ + SetOutputFilter ENCRYPT
+ CryptoCipher aes128
+ CryptoKey file:/path/to/file.key
+ CryptoIV decimal:%{env:MATCH_SEQUENCE}
+ + </LocationMatch>
+

+ +
+
top
+

Directive CryptoCipher

+ + + + + + + +
Description:L'algorithme de chiffrement que le filtre crypto doit utiliser
Syntaxe:CryptoCipher name
Défaut:CryptoCipher aes256
Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
Statut:Extension
Module:mod_crypto
+

La directive CryptoCipher permet de spécifier + l'algorithme de chiffrement à utiliser au cours des phases de chiffrement et + de déchiffrement. L'algorithme de chiffrement par défaut est + aes256.

+ +

C'est le pilote crypto utilisé qui détermine l'étendue du choix des algorithmes de + chiffrement parmi les valeurs possibles suivantes :

+ +
  • 3des192
  • aes128
  • aes192
  • aes256
+ + +
+
top
+

Directive CryptoDriver

+ + + + + + + +
Description:Nom du pilote crypto à utiliser
Syntaxe:CryptoDriver name
Défaut:CryptoDriver openssl
Contexte:configuration du serveur
Statut:Extension
Module:mod_crypto
+

La directive CryptoDriver + permet de spécifier le nom du pilote crypto à utiliser. Un pilote recommandé + par défaut est en général défini pour chaque plateforme. Les pilotes + supportés sont openssl, commoncrypto et + nss.

+ +
+
top
+

Directive CryptoIV

+ + + + + + + +
Description:Le Vecteur d'Initialisation IV (Initialisation Vector) que le +filtre crypto doit utiliser
Syntaxe:CryptoIV value
Défaut:CryptoIV none
Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
Statut:Extension
Module:mod_crypto
+

La directive CryptoIV permet de spécifier le IV + (Initialisation Vector) pour l'espace d'URL considéré. Le IV peut être lu à + partir d'un fichier ou défini via l'interpréteur + d'expressions, ce qui confère plus de souplesse aux scénarios de + définition des clés.

+ +

Les valeurs possibles peuvent être lues depuis un fichier ou exprimées + sous une forme hexadécimale, décimale ou en base64 en fonction des préfixes + suivants :

+ +
  • file:
  • hex:
  • decimal:
  • base64:
+ +

La valeur 'none' désactive la définition du IV. Dans ce cas, un IV + aléatoire sera généré durant le chiffrement et inséré en tant que premier + bloc ; au cours du déchiffrement, le premier bloc sera interprété comme bloc + IV.

+ +
+
top
+

Directive CryptoKey

+ + + + + + + +
Description:Clé que le filtre crypto doit utiliser
Syntaxe:CryptoKey value
Défaut:CryptoKey none
Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
Statut:Extension
Module:mod_crypto
+

La directive CryptoKey permet de spécifier la clé + de chiffrement/déchiffrement pour l'espace d'URL considéré. La clé peut être + lue depuis un fichier ou défini via l'interpréteur + d'expressions, ce qui confère plus de souplesse aux scénarios de + définition des clés.

+ +

Les valeurs possibles peuvent être lues depuis un fichier ou exprimées + sous une forme hexadécimale, décimale ou en base64 en fonction des préfixes + suivants :

+ +
  • file:
  • hex:
  • decimal:
  • base64:
+ +

La valeur 'none' désactive la clé. Toute requête pour obtenir sans clé un fichier + via les filtres ENCRYPT ou DECRYPT se soldera alors par un échec.

+ +
+
top
+

Directive CryptoSize

+ + + + + + + +
Description:Taille maximale en octets du tampon utilisé par le filtre crypto
Syntaxe:CryptoSize integer
Défaut:CryptoSize 131072
Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
Statut:Extension
Module:mod_crypto
+

La directive CryptoSize permet + de spécifier la quantité de données en octets qui sera mise en tampon pour + chaque requête avant d'être chiffrée ou déchiffrée. La valeur par défaut est + 128 Ko.

+ +
+
+
+

Langues Disponibles:  en  | + fr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_filter.html.en b/docs/manual/mod/mod_filter.html.en index ff63362a00..b2b764f90d 100644 --- a/docs/manual/mod/mod_filter.html.en +++ b/docs/manual/mod/mod_filter.html.en @@ -204,15 +204,15 @@ FilterChain gzip
Suppose we want to downsample all web images, and have filters for GIF, JPEG and PNG. 
FilterProvider unpack jpeg_unpack "%{CONTENT_TYPE} = 'image/jpeg'"
-FilterProvider unpack gif_unpack "%{CONTENT_TYPE} = 'image/gif'"
-FilterProvider unpack png_unpack "%{CONTENT_TYPE} = 'image/png'"
+FilterProvider unpack gif_unpack  "%{CONTENT_TYPE} = 'image/gif'"
+FilterProvider unpack png_unpack  "%{CONTENT_TYPE} = 'image/png'"
 
 FilterProvider downsample downsample_filter "%{CONTENT_TYPE} = m|^image/(jpeg|gif|png)|"
 FilterProtocol downsample "change=yes"
 
 FilterProvider repack jpeg_pack "%{CONTENT_TYPE} = 'image/jpeg'"
-FilterProvider repack gif_pack "%{CONTENT_TYPE} = 'image/gif'"
-FilterProvider repack png_pack "%{CONTENT_TYPE} = 'image/png'"
+FilterProvider repack gif_pack  "%{CONTENT_TYPE} = 'image/gif'"
+FilterProvider repack png_pack  "%{CONTENT_TYPE} = 'image/png'"
 <Location "/image-filter">
     FilterChain unpack downsample repack
 </Location>
diff --git a/docs/manual/mod/mod_firehose.html.fr b/docs/manual/mod/mod_firehose.html.fr new file mode 100644 index 0000000000..07b83a7d45 --- /dev/null +++ b/docs/manual/mod/mod_firehose.html.fr @@ -0,0 +1,316 @@ + + + + + +mod_firehose - Serveur Apache HTTP Version 2.5 + + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+ +
+

Module Apache mod_firehose

+
+

Langues Disponibles:  en  | + fr 

+
+ + + +
Description:Multiplexage des entrées/sorties vers un fichier ou un pipe.
Statut:Extension
Identificateur de Module:firehose_module
Fichier Source:mod_firehose.c
+

Sommaire

+ +

mod_firehose fournit un mécanisme permettant + d'enregistrer les données transmises entre le serveur httpd et le + client au niveau élémentaire de la connexion dans un fichier ou un + pipe, de façon à ce que les données puissent être analysées ou + rejouées ultérieurement par le serveur. Il s'apparente à un "tcpdump + pour httpd".

+ +

Les connexions sont enregistrées après décodage de la couche SSL, + et peuvent ainsi être utilisées dans le cadre d'une réquisition + légale.

+ +

L'utilitaire firehose permet en retour de + démultiplexer le flux enregistré dans des fichiers individuels pour + analyse ou rejeu via des outils tels que netcat.

+ +

AVERTISSEMENT

Ce module ignore tout mécanisme + invoqué au niveau de la requête pour rendre les données privées. Il + est donc de la responsabilité de l'administrateur de s'assurer que + les données privées ne seront pas compromises par son utilisation. +
+ +
+ +
top
+
+

Activation de la "Lance à incendie" (Firehose)

+ + +

Pour activer ce module, il doit être compilé et chargé via la + configuration de votre instance httpd courante, et les directives + ci-dessous permettent de sélectionner les données que vous souhaitez + enregistrer.

+ +

Il est possible d'enregistrer les données entrantes et sortantes + dans le même fichier, car la direction du flux est indiquée dans + chaque fragment.

+ +

Il est possible d'écrire vers des fichiers normaux ou des listes + fifos (pipes). Dans le cas des listes fifos, mod_firehose fait en + sorte que la taille des paquets ne dépasse pas la valeur de PIPE_BUF + afin de s'assurer que l'écriture de ces derniers s'effectue en une + seule fois.

+ +

Si une liste fifo sous forme de pipe doit être utilisée, pour que + cette dernière soit ouverte en écriture, certaines données doivent + en être extraites avant le démarrage de httpd. Si l'ouverture du + pipe échoue, mod_firehose ne sera pas activé, et le serveur sera + lancé normalement.

+ +

Par défaut, toute tentative d'écriture bloque le serveur. Si le + serveur a été compilé avec APR version 2.0 ou supérieure, et si le + paramètre "nonblock" a été spécifié, les écritures dans les fichiers + seront non blocantes, et tout dépassement de tampon entraînera la + perte des données de débogage. Dans ce cas, il est possible donner + la priorité à l'exécution du serveur sur l'enregistrement des + données firehose.

+ +
top
+
+

Format du flux

+ + +

En général, le serveur gère plusieurs connexions simultanément, + et de ce fait, les requêtes et les réponses doivent être + multiplexées avant d'être écrites dans le firehose.

+ +

Chaque fragment se présente sous la forme d'un texte en clair + de façon à ce qu'un firehose puisse être ouvert et inspecté par un + éditeur de texte standard. Il est aussi possible d'utiliser + l'utilitaire firehose pour démultiplexer le + firehose en requêtes ou connexions individuelles.

+ +

La taille maximale des fragments multiplexés est définie par la + variable PIPE_BUF. Elle correspond à la taille maximale d'un + élément que le système peut écrire. Si la taille des fragments + multiplexés reste en dessous de PIPE_BUF, le module garantit que les + contenus des différents fragments ne se recouperont pas. La valeur + de PIPE_BUF varie en fonction du système d'exploitation.

+ +

La BNF du format du fragment est la suivante :

+ + 
 stream = 0*(fragment)
+
+ fragment = header CRLF body CRLF
+
+ header = length SPC timestamp SPC ( request | response ) SPC uuid SPC count
+
+ length = <longueur de fragment sur 16 octets hexadécimaux>
+ timestamp = <temps depuis 1970 en microsecondes sur 16 octets hexadécimaux>
+ request = "<"
+ response = ">"
+ uuid = <uuid formaté de la connexion>
+ count = <numéro hexadécimal du fragment dans la connexion>
+
+ body = <contenu binaire du fragment>
+
+ SPC = <un espace>
+ CRLF = <un retour chariot suivi d'une nouvelle ligne>
+ +

Tous les fragments d'une connexion ou d'une requête partagent le + même UUID, selon que les connexions ou les requêtes sont + enregistrées ou non. Si les connexions sont enregistrées, plusieurs + requêtes peuvent apparaître dans la même connexion. Un fragment de + longueur nulle indique la fin de la connexion.

+ +

Certains fragments peuvent manquer ou être supprimés si le + processus qui les lit est trop lent. Si cela se produit, il y aura + des trous dans le comptage des connections. Un avertissement + indiquant l'UUID et le numéro du fragment supprimé sera enregistré + dans le journal des erreurs.

+ +

En cas de crash ou d'arrêt forcé du processus httpd, il est + possible que le fragment vide de terminaison n'apparaisse pas. Cela + peut aussi se produire si le processus qui lit les fragments n'est + pas assez rapide.

+ +
+
top
+

Directive FirehoseConnectionInput

+ + + + + + + + +
Description:Capture le trafic entrant dans le serveur à chaque +connexion.
Syntaxe:FirehoseConnectionInput [ block | nonblock ] filename
Défaut:none
Contexte:configuration du serveur
Statut:Extension
Module:mod_firehose
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Capture le trafic entrant dans le serveur à chaque connexion. + Plusieurs requêtes seront capturées pour la même connexion si les + connexions persistantes sont activées.

+ +

Exemple

FirehoseConnectionInput connection-input.firehose
+
+ +
+
top
+

Directive FirehoseConnectionOutput

+ + + + + + + + +
Description:Capture le trafic sortant du serveur à chaque connexion
Syntaxe:FirehoseConnectionOutput [ block | nonblock ] filename
Défaut:none
Contexte:configuration du serveur
Statut:Extension
Module:mod_firehose
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Capture le trafic sortant du serveur à chaque connexion. + Plusieurs requêtes seront capturées pour la même connexion si les + connexions persistantes sont activées. +

+ +

Exemple

FirehoseConnectionOutput connection-output.firehose
+
+ +
+
top
+

Directive FirehoseProxyConnectionInput

+ + + + + + + + +
Description:Capture le trafic entrant dans mod_proxy
Syntaxe:FirehoseProxyConnectionInput [ block | nonblock ] filename
Défaut:none
Contexte:configuration du serveur
Statut:Extension
Module:mod_firehose
Compatibilité:
+

Capture le trafic reçu par mod_proxy.

+ +

Exemple

FirehoseProxyConnectionInput proxy-input.firehose
+
+ +
+
top
+

Directive FirehoseProxyConnectionOutput

+ + + + + + + + +
Description:Capture le trafic envoyé par mod_proxy
Syntaxe:FirehoseProxyConnectionOutput [ block | nonblock ] filename
Défaut:none
Contexte:configuration du serveur
Statut:Extension
Module:mod_firehose
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Capture le trafic envoyé par mod_proxy.

+ +

Exemple

FirehoseProxyConnectionOutput proxy-output.firehose
+
+ +
+
top
+

Directive FirehoseRequestInput

+ + + + + + + + +
Description:Capture le trafic entrant dans le serveur à chaque requête
Syntaxe:FirehoseRequestInput [ block | nonblock ] filename
Défaut:none
Contexte:configuration du serveur
Statut:Extension
Module:mod_firehose
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Capture le trafic entrant dans le serveur à chaque requête. Les + requêtes sont capturées séparément, que les connexions persistantes + soient activées ou non.

+ +

Exemple

FirehoseRequestInput request-input.firehose
+
+ +
+
top
+

Directive FirehoseRequestOutput

+ + + + + + + + +
Description:Capture le trafic sortant du serveur à chaque requête
Syntaxe:FirehoseRequestOutput [ block | nonblock ] filename
Défaut:none
Contexte:configuration du serveur
Statut:Extension
Module:mod_firehose
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Capture le trafic sortant du serveur à chaque requête. Les + requêtes sont capturées séparément, que les connexions persistantes + soient activées ou non.

+ +

Exemple

FirehoseRequestOutput request-output.firehose
+
+ +
+
+
+

Langues Disponibles:  en  | + fr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_http2.html.fr b/docs/manual/mod/mod_http2.html.fr new file mode 100644 index 0000000000..8d116b80fa --- /dev/null +++ b/docs/manual/mod/mod_http2.html.fr @@ -0,0 +1,1043 @@ + + + + + +mod_http2 - Serveur Apache HTTP Version 2.5 + + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+ +
+

Module Apache mod_http2

+
+

Langues Disponibles:  en  | + fr 

+
+ + + + +
Description:Support de la couche transport HTTP/2
Statut:Extension
Identificateur de Module:http2_module
Fichier Source:mod_http2.c
Compatibilité:Disponible à partir de la version 2.4.17 du serveur + HTTP Apache
+

Sommaire

+ +

Ce module ajoute le support de HTTP/2 (RFC 7540) au serveur HTTP + Apache.

+ +

Il s'appuie sur la bibliothèque libnghttp2 pour implémenter le + moteur de base http/2.

+ +

Avertissement

+

Ce module en est au stade expérimental. Ses comportements, + directives et valeurs par défaut sont susceptibles d'évoluer + au fur et à mesure de la parution de ses futures différentes + versions en relation avec les autres modules standards. Les + utilisateurs sont fortement encouragés à consulter le fichier + "CHANGES" pour les éventuelles mises à jour.

+
+ +

Pour mettre en oeuvre les fonctionnalités décrites dans ce + document, vous devez activer HTTP/2 en utilisant la directive + Protocols. HTTP/2 n'imposant + pas de chiffrement, deux protocoles sont disponibles : + h2 (HTTP/2 avec TLS) at h2c (HTTP/2 avec TCP).

+ +

Voici deux types de configuration courant :

+ +

HTTP/2 dans un contexte de serveur virtuel (TLS seulement)

+ 
Protocols h2 http/1.1
+ +

Permet une négociation HTTP/2 (h2) via TLS ALPN au sein d'un + <VirtualHost> + sécurisé. La vérification du préambule HTTP/2 (mode direct, voir + H2Direct) est désactivée par + défaut pour h2.

+
+ +

HTTP/2 dans un contexte de serveur (TLS et texte pur)

+ 
Protocols h2 h2c http/1.1
+ +

Permet une négociation HTTP/2 (h2) via TLS ALPN au sein d'un + <VirtualHost> + sécurisé. Permet aussi une négociation HTTP/2 en texte pur (h2c) en + effectuant une mise à jour depuis une connexion initiale HTTP/1.1 ou via + une vérification du préambule HTTP/2 (mode direct, voir + H2Direct).

+
+ +

Si vous avez besoin d'informations supplémentaires à propos du + protocole, veuillez vous reporter à la HTTP/2 FAQ.

+ + +
+ +
top
+
+

Comment ça marche ?

+ +

Quantification des ressources + supplémentaires nécessaires à HTTP/2

+

+ Activer HTTP/2 sur votre serveur Apache a un impact sur la + consommation de ressources, et si votre site est très actif, il est + conseillé d'en prendre sérieusement en compte les implications. +

+

+ HTTP/2 attribue à chaque requête qu'il reçoit son propre thread + de travail pour son traitement, la collecte des résultats et + l'envoie de ces derniers au client. Pour y parvenir, il lui faut + lancer des threads supplémentaires, et ceci constituera le premier + effet notable de l'activation de HTTP/2. +

+

+ Dans l'implémentation actuelle, ces threads de travail font partie + d'un jeu de threads distinct de celui des threads de travail du MPM + avec lequel vous êtes familié. Il s'agit simplement du mode de + fonctionnement actuel, et il n'en sera pas obligatoirement toujours + ainsi (il est cependant probable que la situation restera inchangée + avec la version 2.4.x). De par ce mode de fonctionnement, les + threads de travail HTTP/2, ou plus simplement H2 ne seront pas + affichés par mod_status. De même, ils ne seront pas + pris en compte par les directives du style ThreadsPerChild. Par contre, ils + utilisent par défaut la valeur de ThreadsPerChild si vous n'avez pas + spécifié d'autres valeurs via H2MinWorkers et H2MaxWorkers. +

+

+ Autre changement à surveiller : la consommation de mémoire. En + effet, comme HTTP/2 conserve plus d'informations sur le serveur pour + gérer toutes les requêtes en cours, leurs priorités et + interdépendances, il aura toujours besoin de plus de mémoire que + pour un traitement en HTTP/1.1. Trois directives permettent de + limiter l'empreinte mémoire d'une connexion HTTP/2 : H2MaxSessionStreams, H2WindowSize et H2StreamMaxMemSize. +

+

+ La directive H2MaxSessionStreams permet de limiter + le nombre de requêtes simultanées qu'un client peut envoyer sur une + connexion HTTP/2. La valeur que vous allez définir dépend de votre + site. La valeur par défaut qui est de 100 est largement suffisante, + et à moins que vous ne soyez un peu juste en mémoire, je vous + conseille de ne pas la modifier. La plupart des requêtes qu'envoie + un client sont des requêtes de type GET sans corps qui n'utilisent + que très peu de mémoire en attendant le démarrage du traitement. + +

+

+ La directive H2WindowSize + permet de définir la taille maximale que peut avoir le corps d'une + requête que le client envoie avant d'attendre que le serveur + en demande d'avantage. En d'autres termes, il s'agit de la quantité + de données que le serveur peut stocker dans son tampon, valable pour + une requête. +

+

+ En outre, la directive H2StreamMaxMemSize permet de définir + la quantité de données de la réponse qui doit être mise en tampon. + Chaque requête étant prise en charge par un thread H2Worker et + produisant des données que le serveur tente de transmettre au client + via une connexion HTTP/2, si le client n'est pas en mesure de lire + ces données assez rapidement, la connexion les mettra en tampon et + interrompra l'exécution du thread H2Worker correspondant. +

+ + + +

Serveurs virtuels et requêtes mal + redirigées

+

+ De nombreux site utilisent le même certificat TLS pour plusieurs + serveurs virtuels. Ce certificat référence un nom de serveur + générique comme '*.example.org' ou plusieurs noms de serveur + différents. Les navigateurs qui utilisent HTTP/2 détectent ce + comportement et réutilisent une connexion déjà ouverte pour ces + serveurs. +

+

+ Ceci améliore considérablement les performances, mais il y a un prix + à payer : il faut accorder un soin tout particulier à la + configuration de tels serveurs virtuels. Le problème réside dans le + fait que plusieurs requêtes pour plusieurs serveurs virtuels vont se + partager la même connexion TLS, et ceci empêche toute renégociation + car le standard HTTP/2 l'interdit. +

+

+ Ainsi, lorsque plusieurs de vos serveurs virtuels utilisent le même + certificat et si vous souhaitez utiliser HTTP/2 pour y accéder, vous + devez vous assurer que tous vos serveurs virtuels possèdent + exactement la même configuration SSL. En particulier, ils doivent + utiliser les mêmes protocole, algorithme de chiffrement et + configuration pour la vérification du client. +

+

+ Dans le cas contraire, Apache httpd le détectera et renverra au + client un code de réponse spécial, 421 Misdirected Request. +

+ + +

Variables d'environnement

+ +

Ce module peut être configuré pour fournir des informations en + rapport avec HTTP/2 sous la forme de variables d'environnement + supplémentaires dans l'espace de nommage SSI et CGI, ainsi que dans les + configurations personnalisées de le journalisation (voir + %{VAR_NAME}e). +

+ + + + + + + + + + + + + + + +
Nom variable :Type :Description :
HTTPedrapeauHTTP/2 est utilisé.
H2PUSHdrapeauLa + fonctionnalité HTTP/2 Server Push est activée pour cette requête et + supportée par le client.
H2_PUSHdrapeauautre nom pour H2PUSH
H2_PUSHEDchaînevide ou + PUSHED pour une requête pushée par le serveur.
H2_PUSHED_ONnombrenuméro du + flux HTTP/2 qui a déclenché le push de cette requête.
H2_STREAM_IDnombrenuméro du + flux HTTP/2 de cette requête.
H2_STREAM_TAGchaîneidentifiant + de flux unique du processus HTTP/2 composé de l'identifiant de la + connexion et de l'identifiant du flux séparés par -.
+ + + +
+
top
+

Directive H2CopyFiles

+ + + + + + + + + +
Description:Contrôle la gestion des fichiers dans les réponses
Syntaxe:H2CopyFiles on|off
Défaut:H2CopyFiles off
Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
AllowOverride:FileInfo
Statut:Extension
Module:mod_http2
Compatibilité:Disponible à partir de la version 2.4.24 du serveur HTTP + Apache.
+

+ Cette directive permet de définir la manière de gérer les + contenus de fichiers dans les réponses. Lorsqu'elle est à off + (sa valeur par défaut), les descripteurs de fichiers sont + transmis par le processus de traitement de la requête vers la + connexion principale en utilisant le système habituel de mise en + réserve d'Apache pour gérer le durée de vie du fichier. +

+

+ Lorsqu'elle est à on, le contenu du fichier est + recopier pendant le traitement de la requête et ces données + mises en tampon sont transmises vers la connexion principale, ce + qui s'avère avantageux lorsqu'un module tiers injecte dans la + réponse des fichiers possédant des durées de vie différentes. +

+

+ Un exemple de ces modules tiers : mod_wsgi qui peut + injecter des descripteurs de fichiers dans la réponse. Ces + fichiers sont fermés lorsque Python estime que le traitement est + terminé, alors que mod_http2 est probablement + encore loin d'en avoir fini avec eux. +

+ +
+
top
+

Directive H2Direct

+ + + + + + + +
Description:Activation du protocole H2 Direct
Syntaxe:H2Direct on|off
Défaut:H2Direct on pour h2c, off pour le protocole h2
Contexte:configuration du serveur, serveur virtuel
Statut:Extension
Module:mod_http2
+

+ Cette directive permet d'activer/désactiver + l'utilisation du mode HTTP/2 Direct. Elle doit être + située dans une section <VirtualHost> afin d'activer la + communication directe HTTP/2 pour le serveur virtuel + considéré. +

+

+ La notion de communication directe signifie que si les + premiers octets reçus par le serveur correspondent à un + en-tête HTTP/2, le protocole HTTP/2 est utilisé sans + négociation supplémentaire. Ce mode est défini pour + les transmissions en clair (h2c) dans la RFC 7540. Son + utilisation avec les connexions TLS n'est pas + officiellement supportée. +

+

+ Lorsque le protocole h2 ou h2c n'est pas activé via la + directive Protocols, la recherche d'un en-tête HTTP/2 n'est + jamais effectuée au sein d'une connexion. La directive + H2Direct ne produit alors aucun effet. Ceci est + important pour les connexions qui utilisent un protocole + pour lequel une lecture initiale peut entraîner un + blocage définitif comme NNTP. +

+

+ Pour un client qui sait qu'un serveur supporte h2c, la + communication directe HTTP/2 dispense le client d'une + mise à jour HTTP/1.1, ce qui entraîne une amélioration + des performances et évite les restrictions sur les corps + de requête suite à une mise à jour. +

+

+ Cette directive rend aussi h2c plus attractif pour les + communications de serveur à serveur lorsque la connexion + est sure ou peut être sécurisée d'une manière ou d'une + autre. +

+

Exemple

H2Direct on
+
+ +
+
top
+

Directive H2EarlyHints

+ + + + + + + + +
Description:Contrôle l'envoi de codes d'état 103
Syntaxe:H2EarlyHints on|off
Défaut:H2EarlyHints off
Contexte:configuration du serveur, serveur virtuel
Statut:Extension
Module:mod_http2
Compatibilité:Disponible à partir de la version 2.4.24 du serveur HTTP + Apache.
+

+ Cette directive permet de définir si les réponses intermédiaires + contenant un code d'état HTTP 103 doivent être envoyées au + client ou non. Par défaut ce n'est actuellement pas le cas car + certains clients ont encore des problèmes avec les réponses + intermédiaires inattendues. +

+

+ Lorsque cette directive est définie à on, les + ressources PUSHées définie par la directive + H2PushResource déclenchent une réponse + intermédiaire 103 avant la réponse finale. Cette réponse 103 + comporte des en-têtes Link qui provoquent le + préchargement des ressources considérées. +

+ +
+
top
+

Directive H2MaxSessionStreams

+ + + + + + + +
Description:Nombre maximal de flux actifs par session HTTP/2.
Syntaxe:H2MaxSessionStreams n
Défaut:H2MaxSessionStreams 100
Contexte:configuration du serveur, serveur virtuel
Statut:Extension
Module:mod_http2
+

+ Cette directive permet de définir le nombre maximal de flux + actifs par session (connexion) HTTP/2 accepté par le serveur. + Selon la RFC 7540, un flux est considéré comme actif s'il n'est + ni en attente ni fermé. +

+

Exemple

H2MaxSessionStreams 20
+
+ +
+
top
+

Directive H2MaxWorkerIdleSeconds

+ + + + + + + +
Description:Nombre maximal de secondes pendant lequel une unité de + traitement h2 pourra rester inactive sans être arrêtée.
Syntaxe:H2MaxWorkerIdleSeconds n
Défaut:H2MaxWorkerIdleSeconds 600
Contexte:configuration du serveur
Statut:Extension
Module:mod_http2
+

+ Cette directive permet de définir le nombre maximal de secondes + pendant lequel une unité de traitement h2 pourra rester inactive + avant de s'arrêter elle-même. Cet arrêt ne peut cependant se + produire que si le nombre d'unités de traitement h2 dépasse + H2MinWorkers. +

+

Exemple

H2MaxWorkerIdleSeconds 20
+
+ +
+
top
+

Directive H2MaxWorkers

+ + + + + + +
Description:Nombre maximal de threads à utiliser pour chaque processus + enfant.
Syntaxe:H2MaxWorkers n
Contexte:configuration du serveur
Statut:Extension
Module:mod_http2
+

+ Cette directive permet de définir le nombre maximal de threads à + lancer pour le traitement HTTP/2 de chaque processus enfant. Si + cette directive n'est pas définie, mod_http2 + choisira une valeur appropriée en fonction du module mpm + utilisé. + + This directive sets the maximum number of worker threads to spawn + per child process for HTTP/2 processing. If this directive is not used, + mod_http2 will chose a value suitable for the mpm + module loaded. +

+

Exemple

H2MaxWorkers 20
+
+ +
+
top
+

Directive H2MinWorkers

+ + + + + + +
Description:Nombre minimal de threads à utiliser pour chaque processus + enfant.
Syntaxe:H2MinWorkers n
Contexte:configuration du serveur
Statut:Extension
Module:mod_http2
+

+ Cette directive permet de définir le nombre minimal de threads à + lancer pour le traitement HTTP/2 de chaque processus enfant. Si + cette directive n'est pas définie, mod_http2 + choisira une valeur appropriée en fonction du module mpm + utilisé. +

+

Exemple

H2MinWorkers 10
+
+ +
+
top
+

Directive H2ModernTLSOnly

+ + + + + + + + +
Description:Impose les connexions HTTP/2 en mode "TLS moderne" + seulement
Syntaxe:H2ModernTLSOnly on|off
Défaut:H2ModernTLSOnly on
Contexte:configuration du serveur, serveur virtuel
Statut:Extension
Module:mod_http2
Compatibilité:Disponible à partir de la version 2.4.18 du serveur HTTP + Apache.
+

+ Cette directive permet de définir si les vérifications de + sécurité sur les connexions HTTP/2 doivent être exclusivement en + mode TLS (https:). Elle peut être placée au niveau du serveur + principal ou dans une section <VirtualHost>. +

+

+ Les vérifications de sécurité nécessitent TLSv1.2 au minimum et + l'absence de tout algorithme de chiffrement listé dans la RFC + 7540, Appendix A. Ces vérifications seront étendues lorsque de + nouveaux prérequis en matière de sécurité seront mis en place. +

+

+ Le nom provient des définitions Mozilla Security/Server + Side TLS où il est question de "modern compatibility". + Mozilla Firefox et d'autres navigateurs imposent la "modern + compatibility" pour les connexions HTTP/2. Comme toute chose en + matière de sécurité opérationnelle, c'est une cible mouvante + susceptible d'évoluer dans le futur. +

+

+ Un des buts de ces vérifications dans mod_http2 tend à imposer + ce niveau de sécurité pour toutes les connexions, et non + seulement celles en provenance des navigateurs web. Un autre but + est l'interdiction d'utiliser HTTP/2 en tant que protocole dans + les négociations si les prérequis ne sont pas respectés. +

+

+ En fin de compte, la sécurité de la connexion TLS est déterminée + par les directives de configuration du serveur pour mod_ssl. +

+

Exemple

H2ModernTLSOnly off
+
+ +
+
top
+

Directive H2Push

+ + + + + + + + +
Description:Activation/désactivation du server push H2
Syntaxe:H2Push on|off
Défaut:H2Push on
Contexte:configuration du serveur, serveur virtuel
Statut:Extension
Module:mod_http2
Compatibilité:Disponible à partir de la version 2.4.18 du serveur HTTP + Apache.
+

+ Cette directive permet d'activer/désactiver + l'utilisation de la fonctionnalité server push du + protocole HTTP/2. +

+

+ Lorsqu'un client demande une ressource particulière, le + protocole HTTP/2 permet au serveur de lui fournir des + ressources supplémentaires. Ceci s'avère utile lorsque + ces ressources sont reliées entre elles, ce qui peut + laisser supposer que le client va probablement les + demander dans un délai plus ou moins long. Le mécanisme + de pushing permet alors au client d'économiser le temps + qu'il lui aurait fallu pour demander ces ressources + supplémentaires lui-même. Par contre, fournir au client + des ressources dont il n'a pas besoin ou qu'il possède + déjà constitue une perte de bande passante. +

+

+ Les server pushes sont détectés en inspectant les + en-têtes Link des réponses (voir + https://tools.ietf.org/html/rfc5988 pour la + spécification). Lorsqu'un lien spécifié de cette manière + possède l'attribut rel=preload, il est + considéré comme devant faire l'objet d'un push. +

+

+ Les en-têtes link des réponses sont soit définis par + l'application, soit configurés via + mod_headers comme suit : +

+

Exemple de configuration d'en-tête link via mod_headers

<Location /index.html>
+    Header add Link "</css/site.css>;rel=preload"
+    Header add Link "</images/logo.jpg>;rel=preload"
+</Location>
+
+

+ Comme le montre l'exemple, il est possible d'ajouter + autant d'en-têtes link que l'on souhaite à une réponse, ce qui déclenchera + autant de pushes. Cette fonctionnalité doit donc être + utilisée avec prudence car le module ne vérifie pas si + une ressource n'a pas déjà été "pushée" vers un client. +

+

+ Les server pushes HTTP/2 sont activés par défaut. Cette + directive permet de désactiver cette fonctionnalité pour + le serveur virtuel ou non considéré. +

+

Exemple

H2Push off
+
+

+ Enfin, il est important de savoir que les pushes ne se + produisent que si le client en manifeste le désir ; la + plupart des navigateurs le font, mais certains, comme + Safari 9, ne le font pas. En outre, les pushes ne se produisent que + pour les ressources de la même autorité que celle de la + réponse originale. +

+ +
+
top
+

Directive H2PushDiarySize

+ + + + + + + + +
Description:Taille du journal des Pushes H2
Syntaxe:H2PushDiarySize n
Défaut:H2PushDiarySize 256
Contexte:configuration du serveur, serveur virtuel
Statut:Extension
Module:mod_http2
Compatibilité:Disponible à partir de la version 2.4.19 du serveur HTTP + Apache.
+

+ Cette directive permet de définir le nombre maximum de pushes + qui seront enregistrés pour une connexion HTTP/2. Elle peut être + placée dans une section <VirtualHost> afin de définir le nombre + de pushes pour le serveur virtuel considéré. +

+

+ Le journal des pushes enregistre un condensé (sous la forme d'un + nombre de 64 bits) des ressources préchargées (leurs URLs) afin + d'éviter les duplications de pushes pour une même connexion. + Cependant, ces données ne sont pas conservées, et les clients + qui ouvrent une nouvelle connexion se verront à nouveau affecter les + mêmes pushes. A ce titre, une étude est en cours pour permettre + au client de supprimer le condensé des ressources qu'il possède + déjà, et par là-même de réinitialiser le journal des pushes à + chaque nouvelle connexion. +

+

+ Si la taille maximale est atteinte, les nouvelles entrées + remplacent les plus anciennes. Une entrée du journal nécessitant + 8 octets, un journal de 256 entrées consomme 2 Ko de mémoire. +

+

+ Si cette directive est définie à 0, le journal des pushes est + désactivé. +

+ +
+
top
+

Directive H2PushPriority

+ + + + + + + + +
Description:Priorité des pushes H2
Syntaxe:H2PushPriority mime-type [after|before|interleaved] [weight]
Défaut:H2PushPriority * After 16
Contexte:configuration du serveur, serveur virtuel
Statut:Extension
Module:mod_http2
Compatibilité:Disponible à partir de la version 2.4.18 du serveur HTTP + Apache. Nécessite la bibliothèque nghttp2 version 1.5.0 ou supérieure.
+

+ Cette directive permet de définir une gestion de priorité des + pushes en fonction du type de contenu de la réponse. Elle est en + général définie au niveau du serveur principal, mais peut aussi + l'être au niveau d'un serveur virtuel. +

+

+ Les pushes HTTP/2 sont toujours liés à une requête client. + Chaque paire requête/réponse de cette sorte, ou flux, + possède une dépendance et un poids qui définissent la + priorité du flux. +

+

+ Lorsqu'un flux dépend d'un autre, disons X dépend de Y, + alors Y reçoit toute la bande passante avant que X n'en reçoive + ne serait-ce qu'une partie. Notez que cela ne signifie en rien + que Y bloque X ; en effet, si Y n'a aucune donnée à envoyer, + toute la bande passante qui lui est allouée peut être utilisée + par X. +

+

+ Lorsque plusieurs flux dépendent d'un même autre flux, disons X1 + et X2 dépendent tous deux de Y, le poids détermine la + bande passante allouée. Ainsi, si X1 et X2 possèdent le même + poids, ils recevront tous deux la moitié de la bande passante + disponible. Si le poids de X1 est égal au double de celui de X2, + X1 recevra une bande passante double de celle de X2. + +

+

+ En fin de compte, tout flux dépend du flux racine qui + reçoit toute la bande passante disponible mais n'envoie jamais + de données. Cette bande passante est ainsi répartie entre les flux + enfants selon leur poids. Ces derniers l'utilisent alors pour + envoyer leurs données ou pour la répartir entre leurs propres + flux enfants, et ainsi de suite. Si aucun des flux enfants n'a + de données à envoyer, la bande passante est attribuée à d'autres + flux selon les mêmes règles. +

+

+ Ce système de priorités a été conçu de façon a toujours pouvoir + utiliser la bande passante disponible tout en définissant des + priorités et en attribuant des poids aux différents flux. Ainsi, + tous les flux sont en général initialisés par le client qui + lui-même définit les priorités. +

+

+ Seul le fait de savoir qu'un flux implique un PUSH permet au + serveur de décider quelle est la priorité initiale d'un + tel flux. Dans les exemples ci-dessous, X est le flux client. Il + dépend de Y et le serveur décide de "PUSHer" les flux P1 et P2 + sur X. +

+

+ La règle de priorité par défaut est : +

+

Règle de priorité par défaut

H2PushPriority * After 16
+
+

+ Elle peut se traduire par "Envoyer un flux PUSH avec tout type + de contenu et dépendant du flux client avec le poids 16". P1 et + P2 seront alors envoyés après X, et comme leurs poids sont + identiques, il se verront allouer la même quantité de bande + passante. +

+

Règle de priorité entrelacée

H2PushPriority text/css Interleaved 256
+
+

+ Ce qui peut se traduire par "Envoyer toute ressource CSS dans la + même dépendance et avec le même poids que le flux client". Si le + type de contenu de P1 est "text/css", il dépendra de Y (comme X) + et son poids effectif sera calculé selon la formule : P1ew + = Xw * (P1w / 256). Si P1w est de 256, Le poids effectif + de P1 sera le même que celui de X. Si X et P1 ont des données à + envoyer, il se verront allouer la même quantité de bande + passante. +

+

+ Avec un Pw de 512, un flux entrelacé et PUSHé aura un poids + double de celui de X. Avec un poids de 128, son poids ne sera + que la moitié de celui de X. Notez que les poids effectifs sont + toujours plafonnés à 256. + +

+

Règle de priorité Before

H2PushPriority application/json Before
+
+

+ Dans cet exemple, tout flux PUSHé dont le contenu est de type + 'application/json' sera envoyé avant X, ce qui rend P1 + dépendant de Y et X dépendant de P1. Ainsi, X sera mis en + attente aussi longtemps que P1 aura des données à envoyer. Le + poids effectif est hérité du flux client, et l'attribution d'un + poids spécifique n'est pas autorisée. +

+

+ Vous devez garder à l'esprit que les spécifications en matière + de priorités sont limitées par les ressources disponibles du + serveur. Si un serveur ne dispose d'aucun processus/thread de + travail pour les flux PUSHés, les données du flux considéré ne + seront envoyées que lorsque les autres flux auront terminé + l'envoi des leurs. +

+

+ Enfin et surtout, il convient de tenir compte de certaines + particularités de la syntaxe de cette directive : +

+
    +
  1. '*' est la seule expression permettant de remplacer tout + type de contenu. 'image/*' ne fonctionnera pas.
    2. +
  2. La dépendance par défaut est 'After'.
    3. +
  3. Il existe aussi des poids par défaut : pour 'After' le poids + est de 16, alors que pour 'interleaved' il est de 256. +
    4. +
+

Exemples de règles

H2PushPriority application/json 32         # une règle de priorité 'After'
+H2PushPriority image/jpeg before           # poid hérité
+H2PushPriority text/css   interleaved      # poids de 256 par défaut
+
+ +
+
top
+

Directive H2PushResource

+ + + + + + + + +
Description:Déclare des ressources à proposer ("pusher") au client
Syntaxe:H2PushResource [add] path [critical]
Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
AllowOverride:FileInfo
Statut:Extension
Module:mod_http2
Compatibilité:Disponible à partir de la version 2.4.24 du serveur HTTP + Apache.
+

+ Lorsqu'il sont activés pour un répertoire, les PUSHes HTTP/2 seront + tentés pour tous les chemins ajoutés via cette directive. Cette + dernière peut être utilisée plusieurs fois pour le même + répertoire. +

+

+ Cette directive propose des ressources beaucoup plus tôt que les + en-têtes Link de mod_headers. + mod_http2 présente ces ressources au client via + une réponse intermédiaire 103 Early Hints. Ceci + implique que les clients qui ne supportent pas PUSH recevront + quand-même rapidement des propositions de préchargement. +

+

+ A la différence de la définition d'en-têtes de réponse + Link via mod_headers, cette + directive n'aura d'effet que pour les connexions HTTP/2. +

+

+ En ajoutant l'option critical à une telle + ressource, le serveur la traitera prioritairement, et une fois + les données disponibles, ces dernières seront envoyées avant les + données de la requête principale. +

+ +
+
top
+

Directive H2SerializeHeaders

+ + + + + + + +
Description:Active/désactive la sérialisation du traitement des + requêtes/réponses
Syntaxe:H2SerializeHeaders on|off
Défaut:H2SerializeHeaders off
Contexte:configuration du serveur, serveur virtuel
Statut:Extension
Module:mod_http2
+

+ Cette directive permet de définir si les requêtes HTTP/2 doivent + être sérialisées au format HTTP/1.1 pour être traitées par le + noyau de httpd, ou si les données binaires reçues + doivent être passées directement aux request_recs. +

+

+ La sérialisation dégrade les performances, mais garantit une + meilleure compatibilité ascendante lorsque des filtres ou + programmes accroche personnalisés en ont besoin. +

+

Exemple

H2SerializeHeaders on
+
+ +
+
top
+

Directive H2StreamMaxMemSize

+ + + + + + + +
Description:Quantité maximale de données en sortie mises en tampon par + flux.
Syntaxe:H2StreamMaxMemSize bytes
Défaut:H2StreamMaxMemSize 65536
Contexte:configuration du serveur, serveur virtuel
Statut:Extension
Module:mod_http2
+

+ Cette directive permet de définir la quantité maximale de + données en sortie mises en tampon mémoire pour un flux actif. Ce + tampon mémoire n'est pas alloué pour chaque flux en tant que + tel. Les quantités de mémoire sont définies en fonction de + cette limite lorsqu'elles sont sur le point d'être allouées. Le + flux s'arrête lorsque la limite a été atteinte, et ne reprendra + que lorsque les données du tampon auront été transmises au + client. +

+

Exemple

H2StreamMaxMemSize 128000
+
+ +
+
top
+

Directive H2TLSCoolDownSecs

+ + + + + + + + +
Description:
Syntaxe:H2TLSCoolDownSecs seconds
Défaut:H2TLSCoolDownSecs 1
Contexte:configuration du serveur, serveur virtuel
Statut:Extension
Module:mod_http2
Compatibilité:Disponible à partir de la version 2.4.18 du serveur HTTP + Apache.
+

+ Cette directive permet de spécifier le nombre de secondes avant + lequel une connexion TLS inactive va diminuer + la taille des paquets de données à une valeur inférieure (~1300 + octets). Elle peut être définie au niveau du serveur principal + ou pour un <serveur + virtuel> spécifique. +

+

+ Voir la directive H2TLSWarmUpSize pour une description + du "préchauffage" de TLS. La directive H2TLSCoolDownSecs met en + lumière le fait que les connexions peuvent se détériorer au bout + d'un certain temps (et au fur et à mesure des corrections du + flux TCP), et cela même si elle sont inactives. Pour ne pas + détériorer les performances d'une manière générale, il est par + conséquent préférable de revenir à la phase de préchauffage + lorsqu'aucune donnée n'a été transmise pendant un certain nombre + de secondes. +

+

+ Dans les situations où les connexions peuvent être considérées + comme fiables, ce délai peut être désactivé en définissant cette + directive à 0. +

+

+ Dans l'exemple suivant, la directive est définie à 0, ce qui + désactive tout retour à une phase de préchauffage des connexions + TLS. Les connexions TLS déjà préchauffées conservent donc toujours + leur taille de paquet de données maximale. +

+

Exemple

H2TLSCoolDownSecs 0
+
+ +
+
top
+

Directive H2TLSWarmUpSize

+ + + + + + + + +
Description:
Syntaxe:H2TLSWarmUpSize amount
Défaut:H2TLSWarmUpSize 1048576
Contexte:configuration du serveur, serveur virtuel
Statut:Extension
Module:mod_http2
Compatibilité:Disponible à partir de la version 2.4.18 du serveur HTTP + Apache.
+

+ Cette directive permet de définir le nombre d'octets à envoyer + dans les petits enregistrements TLS (~1300 octets) avant + d'atteindre leur taille maximale de 16 ko pour les connexions + https: HTTP/2. Elle peut être définie au niveau du serveur + principal ou pour des <Serveurs virtuels> spécifiques. +

+

+ Les mesures effectuées par les laboratoires de performances de + Google montrent que les meilleurs performances sont atteintes + pour les connexions TLS si la taille initiale des + enregistrements reste en deça du niveau du MTU afin de permettre + à la totatlité d'un enregistrement d'entrer dans un paquet IP. +

+

+ Comme TCP ajuste son contrôle de flux et sa taille de fenêtre, + des enregistrements TLS trop longs peuvent rester en file + d'attente ou même être perdus et devoir alors être réémis. Ceci + est bien entendu vrai pour tous les paquets ; cependant, TLS a + besoin de la totalité de l'enregistrement pour pouvoir le + déchiffrer. Tout octet manquant rendra impossible l'utilisation + de ceux qui ont été reçus. +

+

+ Lorqu'un nombre suffisant d'octets a été transmis avec succès, + la connexion TCP est stable, et la taille maximale (16 ko) des + enregistrements TLS peut être utilisée pour des performances + optimales. +

+

+ Dans les architectures où les serveurs sont atteints par des + machines locales ou pour les connexions de confiance seulement, + la valeur de cette directive peut être définie à 0, ce qui a + pour effet de désactiver la "phase de chauffage". +

+

+ Dans l'exemple suivant, la phase de chauffage est effectivement + désactivée en définissant la directive à 0. +

+

Exemple

H2TLSWarmUpSize 0
+
+ +
+
top
+

Directive H2Upgrade

+ + + + + + + +
Description:Activation/Désactivation du protocole de mise à jour H2
Syntaxe:H2Upgrade on|off
Défaut:H2Upgrade on pour h2c, off pour h2
Contexte:configuration du serveur, serveur virtuel
Statut:Extension
Module:mod_http2
+

+ Cette directive permet d'activer/désactiver l'utilisation de la + méthode de mise à jour pour passer de HTTP/1.1 à HTTP/2. Elle + doit être placée dans une section <VirtualHost> afin d'activer la mise à + jour vers HTTP/2 pour le serveur virtuel considéré. +

+

+ Cette méthode de changement de protocole est définie dans + HTTP/1.1 et utilise l'en-tête "Upgrade" (d'où son nom) pour + indiquer l'intention d'utiliser un autre protocole. Cet en-tête + peut être présent dans toute requête sur une connexion HTTP/1.1. +

+

+ Elle activée par défaut pour les transmissions en clair + (h2c), et désactivée avec TLS (h2), comme préconisé par la RFC + 7540. +

+

+ Sachez cependant que les mises à jour ne sont acceptées que pour + les requêtes qui ne possèdent pas de corps. Le requêtes de type + POST et PUT avec un contenu ne feront jamais l'objet d'une mise + à jour vers HTTP/2. Se référer à la documentation de la + directive H2Direct pour + envisager une alternative à Upgrade. +

+

+ Cette directive n'a d'effet que si h2 ou h2c est activé via la + directive Protocols. +

+

Exemple

H2Upgrade on
+
+ +
+
top
+

Directive H2WindowSize

+ + + + + + + +
Description:Taille maximale des paquets de données pour les transmissions client + vers serveur.
Syntaxe:H2WindowSize bytes
Défaut:H2WindowSize 65535
Contexte:configuration du serveur, serveur virtuel
Statut:Extension
Module:mod_http2
+

+ Cette directive permet de définir la taille maximale des paquets + de données envoyés par le client au serveur, et + limite la quantité de données que le serveur doit mettre en + tampon. Le client arrêtera d'envoyer des données sur un flux + lorsque cette limite sera atteinte jusqu'à ce que le serveur + indique qu'il dispose d'un espace suffisant (car il aura traité + une partie des données). +

+ Cette limite n'affecte que les corps de requêtes, non les + métadonnées comme les en-têtes. Par contre, elle n'affecte pas + les corps de réponses car la taille maximale de ces derniers est + gérée au niveau des clients. +

+

Exemple

H2WindowSize 128000
+
+ +
+
+
+

Langues Disponibles:  en  | + fr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_journald.html.fr b/docs/manual/mod/mod_journald.html.fr new file mode 100644 index 0000000000..2bc79f3df2 --- /dev/null +++ b/docs/manual/mod/mod_journald.html.fr @@ -0,0 +1,148 @@ + + + + + +mod_journald - Serveur Apache HTTP Version 2.5 + + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+ +
+

Module Apache mod_journald

+
+

Langues Disponibles:  en  | + fr 

+
+ + + +
Description:Implémentation du fournisseur de journalisation d'erreurs +"journald"
Statut:Extension
Identificateur de Module:journald_module
Fichier Source:mod_journald.c
+

Sommaire

+ +

Ce module implémente le fournisseur de journalisation d'erreurs + "journald". Il permet l'enregistrement des messages d'erreur et la + gestion des journaux personnalisés via systemd-journald(8).

+
+

Sujets

+

Directives

+

Ce module ne fournit aucune directive.

+

Traitement des bugs

Voir aussi

+
+
top
+
+

Jounalisation structurée

+ +

Systemd-journald permet d'effectuer une journalisation + structurée, et autorise donc le filtrage des messages en fonction de + diverses variables. Les variables actuellement supportées sont : +

+
+
LOG
+
Le nom du journal. Pour ErrorLog, la valeur est "error_log". + Pour CustomLog ou TransferLog, la valeur correspond au premier + argument de ces directives.
+
REQUEST_HOSTNAME
+
Le nom d'hôte tel qu'il est fourni dans l'URI, ou l'en-tête + Host: de la requête.
+
REQUEST_USER
+
Correspond au nom d'utilisateur si une authentification a eu + lieu.
+
REQUEST_USERAGENT_IP
+
L'adresse IP de l'agent qui a envoyé la requête.
+
REQUEST_URI
+
La partie chemin de l'URI, ou "/" si l'URI ne contient pas de + chemin.
+
SERVER_HOSTNAME
+
Le nom d'hôte du serveur pour lequel le message a été généré.
+
+ +

Ces variables peuvent par exemple être utilisées pour ne montrer + que les messages concernant un URI particulier via la commande + journalctl : +

+ + 
journalctl REQUEST_URI=/index.html -a
+ + +

Pour d'autres exemples, voir la documentation de + systemd-journalctl.

+
top
+
+

Exemples

+ + +

Si le système le supporte, il est possible d'utiliser + systemd-journald(8) pour effectuer la journalisation en spécifiant + journald à la place d'un nom de fichier dans la + directive ErrorLog (voir core). +

+ + 
ErrorLog journald
+ + +

Spécifier journald comme fournisseur de journal + d'erreurs avec la directive CustomLog (voir + mod_log_config) active la journalisation via + systemd-journald(8) si le système le supporte. +

+ + 
CustomLog "journald" "%h %l %u %t \"%r\" %>s %b"
+ + +

Avertissement en matière de performances

+ Actuellement, systemd-journald n'est pas conçu pour une + jounalisation à haut débit et son utilisation pour la journalisation + des accès peut induire une baisse importante de performances. +

+ +
+
+
+

Langues Disponibles:  en  | + fr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_policy.html.fr b/docs/manual/mod/mod_policy.html.fr new file mode 100644 index 0000000000..e98be317a8 --- /dev/null +++ b/docs/manual/mod/mod_policy.html.fr @@ -0,0 +1,742 @@ + + + + + +mod_policy - Serveur Apache HTTP Version 2.5 + + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+ +
+

Module Apache mod_policy

+
+

Langues Disponibles:  en  | + fr 

+
+ + + +
Description:Mise en conformité avec le protocole HTTP.
Statut:Extension
Identificateur de Module:policy_module
Fichier Source:mod_policy.c
+

Sommaire

+ +

Le protocole HTTP recommande aux clients d'être "indulgents pour + ce qu'ils doivent accepter", et aux serveurs d'être "stricts pour ce + qu'ils envoient". Dans certains cas, il peut s'avérer difficile de + déterminer si un serveur ou une application a été mal configuré, + sert un contenu qui ne peut pas être mis en cache ou se comporte de + manière non optimale, car le client HTTP est souvent en mesure de + compenser les défauts du serveur. Ces problèmes peuvent induire une + consommation de bande passante excessive, ou même une interruption + de service suite à une charge trop importante du serveur.

+ +

Le module mod_policy propose un jeu de filtres + qui permettent de tester la conformité du serveur au protocole HTTP. + Ces tests permettent à l'administrateur du serveur de journaliser + les violations, ou même de rejeter une réponse losque certaines + conditions spécifiées se réalisent.

+ +

Il devient ainsi possible de définir des critères de conformité + minimale au protocole HTTP pour développer des applications + sans problème. En outre, il est possible de configurer un + mandataire inverse ou un cache pour qu'il se protège lui-même contre + les serveurs d'origine mal configurés ou les contenus indument + impossible à être mis en cache, ou un mécanisme qui détecte les + erreurs de configuration au sein du serveur lui-même.

+ +
+ +
top
+
+

Actions

+ + +

Si une règle est violée, il possible d'effectuer les actions + suivantes :

+ +
+
ignore
+
La vérification de la politique de conformité sera désactivée + pour l'espace d'URL spécifié, même si le filtre est présent.
+ +
log
+
La vérification de la politique de conformité sera exécutée, et + si une violation est détectée, un avertissement sera enregistré dans + le journal error_log du serveur, et un en-tête Warning + ajouté à la réponse en tant qu'information à destination du client.
+ +
enforce
+
La vérification de la politique de conformité sera exécutée, + + The policy check will be executed, and if a violation is detected + an error will be logged to the server error_log, a + Warning header added to the response, and a 502 + Bad Gateway will be returned to the client. Optional links to + explanatory documentation can be added to each error message, + detailing the origin of each policy.
+ +
+ +

Il est aussi possible de désactiver toutes les règles pour un + espace d'URL donné, si le besoin s'en fait sentir, via la directive + PolicyFilter.

+ +

En outre, la directive PolicyEnvironment permet de + spécifier une variable d'environnement qui, si elle est définie, va + court-circuiter les règles ou diminuer leur portée.

+ +
top
+
+

Tests de la politique de filtrage

+ + +

Les filtres suivants sont disponibles :

+ +
+
POLICY_TYPE + : Impose la validité des types de contenus
+
La requête peut être rejetée suite à la présence de types de contenus vides + ou syntaxiquement invalides. Les types peuvent aussi être restreints + à une liste pouvant contenir des caractères génériques ? et *.
+ +
POLICY_LENGTH + : Impose la présence de l'en-tête Content-Length
+
La longueur des réponses peut être spécifiée de trois manières + différentes : en spécifiant à l'avance une longueur explicite, en + utilisant un codage de morcellement (chunking) pour définir la + longueur, ou en ne spécifiant aucune longueur et en terminant la + requête lorsque son traitement est achevé. L'absence de + spécification d'une longueur de contenu peut affecter la possibilité + de mise en cache de la réponse, et empêcher l'utilisation de la + persistance avec les requêtes de type HTTP/1.0. Ce filtre impose la + présence d'une longueur de contenu explicite dans la réponse.
+ +
POLICY_KEEPALIVE + : Impose l'option de persistance
+
Moins restrictif que le filtre POLICY_LENGTH, ce filtre impose + la possibilité de persistance de la réponse. Si la réponse n'a pas + de longueur définie à 0 par le protocole, si elle n'est pas une + erreur, et si elle ne contient pas d'en-tête Content-Length ou si + elle est de type HTTP/1.1 et ne contient pas l'en-tête + Content-Encoding: chunked, alors elle sera rejetée.
+ +
POLICY_VARY + : Interdit la présence de certains en-têtes au sein des + en-têtes Vary
+
Si l'en-tête Vary contient un des en-têtes spécifiés, ce filtre + va rejeter la requête. Un cas typique est la présence de l'en-tête + User-Agent dans l'en-tête Vary, ce qui peut être à l'origine d'une + condition de déni de service au niveau du cache.
+ +
+ POLICY_VALIDATION: Impose la présence d'un en-tête Etag + et/ou Last-Modified
+
La possibilité pour un cache de déterminer si une entité qu'il + contient peut être rafraîchie dépend de la présence d'un en-tête + Etag et/ou Last-Modified pour vérifier si elle est valide. La requête sera + rejetée en cas d'absence de ces deux en-têtes, ou d'une syntaxe + invalide d'un de ces deux en-têtes.
+ +
+ POLICY_CONDITIONAL: Impose un traitement conforme des + en-têtes conditionnels
+
Lorsqu'une requête contient des en-têtes conditonnels, un + serveur doit répondre dans certaines conditions avec un code + 304 Not Modified ou 412 Precondition + Failed. Il arrive q'un serveur ignore les en-têtes + conditionnels, et cela diminue l'efficacité du mécanisme de mise en + cache HTTP. Ce filtre rejète les requêtes lorsqu'un en-tête + conditionnel était présent, et une réponse 2xx a été renvoyée au + lieu de la réponse 304 ou 412 attendue.
+ +
POLICY_NOCACHE + : Impose la possibilité de mise en cache des réponses
+
Lorsqu'une requête se déclare elle-même impossible à mettre en + cache, elle est rejetée. C'est le cas si elle contient l'un des + en-têtes suivants : +
  • Cache-Control: no-cache
    • +
  • Pragma: no-cache
    • +
  • Cache-Control: no-store
    • +
  • Cache-Control: private
    • +
+ +
POLICY_MAXAGE + : Impose une durée de vie minimale
+
Lorsqu'une réponse possède une durée de vie inférieure à la + valeur spécifiée, ou si cette durée de vie est heuristique, la + requête est rejetée. La chronologie de la vérification d'une réponse + est la suivante : +
  • Si s-maxage est présent mais d'une valeur trop + faible; ou
    • +
  • Si max-age est présent mais d'une valeur trop + faible; ou
    • +
  • Si Expires est présent et invalide; ou
    • +
  • Date est présent et invalide; ou
    • +
  • Expires moins Date est trop faible ; ou
    • +
  • Aucun en-tête s-maxage, maxage, ou + Expires/Date n'est présent
    • +
+ +
POLICY_VERSION + : Impose une version HTTP minimale dans la requête
+
Lorsqu'une requête possède un numéro de version HTTP inférieur + au numéro de version minimum requis, la requête est rejetée. Les + numéros de version suivants sont reconnus : +
  • HTTP/1.1
    • +
  • HTTP/1.0
    • +
  • HTTP/0.9
    • +
+ +
+ +
top
+
+

Exemple de configuration

+ + +

Voici un exemple de configuration qui protège un serveur qui + délivre du contenu statique :

+ + 
<Location "/">
+  SetOutputFilter POLICY_TYPE;POLICY_LENGTH;POLICY_KEEPALIVE;POLICY_VARY;POLICY_VALIDATION; \
+    POLICY_CONDITIONAL;POLICY_NOCACHE;POLICY_MAXAGE;POLICY_VERSION
+
+  # le contenu peut être quelconque, mais l'en-tête Content-Type doit être
+     # présent et valide
+  PolicyType enforce */*
+
+  # rejet si aucune longueur de contenu déclarée
+  PolicyLength enforce
+
+  # pris en charge par le filtre policy length
+  PolicyKeepalive ignore
+
+  # rejet si l'en-tête User-Agent aparaît dans les en-têtes Vary
+  PolicyVary enforce User-Agent
+
+  # la validation est imposée
+  PolicyValidation enforce
+
+  # les réponses conditionnelles non conformes sont rejetées
+  PolicyConditional enforce
+
+  # les réponses impossibles à mettre en cache sont rejetées
+  PolicyNocache enforce
+
+  # la durée de vie doit être au moins d'un jour
+  PolicyMaxage enforce 86400
+
+  # le numéro de version de la requête peut être quelconque
+  PolicyVersion ignore HTTP/1.1
+</Location>
+
+# désactivation du filtrage pour le répertoire /server-status
+<Location "/server-status">
+  PolicyFilter off
+</Location>
+ + +
+
top
+

Directive PolicyConditional

+ + + + + + + + +
Description:Active le filtrage des requêtes conditionnelles.
Syntaxe:PolicyConditional ignore|log|enforce
Défaut:ignore
Contexte:configuration du serveur, serveur virtuel, répertoire
Statut:Extension
Module:mod_policy
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Avec l'argument enforce, une réponse qui aurait du être + conditionnelle mais ne l'est pas sera rejetée.

+ +

Exemple

# les réponses conditionnelles non conformes doivent être rejetées
+PolicyConditional enforce
+
+ + + +
+
top
+

Directive PolicyConditionalURL

+ + + + + + + + +
Description:URL contenant la description de la politique de filtrage +des requêtes conditionnelles.
Syntaxe:PolicyConditionalURL url
Défaut:none
Contexte:configuration du serveur, serveur virtuel, répertoire
Statut:Extension
Module:mod_policy
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Cette directive permet de spécifier l'URL de la documentation + décrivant la politique de filtrage des requêtes conditionnelles ; + elle apparaîtra dans les messages d'erreur.

+ +
+
top
+

Directive PolicyEnvironment

+ + + + + + + + +
Description:Modification des règles de filtrage en fonction d'une +variable d'environnement.
Syntaxe:PolicyEnvironment variable log-value ignore-value
Défaut:none
Contexte:configuration du serveur, serveur virtuel, répertoire
Statut:Extension
Module:mod_policy
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Limite l'action des règles à la journalisation ou les désactive + totalement en fonction de la présence d'une variable d'environnement. Si + la variable spécifiée est présente et égale à la valeur de + l'argument log-value, les erreurs rencontrées par les filtres ne + seront que journalisées. Si la variable spécifiée est présente et + égale à la valeur de l'argument ignore-value, toutes les règles + seront ignorées.

+ +

Example

# limitation de l'action des règles si la variable POLICY_CONTROL
+# est présente
+PolicyEnvironment POLICY_CONTROL log ignore
+
+ +
+
top
+

Directive PolicyFilter

+ + + + + + + + +
Description:Active ou désactive le filtrage pour un espace d'URL donné.
Syntaxe:PolicyFilter on|off
Défaut:on
Contexte:configuration du serveur, serveur virtuel, répertoire
Statut:Extension
Module:mod_policy
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Commutateur principal qui permet d'activer ou de désactiver le + filtrage pour un espace d'URL donné.

+ +

Example

# activé par défaut
+<Location "/">
+  PolicyFilter on
+</Location>
+
+# désactivation du filtrage pour le répertoire /server-status
+<Location "/server-status">
+  PolicyFilter off
+</Location>
+
+ +
+
top
+

Directive PolicyKeepalive

+ + + + + + + + +
Description:Active la politique de persistance.
Syntaxe:PolicyKeepalive ignore|log|enforce
Défaut:ignore
Contexte:configuration du serveur, serveur virtuel, répertoire
Statut:Extension
Module:mod_policy
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Avec l'argument enforce, une réponse qui ne contient ni en-tête + Content-Length, ni en-tête + Transfer-Encoding de valeur chunked sera + rejetée.

+ +

Exemple

# rejet suite a absence d'en-tête Content-Length ou Transfer-Encoding
+PolicyKeepalive enforce
+
+ +
+
top
+

Directive PolicyKeepaliveURL

+ + + + + + + + +
Description:URL contenant la description de la politique de persistance.
Syntaxe:PolicyKeepaliveURL url
Défaut:none
Contexte:configuration du serveur, serveur virtuel, répertoire
Statut:Extension
Module:mod_policy
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Cette directive permet de spécifier l'URL contenant la + description de la politique de persistance ; elle apparaîtra dans + les messages d'erreur.

+ +
+
top
+

Directive PolicyLength

+ + + + + + + + +
Description:Active le filtrage de la spécification de la longueur du +contenu.
Syntaxe:PolicyLength ignore|log|enforce
Défaut:ignore
Contexte:configuration du serveur, serveur virtuel, répertoire
Statut:Extension
Module:mod_policy
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Avec l'argument enforce, une réponse qui ne contient pas + d'en-tête Content-Length sera rejetée.

+ +

Exemple

# rejet suite à l'absence de l'en-tête Content-Length
+PolicyLength enforce
+
+ +
+
top
+

Directive PolicyLengthURL

+ + + + + + + + +
Description:URL contenant la description de la politique de filtrage de +la spécification de la longueur du contenu.
Syntaxe:PolicyLengthURL url
Défaut:none
Contexte:configuration du serveur, serveur virtuel, répertoire
Statut:Extension
Module:mod_policy
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Cette directive permet de spécifier l'URL contenant la + documentation décrivant la politique de filtrage de la spécification + de la longueur du contenu ; elle apparaîtra dans les messages + d'erreur.

+ +
+
top
+

Directive PolicyMaxage

+ + + + + + + + +
Description:Active le filtrage de la durée de vie des réponses.
Syntaxe:PolicyMaxage ignore|log|enforce age
Défaut:ignore
Contexte:configuration du serveur, serveur virtuel, répertoire
Statut:Extension
Module:mod_policy
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Avec l'argument enforce, une réponse dont la durée de vie n'est + pas explicitement spécifiée via un en-tête max-age, + s-maxage ou Expires, ou dont la durée de + vie est inférieure à la valeur donnée sera rejetée.

+ +

Exemple

# rejet des réponses dont la durée de vie est inférieure à une
+# journée
+PolicyMaxage enforce 86400
+
+ + +
+
top
+

Directive PolicyMaxageURL

+ + + + + + + + +
Description:URL contenant la description de la politique de filtrage +des réponses en fonction de leur durée de vie.
Syntaxe:PolicyMaxageURL url
Défaut:none
Contexte:configuration du serveur, serveur virtuel, répertoire
Statut:Extension
Module:mod_policy
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Cette directive permet de spécifier l'URL contenant la + description de la politique de filtrage des réponses en fonction de + leur durée de vie ; elle apparaîtra dans les messages d'erreur.

+ +
+
top
+

Directive PolicyNocache

+ + + + + + + + +
Description:Active le filtrage des réponses qui se définissent +elles-mêmes comme impossibles à mettre en cache.
Syntaxe:PolicyNocache ignore|log|enforce
Défaut:ignore
Contexte:configuration du serveur, serveur virtuel, répertoire
Statut:Extension
Module:mod_policy
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Avec l'argument enforce, une réponse qui se définit elle-même + comme impossible à mettre en cache via l'en-tête + Cache-Control ou Pragma sera rejetée.

+ +

Exemple

# une réponse contenant l'en-tête Cache-Control: no-cache sera
+# rejetée
+PolicyNocache enforce
+
+ + +
+
top
+

Directive PolicyNocacheURL

+ + + + + + + + +
Description:URL contenant la description de la politique de filtrage +des réponses qui se définissent elles-mêmes comme impossibles à mettre +en cache.
Syntaxe:PolicyNocacheURL url
Défaut:none
Contexte:configuration du serveur, serveur virtuel, répertoire
Statut:Extension
Module:mod_policy
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Cette directive permet de spécifier l'URL contenant la + description de la politique de filtrage des réponses qui se + définissent elles-mêmes comme impossibles à mettre en cache ; elle + apparaîtra dans les messages d'erreur.

+ +
+
top
+

Directive PolicyType

+ + + + + + + + +
Description:Active la politique des types de contenus.
Syntaxe:PolicyType ignore|log|enforce type [ type [ ... ]]
Défaut:ignore
Contexte:configuration du serveur, serveur virtuel, répertoire
Statut:Extension
Module:mod_policy
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Avec l'argument enforce, une réponse qui ne contient pas + d'en-tête Content-Type, ou dont l'en-tête + Content-Type est mal formé, ou dont l'en-tête + Content-Type contient une valeur qui ne correspond pas + au(x) modèle(s) spécifié(s) sera rejetée.

+ +

Exemple

# impose le type de contenu json ou XML
+PolicyType enforce application/json text/xml
+
+ +

Exemple

# rejet suite à type de contenu mal formé
+PolicyType enforce */*
+
+ + +
+
top
+

Directive PolicyTypeURL

+ + + + + + + + +
Description:URL contenant la description de la politique des types de +contenu.
Syntaxe:PolicyTypeURL url
Défaut:none
Contexte:configuration du serveur, serveur virtuel, répertoire
Statut:Extension
Module:mod_policy
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Cette directive permet de spécifier l'URL contenant la + description de la politique des types de contenu ; elle apparaîtra + dans les messages d'erreur.

+ +
+
top
+

Directive PolicyValidation

+ + + + + + + + +
Description:Active le filtrage de la validation du contenu.
Syntaxe:PolicyValidation ignore|log|enforce
Défaut:ignore
Contexte:configuration du serveur, serveur virtuel, répertoire
Statut:Extension
Module:mod_policy
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Avec l'argument enforce, une réponse qui ne contient ni en-tête + ETag valide, ni en-tête Last-Modified, ou + dont la syntaxe d'un de ces deux en-têtes est incorrecte sera + rejetée.

+ +

Exemple

# rejet suite à l'absence des en-têtes Etag et/ou Last-Modified
+PolicyValidation enforce
+
+ + +
+
top
+

Directive PolicyValidationURL

+ + + + + + + + +
Description:URL contenant la description de la politique de filtrage de +la validation du contenu.
Syntaxe:PolicyValidationURL url
Défaut:none
Contexte:configuration du serveur, serveur virtuel, répertoire
Statut:Extension
Module:mod_policy
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Cette directive permet de spécifier l'URL contenant la + description de la politique de filtrage de la validation du contenu + ; elle apparaîtra dans les messages d'erreur.

+ +
+
top
+

Directive PolicyVary

+ + + + + + + + +
Description:Active la politique de filtrage de l'en-tête Vary.
Syntaxe:PolicyVary ignore|log|enforce header [ header [ ... ]]
Défaut:ignore
Contexte:configuration du serveur, serveur virtuel, répertoire
Statut:Extension
Module:mod_policy
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Avec l'argument enforce, une réponse dont l'en-tête + Vary contient un des en-têtes spécifiés sera rejetée.

+ +

Exemple

# rejet suite à la présence de l'en-tête "User-Agent" dans l'en-tête
+# Vary
+PolicyVary enforce User-Agent
+
+ + +
+
top
+

Directive PolicyVaryURL

+ + + + + + + + +
Description:URL contenant la description de la politique de filtrage de +l'en-tête Vary.
Syntaxe:PolicyVaryURL url
Défaut:none
Contexte:configuration du serveur, serveur virtuel, répertoire
Statut:Extension
Module:mod_policy
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Cette directive permet de spécifier l'URL contenant la + description de la politique de filtrage de l'en-tête Vary ; elle + apparaîtra dans les messages d'erreur.

+ +
+
top
+

Directive PolicyVersion

+ + + + + + + + +
Description:Active le filtrage des requêtes en fonction du numéro de +version HTTP.
Syntaxe:PolicyVersion ignore|log|enforce HTTP/0.9|HTTP/1.0|HTTP/1.1
Défaut:ignore
Contexte:configuration du serveur, serveur virtuel, répertoire
Statut:Extension
Module:mod_policy
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Avec l'argument enforce, une requête dont le numéro de version + HTTP est inférieur à la valeur spécifiée sera rejetée.

+ +

Exemple

# rejet des requêtes dont le numéro de version HTTP est inférieur à
+# HTTP/1.1
+PolicyVersion enforce HTTP/1.1
+
+ + +
+
top
+

Directive PolicyVersionURL

+ + + + + + + + +
Description:URL contenant la description de la politique de filtrage +des requêtes en fonction du numéro de version HTTP.
Syntaxe:PolicyVersionURL url
Défaut:none
Contexte:configuration du serveur, serveur virtuel, répertoire
Statut:Extension
Module:mod_policy
Compatibilité:Disponible à partir de la version 2.5.0 du serveur HTTP +Apache.
+

Cette directive permet de spécifier l'URL contenant la + description de la politique de filtrage des requêtes en fonction du + numéro de version HTTP ; elle apparaîtra dans les messages d'erreur.

+ +
+
+
+

Langues Disponibles:  en  | + fr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_proxy_hcheck.html.fr b/docs/manual/mod/mod_proxy_hcheck.html.fr new file mode 100644 index 0000000000..959582d30e --- /dev/null +++ b/docs/manual/mod/mod_proxy_hcheck.html.fr @@ -0,0 +1,299 @@ + + + + + +mod_proxy_hcheck - Serveur Apache HTTP Version 2.5 + + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+ +
+

Module Apache mod_proxy_hcheck

+
+

Langues Disponibles:  en  | + fr 

+
+ + + + +
Description:Check up dynamique des membres du groupe de répartition de charge +(équipiers) pour mod_proxy
Statut:Extension
Identificateur de Module:proxy_hcheck_module
Fichier Source:mod_proxy_hcheck.c
Compatibilité:Disponible à partir de la version 2.4.21 du serveur HTTP Apache
+

Sommaire

+ +

Ce module permet d'effectuer un check up dynamique des membres du groupe + de répartition de charge (équipiers). Ce check up peut être activé pour un + ou plusieurs équipiers et il est indépendant des requêtes de mandataire + inverse proprement dites.

+ +

Pour fonctionner, ce module nécessite le chargement préalable de + mod_watchdog.

+ +

Paramètres

+

Le mécanisme de check up est activé via l'utilisation de paramètres + supplémentaires de BalancerMember configurés de manière standard via la + directive ProxyPass :

+ +

Ce module définit un nouveau drapeau d'état pour BalancerMember : + "C". Lorsque l'équipier est mis hors service suite à un + disfonctionnement déterminé par le module de check up, ce drapeau est activé + et peut être lu (et modifié) via le balancer-manager.

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
ParamètreDéfautDescription
hcmethodNoneAucun check up dynamique n'est effectué. Les choix possibles sont : + + + + + + + + + + +
MethodDescriptionNote
NoneAucun check up dynamique effectué
TCPVérifie qu'un socket vers le serveur + d'arrière-plan peut être créé ; par exemple "es-tu en + état de fonctionner"
OPTIONSEnvoie une requête HTTP + OPTIONS au serveur d'arrière-plan*
HEADEnvoie une requête HTTP + HEAD au serveur d'arrière-plan*
GETEnvoie une requête HTTP + GET au serveur d'arrière-plan*
*: si hcexpr n'est pas + utilisé, un retour HTTP 2xx ou 3xx sera + interprété comme un passage avec succès du check + up.
+
hcpasses1Nombre de check up à passer avec succès avant de remettre en service + l'équipier
hcfails1Nombre de check up échoués avant mettre hors service l'équipier
hcinterval30Intervalle entre deux check up en secondes (par défaut effectué + toutes les 30 secondes). Utilise la syntaxe time-interval.
hcuri URI supplémentaire à ajouter à l'URL de l'équipier pour le check up.
hctemplate Nom du modèle créé via ProxyHCTemplate à + utiliser pour définir les paramètres de check up de cet équipier
hcexpr Nom de l'expression créée via ProxyHCExpr + utilisée pour analyser les en-têtes de la réponse du check up.
+ Si ce paramètre est absent, un état HTTP de 2xx à 3xx est + interprété comme un check up réussi.
+
+ +
+ +
top
+
+

Exemples d'utilisation

+ + +

L'exemple suivant montre comment configurer le check up pour différents + serveurs d'arrière-plan :

+ + + 
ProxyHCExpr ok234 {%{REQUEST_STATUS} =~ /^[234]/}
+ProxyHCExpr gdown {%{REQUEST_STATUS} =~ /^[5]/}
+ProxyHCExpr in_maint {hc('body') !~ /Under maintenance/}
+
+<Proxy balancer://foo>
+  BalancerMember http://www.example.com/  hcmethod=GET hcexpr=in_maint hcuri=/status.php
+  BalancerMember http://www2.example.com/  hcmethod=HEAD hcexpr=ok234 hcinterval=10
+  BalancerMember http://www3.example.com/ hcmethod=TCP hcinterval=5 hcpasses=2 hcfails=3
+  BalancerMember http://www4.example.com/
+</Proxy>
+
+ProxyPass "/" "balancer://foo"
+ProxyPassReverse "/" "balancer://foo"
+ + +

Dans ce scénario, on teste l'équipier http://www.example.com/ en lui +envoyant une requête GET /status.php et en regardant si la réponse +contient la chaîne Under maintenance. Si c'est le cas, le check up est +considéré comme ayant échoué et l'équipier est mis hors service. Ce check up +dynamique est effectué toutes les 30 secondes, ce qui correspond à la valeur par +défaut.

+ +

On teste l'équipier http://www2.example.com/ en lui envoyant +simplement une requête HEAD toutes les 10 secondes et en vérifiant +que la réponse HTTP est bien un code d'état de 2xx, 3xx ou 4xx. On teste +l'équipier http://www3.example.com/ en vérifiant simplement toutes +les 5 secondes que le socket vers ce serveur est bien opérationnel. Si ce +serveur est marqué "hors service", il lui faudra 2 check up réussis pour être +réactivé et participer à nouveau à la répartition de charge. Si à ce moment-là +il échoue à 3 check up successifs, il sera à nouveau mis hors service. Enfin, +l'équipier http://www4.example.com/ ne fait l'objet d'aucun check +up.

+ +
+
top
+

Directive ProxyHCExpr

+ + + + + + + +
Description:Crée et nomme une expression conditionnelle à utiliser pour +déterminer la santé d'un serveur d'arrière-plan en fonction de sa valeur.
Syntaxe:ProxyHCExpr name {ap_expr expression}
Contexte:configuration du serveur, serveur virtuel
AllowOverride:FileInfo
Statut:Extension
Module:mod_proxy_hcheck
+

La directive ProxyHCExpr permet de créer et nommer + une expression conditionnelle dont la valeur calculée en fonction des + en-têtes de la réponse du serveur d'arrière-plan permettra d'évaluer la + santé de ce dernier. Cette expression nommée peut alors être assignée aux + serveurs d'arrière-plan via le paramètre hcexpr.

+ +

ProxyHCExpr: interprète les réponses 2xx/3xx/4xx comme des + check up réussis

ProxyHCExpr ok234 {%{REQUEST_STATUS} =~ /^[234]/}
+ProxyPass "/apps"     "balancer://foo"
+
+<Proxy balancer://foo>
+  BalancerMember http://www2.example.com/  hcmethod=HEAD hcexpr=ok234 hcinterval=10
+</Proxy>
+
+ +
+ L'expression peut utiliser des accolades ("{}") + comme délimiteurs en plus des guillemets normaux. +
+ +

Si l'on utilise une méthode de check up (par exemple GET) + qui génère un corps de réponse, ce corps peut lui-même être ausculté via + ap_expr en utilisant la fonction associée aux expressions + hc() spécifique à ce module.

+ +

Dans l'exemple suivant, on envoie une requête GET au serveur + d'arrière-plan, et si le corps de la réponse contient la chaîne Under + maintenance, ce serveur d'arrière-plan est mis hors service.

+ +

ProxyHCExpr: auscultation du corps de la réponse

ProxyHCExpr in_maint {hc('body') !~ /Under maintenance/}
+ProxyPass "/apps"     "balancer://foo"
+
+<Proxy balancer://foo>
+  BalancerMember http://www.example.com/ hcexpr=in_maint hcmethod=get hcuri=/status.php
+</Proxy>
+
+ +

NOTE: Comme le corps de la réponse peut être assez grand, il est + recommandé de privilégier un check up basé sur les codes d'état.

+ +
+
top
+

Directive ProxyHCTemplate

+ + + + + + + +
Description:Crée et nomme un modèle permettant de définir différents +paramètres de check up
Syntaxe:ProxyHCTemplate name parameter=setting <...>
Contexte:configuration du serveur, serveur virtuel
AllowOverride:FileInfo
Statut:Extension
Module:mod_proxy_hcheck
+

La directive ProxyHCTemplate permet de créer et + nommer un modèle de paramètres de check up qui peut alors être assigné aux + équipiers via le paramètre hctemplate

+ +

ProxyHCTemplate

ProxyHCTemplate tcp5 hcmethod=tcp hcinterval=5
+ProxyPass "/apps"     "balancer://foo"
+
+<Proxy balancer://foo>
+  BalancerMember http://www2.example.com/ hctemplate=tcp5
+</Proxy>
+
+ + +
+
top
+

Directive ProxyHCTPsize

+ + + + + + +
Description:Définit la taille totale, pour l'ensemble du +serveur, du jeu de threads utilisé pour le check up des +équipiers.
Syntaxe:ProxyHCTPsize <size>
Contexte:configuration du serveur
Statut:Extension
Module:mod_proxy_hcheck
+

Si Apache httpd et APR ont été compilés avec le support des threads, le + module de check up peut confier ce travail à un jeu de threads associé au + processus Watchdog, ce qui permet l'exécution des check up en parallèle. La + directive ProxyHCTPsize permet de déterminer la + taille de ce jeu de threads. Une valeur de 0 signifie qu'aucun + jeu de threads ne sera utilisé, et le check up des différents équipiers sera + alors effectué séquentiellement. La taille par défaut du jeu de threads est + de 16.

+ +

ProxyHCTPsize

ProxyHCTPsize 32
+
+ + +
+
+
+

Langues Disponibles:  en  | + fr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_proxy_http2.html.fr b/docs/manual/mod/mod_proxy_http2.html.fr new file mode 100644 index 0000000000..b75d5d1d1e --- /dev/null +++ b/docs/manual/mod/mod_proxy_http2.html.fr @@ -0,0 +1,154 @@ + + + + + +mod_proxy_http2 - Serveur Apache HTTP Version 2.5 + + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+ +
+

Module Apache mod_proxy_http2

+
+

Langues Disponibles:  en  | + fr 

+
+ + + +
Description:Support de HTTP/2 pour mod_proxy
Statut:Extension
Identificateur de Module:proxy_http2_module
Fichier Source:mod_proxy_http2.c
+

Sommaire

+ +

mod_proxy_http2 ne + supporte que HTTP/2 et ne permet pas de rétrogradation vers HTTP/1.1. Cela + signifie que le serveur d'arrière-plan doit supporter HTTP/2 car HTTP/1.1 ne + pourra alors pas être utilisé.

+ +

Ce module nécessite la présence de mod_proxy ; + pour pouvoir traiter les requêtes mandatées HTTP/2, + mod_proxy et mod_proxy_http2 doivent donc + être chargés par le serveur.

+ +

mod_proxy_http2 travaille avec des requêtes entrantes en + HTTP/1.1 ou HTTP/2. Dans les deux cas, les requêtes vers le même serveur + d'arrière-plan sont envoyées + via une seule connexion TCP, dans la mesure du possible (autrement dit + lorsque la connexion peut être réutilisée).

+ +

Avertissement : il ne sera effectué aucune tentative de fusion de + plusieurs requêtes entrantes HTTP/1 (devant être mandatées vers le même + serveur d'arrière-plan) vers des flux HTTP/2 appartenant à la même requête + HTTP/2. Chaque requête HTTP/1 entrante sera mandatée vers le serveur + d'arrière-plan en utilisant une requête HTTP/2 séparée (tout en réutilisant + si possible la même connexion TCP).

+ +

Ce module s'appuie sur libnghttp2 pour + fournir le moteur central http/2.

+ +

Avertissement

Ce module en est au + stade expérimental. Ses comportement, directives et valeurs par défauts sont + donc susceptibles de modifications d'une version à l'autre plus fréquentes + que pour les autres modules. A ce titre, il est fortement conseillé aux + utilisateurs de consulter le fichier "CHANGES" pour prendre connaissance de + ces modifications.

+ +

Avertissement

+

N'activez pas le mandatement avant d'avoir sécurisé votre serveur. Les serveurs + mandataires ouverts sont dangereux non seulement pour votre propre réseau, + mais aussi pour l'Internet au sens large.

+
+
+

Sujets

+

Directives

+

Ce module ne fournit aucune directive.

+

Traitement des bugs

Voir aussi

+
+
top
+
+

Exemples de base

+ +

Les exemples ci-dessous montrent comment configurer HTTP/2 pour des + connexions d'arrière-plan vers un mandataire inverse.

+ +

HTTP/2 (TLS)

ProxyPass "/app" "h2://app.example.com"
+ProxyPassReverse "/app" "https://app.example.com"
+
+ +

HTTP/2 (non sécurisé)

ProxyPass "/app" "h2c://app.example.com"
+ProxyPassReverse "/app" "http://app.example.com"
+
+ +
+

Pour mandater en inverse les protocoles h2 ou + h2c, on utilise la directive + ProxyPassReverse avec les schèmes habituels + https et respectivement + http qui sont connus et utilisés par l'agent utilisateur.

+
+
top
+
+

Informations sur les requêtes

+

mod_proxy_http fournit les informations sur les requêtes + suivantes pour enregistrement dans les journaux en utilisant le format + %{VARNAME}n avec les directives LogFormat ou ErrorLogFormat : +

+
+
proxy-source-port
+
Le numéro de port local utilisé pour la connexion vers le serveur + d'arrière-plan.
+
proxy-status
+
Le statut HTTP/2 en provenance du serveur d'arrière-plan.
+
+
+
+
+

Langues Disponibles:  en  | + fr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_proxy_wstunnel.html.fr b/docs/manual/mod/mod_proxy_wstunnel.html.fr new file mode 100644 index 0000000000..4f7a4f9214 --- /dev/null +++ b/docs/manual/mod/mod_proxy_wstunnel.html.fr @@ -0,0 +1,157 @@ + + + + + +mod_proxy_wstunnel - Serveur Apache HTTP Version 2.5 + + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+ +
+

Module Apache mod_proxy_wstunnel

+
+

Langues Disponibles:  en  | + fr 

+
+ + + + +
Description:Module pour mod_proxy supportant les +websockets
Statut:Extension
Identificateur de Module:proxy_wstunnel_module
Fichier Source:mod_proxy_wstunnel.c
Compatibilité:Disponible à partir de la version 2.4.5 du serveur HTTP +Apache
+

Sommaire

+ +

Pour utiliser ce module, mod_proxy doit être + chargé. Il fournit le support du tunnelling pour les connexions + websocket vers un serveur websockets d'arrière-plan. La connexion + est automatiquement promue en connexion websocket :

+ +

Réponse HTTP

Upgrade: WebSocket
+Connection: Upgrade
+
+ +

Le mandatement des requêtes vers un serveur websockets comme +echo.websocket.org peut être configuré via la directive ProxyPass :

+ 
ProxyPass "/ws2/"  "ws://echo.websocket.org/"
+ProxyPass "/wss2/" "wss://echo.websocket.org/"
+ + +

La répartition de charge entre plusieurs serveurs d'arrière-plan peut être +configurée via le module mod_proxy_balancer.

+ +

En fait, ce module permet d'accepter d'autres protocoles ; vous pouvez à cet +effet utiliser le paramètre upgrade de la directive ProxyPass. La valeur NONE +signifie que vous court-circuitez la consultation de l'en-tête, mais que vous +autorisez quand-même WebSocket. La valeur ANY signifie que Upgrade +va lire les en-têtes de la requête et les utilisera dans l'en-tête +Upgrade de la réponse.

+
+ + +
top
+

Directive ProxyWebsocketAsync

+ + + + + + +
Description:Création d'un tunnel asynchrone
Syntaxe:ProxyWebsocketAsync ON|OFF
Contexte:configuration du serveur, serveur virtuel
Statut:Extension
Module:mod_proxy_wstunnel
+

Cette directive permet d'imposer la création d'un tunnel + asynchrone. Si le module MPM utilisé ne supporte pas les + fonctionnalités nécessaires, le tunnel est créé en mode synchrone.

+

Note

Le support du mode asynchrone est + au stade expérimental et est susceptible d'évoluer.

+ +
+
top
+

Directive ProxyWebsocketAsyncDelay

+ + + + + + + +
Description:Temps d'attente synchrone maximum pour des données
Syntaxe:ProxyWebsocketAsyncDelay num[ms]
Défaut:ProxyWebsocketAsyncDelay 0
Contexte:configuration du serveur, serveur virtuel
Statut:Extension
Module:mod_proxy_wstunnel
+

Si la directive ProxyWebsocketAsync est + activée, cette directive permet de définir le temps maximum pendant lequel + le serveur attendra des données en mode synchrone. Par défaut, ce temps est exprimé + en secondes, mais vous pouvez le spécifier en millisecondes en utilisant le + suffixe ms.

+ +

Note

Le support du mode asynchrone est + au stade expérimental et est susceptible d'évoluer.

+ +
+
top
+

Directive ProxyWebsocketIdleTimeout

+ + + + + + + +
Description:Temps d'attente maximum pour des données sur le tunnel websockets
Syntaxe:ProxyWebsocketIdleTimeout num[ms]
Défaut:ProxyWebsocketIdleTimeout 0
Contexte:configuration du serveur, serveur virtuel
Statut:Extension
Module:mod_proxy_wstunnel
+

Cette directive permet de définir un temps maximum pendant lequel + le tunnel pourra rester ouvert et inactif. Par défaut, ce temps est exprimé + en secondes, mais vous pouvez le spécifier en millisecondes en utilisant le + suffixe ms.

+ +
+
+
+

Langues Disponibles:  en  | + fr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_ssl_ct.html.fr b/docs/manual/mod/mod_ssl_ct.html.fr new file mode 100644 index 0000000000..c6c6307087 --- /dev/null +++ b/docs/manual/mod/mod_ssl_ct.html.fr @@ -0,0 +1,672 @@ + + + + + +mod_ssl_ct - Serveur Apache HTTP Version 2.5 + + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+ +
+

Module Apache mod_ssl_ct

+
+

Langues Disponibles:  en  | + fr 

+
+ + + +
Description:Implémentation de la transparence des certificats +(Certificat Transparency - RFC 6962) +
Statut:Extension
Identificateur de Module:ssl_ct_module
Fichier Source:mod_ssl_ct.c
+

Sommaire

+ + +

Ce module implémente la transparence des certificats en conjonction +avec mod_ssl et les outils en ligne de commande du +projet open source certificate-transparency. +Le but de la transparence des certificats consiste à révéler +l'utilisation de certificats de confiance délivrés par +erreur ou dans un but malintentionné. Vous trouverez plus de détails à +propos de la transparence des certificats ici : http://www.certificate-transparency.org/. +Voici la signification des termes utilisés dans cette documentation :

+ +
+
Certificate log
+
Un Certificate log, auquel on fera référence avec le simple + terme log tout au long de ce document, est un service réseau + auquel les certificats de serveurs sont soumis. Un agent + utilisateur peut vérifier que le certificat d'un serveur auquel il + accède a bien été soumis à un log auquel il fait confiance, et que le log + lui-même n'a pas rencontré de problème avec ce certificat.
+ +
Horodatage signé du certificat (Signed Certificate Timestamp - SCT)
+
Il s'agit d'une information en provenance d'un log indiquant qu'il + a validé un certificat. Cet horodatage est signé avec la clé publique + du log. Un ou plusieurs SCTs sont passés au client durant la phase de + négociation de la connexion, soit dans le ServerHello (extension TLS), + soit dans l'extension du certificat, soit dans une réponse OCSP + jointe.
+
+ +

Cette implémentation pour Apache httpd fournit les fonctionnalités +suivantes pout les serveurs et mandataires TLS :

+ +
    +
  • Les SCTs peuvent être extraits automatiquement des logs, et en + conjonction avec tout SCT défini statiquement, envoyés aux clients + qui les supportent durant la phase ServerHello de la négociation de la + connexion.
    • +
  • Le serveur mandataire peut recevoir les SCTs en provenance du + serveur original au cours de la phase ServerHello sous la forme d'une + extension de certificat, et/ou au sein des réponses OCSP agrafées ; + tout SCT reçu peut être validé partiellement en ligne, et + éventuellement mis en file d'attente pour un examen plus approfondi + hors ligne.
    • +
  • Le serveur mandataire peut être configuré de façon à refuser la + communication avec un serveur original qui ne fournit pas de SCT + pouvant âtre validé en ligne.
    • +
+ +

La configuration des logs peut être définie statiquement au niveau de +la configuration du serveur web, ou enregistrée dans une base de données +SQLite3. Dans ce dernier cas, mod_ssl_ct rechargera à +intervalles réguliers la base de données, de façon à ce que tout +changement dans la configuration de la maintenance et de la propagation +des logs pour un site spécifique ne nécessite pas de redémarrer httpd.

+ +
Ce module en est au stade expérimental pour les raisons suivantes +: +
    +
  • Tests et retours d'information insuffisants
    • +
  • Repose sur une version non stable (version 1.0.2, Beta 3 ou + supérieure) d'OpenSSL pour les + opérations de base
    • +
  • Implémentation de la fonctionnalité d'audit hors + ligne incomplète
    • +
+ +

Les mécanismes de configuration, le format des données enregistrées +pour l'audit hors ligne, ainsi que d'autres caractéristiques sont +appelés à évoluer en fonction des tests et retours d'informations à +venir.

+
+
+ +
top
+
+

Vue d'ensemble du fonctionnement au niveau du serveur

+ + +

Les serveurs doivent pouvoir envoyer les SCTs aux clients. Les SCTs + seront envoyés sous la forme d'une extension de certificat ou au sein + d'une réponse OCSP agrafée sans logique préprogrammée. Ce module gère + l'envoi des SCTs configurés par l'administrateur ou en provenance des + logs définis.

+ +

Le nombre de SCTs envoyés au cours de la phase ServerHello (c'est à + dire les SCTs autres que ceux inclus dans une extension de certificat + ou une réponse OCSP agrafée) peut être limité via la directive + CTServerHelloSCTLimit.

+ +

Pour chaque certificat de serveur, un processus maintient une liste + de SCTs à envoyer au cours de la phase ServerHello ; cette liste est + créée à partir des SCTs configurés statiquement, mais aussi à partir + de ceux reçus depuis les logs. Les logs marqués comme suspects ou + arrivés à péremption seront ignorés. A intervalles réguliers, le + processus va soumettre les certificats à un log selon les besoins + (suite à un changement de configuration du log ou de sa durée de vie), + et reconstruire la concaténation des SCTs.

+ +

La liste des SCTs pour un certificat de serveur sera envoyée au + cours de la phase ClientHello, lorsque ce certificat de serveur + particulier est utilisé, à tout client qui fait savoir qu'il supporte + cette fonctionnalité.

+ +
top
+
+

Vue d'ensemble du fonctionnement au niveau du serveur + mandataire

+ + +

Le serveur mandataire indique qu'il supporte la Transparence des + Certificats au cours de la phase ClientHello en incluant l'extension + signed_certificate_timestamp. Il peut reconnaître les SCTs + reçus au cours de la phase ServerHello dans une extension du + certificat du serveur original, ou au sein d'une réponse OCSP agrafée.

+ +

Une vérification en ligne est effectuée pour tout SCT reçu :

+ +
    +
  • Le repère de temps de chaque SCT peut être vérifié pour voir + s'il n'est pas encore valide en le comparant avec l'heure actuelle + ou tout intervalle de temps valide défini pour le log.
    • +
  • Dans le cas d'un SCT issu d'un log pour lequel une clé publique + a été définie, la signature du serveur sera vérifiée.
    • +
+ +

Si la vérification échoue ou renvoie un résultat négatif pour au + moins un SCT et si la directive CTProxyAwareness est définie à + require, la tentative de connexion est abandonnée.

+ +

En outre, si la directive CTAuditStorage est définie, la chaîne + de certification du serveur et les SCTs sont stockés pour une + vérification hors ligne.

+ +

A titre d'optimisation, la vérification en ligne et le stockage des + données en provenance du serveur ne sont effectués que la première + fois où un processus enfant du serveur web reçoit ces données, ce qui + permet d'économiser du temps processeur et de l'espace disque. Dans le + cas d'une configuration typique de mandataire inverse, seule une + légère augmentation de la charge processeur sera induite.

+ +
top
+
+

Configuration du log

+ + +

Les serveurs et les mandataires utilisent des informations + différentes en ce qui concerne les logs et leurs traitements. Cette + configuration des logs peut être effectuée de deux manières :

+ +
    +
  • On peut créer une base de données pour configurer le log en + utilisant la commande ctlogconfig et en + définissant le chemin vers cette base de données via la directive + CTLogConfig. + mod_ssl_ct relit la base de données à + intervalles réguliers ; cette méthode de configuration supporte donc + les mises à jour dynamiques. En outre, la commande d'audit hors + ligne ctauditscts peut utiliser cette configuration pour + trouver l'URL des logs.
    • + +
  • On peut aussi configurer les logs statiquement via la directive + CTStaticLogConfig. Toute + modification de cette directive nécessitera alors un redémarrage du serveur + pour être prise en compte, comme pour toutes les autres directives.
    • +
+ +

Les éléments de configuration pouvant être définis par l'une ou + l'autre méthode sont les suivants :

+ +
+
Identifiant du log
+
L'identifiant du log est le hash SHA-256 de sa clé publique, et + est inclus dans tout SCT. Ceci permet d'identifier aisément un log + particulier lorsqu'on définit des plages de repères de temps + valides ou certaines autres informations.
+ +
Clé publique du log
+
Un mandataire doit disposer de la clé publique du log afin de + pouvoir vérifier la signature dans les SCTs en provenance de ce log. +
+ Un serveur doit posséder la clé publique du log afin de pouvoir lui + soumettre des certificats.
+ +
Configuration générale confiance/méfiance
+
Il s'agit d'un mécanisme permettant d'instaurer une méfiance ou + de restaurer une confiance envers un log donné pour certaines + raisons particulières (y compris la simple interruption des + interactions avec le log dans les situations où il est hors ligne).
+ +
Repères de temps minima et/ou maxima valides
+
Lorsqu'ils sont définis, le mandataire pourra vérifier que les + repères de temps contenus dans les SCTs sont compris dans une plage + valide
+ +
URL du log
+
Pour qu'un serveur puisse soumettre des certificats de serveur à + un log, il doit connaître l'URL de ce dernier (pour son API). Le + serveur soumettra chaque certificat de serveur afin d'obtenir un + SCT pour chaque log dont l'URL est définie, sauf pour les logs aussi + marqués comme non dignes de confiance ou si l'heure actuelle ne se + situe dans aucune des plages de temps valides définies. +
+ L'audit hors ligne des SCTs reçus par un mandataire nécessite aussi + de connaître l'URL du log.
+
+ +

En général, seuls quelque uns de ces éléments de configuration sont + définis pour un log donné. Pour plus de détails, veuillez vous référer + à la documentation de la directive CTStaticLogConfig et de la commande + ctlogconfig.

+ +
top
+
+

Stockage des SCTs sous une forme compréhensible pour mod_ssl_ct

+ + +

Le module mod_ssl_ct permet de configurer les SCTs + de manière statique via la directive + CTStaticSCTs. Ils doivent alors être sous une forme + binaire prête à être envoyée au client.

+ +

Vous trouverez dans le Dépôt ct-tools de Tom + Ritter un exemple de code sous la forme d'un script Python + (write-sct.py) permettant de générer un SCT sous un + format correct avec des données en provenance d'un log.

+
top
+
+

Journalisation des repères de temps des certificats (CT) dans + le journal des accès

+ + +

Dans les deux modes mandataire et serveur, les variables + SSL_CT_PROXY_STATUS et + SSL_CT_CLIENT_STATUS sont définies et indiquent si le + serveur supporte les CTs.

+ +

Dans le mode mandataire, la variable + SSL_CT_PROXY_SCT_SOURCES est définie pour indiquer si des + SCTs ont été reçus ainsi que leur source (phase ServerHello de la + connexion, extension de certificat, etc...).

+ +

Les valeurs de ces variables peuvent être journalisées via la + chaîne de format %{varname}e de + mod_log_config.

+
top
+
+

Audit hors ligne pour mandataire

+ + +

Le support de cette fonctionnalité en est au stade expérimental, et + est implémenté par la commande ctauditscts, qui repose + elle-même sur l'utilitaire verify_single_proof.py du + projet open source certificate-transparency. La commande + ctauditscts peut parcourir des données, et ainsi effectuer + un audit hors ligne (activé via la directive CTAuditStorage) en invoquant + l'utilitaire verify_single_proof.py.

+ +

Voici quelques indication à l'état brut pour l'utilisation de + ctauditscts :

+ +
    +
  • Créez un virtualenv en utilisant le fichier + requirements.txt du projet + certificate-transparency, et exécuter les étapes suivantes + avec ce virtualenv activé.
    • +
  • Définissez PYTHONPATH de façon à inclure le + répertoire python dans les chemins par défaut des + utilitaires du projet certificate-transparency.
    • +
  • Définissez PATH de façon à inclure le chemin du + répertoire python/ct/client/tools.
    • +
  • Exécutez la commande ctauditscts avec comme + arguments la valeur de la directive + CTAuditStorage, et éventuellement le chemin + de la base de données de configuration des logs. Cette dernière sera + utilisée pour extraire les URLs des logs en fonction de leurs + identifiants.
    • +
+ +

Les données stockées à des fins d'audit peuvent aussi être + utilisées par d'autres programmes ; veuillez vous référer au code + source de ctauditscts pour plus de détails à propos du + traitement des données.

+
+
top
+

Directive CTAuditStorage

+ + + + + + + +
Description:Répertoire de stockage des données pour l'audit hors ligne
Syntaxe:CTAuditStorage directory
Défaut:none
Contexte:configuration du serveur
Statut:Extension
Module:mod_ssl_ct
+

La directive CTAuditStorage permet de + définir le chemin du répertoire où les données destinées à un audit hors + ligne seront stockées. Ce répertoire doit exister au préalable. Si le + chemin contenu dans l'argument directory n'est pas absolu, il + sera considéré comme relatif au chemin défini par la directive + DefaultRuntimeDir.

+ +

Si cette directive n'est pas définie, aucune donnée ne sera stockée + en vue d'un audit hors ligne.

+ +

Le répertoire considéré contiendra des fichiers nommés + PID.tmp pour les processus enfants actifs et + PID.out pour les processus enfants terminés. Les + données disponibles pour un audit hors ligne sont donc contenues dans les + fichiers .out. La commande expérimentale + ctauditscts (située dans l'arborescence des sources de + httpd, mais non encore prise en compte par le processus + d'installation), fait appel aux utilitaires du projet + certificate-transparency pour effectuer l'audit.

+ +
+
top
+

Directive CTLogClient

+ + + + + + + +
Description:Chemin de l'utilitaire client du log certificate-transparency
Syntaxe:CTLogClient executable
Défaut:none
Contexte:configuration du serveur
Statut:Extension
Module:mod_ssl_ct
+

executable est le chemin complet de l'utilitaire client du + log qui est normalement le fichier cpp/client/ct (ou + ct.exe) de l'arborescence des sources du projet open + source certificate-transparency.

+ +

Il est possible d'utiliser une implémentation alternative pour + extraire les SCTs d'un certificat de serveur à partir du moment où + l'interface de la ligne de commande est équivalente.

+ +

Si cette directive n'est pas définie, il n'est pas possible de + soumettre les certificats aux logs pour en extraire les SCTs ; seuls + les SCTs gérés par l'administrateur ou situés dans une extension de + certificat seront alors fournis aux clients.

+ +
+
top
+

Directive CTLogConfigDB

+ + + + + + + +
Description:Base de données pour la configuration des logs avec mises à +jour dynamiques
Syntaxe:CTLogConfigDB filename
Défaut:none
Contexte:configuration du serveur
Statut:Extension
Module:mod_ssl_ct
+

La directive CTLogConfigDB permet de définir + le nom de la base de données contenant la configuration des logs + connus. Si le chemin contenu dans filename n'est pas absolu, + il est considéré comme relatif au chemin défini par la directive + ServerRoot.

+ +

Veuillez vous référer à la documentation du programme + ctlogconfig qui gère la base de données.

+ +
+
top
+

Directive CTMaxSCTAge

+ + + + + + + +
Description:Age maximum d'un SCT obtenu depuis un log avant son +raffraîchissement
Syntaxe:CTMaxSCTAge num-seconds
Défaut:1 jour
Contexte:configuration du serveur
Statut:Extension
Module:mod_ssl_ct
+

Les certificats de serveur dont les SCTs sont supérieurs à cet âge + maximum seront soumis à nouveau aux logs définis. En général, le log + va renvoyer le même SCT que précédemment, mais ceux-ci font alors l'objet + d'une opération de la part du log. Les SCTs seront raffraîchis autant que + nécessaire au cours du fonctionnement normal du serveur, les nouveaux + SCTs étant envoyés aux clients au fur et à mesure de leur + disponibilité.

+ +
+
top
+

Directive CTProxyAwareness

+ + + + + + + +
Description:Niveau de prise en compte et de mise en oeuvre des CTs pour un +mandataire +
Syntaxe:CTProxyAwareness oblivious|aware|require
Défaut:aware
Contexte:configuration du serveur, serveur virtuel
Statut:Extension
Module:mod_ssl_ct
+

Cette directive permet de contrôler la prise en compte et les + recherches de SCTs valides pour un mandataire. Les options disponibles + sont les suivantes :

+ +
+
oblivious
+
Le mandataire de demandera jamais de SCTs, et par conséquent + n'en examinera pas. Le processus de transparance des certificats est + alors entièrement désactivé pour ce mandataire.
+ +
aware
+
Le mandataire prendra en charge l'ensemble du processus de + transparence des certificats, à savoir la recherche de SCTs et leur + examen. Le mandataire n'interrompra cependant pas la connexion si le + serveur original ne fournit pas de SCTs valides.
+ +
require
+
Le mandataire interrompra la connexion avec le serveur original + si ce dernir ne fournit pas au moins un SCT qui passe avec succès le + test de validation en ligne.
+
+ + +
+
top
+

Directive CTSCTStorage

+ + + + + + + +
Description:Répertoire où les SCTs sont stockés
Syntaxe:CTSCTStorage directory
Défaut:none
Contexte:configuration du serveur
Statut:Extension
Module:mod_ssl_ct
+

La directive CTSCTStorage permet de définir + le nom du répertoire où les SCTs et listes de SCTs seront stockés. Si + le chemin contenu dans directory n'est pas absolu, il sera + considéré comme relatif au chemin défini par la directive DefaultRuntimeDir.

+ +

Chaque certificat voit ses informations stockées dans un sous-répertoire + qui lui est propre ; le nom de ce sous-répertoire correspond au hash + SHA-256 du certificat considéré.

+ +

Les sous-répertoires propres à chaque certificat contiennent des + SCTs en provenance des logs définis, des listes de SCTs préparées à + partir des SCTs configurés statiquement et des SCTs extraits, ainsi + que diverses informations utilisées pour gérer les SCTs.

+ +
+
top
+

Directive CTServerHelloSCTLimit

+ + + + + + + +
Description:Nombre maximum de SCTs pouvant être renvoyés au cours de la +phase ServerHello
Syntaxe:CTServerHelloSCTLimit limit
Défaut:100
Contexte:configuration du serveur
Statut:Extension
Module:mod_ssl_ct
+

Cette directive permet de définir le nombre maximum de SCTs pouvant + être renvoyés par un serveur TLS au cours de la phase ServerHello dans + le cas où le nombre de logs définis et de SCTs définis statiquement + est assez important.

+ +

En général, seuls quelques SCTs sont disponibles, cette directive + n'est donc nécessaire que dans certaines circonstances particulières.

+ +

Cette directive ne tient pas compte des SCTs contenus dans les + extensions de certificats ou les réponses OCSP agrafées.

+ +
+
top
+

Directive CTStaticLogConfig

+ + + + + + + +
Description:Configuration statique d'un log
Syntaxe:CTStaticLogConfig log-id|- public-key-file|- +1|0|- min-timestamp|- max-timestamp|- +log-URL|-
Défaut:none
Contexte:configuration du serveur
Statut:Extension
Module:mod_ssl_ct
+

Cette directive permet de configurer un log particulier. Elle est + particulièrement appropriée dans les cas où cette configuration est + rarement modifiée. Si votre cas nécessite plutôt une configuration + dynamique, veuillez vous référer à la documentation de la directive + CTLogConfigDB.

+ +

Chacun des six champs doit être renseigné, mais en général, la + configuration d'un log nécessite peu d'information ; utilisez + - lorsque vous ne disposez d'aucune information à spécifier + pour un champ particulier. Par exemple, dans le cas d'une + configuration de serveur simple (non mandataire), l'administrateur n'a + besoin de spécifier que l'URL du log auquel soumettre des certificats de + serveur afin d'en extraire les SCTs.

+ +

Les champs se définissent comme suit :

+ +
+
log-id
+
Il s'agit de l'identifiant du log qui correspond au hash SHA-256 + de la clé publique du log, codé en hexadécimal. Cette chaîne a une + taille de 64 caractères. +
+ Ce champ peut être omis lorsque public-key-file est + renseigné.
+ +
public-key-file
+
Il s'agit du chemin d'un fichier contenant la clé publique du log + codée au format PEM. Si ce chemin n'est pas absolu, il est considéré + comme relatif au chemin défini par la directive ServerRoot.
+ +
trust/distrust
+
Définissez ce champ à 1 pour marquer le log comme non + digne de confiance, ou pour tout simplement interdire son + utilisation pour le traitement des certificats. Définissez ce champ + à - ou 0 (valeur par défaut) pour accorder votre + confiance au log.
+ +
min-timestamp et max-timestamp
+
Un repère de temps (timestamp) est un temps exprimé en + millisecondes depuis le temps epoch, sans tenir compte des secondes + sautées. C'est le format de temps utilisé dans les SCTs. Le repère + de temps doit être fourni sous la forme d'un nombre décimal. +
+ Spécifiez - pour un des repères de + temps s'il n'est pas connu. Par exemple, lorsque vous définissez le + repère de temps minimum valide pour un log qui reste valide, + spécifiez - pour + max-timestamp. +
+ Les SCTs reçu par le mandataire depuis ce log seront invalides si le + repère de temps est plus ancien que min-timestamp ou plus + récent que max-timestamp.
+ +
log-URL
+
Il s'agit de l'URL du log auquel soumettre les certificats de + serveur et ainsi obtenir des SCTs à envoyer aux clients.
+
+ +

Voir aussi

+
    +
  • Le paragraphe Configuration des logs +contient des informations à caractère plus général à propos des champs qui +peuvent être définis via cette directive.
    • +
+
+
top
+

Directive CTStaticSCTs

+ + + + + + + +
Description:Configuration statique d'un ou plusieurs SCTs pour un +certificat de serveur +
Syntaxe:CTStaticSCTs certificate-pem-file sct-directory
Défaut:none
Contexte:configuration du serveur
Statut:Extension
Module:mod_ssl_ct
+

Cette directive permet de définir statiquement un ou plusieurs SCTs + correspondant à un certificat de serveur. Ce mécanisme peut être + utilisé à la place ou en complément de l'obtention dynamique des SCTs + en provenance des logs. Toute modification dans le jeu de SCTs d'un + certificat de serveur particulier sera prise en compte de manière + dynamique sans avoir à redémarrer le serveur.

+ +

certificate-pem-file fait référence au fichier contenant + le certificat de serveur au format PEM. Si ce chemin n'est pas absolu, + il sera considéré comme relatif au chemin défini par la directive + ServerRoot.

+ +

sct-directory doit contenir le chemin vers un ou plusieurs + fichiers possédant l'extension de nom de fichier .sct, + représentant un ou plusieurs SCTs correspondant au certificat de + serveur. Si ce chemin n'est pas absolu, + il sera considéré comme relatif au chemin défini par la directive + ServerRoot.

+ +

Si sct-directory est vide, aucun message d'erreur ne sera + affiché.

+ +

Cette directive peut servir à identifier des répertoires de SCTs + gérés par une autre infrastructure, sous réserve qu'ils soient + enregistrés au format binaire avec l'extension de nom de fichier + .sct.

+ +
+
+
+

Langues Disponibles:  en  | + fr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_syslog.html.fr b/docs/manual/mod/mod_syslog.html.fr new file mode 100644 index 0000000000..7af75c6dae --- /dev/null +++ b/docs/manual/mod/mod_syslog.html.fr @@ -0,0 +1,99 @@ + + + + + +mod_syslog - Serveur Apache HTTP Version 2.5 + + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+ +
+

Module Apache mod_syslog

+
+

Langues Disponibles:  en  | + fr 

+
+ + + +
Description:Support du fournisseur de journalisation "syslog"
Statut:Extension
Identificateur de Module:syslog_module
Fichier Source:mod_syslog.c
+

Sommaire

+ + +

Ce module implémente le fournisseur de journalisation "syslog". + Il permet de journaliser les messages d'erreur via syslogd(8).

+
+

Sujets

+

Directives

+

Ce module ne fournit aucune directive.

+

Traitement des bugs

Voir aussi

+
+
top
+
+

Exemples

+ + +

Si le système le supporte, l'utilisation du paramètre + syslog avec la directive ErrorLog (voir la + documentation du module core) à la place d'un nom + de fichier permet de journaliser les messages d'erreur via + syslogd(8). Par défaut, c'est le port syslog local7 qui + est utilisé, mais vous pouvez le modifier via la syntaxe + syslog:port où port pourra + correspondre à un des noms habituellement définis dans la + documentation de syslog(1). La définition de ce port est réellement + globale, et même si elle est modifiée au niveau d'un serveur + virtuel, elle affecte l'ensemble du serveur.

+ + 
ErrorLog syslog:user
+ + +
+
+
+

Langues Disponibles:  en  | + fr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_systemd.html.fr b/docs/manual/mod/mod_systemd.html.fr new file mode 100644 index 0000000000..27fa2927c1 --- /dev/null +++ b/docs/manual/mod/mod_systemd.html.fr @@ -0,0 +1,118 @@ + + + + + +mod_systemd - Serveur Apache HTTP Version 2.5 + + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+ +
+

Module Apache mod_systemd

+
+

Langues Disponibles:  en  | + fr 

+
+ + + +
Description:Fournit un support amélioré pour l'intégration de systemd
Statut:Extension
Identificateur de Module:systemd_module
Fichier Source:mod_systemd.c
+

Sommaire

+ +

Ce module implémente le support de l'intégration de systemd. Il + permet de démarrer httpd en temps que service avec le paramètre de + systemd Type=notify (voir la page de manuel + systemd.service(5) pour plus de détails). Il ajoute aussi des + statistiques à la sortie de la commande systemctl + status, et fournit diverses directives pour l'intégration de + systemd. +

+
+ + +
top
+

Directive IdleShutdown

+ + + + + + + +
Description:Permet d'arrêter httpd lorsque qu'il est inactif pendant un +certain temps.
Syntaxe:IdleShutdown seconds
Défaut:IdleShutdown 0
Contexte:configuration du serveur
Statut:Extension
Module:mod_systemd
+

La directive IdleShutdown permet d'arrêter + httpd lorsque qu'il est inactif pendant un certain temps. Ce statut + d'inactivité se base sur le nombre d'octets envoyés ; par conséquent, si + aucun octet n'est envoyé pendant le temps spécifié par cette + directive, httpd sera arrêté. Par défaut, IdleShutdown est définie à + 0, ce qui signifie que cette fonctionnalité est désactivée. +

+ +

Cette fonctionnalité prend tout son sens en combinaison avec + l'activation du socket systemd (voir la page de manuel + systemd.socket(5)). En effet, lorsque httpd est démarré par systemd + suite à l'arrivée d'une ou plusieurs requêtes HTTP, cette directive + vous permet d'arrêter httpd automatiquement lorsque toutes les + requêtes ont été traitées. +

+ +

Particularité de cette implémentation

+ De par la conception de cette implémentation, l'inactivité de httpd + n'est vérifiée que toutes les 10 secondes, ce qui signifie que si + vous spécifiez IdleShutdown 14, httpd ne s'arrêtera + qu'après 20 secondes d'inactivité. +

+ +
+
+
+

Langues Disponibles:  en  | + fr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_version.html.fr b/docs/manual/mod/mod_version.html.fr new file mode 100644 index 0000000000..13a3fb1fed --- /dev/null +++ b/docs/manual/mod/mod_version.html.fr @@ -0,0 +1,176 @@ + + + + + +mod_version - Serveur Apache HTTP Version 2.5 + + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+ +
+

Module Apache mod_version

+
+

Langues Disponibles:  en  | + fr  | + ja  | + ko 

+
+ + + +
Description:Configuration dépendant de la version
Statut:Extension
Identificateur de Module:version_module
Fichier Source:mod_version.c
+

Sommaire

+ +

Ce module a été conçu pour être utilisé dans les suites de tests + et les grands réseaux qui doivent prendre en compte différentes + versions de httpd et différentes configurations. Il fournit un + nouveau conteneur -- <IfVersion>, qui apporte une grande + souplesse dans la vérification de version en permettant une + comparaison numérique et l'utilisation d'expressions + rationnelles.

+ +

Exemples

<IfVersion 2.4.2>
+    # la version actuelle de httpd est exactement 2.4.2
+</IfVersion>
+
+<IfVersion >= 2.5>
+    # utilise vraiment les nouvelles fonctionnalités :-)
+</IfVersion>
+
+ +

Voir ci-dessous pour d'autres exemples.

+
+ + +
top
+

Directive <IfVersion>

+ + + + + + + +
Description:Contient des portions de configuration dépendantes de la +version
Syntaxe:<IfVersion [[!]opérateur] version> ... +</IfVersion>
Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
AllowOverride:All
Statut:Extension
Module:mod_version
+

La section <IfVersion> + rassemble des directives de configuration qui ne sont exécutées que + si la version de httpd satisfait aux critères spécifiés. Pour une + comparaison normale (numérique), l'argument version doit + être spécifié sous le format + majeur[.mineur[.patch]], + comme par exemple 2.1.0 ou 2.2. + mineur et patch sont optionnels. Si ces + numéros sont absents, il se voient affectée implicitement la valeur + 0. Les opérateurs numériques suivants sont autorisés + :

+ + + + + + + + + + + + +
opérateurdescription
= ou ==La version de httpd est égale à la valeur + spécifiée
>La version de httpd est supérieure à la valeur + spécifiée
>=La version de httpd est supérieure ou égale à la valeur + spécifiée
<La version de httpd est inférieure à la valeur + spécifiée
<=La version de httpd est inférieure ou égale à la valeur + spécifiée
+ +

Exemple

<IfVersion >= 2.3>
+    # la condition n'est satisfaite que pour les versions de httpd
+	# supérieures ou égales à 2.3
+</IfVersion>
+
+ +

En plus d'une comparaison numérique, il est possible de comparer + la version de httpd avec une expression + rationnelle. Il existe deux méthodes pour spécifier cette + dernière :

+ + + + + + +
opérateurdescription
= ou ==version est de la forme + /regex/
~version est de la forme + regex
+ +

Exemple

<IfVersion = /^2.4.[01234]$/>
+    # exemple de contournement pour les versions boguées
+</IfVersion>
+
+ +

Pour inverser la condition, tous les opérateurs peuvent être + préfixés par un point d'exclamation (!) :

+ + 
<IfVersion !~ ^2.4.[01234]$>
+    # pas pour ces versions
+</IfVersion>
+
+ +

Si opérateur est absent, sa valeur implicite est + =.

+ +
+
+
+

Langues Disponibles:  en  | + fr  | + ja  | + ko 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_watchdog.html.fr b/docs/manual/mod/mod_watchdog.html.fr new file mode 100644 index 0000000000..d6bc3b3f83 --- /dev/null +++ b/docs/manual/mod/mod_watchdog.html.fr @@ -0,0 +1,108 @@ + + + + + +mod_watchdog - Serveur Apache HTTP Version 2.5 + + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+ +
+

Module Apache mod_watchdog

+
+

Langues Disponibles:  en  | + fr 

+
+ + + + +
Description:Fournit une infrastructure permettant à d'autres modules +d'exécuter des tâches périodiques.
Statut:Base
Identificateur de Module:watchdog_module
Fichier Source:mod_watchdog.c
Compatibilité:Disponible à partir de la version 2.3 du serveur HTTP +Apache
+

Sommaire

+ +

Le module mod_watchdog définit des +branchements (hooks) programmés pour permettre à d'autres modules +d'exécuter des tâches périodiques. Ces modules peuvent enregistrer des +gestionnaires (handlers) pour les branchements de +mod_watchdog. Actuellement, seuls les modules suivants +de la distribution Apache utilisent cette fonctionnalité :

+ +
+Pour qu'un module puisse utiliser la fonctionnalité de +mod_watchdog, ce dernier doit être lié statiquement +avec le serveur httpd ; s'il a été lié dynamiquement, il doit être +chargé avant l'appel au module qui doit utiliser sa fonctionnalité. +
+
+ + +
top
+

Directive WatchdogInterval

+ + + + + + + +
Description:Intervalle Watchdog en secondes
Syntaxe:WatchdogInterval time-interval[s]
Défaut:WatchdogInterval 1
Contexte:configuration du serveur
Statut:Base
Module:mod_watchdog
+

Cette directive permet de définir l'intervalle entre chaque exécution +du branchement watchdog. La valeur par défaut est de 1 seconde.

+ +
+
+
+

Langues Disponibles:  en  | + fr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/programs/ctlogconfig.html b/docs/manual/programs/ctlogconfig.html index d1b41e1493..feca1db8e9 100644 --- a/docs/manual/programs/ctlogconfig.html +++ b/docs/manual/programs/ctlogconfig.html @@ -3,3 +3,7 @@ URI: ctlogconfig.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 + +URI: ctlogconfig.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 diff --git a/docs/manual/programs/ctlogconfig.html.en b/docs/manual/programs/ctlogconfig.html.en index 0d5b2bda35..d7cedc6b0d 100644 --- a/docs/manual/programs/ctlogconfig.html.en +++ b/docs/manual/programs/ctlogconfig.html.en @@ -23,7 +23,8 @@

ctlogconfig - Certificate Transparency log configuration tool

-

Available Languages:  en 

+

Available Languages:  en  | + fr 

ctlogconfig is a tool for creating and maintaining a log @@ -204,7 +205,8 @@

-

Available Languages:  en 

+

Available Languages:  en  | + fr 

top

Comments

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.
+ + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+

ctlogconfig, l'utilitaire de configuration du service de +transparence des certificats

+
+

Langues Disponibles:  en  | + fr 

+
+ +

ctlogconfig est un utilitaire permettant de créer et + maintenir une base de données pour la configuration du service de + transparence des certificats utilisable par le module + mod_ssl_ct ; nous nous référerons à ce service + sous le terme "log" dans la suite de cette documentation.

+ +

Avant d'aller plus loin, et si ce n'est déjà fait, veuillez + consulter le document Configuration des logs + dans la documentation du module mod_ssl_ct.

+ +

Vous pouvez vous inspirer des exemples + ci-dessous pour une utilisation typique.

+ +
+ +
top
+
+

Exemples et définitions

+ +

+ ctlogconfig /path/to/db dump +

+ +

+ ctlogconfig /path/to/db configure-public-key + [ log-id|record-id ] + /path/to/public-key.pem +

+ +

+ ctlogconfig /path/to/db configure-url + [ log-id|record-id ] + log-URL +

+ +

+ ctlogconfig /path/to/db valid-time-range + log-id|record-id + min-timestamp max-timestamp +

+ +

+ ctlogconfig /path/to/db trust + log-id|record-id +

+ +

+ ctlogconfig /path/to/db distrust + log-id|record-id +

+ +

+ ctlogconfig /path/to/db forget + log-id|record-id +

+ +
+
log-id
+
Il s'agit de l'identifiant du log qui est généré en effectuant + un hash SHA-256 au format hexadécimal de la clé publique du log. + La taille de cette chaîne est de 64 caractères.
+ +
record-id
+
Il s'agit du numéro d'enregistrement dans la base de données, + tel qu'il s'affiche avec la sous-commande dump, + préfixé par le caractère #. Par exemple, + #4 renvoie au quatrième enregistrement de la base + de données (utilisez le mécanisme d'échappement du shell si + nécessaire).
+ +
/path/to/public-key.pem
+
Il s'agit du chemin vers le fichier contenant la clé publique du + log au format PEM. En effet, la clé publique n'est pas stockée dans la base de + données, et le fichier ne peut donc pas être supprimé jusqu'à ce que + la donnée qui y fait référence dans la base de données soit + supprimée ou modifiée.
+ +
min-timestamp, max-timestamp
+
Un repère de temps (timestamp) est un temps exprimé en + millisecondes depuis le temps epoch, sans tenir compte des secondes + sautées. C'est le format de temps utilisé dans les SCTs. Le repère + de temps doit être fourni sous la forme d'un nombre décimal. +
+ Spécifiez - pour un des repères de + temps s'il n'est pas connu. Par exemple, lorsque vous définissez le + repère de temps minimum valide pour un log qui reste valide, + spécifiez - pour + max-timestamp. +
+ Les SCTs reçu par le mandataire depuis ce log seront invalides si le + repère de temps est plus ancien que min-timestamp ou plus + récent que max-timestamp.
+ +
+ +
top
+
+

Commandes

+ +
+
dump
+
Affiche les éléments de configuration de la base de données. + L'identifiant des enregistrements que cette commande affiche peut + servir de référence pour les enregistrements devant être affectés + par les autres commandes.
+ +
configure-public-key
+
Ajoute une clé publique pour un log de la base de données ou + modifie la clé publique d'un log existant. La clé publique d'un log + permet de valider la signature des SCTs (Signed certificate + Timestamp) reçus par un mandataire depuis un serveur d'arrière-plan + (La base de données sera créée si elle n'existe pas encore).
+ +
configure-url
+
Ajoute une URL pour un log de la base de données ou modifie + l'URL d'un log existant. L'URL d'un log permet de soumettre des + certificats de serveur à ce dernier afin d'obtenir des SCTs qui + pourront être envoyés aux clients (La base de données sera créée si + elle n'existe pas encore).
+ +
valid-time-range
+
Cette commande permet de définir le temps de validation minimum + et/ou maximum pour un log. Les SCTs en provenance du log possédant + un repère de temps en dehors de la plage définie seront rejetés. + Utilisez - pour un temps non défini (La base de données + sera créée si elle n'existe pas encore).
+ +
trust
+
Marque un log comme digne de confiance, ce qui est la situation + par défaut. Cette command permet de marquer un log comme digne de + confiance, alors que ce n'était pas le cas auparavant (La base de + données sera créée si elle n'existe pas encore).
+ +
distrust
+
Marque un log comme non digne de confiance (La base de + données sera créée si elle n'existe pas encore).
+ +
forget
+
Supprime de la base de données les informations relatives + à un log.
+
+
top
+
+

Exemples

+ + +

Soit une instance de httpd Apache qui fonctionne en tant que + serveur TLS et mandataire. Le serveur TLS doit obtenir des SCTs de la + part de certains logs connus afin de pouvoir les transmettre aux + clients, et le mandataire doit pouvoir valider la signature des SCTs + en provenance des serveurs d'arrière-plan.

+ +

Nous allons tout d'abord définir les URLs des logs où les + certificats sont enregistrés :

+ +

+ $ ctlogconfig /path/to/conf/log-config configure-url http://log1.example.com/
+ $ ctlogconfig /path/to/conf/log-config configure-url http://log2.example.com/
+ $ ctlogconfig /path/to/conf/log-config dump
+ Log entry:
+ Record 1
+ Log id : (not configured)
+ Public key file: (not configured)
+ URL : http://log1.example.com/
+ Time range : -INF to +INF
+
+ Log entry:
+ Record 2
+ Log id : (not configured)
+ Public key file: (not configured)
+ URL : http://log2.example.com/
+ Time range : -INF to +INF
+

+ +

Nous pouvons maintenant attribuer une clé publique à un log où le + certificat de notre seul serveur d'arrière-plan est publié. Dans notre + cas, il s'agit du log dont l'URL est http://log2.example.com/, et qui + a déjà été configuré.

+ +

+ $ ctlogconfig /path/to/conf/log-config configure-public-key \#2 /path/to/conf/log2-pub.pem
+ $ ctlogconfig /path/to/conf/log-config dump
+ Log entry:
+ Record 1
+ Log id : (not configured)
+ Public key file: (not configured)
+ URL : http://log1.example.com/
+ Time range : -INF to +INF
+
+ Log entry:
+ Record 2
+ Log id : (not configured)
+ Public key file: /path/to/conf/log2-pub.pem
+ URL : http://log2.example.com/
+ Time range : -INF to +INF
+

+
+
+

Langues Disponibles:  en  | + fr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/programs/firehose.html b/docs/manual/programs/firehose.html index be4e77d886..7afc3b3c84 100644 --- a/docs/manual/programs/firehose.html +++ b/docs/manual/programs/firehose.html @@ -3,3 +3,7 @@ URI: firehose.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 + +URI: firehose.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 diff --git a/docs/manual/programs/firehose.html.en b/docs/manual/programs/firehose.html.en index 2489945eee..84dac9b5a0 100644 --- a/docs/manual/programs/firehose.html.en +++ b/docs/manual/programs/firehose.html.en @@ -23,7 +23,8 @@

firehose - Demultiplex a firehose stream

-

Available Languages:  en 

+

Available Languages:  en  | + fr 

firehose demultiplexes the given stream of multiplexed @@ -75,7 +76,8 @@

-

Available Languages:  en 

+

Available Languages:  en  | + fr 

top

Comments

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.
+ + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+

firehose - Démultiplexe un flux firehose

+
+

Langues Disponibles:  en  | + fr 

+
+ +

firehose démultiplexe le flux de connexions + multiplexées donné, et enregistre chacune d'entre elles dans un + fichier individuel.

+ +

Lors de son enregistrement, chaque connexion est placée dans un + fichier dédié dont le nom est généré à partir de l'UUID de la + connexion dans le flux. Si le flux comporte des requêtes et des + réponses, ces dernières feront l'objet de fichiers séparés.

+ +

Si le paramètre optionnel prefix est spécifié, les connexions qui + commencent par le préfixe donné seront incluses. Le préfixe doit + correspondre exactement au premier fragment pour un résultat de + comparaison positif.

+ +
+ +
top
+
+

Syntaxe

+

firehose + [ -f entrée ] + [ -o répertoire-sortie ] + [ -u uuid ] + [ -h ] + [ --version ] + [préfixe1 [...]]

+ +
top
+
+

Options

+
+
--file, -f nom-fichier
+
Fichier depuis lequel doit être lu le flux firehose. La valeur + par défaut est stdin.
+ +
--output-directory, -o répertoire-sortie
+
Répertoire dans lequel les connexions démultiplexées doivent + être enregistrées.
+ +
--uuid, -u uuid
+
L'UUID de la connexion à démultiplexer. Plusieurs UUID peuvent + être spécifiés. Par défaut, tout les UUID seront démultiplexés.
+ +
--help, -h
+
Ce texte d'aide.
+ +
--version
+
Affiche la version du programme.
+
+ +
+
+

Langues Disponibles:  en  | + fr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/programs/log_server_status.html b/docs/manual/programs/log_server_status.html index 192b6142ae..b3a6d91af0 100644 --- a/docs/manual/programs/log_server_status.html +++ b/docs/manual/programs/log_server_status.html @@ -3,3 +3,7 @@ URI: log_server_status.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 + +URI: log_server_status.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 diff --git a/docs/manual/programs/log_server_status.html.en b/docs/manual/programs/log_server_status.html.en index bcf8d2a057..ee6234af4d 100644 --- a/docs/manual/programs/log_server_status.html.en +++ b/docs/manual/programs/log_server_status.html.en @@ -23,7 +23,8 @@

log_server_status - Log periodic status summaries

-

Available Languages:  en 

+

Available Languages:  en  | + fr 

This perl script is designed to be run at a frequent interval by @@ -56,7 +57,8 @@ which can then be used for statistical analysis.

-

Available Languages:  en 

+

Available Languages:  en  | + fr 

top

Comments

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.
+ + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+

log_server_status - Enregistrement périodique de l'état du serveur

+
+

Langues Disponibles:  en  | + fr 

+
+ +

Ce script perl a été conçu pour être exécuté à intervalles + réguliers via un déclencheur de type cron. Il se connecte au serveur + pour en extraire des informations quant à son état. Il formate ces + informations sous la forme d'une seule ligne qu'il enregistre dans + un fichier. Vous devez éditer la valeur des variables en tête de + script afin de définir le chemin du fichier de sortie. Pour que ce + script puisse fonctionner, mod_status doit au + préalable être chargé et configuré.

+
+
top
+
+

Mode d'emploi

+ +

Le script contient les sections suivantes :

+ +
my $wherelog = "/usr/local/apache2/logs/";  # Le fichier de sortie sera
+					# du style "/usr/local/apache2/logs/19960312"
+my $server   = "localhost";        # Nom du serveur, par exemple "www.foo.com"
+my $port     = "80";               # Port d'écoute du serveur
+my $request = "/server-status/?auto";    # Requête à soumettre
+ + +

Ces variables doivent contenir des valeurs correctes, et le +gestionnaire /server-status doit être configuré pour le +répertoire considéré. En outre, l'utilisateur qui exécute le script doit +avoir les droits d'écriture sur le chemin du fichier de sortie.

+ +

L'exécution périodique du script via cron permet d'obtenir un jeu de +rapports d'état qui pourra être utilisé à des fins d'analyse +statistique.

+ +
+
+

Langues Disponibles:  en  | + fr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/programs/other.html b/docs/manual/programs/other.html index d9c31cd3c0..d1199ee1cd 100644 --- a/docs/manual/programs/other.html +++ b/docs/manual/programs/other.html @@ -4,6 +4,10 @@ URI: other.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 +URI: other.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 + URI: other.html.ko.euc-kr Content-Language: ko Content-type: text/html; charset=EUC-KR diff --git a/docs/manual/programs/other.html.en b/docs/manual/programs/other.html.en index eb892e8171..cf0a67ffea 100644 --- a/docs/manual/programs/other.html.en +++ b/docs/manual/programs/other.html.en @@ -24,6 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5 > Programs

Other Programs

Available Languages:  en  | + fr  |  ko  |  tr 

@@ -37,6 +38,7 @@

Available Languages:  en  | + fr  |  ko  |  tr 

top

Comments

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.
diff --git a/docs/manual/programs/other.html.fr b/docs/manual/programs/other.html.fr new file mode 100644 index 0000000000..2e75a746d2 --- /dev/null +++ b/docs/manual/programs/other.html.fr @@ -0,0 +1,70 @@ + + + + + +Autres programmes - Serveur Apache HTTP Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+

Autres programmes

+
+

Langues Disponibles:  en  | + fr  | + ko  | + tr 

+
+ + +

Cette page contenait la documentation de programmes qui possèdent + maintenant leurs propres pages de documentation. Merci de bien + vouloir mettre à jour vos liens.

+ +

log_server_status

+

split-logfile

+
+
+
+

Langues Disponibles:  en  | + fr  | + ko  | + tr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/programs/other.html.ko.euc-kr b/docs/manual/programs/other.html.ko.euc-kr index daa9f14a57..04be868575 100644 --- a/docs/manual/programs/other.html.ko.euc-kr +++ b/docs/manual/programs/other.html.ko.euc-kr @@ -24,6 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5 > Programs

Other Programs

°¡´ÉÇÑ ¾ð¾î:  en  | + fr  |  ko  |  tr 

@@ -58,6 +59,7 @@

°¡´ÉÇÑ ¾ð¾î:  en  | + fr  |  ko  |  tr 

top

Comments

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.
diff --git a/docs/manual/programs/other.html.tr.utf8 b/docs/manual/programs/other.html.tr.utf8 index ad781ea4c9..2ee8b3d92a 100644 --- a/docs/manual/programs/other.html.tr.utf8 +++ b/docs/manual/programs/other.html.tr.utf8 @@ -24,6 +24,7 @@ Apache > HTTP Sunucusu > Belgeleme > Sürüm 2.5 > Programlar

DiÄŸer Programlar

Mevcut Diller:  en  | + fr  |  ko  |  tr 

@@ -75,6 +76,7 @@

Mevcut Diller:  en  | + fr  |  ko  |  tr 

top

Yorum

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.
diff --git a/docs/manual/programs/split-logfile.html b/docs/manual/programs/split-logfile.html index 80b48605c0..dfd27f9789 100644 --- a/docs/manual/programs/split-logfile.html +++ b/docs/manual/programs/split-logfile.html @@ -3,3 +3,7 @@ URI: split-logfile.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 + +URI: split-logfile.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 diff --git a/docs/manual/programs/split-logfile.html.en b/docs/manual/programs/split-logfile.html.en index c006b14764..6121d92059 100644 --- a/docs/manual/programs/split-logfile.html.en +++ b/docs/manual/programs/split-logfile.html.en @@ -23,7 +23,8 @@

split-logfile - Split up multi-vhost logfiles

-

Available Languages:  en 

+

Available Languages:  en  | + fr 

This perl script will take a combined Web server access log file and @@ -55,7 +56,8 @@ CustomLog "logs/access_log" combined_plus_vhost

-

Available Languages:  en 

+

Available Languages:  en  | + fr 

top

Comments

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.
+ + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+

split-logfile - Eclatement des journaux en fonction des serveurs +virtuels

+
+

Langues Disponibles:  en  | + fr 

+
+ +

Ce script perl permet d'extraire un journal pour chaque serveur + virtuel à partir d'un journal d'accès global du serveur web. Pour + que ce script fonctionne, le premier champ de chaque ligne du + journal global doit contenir l'identité du serveur virtuel ; ce + champ aura été ajouté à la directive LogFormat via la variable + "%v". +

+
+
top
+
+

Mode d'emploi

+ +

Création d'un fichier journal comportant l'identité du serveur + virtuel considéré :

+ + 
LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined_plus_vhost
+CustomLog "logs/access_log" combined_plus_vhost
+ + +

Un fichier journal sera créé dans le répertoire à partir duquel + vous exécutez le script pour chaque serveur virtuel qui apparaît + dans le journal global. Ces fichiers journaux seront nommés à partir + du nom du serveur virtuel considéré, avec l'extension + .log.

+ +

Le fichier journal global est lu depuis l'entrée standard stdin. + Les entrées de ce journal sont alors ajoutées au journal du serveur + virtuel correspondant.

+ +

split-logfile < access_log

+ + +
+
+

Langues Disponibles:  en  | + fr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/programs/suexec.html b/docs/manual/programs/suexec.html index 439a0689a7..be1c74bb52 100644 --- a/docs/manual/programs/suexec.html +++ b/docs/manual/programs/suexec.html @@ -4,6 +4,10 @@ URI: suexec.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 +URI: suexec.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 + URI: suexec.html.ko.euc-kr Content-Language: ko Content-type: text/html; charset=EUC-KR diff --git a/docs/manual/programs/suexec.html.en b/docs/manual/programs/suexec.html.en index 07421dd25e..cf007dfb92 100644 --- a/docs/manual/programs/suexec.html.en +++ b/docs/manual/programs/suexec.html.en @@ -24,6 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5 > Programs

suexec - Switch user before executing external programs

Available Languages:  en  | + fr  |  ko  |  tr 

@@ -60,6 +61,7 @@ changeable only at compile time.

Available Languages:  en  | + fr  |  ko  |  tr 

top

Comments

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.
diff --git a/docs/manual/programs/suexec.html.fr b/docs/manual/programs/suexec.html.fr new file mode 100644 index 0000000000..48e0c70bcf --- /dev/null +++ b/docs/manual/programs/suexec.html.fr @@ -0,0 +1,96 @@ + + + + + +suexec - Change d'utilisateur avant l'exécution d'un programme +externe - Serveur Apache HTTP Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur Apache HTTP Version 2.5

+
+
<-
+

suexec - Change d'utilisateur avant l'exécution d'un programme +externe

+
+

Langues Disponibles:  en  | + fr  | + ko  | + tr 

+
+ +

suexec permet au serveur HTTP Apache de changer + d'utilisateur avant d'exécuter un programme CGI. Pour ce faire, il + doit être exécuté par root. A cet effet, comme le + démon HTTP ne s'exécute en général pas en tant que + root, l'exécutable suexec doit posséder + le bit setuid et avoir comme propriétaire root. Seul + root doit en posséder les droits en écriture.

+ +

Pour plus d'informations à propos des concepts et du modèle de + sécurité du programme suexec, veuillez vous reporter à sa + documentation : http://httpd.apache.org/docs/trunk/suexec.html.

+
+ +
top
+
+

Synopsis

+

suexec -V

+
top
+
+

Options

+ +
+
-V
+ +
Si vous êtes root, cette option permet d'afficher les +options de compilation du programme suexec. Pour des +raisons de sécurité, toutes les options de configuration ne sont +modifiables qu'à la compilation.
+ +
+
+
+

Langues Disponibles:  en  | + fr  | + ko  | + tr 

+
top

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.
+
+ \ No newline at end of file diff --git a/docs/manual/programs/suexec.html.ko.euc-kr b/docs/manual/programs/suexec.html.ko.euc-kr index 8b357aa716..563a0a982d 100644 --- a/docs/manual/programs/suexec.html.ko.euc-kr +++ b/docs/manual/programs/suexec.html.ko.euc-kr @@ -24,6 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5 > Programs

suexec - ¿ÜºÎ ÇÁ·Î±×·¥À» ½ÇÇàÇϱâ Àü¿¡ »ç¿ëÀÚ¸¦ º¯°æÇÑ´Ù

°¡´ÉÇÑ ¾ð¾î:  en  | + fr  |  ko  |  tr 

@@ -63,6 +64,7 @@

°¡´ÉÇÑ ¾ð¾î:  en  | + fr  |  ko  |  tr 

top

Comments

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.
diff --git a/docs/manual/programs/suexec.html.tr.utf8 b/docs/manual/programs/suexec.html.tr.utf8 index 272d9ffd48..4304c779ce 100644 --- a/docs/manual/programs/suexec.html.tr.utf8 +++ b/docs/manual/programs/suexec.html.tr.utf8 @@ -24,6 +24,7 @@ Apache > HTTP Sunucusu > Belgeleme > Sürüm 2.5 > Programlar

suexec - harici programları çalıştırmadan önce kullanıcıyı değiştirir

Mevcut Diller:  en  | + fr  |  ko  |  tr 

@@ -61,6 +62,7 @@

Mevcut Diller:  en  | + fr  |  ko  |  tr 

top

Yorum

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.
diff --git a/docs/manual/sections.html.fr b/docs/manual/sections.html.fr index 1c9c81dcbc..d19cab92ea 100644 --- a/docs/manual/sections.html.fr +++ b/docs/manual/sections.html.fr @@ -29,8 +29,6 @@  ko  |  tr 

-
Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.

Les directives des fichiers de configuration peuvent s'appliquer au serveur dans son ensemble, ou seulement à des répertoires, fichiers, hôtes, ou URLs particuliers. Ce document décrit comment utiliser les conteneurs de @@ -51,7 +49,7 @@ arborescence du site web et expressions bool

Types de conteneurs de sections de configuration

-
Modules ApparentésDirectives Apparentées
+
Modules ApparentésDirectives Apparentées

Il existe deux grands types de conteneurs. La plupart des conteneurs sont évalués pour chaque requête. Les directives qu'ils contiennent s'appliquent @@ -510,7 +508,7 @@ sont interpr le conteneur <Proxy> prend la place du conteneur <Directory> dans l'ordre de traitement. - +

Note technique

Une séquence <Location>/<LocationMatch> est réellement traitée juste avant la phase de traduction du nom @@ -559,7 +557,7 @@ modules et sections de configuration <Directory "/example"> Header set CustomHeaderName two </Directory> - +
-
Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.

Ce document propose une méthode performante pour servir un nombre @@ -107,7 +105,7 @@ mod_rewrite fichier. Il est préférable de rediriger les journaux via un pipe ou une file fifo vers un programme, et faire en sorte que ce dernier éclate les journaux - en un journal par serveur virtuel. L'utilitaire split-logfile + en un journal par serveur virtuel. L'utilitaire split-logfile constitue un exemple de ce traitement.

top
@@ -255,18 +253,18 @@ LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon <VirtualHost 111.22.33.44> ServerName www.commercial.example.com - + CustomLog "logs/access_log.commercial" vcommon - + VirtualDocumentRoot "/www/commercial/%0/docs" VirtualScriptAlias "/www/commercial/%0/cgi-bin" </VirtualHost> <VirtualHost 111.22.33.45> ServerName www.homepages.example.com - + CustomLog "logs/access_log.homepages" vcommon - + VirtualDocumentRoot "/www/homepages/%0/docs" ScriptAlias "/cgi-bin/" "/www/std-cgi/" </VirtualHost> -- cgit v1.2.3