From 63b487c114be1370e3dec4e1d05492be473702c4 Mon Sep 17 00:00:00 2001 From: Lucien Gentis Date: Fri, 12 Jun 2026 15:43:39 +0000 Subject: [PATCH] fr doc XML file update plus 1 nex file added. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1935211 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/mod/core.xml.fr | 42 ++- docs/manual/mod/mod_proxy_beacon.xml.fr | 417 ++++++++++++++++++++++++ 2 files changed, 448 insertions(+), 11 deletions(-) create mode 100644 docs/manual/mod/mod_proxy_beacon.xml.fr diff --git a/docs/manual/mod/core.xml.fr b/docs/manual/mod/core.xml.fr index d9a67b5d7d..a6cbd45769 100644 --- a/docs/manual/mod/core.xml.fr +++ b/docs/manual/mod/core.xml.fr @@ -1,7 +1,7 @@ - + @@ -517,16 +517,36 @@ autorisés à transiter dans les URLs tels quels pouvant être définies à l'aide de la directive Options. - Désactivation implicite des options -

Bien que la liste des options disponibles dans les fichiers - .htaccess puisse être limitée par cette directive, tant qu'un - directive Options est - autorisée, toute autre option héritée peut être désactivée en - utilisant la syntaxe non-relative. En d'autres termes, ce - mécanisme ne peut pas forcer une option spécifique à rester - activée tout en permettant à toute autre option d'être - activée. -

+ Désactivation implicite des options +

Cette restriction ne contrôle que les options qu’un fichier + .htaccess peut activer. Elle n’empêche pas la + désactivation des options héritées.

+ +

Lorsqu’une directive Options dans + un fichier .htaccess utilise une syntaxe absolue (sans + préfixe + ou -), elle remplace la + totalité du jeu d’options héritées. Toute option auparavant active qui + n’est pas listée est implicitement désactivée—il en est de même pour + les options qui ne sont pas dans la liste AllowOverride des + options permises.

+ +

Par exemple, si la configuration définit :

+ +Options Indexes FollowSymLinks ExecCGI +AllowOverride Options=Indexes + +

et si un fichier .htaccess contient :

+ +Options Indexes + +

les options FollowSymLinks et ExecCGI seront + implicitement désactivée pour le répertoire concerné, même si la ligne + AllowOverride ne fait que permettre la définition de l’option + Indexes.

+ +

En bref, ce mécanisme ne peut pas forcer une option spécifique à rester + définie tout en permettant la définition de toutes les autres.

+ AllowOverride Options=Indexes,MultiViews diff --git a/docs/manual/mod/mod_proxy_beacon.xml.fr b/docs/manual/mod/mod_proxy_beacon.xml.fr new file mode 100644 index 0000000000..ccb5691270 --- /dev/null +++ b/docs/manual/mod/mod_proxy_beacon.xml.fr @@ -0,0 +1,417 @@ + + + + + + + + + + +mod_proxy_beacon +Inscription dynamique comme membre d’un répartiteur de charge où +les serveurs dorsaux s’annoncent eux-mêmes au mandataire inverse à l’aide de +datagrammes UDP unicast +Extension +mod_proxy_beacon.c +proxy_beacon_module +Disponible à partir de la version 2.5 du serveur HTTP Apache + + +

Ce module permet à des serveurs dorsaux de s’annoncer eux-mêmes + à un mandataire inverse frontal qui les ajoute alors en tant que membre + actif (worker) d’un répartiteur de charge de + mod_proxy_balancer. Lorsqu’un serveur dorsal cesse de + s’annoncer, le mandataire l’enlève de la rotation. Cela permet une gestion + autonome (inscriptions et maintenance) de la liste des membres du + répartiteur sans avoir à éditer la configuration du mandataire ou piloter le + balancer-manager à la main.

+ +

