diff options
-rw-r--r-- | docs/manual/mod/mod_proxy_http2.xml.fr | 122 | ||||
-rw-r--r-- | docs/manual/mod/mod_proxy_http2.xml.meta | 1 | ||||
-rw-r--r-- | docs/manual/mod/mod_proxy_wstunnel.xml.fr | 126 | ||||
-rw-r--r-- | docs/manual/mod/mod_proxy_wstunnel.xml.meta | 1 | ||||
-rw-r--r-- | docs/manual/mod/mod_ssl_ct.xml.fr | 621 | ||||
-rw-r--r-- | docs/manual/mod/mod_ssl_ct.xml.meta | 1 | ||||
-rw-r--r-- | docs/manual/mod/mod_syslog.xml.fr | 59 | ||||
-rw-r--r-- | docs/manual/mod/mod_syslog.xml.meta | 1 | ||||
-rw-r--r-- | docs/manual/mod/mod_systemd.xml.fr | 79 | ||||
-rw-r--r-- | docs/manual/mod/mod_systemd.xml.meta | 1 | ||||
-rw-r--r-- | docs/manual/mod/mod_version.xml.fr | 148 | ||||
-rw-r--r-- | docs/manual/mod/mod_version.xml.meta | 1 |
12 files changed, 1161 insertions, 0 deletions
diff --git a/docs/manual/mod/mod_proxy_http2.xml.fr b/docs/manual/mod/mod_proxy_http2.xml.fr new file mode 100644 index 0000000000..1520e8e51a --- /dev/null +++ b/docs/manual/mod/mod_proxy_http2.xml.fr @@ -0,0 +1,122 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd"> +<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?> +<!-- English Revision : 1783722 --> +<!-- French translation : Lucien GENTIS --> +<!-- $LastChangedRevision: 2017022501 $ --> + +<!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the "License"); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +--> + +<modulesynopsis metafile="mod_proxy_http2.xml.meta"> + +<name>mod_proxy_http2</name> +<description>Support de HTTP/2 pour <module>mod_proxy</module></description> +<status>Extension</status> +<sourcefile>mod_proxy_http2.c</sourcefile> +<identifier>proxy_http2_module</identifier> + +<summary> + <p><module>mod_proxy_http2</module> 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é.</p> + + <p>Ce module <em>nécessite</em> la présence de <module>mod_proxy</module> ; + pour pouvoir traiter les requêtes mandatées HTTP/2, + <module>mod_proxy</module> et <module>mod_proxy_http2</module> doivent donc + être chargés par le serveur.</p> + + <p><module>mod_proxy_http2</module> 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).</p> + + <p>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).</p> + + <p>Ce module s'appuie sur <a href="http://nghttp2.org/">libnghttp2</a> pour + fournir le moteur central http/2.</p> + + <note type="warning"><title>Avertissement</title> <p>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.</p> </note> + + <note type="warning"><title>Avertissement</title> + <p>N'activez pas le mandatement avant d'avoir <a + href="mod_proxy.html#access">sécurisé votre serveur</a>. Les serveurs + mandataires ouverts sont dangereux non seulement pour votre propre réseau, + mais aussi pour l'Internet au sens large.</p> + </note> +</summary> +<seealso><module>mod_http2</module></seealso> +<seealso><module>mod_proxy</module></seealso> +<seealso><module>mod_proxy_connect</module></seealso> + + <section id="examples"><title>Exemples de base</title> + + <p>Les exemples ci-dessous montrent comment configurer HTTP/2 pour des + connexions d'arrière-plan vers un mandataire inverse.</p> + + <example><title>HTTP/2 (TLS)</title> + <highlight language="config"> +ProxyPass "/app" "h2://app.example.com" +ProxyPassReverse "/app" "https://app.example.com" + </highlight> + </example> + + <example><title>HTTP/2 (non sécurisé)</title> + <highlight language="config"> +ProxyPass "/app" "h2c://app.example.com" +ProxyPassReverse "/app" "http://app.example.com" + </highlight> + </example> + + <note> + <p>Pour mandater en inverse les protocoles <code>h2</code> ou + <code>h2c</code>, on utilise la directive + <directive>ProxyPassReverse</directive> avec les schèmes habituels + <code>https</code> et respectivement + <code>http</code> qui sont connus et utilisés par l'agent utilisateur.</p> + </note> + </section> <!-- /examples --> + +<section id="notes"><title>Informations sur les requêtes</title> + <p><module>mod_proxy_http</module> fournit les informations sur les requêtes + suivantes pour enregistrement dans les journaux en utilisant le format + <code>%{VARNAME}n</code> avec les directives <directive + module="mod_log_config">LogFormat</directive> ou <directive + module="core">ErrorLogFormat</directive> : + </p> + <dl> + <dt>proxy-source-port</dt> + <dd>Le numéro de port local utilisé pour la connexion vers le serveur + d'arrière-plan.</dd> + <dt>proxy-status</dt> + <dd>Le statut HTTP/2 en provenance du serveur d'arrière-plan.</dd> + </dl> +</section> + +</modulesynopsis> diff --git a/docs/manual/mod/mod_proxy_http2.xml.meta b/docs/manual/mod/mod_proxy_http2.xml.meta index 2ccd79bba6..071a546512 100644 --- a/docs/manual/mod/mod_proxy_http2.xml.meta +++ b/docs/manual/mod/mod_proxy_http2.xml.meta @@ -8,5 +8,6 @@ <variants> <variant>en</variant> + <variant>fr</variant> </variants> </metafile> diff --git a/docs/manual/mod/mod_proxy_wstunnel.xml.fr b/docs/manual/mod/mod_proxy_wstunnel.xml.fr new file mode 100644 index 0000000000..d7f0ea81e8 --- /dev/null +++ b/docs/manual/mod/mod_proxy_wstunnel.xml.fr @@ -0,0 +1,126 @@ +<?xml version="1.0" encoding="utf-8"?> +<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd"> +<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?> +<!-- English Revision : 1801594 --> +<!-- French translation : Lucien GENTIS --> +<!-- $LastChangedRevision: 2017071501 $ --> + +<!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the "License"); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +--> + +<modulesynopsis metafile="mod_proxy_wstunnel.xml.meta"> + +<name>mod_proxy_wstunnel</name> +<description>Module pour <module>mod_proxy</module> supportant les +websockets</description> +<status>Extension</status> +<sourcefile>mod_proxy_wstunnel.c</sourcefile> +<identifier>proxy_wstunnel_module</identifier> +<compatibility>Disponible à partir de la version 2.4.5 du serveur HTTP +Apache</compatibility> + +<summary> + <p>Pour utiliser ce module, <module>mod_proxy</module> 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 :</p> + + <example><title>Réponse HTTP</title> + <highlight language="config"> +Upgrade: WebSocket +Connection: Upgrade + </highlight> + </example> + +<p>Le mandatement des requêtes vers un serveur websockets comme +<code>echo.websocket.org</code> peut être configuré via la directive <directive +type="ProxyPass" module="mod_proxy">ProxyPass</directive> :</p> + <highlight language="config"> +ProxyPass "/ws2/" "ws://echo.websocket.org/" +ProxyPass "/wss2/" "wss://echo.websocket.org/" + </highlight> + +<p>La répartition de charge entre plusieurs serveurs d'arrière-plan peut être +configurée via le module <module>mod_proxy_balancer</module>.</p> + +<p>En fait, ce module permet d'accepter d'autres protocoles ; vous pouvez à cet +effet utiliser le paramètre <code>upgrade</code> de la directive <directive +type="ProxyPass" module="mod_proxy">ProxyPass</directive>. 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 <code>Upgrade</code> +va lire les en-têtes de la requête et les utilisera dans l'en-tête +<code>Upgrade</code> de la réponse.</p> +</summary> + +<seealso><module>mod_proxy</module></seealso> + +<directivesynopsis> +<name>ProxyWebsocketAsync</name> +<description>Création d'un tunnel asynchrone</description> +<syntax>ProxyWebsocketAsync ON|OFF</syntax> +<contextlist><context>server config</context> +<context>virtual host</context> +</contextlist> + +<usage> + <p>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.</p> + <note><title>Note</title><p>Le support du mode asynchrone est + au stade expérimental et est susceptible d'évoluer.</p></note> +</usage> +</directivesynopsis> + +<directivesynopsis> +<name>ProxyWebsocketIdleTimeout</name> +<description>Temps d'attente maximum pour des données sur le tunnel websockets</description> +<syntax>ProxyWebsocketIdleTimeout <var>num</var>[ms]</syntax> +<default>ProxyWebsocketIdleTimeout 0</default> +<contextlist><context>server config</context> +<context>virtual host</context> +</contextlist> + +<usage> + <p>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 <em>ms</em>.</p> +</usage> +</directivesynopsis> + +<directivesynopsis> +<name>ProxyWebsocketAsyncDelay</name> +<description>Temps d'attente synchrone maximum pour des données</description> +<syntax>ProxyWebsocketAsyncDelay <var>num</var>[ms]</syntax> +<default>ProxyWebsocketAsyncDelay 0</default> +<contextlist><context>server config</context> +<context>virtual host</context> +</contextlist> + +<usage> + <p>Si la directive <directive>ProxyWebsocketAsync</directive> 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 <em>ms</em>.</p> + + <note><title>Note</title><p>Le support du mode asynchrone est + au stade expérimental et est susceptible d'évoluer.</p></note> +</usage> +</directivesynopsis> + +</modulesynopsis> diff --git a/docs/manual/mod/mod_proxy_wstunnel.xml.meta b/docs/manual/mod/mod_proxy_wstunnel.xml.meta index d12fab9bcb..6c0a516e2a 100644 --- a/docs/manual/mod/mod_proxy_wstunnel.xml.meta +++ b/docs/manual/mod/mod_proxy_wstunnel.xml.meta @@ -8,5 +8,6 @@ <variants> <variant>en</variant> + <variant>fr</variant> </variants> </metafile> diff --git a/docs/manual/mod/mod_ssl_ct.xml.fr b/docs/manual/mod/mod_ssl_ct.xml.fr new file mode 100644 index 0000000000..1a9901f165 --- /dev/null +++ b/docs/manual/mod/mod_ssl_ct.xml.fr @@ -0,0 +1,621 @@ +<?xml version="1.0"?> +<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd"> +<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?> +<!-- English Revision : 1690137 --> +<!-- French translation : Lucien GENTIS --> +<!-- $LastChangedRevision: 2015071101 $ --> + +<!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the "License"); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +--> + +<modulesynopsis metafile="mod_ssl_ct.xml.meta"> + +<name>mod_ssl_ct</name> +<description>Implémentation de la transparence des certificats +(Certificat Transparency - RFC 6962) +</description> +<status>Extension</status> +<sourcefile>mod_ssl_ct.c</sourcefile> +<identifier>ssl_ct_module</identifier> + +<summary> + +<p>Ce module implémente la transparence des certificats en conjonction +avec <module>mod_ssl</module> et les outils en ligne de commande du +projet open source <a +href="https://code.google.com/p/certificate-transparency/">certificate-transparency</a>. +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 : <a +href="http://www.certificate-transparency.org/">http://www.certificate-transparency.org/</a>. +Voici la signification des termes utilisés dans cette documentation :</p> + +<dl> + <dt>Certificate log</dt> + <dd>Un Certificate log, auquel on fera référence avec le simple + terme <q>log</q> 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.</dd> + + <dt>Horodatage signé du certificat (Signed Certificate Timestamp - SCT)</dt> + <dd>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.</dd> +</dl> + +<p>Cette implémentation pour Apache httpd fournit les fonctionnalités +suivantes pout les serveurs et mandataires TLS :</p> + +<ul> + <li>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.</li> + <li>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.</li> + <li>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.</li> +</ul> + +<p>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, <module>mod_ssl_ct</module> 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.</p> + +<note>Ce module en est au stade expérimental pour les raisons suivantes +: +<ul> + <li>Tests et retours d'information insuffisants</li> + <li>Repose sur une version non stable (version 1.0.2, Beta 3 ou + supérieure) d'OpenSSL pour les + opérations de base</li> + <li>Implémentation de la <a href="#audit">fonctionnalité d'audit hors + ligne</a> incomplète</li> +</ul> + +<p>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.</p> +</note> +</summary> + +<section id="server"> + <title>Vue d'ensemble du fonctionnement au niveau du serveur</title> + + <p>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.</p> + + <p>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 + <directive module="mod_ssl_ct">CTServerHelloSCTLimit</directive>.</p> + + <p>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.</p> + + <p>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é.</p> + +</section> + +<section id="proxy"> + <title>Vue d'ensemble du fonctionnement au niveau du serveur + mandataire</title> + + <p>Le serveur mandataire indique qu'il supporte la Transparence des + Certificats au cours de la phase ClientHello en incluant l'extension + <em>signed_certificate_timestamp</em>. 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.</p> + + <p>Une vérification en ligne est effectuée pour tout SCT reçu :</p> + + <ul> + <li>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.</li> + <li>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.</li> + </ul> + + <p>Si la vérification échoue ou renvoie un résultat négatif pour au + moins un SCT et si la directive <directive + module="mod_ssl_ct">CTProxyAwareness</directive> est définie à + <em>require</em>, la tentative de connexion est abandonnée.</p> + + <p>En outre, si la directive <directive + module="mod_ssl_ct">CTAuditStorage</directive> est définie, la chaîne + de certification du serveur et les SCTs sont stockés pour une + vérification hors ligne.</p> + + <p>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.</p> + +</section> + +<section id="logconf"> + <title>Configuration du log</title> + + <p>Les serveurs et les mandataires utilisent des informations + différentes en ce qui concerne les logs et leurs traitements. Cette + <em>configuration des logs</em> peut être effectuée de deux manières :</p> + + <ul> + <li>On peut créer une base de données pour configurer le log en + utilisant la commande <program>ctlogconfig</program> et en + définissant le chemin vers cette base de données via la directive + <directive module="mod_ssl_ct">CTLogConfig</directive>. + <module>mod_ssl_ct</module> 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 <code>ctauditscts</code> peut utiliser cette configuration pour + trouver l'URL des logs.</li> + + <li>On peut aussi configurer les logs statiquement via la directive + <directive module="mod_ssl_ct">CTStaticLogConfig</directive>. Toute + modification de cette directive nécessitera alors un redémarrage du serveur + pour être prise en compte, comme pour toutes les autres directives.</li> + </ul> + + <p>Les éléments de configuration pouvant être définis par l'une ou + l'autre méthode sont les suivants :</p> + + <dl> + <dt>Identifiant du log</dt> + <dd>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.</dd> + + <dt>Clé publique du log</dt> + <dd>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. + <br /> + Un serveur doit posséder la clé publique du log afin de pouvoir lui + soumettre des certificats.</dd> + + <dt>Configuration générale confiance/méfiance</dt> + <dd>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).</dd> + + <dt>Repères de temps minima et/ou maxima valides</dt> + <dd>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</dd> + + <dt>URL du log</dt> + <dd>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. + <br /> + L'audit hors ligne des SCTs reçus par un mandataire nécessite aussi + de connaître l'URL du log.</dd> + </dl> + + <p>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 <directive + module="mod_ssl_ct">CTStaticLogConfig</directive> et de la commande + <program>ctlogconfig</program>.</p> + +</section> + +<section id="static"> + <title>Stockage des SCTs sous une forme compréhensible pour mod_ssl_ct</title> + + <p>Le module <module>mod_ssl_ct</module> permet de configurer les SCTs + de manière statique via la directive + <directive>CTStaticSCTs</directive>. Ils doivent alors être sous une forme + binaire prête à être envoyée au client.</p> + + <p>Vous trouverez dans le <a + href="https://github.com/tomrittervg/ct-tools">Dépôt ct-tools de Tom + Ritter</a> un exemple de code sous la forme d'un script Python + (<code>write-sct.py</code>) permettant de générer un SCT sous un + format correct avec des données en provenance d'un log.</p> +</section> + +<section id="logging"> + <title>Journalisation des repères de temps des certificats (CT) dans + le journal des accès</title> + + <p>Dans les deux modes mandataire et serveur, les variables + <code>SSL_CT_PROXY_STATUS</code> et + <code>SSL_CT_CLIENT_STATUS</code> sont définies et indiquent si le + serveur supporte les CTs.</p> + + <p>Dans le mode mandataire, la variable + <code>SSL_CT_PROXY_SCT_SOURCES</code> 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...).</p> + + <p>Les valeurs de ces variables peuvent être journalisées via la + chaîne de format <code>%{<em>varname</em>}e</code> de + <module>mod_log_config</module>.</p> +</section> + +<section id="audit"> + <title>Audit hors ligne pour mandataire</title> + + <p>Le support de cette fonctionnalité en est au stade expérimental, et + est implémenté par la commande <code>ctauditscts</code>, qui repose + elle-même sur l'utilitaire <code>verify_single_proof.py</code> du + projet open source <em>certificate-transparency</em>. La commande + <code>ctauditscts</code> peut parcourir des données, et ainsi effectuer + un audit hors ligne (activé via la directive <directive + module="mod_ssl_ct">CTAuditStorage</directive>) en invoquant + l'utilitaire <code>verify_single_proof.py</code>.</p> + + <p>Voici quelques indication à l'état brut pour l'utilisation de + <code>ctauditscts</code> :</p> + + <ul> + <li>Créez un <em>virtualenv</em> en utilisant le fichier + <code>requirements.txt</code> du projet + <em>certificate-transparency</em>, et exécuter les étapes suivantes + avec ce <em>virtualenv</em> activé.</li> + <li>Définissez <code>PYTHONPATH</code> de façon à inclure le + répertoire <code>python</code> dans les chemins par défaut des + utilitaires du projet <em>certificate-transparency</em>.</li> + <li>Définissez <code>PATH</code> de façon à inclure le chemin du + répertoire <code>python/ct/client/tools</code>.</li> + <li>Exécutez la commande <code>ctauditscts</code> avec comme + arguments la valeur de la directive + <directive>CTAuditStorage</directive>, 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.</li> + </ul> + + <p>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 <code>ctauditscts</code> pour plus de détails à propos du + traitement des données.</p> +</section> + +<directivesynopsis> +<name>CTAuditStorage</name> +<description>Répertoire de stockage des données pour l'audit hors ligne</description> +<syntax>CTAuditStorage <em>directory</em></syntax> +<default>none</default> +<contextlist><context>server config</context></contextlist> + +<usage> + <p>La directive <directive>CTAuditStorage</directive> 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 <em>directory</em> n'est pas absolu, il + sera considéré comme relatif au chemin défini par la directive + <directive module="core">DefaultRuntimeDir</directive>.</p> + + <p>Si cette directive n'est pas définie, aucune donnée ne sera stockée + en vue d'un audit hors ligne.</p> + + <p>Le répertoire considéré contiendra des fichiers nommés + <code><em>PID</em>.tmp</code> pour les processus enfants actifs et + <code><em>PID</em>.out</code> pour les processus enfants terminés. Les + données disponibles pour un audit hors ligne sont donc contenues dans les + fichiers <code>.out</code>. La commande expérimentale + <code>ctauditscts</code> (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 + <em>certificate-transparency</em> pour effectuer l'audit.</p> +</usage> +</directivesynopsis> + +<directivesynopsis> +<name>CTLogClient</name> +<description>Chemin de l'utilitaire client du log certificate-transparency</description> +<syntax>CTLogClient <em>executable</em></syntax> +<default>none</default> +<contextlist><context>server config</context> +</contextlist> + +<usage> + <p><em>executable</em> est le chemin complet de l'utilitaire client du + log qui est normalement le fichier <code>cpp/client/ct</code> (ou + <code>ct.exe</code>) de l'arborescence des sources du projet open + source <a + href="https://code.google.com/p/certificate-transparency/">certificate-transparency</a>.</p> + + <p>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.</p> + + <p>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.</p> +</usage> +</directivesynopsis> + +<directivesynopsis> +<name>CTLogConfigDB</name> +<description>Base de données pour la configuration des logs avec mises à +jour dynamiques</description> +<syntax>CTLogConfigDB <em>filename</em></syntax> +<default>none</default> +<contextlist><context>server config</context></contextlist> + +<usage> + <p>La directive <directive>CTLogConfigDB</directive> permet de définir + le nom de la base de données contenant la configuration des logs + connus. Si le chemin contenu dans <em>filename</em> n'est pas absolu, + il est considéré comme relatif au chemin défini par la directive + <directive module="core">ServerRoot</directive>.</p> + + <p>Veuillez vous référer à la documentation du programme + <program>ctlogconfig</program> qui gère la base de données.</p> +</usage> +</directivesynopsis> + +<directivesynopsis> +<name>CTMaxSCTAge</name> +<description>Age maximum d'un SCT obtenu depuis un log avant son +raffraîchissement</description> +<syntax>CTMaxSCTAge <em>num-seconds</em></syntax> +<default>1 jour</default> +<contextlist><context>server config</context></contextlist> + +<usage> + <p>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é.</p> +</usage> +</directivesynopsis> + +<directivesynopsis> +<name>CTProxyAwareness</name> +<description>Niveau de prise en compte et de mise en oeuvre des CTs pour un +mandataire +</description> +<syntax>CTProxyAwareness <em>oblivious|aware|require</em></syntax> +<default>aware</default> +<contextlist><context>server config</context> +<context>virtual host</context></contextlist> + +<usage> + <p>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 :</p> + + <dl> + <dt>oblivious</dt> + <dd>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.</dd> + + <dt>aware</dt> + <dd>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.</dd> + + <dt>require</dt> + <dd>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.</dd> + </dl> + +</usage> +</directivesynopsis> + +<directivesynopsis> +<name>CTSCTStorage</name> +<description>Répertoire où les SCTs sont stockés</description> +<syntax>CTSCTStorage <em>directory</em></syntax> +<default>none</default> +<contextlist><context>server config</context> +</contextlist> + +<usage> + <p>La directive <directive>CTSCTStorage</directive> permet de définir + le nom du répertoire où les SCTs et listes de SCTs seront stockés. Si + le chemin contenu dans <em>directory</em> n'est pas absolu, il sera + considéré comme relatif au chemin défini par la directive <directive + module="core">DefaultRuntimeDir</directive>.</p> + + <p>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é.</p> + + <p>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.</p> +</usage> +</directivesynopsis> + +<directivesynopsis> +<name>CTServerHelloSCTLimit</name> +<description>Nombre maximum de SCTs pouvant être renvoyés au cours de la +phase ServerHello</description> +<syntax>CTServerHelloSCTLimit <em>limit</em></syntax> +<default>100</default> +<contextlist><context>server config</context> +</contextlist> + +<usage> + <p>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.</p> + + <p>En général, seuls quelques SCTs sont disponibles, cette directive + n'est donc nécessaire que dans certaines circonstances particulières.</p> + + <p>Cette directive ne tient pas compte des SCTs contenus dans les + extensions de certificats ou les réponses OCSP agrafées.</p> +</usage> +</directivesynopsis> + +<directivesynopsis> +<name>CTStaticLogConfig</name> +<description>Configuration statique d'un log</description> +<syntax>CTStaticLogConfig <em>log-id|-</em> <em>public-key-file|-</em> +<em>1|0|-</em> <em>min-timestamp|-</em> <em>max-timestamp|-</em> +<em>log-URL|-</em></syntax> +<default>none</default> +<contextlist><context>server config</context> +</contextlist> + +<usage> + <p>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 + <directive module="mod_ssl_ct">CTLogConfigDB</directive>.</p> + + <p>Chacun des six champs doit être renseigné, mais en général, la + configuration d'un log nécessite peu d'information ; utilisez + <em>-</em> 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.</p> + + <p>Les champs se définissent comme suit :</p> + + <dl> + <dt><em>log-id</em></dt> + <dd>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. + <br /> + Ce champ peut être omis lorsque <em>public-key-file</em> est + renseigné.</dd> + + <dt><em>public-key-file</em></dt> + <dd>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 <directive + module="core">ServerRoot</directive>.</dd> + + <dt><em>trust/distrust</em></dt> + <dd>Définissez ce champ à <em>1</em> 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 + à <em>-</em> ou <em>0</em> (valeur par défaut) pour accorder votre + confiance au log.</dd> + + <dt><em>min-timestamp</em> et <em>max-timestamp</em></dt> + <dd>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. + <br /> + Spécifiez <strong><code>-</code></strong> 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 <strong><code>-</code></strong> pour + <em>max-timestamp</em>. + <br /> + Les SCTs reçu par le mandataire depuis ce log seront invalides si le + repère de temps est plus ancien que <em>min-timestamp</em> ou plus + récent que <em>max-timestamp</em>.</dd> + + <dt><em>log-URL</em></dt> + <dd>Il s'agit de l'URL du log auquel soumettre les certificats de + serveur et ainsi obtenir des SCTs à envoyer aux clients.</dd> + </dl> +</usage> + +<seealso>Le paragraphe <a href="#logconf">Configuration des logs</a> +contient des informations à caractère plus général à propos des champs qui +peuvent être définis via cette directive.</seealso> + +</directivesynopsis> + +<directivesynopsis> +<name>CTStaticSCTs</name> +<description>Configuration statique d'un ou plusieurs SCTs pour un +certificat de serveur +</description> +<syntax>CTStaticSCTs <em>certificate-pem-file</em> <em>sct-directory</em></syntax> +<default>none</default> +<contextlist><context>server config</context> +</contextlist> + +<usage> + <p>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.</p> + + <p><em>certificate-pem-file</em> 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 + <directive module="core">ServerRoot</directive>.</p> + + <p><em>sct-directory</em> doit contenir le chemin vers un ou plusieurs + fichiers possédant l'extension de nom de fichier <code>.sct</code>, + 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 + <directive module="core">ServerRoot</directive>.</p> + + <p>Si <em>sct-directory</em> est vide, aucun message d'erreur ne sera + affiché.</p> + + <p>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 + <em>.sct</em>.</p> +</usage> +</directivesynopsis> + +</modulesynopsis> diff --git a/docs/manual/mod/mod_ssl_ct.xml.meta b/docs/manual/mod/mod_ssl_ct.xml.meta index c33bcb9fde..8fc8c4826d 100644 --- a/docs/manual/mod/mod_ssl_ct.xml.meta +++ b/docs/manual/mod/mod_ssl_ct.xml.meta @@ -8,5 +8,6 @@ <variants> <variant>en</variant> + <variant>fr</variant> </variants> </metafile> diff --git a/docs/manual/mod/mod_syslog.xml.fr b/docs/manual/mod/mod_syslog.xml.fr new file mode 100644 index 0000000000..9926ee9cd8 --- /dev/null +++ b/docs/manual/mod/mod_syslog.xml.fr @@ -0,0 +1,59 @@ +<?xml version="1.0"?> +<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd"> +<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?> +<!-- English Revision : 1673945 --> +<!-- French translation : Lucien GENTIS --> +<!-- $LastChangedRevision: 2015050201 $ --> + +<!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the "License"); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +--> + +<modulesynopsis metafile="mod_syslog.xml.meta"> + +<name>mod_syslog</name> +<description>Support du fournisseur de journalisation "syslog"</description> +<status>Extension</status> +<sourcefile>mod_syslog.c</sourcefile> +<identifier>syslog_module</identifier> + +<summary> + + <p>Ce module implémente le fournisseur de journalisation "syslog". + Il permet de journaliser les messages d'erreur via syslogd(8).</p> +</summary> + +<section id="examples"> + <title>Exemples</title> + + <p>Si le système le supporte, l'utilisation du paramètre + <code>syslog</code> avec la directive ErrorLog (voir la + documentation du module <module>core</module>) à 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 <code>local7</code> qui + est utilisé, mais vous pouvez le modifier via la syntaxe + <code>syslog:<var>port</var></code> où <var>port</var> 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.</p> + + <highlight language="config">ErrorLog syslog:user</highlight> + +</section> + + +</modulesynopsis> diff --git a/docs/manual/mod/mod_syslog.xml.meta b/docs/manual/mod/mod_syslog.xml.meta index cb174b302f..bf9b2c11e9 100644 --- a/docs/manual/mod/mod_syslog.xml.meta +++ b/docs/manual/mod/mod_syslog.xml.meta @@ -8,5 +8,6 @@ <variants> <variant>en</variant> + <variant>fr</variant> </variants> </metafile> diff --git a/docs/manual/mod/mod_systemd.xml.fr b/docs/manual/mod/mod_systemd.xml.fr new file mode 100644 index 0000000000..2766954785 --- /dev/null +++ b/docs/manual/mod/mod_systemd.xml.fr @@ -0,0 +1,79 @@ +<?xml version="1.0"?> +<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd"> +<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?> +<!-- English Revision : 1620075 --> +<!-- French translation : Lucien GENTIS --> +<!-- $LastChangedRevision: 2015011801 $ --> + +<!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the "License"); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +--> + +<modulesynopsis metafile="mod_systemd.xml.meta"> + +<name>mod_systemd</name> +<description>Fournit un support amélioré pour l'intégration de systemd</description> +<status>Extension</status> +<sourcefile>mod_systemd.c</sourcefile> +<identifier>systemd_module</identifier> + +<summary> + <p>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 <code>Type=notify</code> (voir la page de manuel + systemd.service(5) pour plus de détails). Il ajoute aussi des + statistiques à la sortie de la commande <code>systemctl + status</code>, et fournit diverses directives pour l'intégration de + systemd. + </p> +</summary> + +<directivesynopsis> +<name>IdleShutdown</name> +<description>Permet d'arrêter httpd lorsque qu'il est inactif pendant un +certain temps.</description> +<syntax>IdleShutdown seconds</syntax> +<default>IdleShutdown 0</default> +<contextlist><context>server config</context></contextlist> + +<usage> + <p>La directive <directive>IdleShutdown</directive> 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. + </p> + + <p>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. + </p> + + <note type="warning"><title>Particularité de cette implémentation</title><p> + 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 <code>IdleShutdown 14</code>, httpd ne s'arrêtera + qu'après 20 secondes d'inactivité. + </p></note> +</usage> +</directivesynopsis> + + +</modulesynopsis> diff --git a/docs/manual/mod/mod_systemd.xml.meta b/docs/manual/mod/mod_systemd.xml.meta index 736c72dc7a..edb0b7cbc9 100644 --- a/docs/manual/mod/mod_systemd.xml.meta +++ b/docs/manual/mod/mod_systemd.xml.meta @@ -8,5 +8,6 @@ <variants> <variant>en</variant> + <variant>fr</variant> </variants> </metafile> diff --git a/docs/manual/mod/mod_version.xml.fr b/docs/manual/mod/mod_version.xml.fr new file mode 100644 index 0000000000..c7c503f76b --- /dev/null +++ b/docs/manual/mod/mod_version.xml.fr @@ -0,0 +1,148 @@ +<?xml version="1.0"?> +<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd"> +<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?> +<!-- English Revision : 1421821 --> +<!-- French translation : Lucien GENTIS --> +<!-- $LastChangedRevision: 2012121601 $ --> + +<!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the "License"); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +--> + +<modulesynopsis metafile="mod_version.xml.meta"> +<name>mod_version</name> +<description>Configuration dépendant de la version</description> +<status>Extension</status> +<sourcefile>mod_version.c</sourcefile> +<identifier>version_module</identifier> + +<summary> + <p>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 -- <directive type="section" + module="mod_version">IfVersion</directive>, qui apporte une grande + souplesse dans la vérification de version en permettant une + comparaison numérique et l'utilisation d'expressions + rationnelles.</p> + + <example><title>Exemples</title> + <highlight language="config"> +<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> + </highlight> + </example> + + <p>Voir ci-dessous pour d'autres exemples.</p> +</summary> + +<directivesynopsis type="section"> +<name>IfVersion</name> +<description>Contient des portions de configuration dépendantes de la +version</description> +<syntax><IfVersion [[!]<var>opérateur</var>] <var>version</var>> ... +</IfVersion></syntax> +<contextlist><context>server config</context><context>virtual host +</context> +<context>directory</context><context>.htaccess</context></contextlist> +<override>All</override> + +<usage> + <p>La section <directive type="section">IfVersion</directive> + 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 <var>version</var> doit + être spécifié sous le format + <code><var>majeur</var>[.<var>mineur</var>[.<var>patch</var>]]</code>, + comme par exemple <code>2.1.0</code> ou <code>2.2</code>. + <var>mineur</var> et <var>patch</var> sont optionnels. Si ces + numéros sont absents, il se voient affectée implicitement la valeur + 0. Les <var>opérateur</var>s numériques suivants sont autorisés + :</p> + + <table style="zebra" border="1"> + <tr><th><var>opérateur</var></th><th>description</th></tr> + <tr><td><code>=</code> ou <code>==</code></td> + <td>La version de httpd est égale à la valeur + spécifiée</td></tr> + <tr><td><code>></code></td> + <td>La version de httpd est supérieure à la valeur + spécifiée</td></tr> + <tr><td><code>>=</code></td> + <td>La version de httpd est supérieure ou égale à la valeur + spécifiée</td></tr> + <tr><td><code><</code></td> + <td>La version de httpd est inférieure à la valeur + spécifiée</td></tr> + <tr><td><code><=</code></td> + <td>La version de httpd est inférieure ou égale à la valeur + spécifiée</td></tr> + </table> + + <example><title>Exemple</title> + <highlight language="config"> +<IfVersion >= 2.3> + # la condition n'est satisfaite que pour les versions de httpd + # supérieures ou égales à 2.3 +</IfVersion> + </highlight> + </example> + + <p>En plus d'une comparaison numérique, il est possible de comparer + la version de httpd avec une <glossary ref="regex">expression + rationnelle</glossary>. Il existe deux méthodes pour spécifier cette + dernière :</p> + + <table style="zebra" border="1"> + <tr><th><var>opérateur</var></th><th>description</th></tr> + <tr><td><code>=</code> ou <code>==</code></td> + <td><var>version</var> est de la forme + <code>/<var>regex</var>/</code></td></tr> + <tr><td><code>~</code></td> + <td><var>version</var> est de la forme + <code><var>regex</var></code></td></tr> + </table> + + <example><title>Exemple</title> + <highlight language="config"> +<IfVersion = /^2.4.[01234]$/> + # exemple de contournement pour les versions boguées +</IfVersion> + </highlight> + </example> + + <p>Pour inverser la condition, tous les opérateurs peuvent être + préfixés par un point d'exclamation (<code>!</code>) :</p> + + <example> + <highlight language="config"> +<IfVersion !~ ^2.4.[01234]$> + # pas pour ces versions +</IfVersion> + </highlight> + </example> + + <p>Si <var>opérateur</var> est absent, sa valeur implicite est + <code>=</code>.</p> +</usage> +</directivesynopsis> + +</modulesynopsis> diff --git a/docs/manual/mod/mod_version.xml.meta b/docs/manual/mod/mod_version.xml.meta index 4fbd74a3a1..5dcdb84f2e 100644 --- a/docs/manual/mod/mod_version.xml.meta +++ b/docs/manual/mod/mod_version.xml.meta @@ -8,6 +8,7 @@ <variants> <variant>en</variant> + <variant>fr</variant> <variant>ja</variant> <variant outdated="yes">ko</variant> </variants> |