La communication utilise des datagrammes pleinement unicast + UDP (pas de multicast qui est filtré sur la plupart des réseaux et + ne passe pas sur l’Internet public). Les données sont transmises du serveur + dorsal vers le mandataire :

+ +
    +
  • Le mandataire inverse se lie à un socket UDP et reçoit les + données sur une adresse fixe (ProxyBeaconListen).
    • +
  • Chaque serveur dorsal envoie périodiquement un court + datagramme d’annonce au mandataire + (ProxyBeaconAddress), indiquant son propre URL + routable (ProxyBeaconAdvertise).
    • +
+ +

Les datagrammes sont envoyés en mode « fire-and-forget » : une annonce + perdue est récupérée par la prochaine annonce périodique, et le + réordonnancement est rejeté par une vérification d’horodatage par serveur + dorsal ; aucune connexion, reconnection ou couche de cadrage n’est donc + nécessaire.

+ +

Au niveau du mandataire, la directive + ProxyBeaconBalancer nomme le répartiteur de charge + auquel des serveurs dorsaux qui se sont annoncés ont été ajoutés. Les + changements d’appartenance s’appliquent en utilisant le même mécanisme + interne que l’interface web balancer-manager ; un serveur + dorsal ajouté de cette manière se comporte donc exactement comme un + BalancerMember configuré + statiquement ou ajouté manuellement, et est visible et éditable dans + balancer-manager.

+ +

Ce module nécessite les services de mod_watchdog et + mod_proxy_balancer. Le travail d’arrière-plan (écoute, + publication, ajout et suppression de membres) est effectué par un seul + processus enfant de mod_watchdog ; il n’est donc pas + disponible avec le comportement du MPM prefork où ce singleton + ne peut pas s’exécuter.

+ +Authentification +

Tout hôte qui peut atteindre le port de réception du mandataire peut + aussi annoncer un URL de serveur dorsal arbitraire et faire que le + mandataire envoie le trafic du client à ce dernier (et une adresse source + UDP est facile à usurper). Définissez la directive + ProxyBeaconSecret à la même valeur sur le mandataire + et sur chaque serveur dorsal de façon que les annonces soient authentifiées + avec un message-authentication code (MAC) avec clé et un horodatage. + Lorsqu’une phrase secrète est configurée, le mandataire rejette toute + annonce qui n’est pas valablement signée et récente. Si aucune phrase + secrète n’est configurée, le canal n’est pas authentifié et + le mandataire journalise un avertissement au démarrage.

+ + +Confidentialité +

Les annonces sont authentifiées mais non chiffrées ; la charge utile + comporte des métadonnées opérationnelles (URLs de serveur dorsal) non + chiffrées. La confidentialité du transport (par exemple DTLS) + n’est actuellement pas prise en charge et fera l’objet d’une couche + séparée.

+ + + +mod_proxy +mod_proxy_balancer +mod_proxy_hcheck +mod_watchdog + +
+ Exemple d’utilisation + +

L’exemple suivant configure un répartiteur de charge à enregistrement + autonome. Les serveurs dorsaux n’ont pas besoin de se connaître entre eux et + le mandataire n’a pas besoin d’entrées BalancerMember prédéclarées — seulement + un répartiteur vide avec de la place pour grossir.

+ +

Sur le mandataire inverse :

+ +# Réception des annonces des serveurs dorsaux sur +# l’interface réseau de cluster (UDP). +ProxyBeaconListen 0.0.0.0:5555 +ProxyBeaconSecret "une_grande_phrase_secrète_partagée_aléatoire_de_cluster" +ProxyBeaconBalancer cluster + +# Un serveur dorsal est éjecté de la rotation s’il ne +# s’annonce pas pendant 30 secondes. +ProxyBeaconTimeout 30 + +# Un répartiteur initialement vide avec des emplacements +# libres pour les membres dynamiques. +<Proxy balancer://cluster> + ProxySet growth=16 +</Proxy> +ProxyPass "/" "balancer://cluster/" +ProxyPassReverse "/" "balancer://cluster/" + + +

Sur chaque serveur dorsal :

+ +# Annoncer au mandataire cette adresse routable de serveur dorsal +# toutes les 10 secondes (UDP). +ProxyBeaconAddress proxy.example.com:5555 +ProxyBeaconAdvertise http://10.0.0.5:8080 +ProxyBeaconSecret "une_grande_phrase_secrète_partagée_aléatoire_de_cluster" +ProxyBeaconInterval 10 + + +

Au démarrage d’un serveur dorsal, ce dernier commence à s’annoncer. Le + mandataire vérifie la validité de chaque annonce à l’aide de la phrase + secrète, ajoute http://10.0.0.5:8080 comme membre de + balancer://cluster, et l’active. Si ce serveur dorsal arrête de + s’annoncer pendant une durée supérieure à la valeur de la directive + ProxyBeaconTimeout, le mandataire le désactive (en + l’enlevant de la rotation) ; si le serveur dorsal s’annonce à nouveau, il + est réactivé.

+ + +

Un serveur dorsal ajouté à l’exécution occupe un des emplacements + du répartiteur pour la durée de vie du processus serveur ; plutôt que de le + supprimer lorsqu’il arrête de s’annoncer, il est désactivé, suivant en cela + le comportement du balancer-manager (qui peut ajouter des + membres à l’exécution, mais pas les supprimer). La taille du répartiteur + augmente jusqu’au nombre maximal de serveurs dorsaux que vous + souhaitez enregistrer.

+ + +
+ + +ProxyBeaconListen +Adresse sur laquelle le mandataire inverse reçoit les annonces des +serveurs dorsaux +ProxyBeaconListen [address][:port] +server configvirtual host + + + +

La directive ProxyBeaconListen marque un serveur + comme récepteur « phare » (le mandataire inverse). Il lie un socket + UDP à l’adresse spécifiée, par exemple 0.0.0.0:5555 pour + effectuer la réception sur toutes les interfaces. Un préfixe de protocole + (tel que tcp://) est accepté et ignoré.

+ +

L’adresse et le port sont facultatifs et, s’ils sont omis, sont hérités + de l’adresse et du port de ce serveur (ses directives Listen et ServerName). Si aucun argument n’est fourni, + l’écouteur du « phare » lie les propres adresse et port du serveur ; si + seule l’adresse est donnée, le port est hérité, et ainsi de suite. Étant + donné que UDP et TCP sont des espaces de port indépendants, lier le socket + du « phare » au port du serveur n’entre pas en collision avec + l’écouteur TCP du serveur — faisant que le canal du « phare » partage + le point de terminaison du service, qui identifie aussi le mandataire auprès + des serveurs dorsaux avec son adresse réelle (comme l’écouteur effectue ses + liens dans un processus enfant non privilégié, un port privilégié comme 80 + ou 443 ne peut pas être partagé de cette manière ; n’utilisez le port du + serveur que s’il est non privilégié).

+ +

Les serveurs dorsaux envoient leurs annonces à l’adresse spécifiée par la + directive ProxyBeaconAddress. Cette dernière doit + être utilisée conjointement avec la directive + ProxyBeaconBalancer ; dans le cas contraire, les + annonces sont reçues et journalisées, mais aucun membre n’est ajouté. Les + directives ProxyBeaconListen et + ProxyBeaconAddress sont mutuellement exclusives sur + un même serveur.

+ + + + +ProxyBeaconAddress +Adresse du mandataire inverse à laquelle un serveur dorsal envoie +ses annonces +ProxyBeaconAddress address:port +server configvirtual host + + + +

La directive ProxyBeaconAddress marque un serveur + comme émetteur d’annonces (un serveur dorsal). Ce dernier envoie + des datagrammes UDP à l’adresse ProxyBeaconListen du + mandataire sous la forme adresse:port, par exemple + proxy.example.com:5555 (un préfixe de protocole tel que + tcp:// est accepté, mais ignoré). Étant donné que UDP est sans + connexion, un serveur dorsal peut être démarré avant que le mandataire soit + disponible : les datagrammes seront simplement supprimés et continueront à + être envoyés selon l’intervalle spécifié.

+ +

Utilisez la directive ProxyBeaconAdvertise pour + spécifier l’URL routable qu’annonce le serveur dorsal. Les + directives ProxyBeaconListen et + ProxyBeaconAddress sont mutuellement exclusives sur + un même serveur.

+ + + + +ProxyBeaconAdvertise +L’URL routable qu’annonce le serveur dorsal au mandataire inverse +ProxyBeaconAdvertise url +server configvirtual host + + + +

La directive ProxyBeaconAdvertise permet de + définir l’adresse à laquelle le serveur dorsal peut être atteint (par + exemple http://10.0.0.5:8080) et que le mandataire ajoutera en + tant que membre BalancerMember. + Il doit s’agir d’un URL complet comme scheme://host[:port] que + le mandataire pourra atteindre — pas l’adresse d’écoute locale — + et qui sera validé lors de l’analyse de la configuration.

+ +

Cette directive est utilisée sur un serveur dorsal avec la directive + ProxyBeaconAddress. Si elle est omise, le serveur + dorsal envoie quand-même un signe de vie, mais pas d’URL ; le mandataire + journalise alors l’annonce sans ajouter de membre.

+ + + + +ProxyBeaconBalancer +Le nom du répartiteur de charge auquel les serveurs dorsaux +annoncés sont ajoutés +ProxyBeaconBalancer name +server configvirtual host + + + +

La directive ProxyBeaconBalancer permet de nommer + le répartiteur, sur le mandataire inverse, dans lequel les serveurs dorsaux + annoncés sont insérés en tant que membres. Indiquez seulement le nom du + répartiteur (par exemple cluster pour + balancer://cluster) ; le préfixe balancer:// est + accepté et supprimé.

+ +

Le répartiteur nommé doit exister et disposer d’emplacements vides. + Déclarez-le dans un bloc <Proxy> avec un paramètre + growth (ou utilisez la valeur de la directive BalancerGrowth) de façon qu’il y ait des + emplacements libres pour l’ajout dynamique de membres. Cette directive est + utilisée conjointement avec la directive + ProxyBeaconListen.

+ + + + +ProxyBeaconInterval +Périodicité de l’envoi d’annonces par le serveur dorsal +ProxyBeaconInterval interval +ProxyBeaconInterval 5 +server configvirtual host + + + +

La directive ProxyBeaconInterval permet de définir + la périodicité à laquelle un serveur dorsal (un serveur + ProxyBeaconAddress) envoie ses annonces. Elle utilise + la syntaxe de la directive time-interval et sa valeur s’exprime + par défaut en secondes ; sa valeur par défaut est 5 secondes.

+ +

L’intervalle doit être significativement plus petit que la valeur de la + directive ProxyBeaconTimeout, de façon qu’une perte + occasionnelle ou qu’une annonce retardée ne provoquent pas l’éviction d’un + serveur dorsal opérationnel.

+ + + + +ProxyBeaconTimeout +Durée maximale de l’absence d’annonce d’un serveur dorsal au bout +de laquelle le mandataire enlève ce dernier de la rotation +ProxyBeaconTimeout interval +ProxyBeaconTimeout 0 +server configvirtual host + + + +

La directive ProxyBeaconTimeout permet de définir + la durée maximale pendant laquelle le mandataire attendra une annonce en + provenance d’un serveur dorsal avant de désactiver ce dernier (en l’enlevant + de la rotation). Si ce serveur dorsal renvoie une annonce par la suite, il + est réactivé. Cette directive utilise + la syntaxe de la directive time-interval et sa valeur s’exprime + par défaut en secondes.

+ +

La valeur par défaut, 0, désactive complètement l’éviction : + les serveurs dorsaux sont ajoutés lorsqu’ils s’annoncent mais ne sont jamais + désactivés automatiquement. Définissez cette directive à un multiple de + (quelques fois) la valeur de la directive + ProxyBeaconInterval du serveur dorsal pour mettre en + œuvre une maintenance autonome des adhésions. Cette directive est définie + sur le mandataire.

+ + + + +ProxyBeaconSecret +Phrase secrète partagée à l’avance pour authentifier les annonces +des serveurs dorsaux +ProxyBeaconSecret secret +server configvirtual host + + + +

La directive ProxyBeaconSecret permet de définir + une phrase secrète partagée à l’avance au sein de la grappe de serveurs. + Elle doit être définie avec la même valeur sur le mandataire + inverse et sur chaque serveur dorsal. Le serveur dorsal (l’émetteur) signe + chaque annonce avec un message-authentication code (un SipHash MAC) avec + clé, dérivé de la phrase secrète et avec un horodatage ; le mandataire (le + récepteur) recalcule le MAC et vérifie l’horodatage, en rejetant toute + annonce falsifiée, usurpée ou réenvoyée. Les messages réenvoyés sont + interceptés de deux manières : une fenêtre de fraîcheur (directive + ProxyBeaconMaxSkew) rejette les horodatages anciens, + et une vérification pour chaque serveur dorsal rejette toute annonce dont + l’horodatage n’avance pas strictement ; ainsi, un message capturé et renvoyé + (par exemple pour empêcher l’éviction d’un serveur dorsal éteint) sera + rejeté.

+ +

Si la directive ProxyBeaconSecret est définie sur + le mandataire, chaque annonce doit comporter un MAC valable et récent, sous + peine d’être rejetée. Si les phrases secrètes du mandataire et d’un serveur + dorsal diffèrent, les annonces de ce dernier seront rejetées silencieusement + (et journalisées), ce qui donne l’impression que le serveur dorsal n’a + jamais atteint le répartiteur de charge.

+ +

Si aucune phrase secrète n’est configurée, le canal n’est pas authentifié + et le mandataire émet un avertissement lorsqu’il commence à écouter. Étant + donné que la phrase secrète est stockée dans le fichier de configuration, + définissez les permissions de ce dernier comme s’il s’agissait d’une clé + privée.

+ + Synchronisation de l’horloge +

La protection contre la réémission basée sur l’horodatage compare le + moment de l’annonce avec l’horloge du mandataire ; le mandataire et les + serveurs dorsaux doivent donc avoir des horloges correctement synchronisées + (par exemple à l’aide de NTP). Voir la directive + ProxyBeaconMaxSkew.

+ + + + + +ProxyBeaconMaxSkew +Age maximal autorisé d’une annonce signée +ProxyBeaconMaxSkew interval +server configvirtual host + + + +

La directive ProxyBeaconMaxSkew permet de définir + la fenêtre anti-réémission utilisée lorsque la directive + ProxyBeaconSecret est configurée : le mandataire + rejette toute annonce dont l’horodatage signé diffère du temps actuel d’une + valeur supérieure à celle de la directive + ProxyBeaconMaxSkew, et cela dans les deux directions. + Cette directive utilise la syntaxe de la directive time-interval et sa valeur s’exprime + par défaut en secondes.

+ +

Si elle n’est pas définie, sa valeur par défaut est de 30 secondes. Une + fenêtre plus large tolère des écarts d’horloge plus grands entre les hôtes ; + une fenêtre plus petite restreint la tolérance sur la vérification de + fraîcheur. Notez que la vérification de la croissance stricte des + horodatages d’un même serveur (voir la directive + ProxyBeaconSecret) bloque les réémissions, quelle que + soit la valeur de cette fenêtre. Cette directive est utilisée au niveau du + mandataire.

+ + + + -- 2.47.3