diff options
author | Jean Paul Guillonneau <jptha-guest> | 2017-02-21 08:29:34 +0000 |
---|---|---|
committer | Jean Paul Guillonneau <jptha-guest> | 2017-02-21 08:29:34 +0000 |
commit | 69915b6d62dcb09bdda70609b2efc4d3609bc5eb (patch) | |
tree | 3479e7f026522e78f8ff8659f35d4ab71273da8c /french/mirror | |
parent | 3fbd31d4177a2c2f37503f3de55a46e3b65b9be2 (diff) |
(fr) Sync
CVS version numbers
french/mirror/push_mirroring.wml: 1.13 -> 1.14
Diffstat (limited to 'french/mirror')
-rw-r--r-- | french/mirror/push_mirroring.wml | 131 |
1 files changed, 36 insertions, 95 deletions
diff --git a/french/mirror/push_mirroring.wml b/french/mirror/push_mirroring.wml index 0aa4bba3a3e..6c0d1a0f29d 100644 --- a/french/mirror/push_mirroring.wml +++ b/french/mirror/push_mirroring.wml @@ -1,6 +1,6 @@ #use wml::debian::template title="Explication des miroirs par repoussage" -#use wml::debian::translation-check translation="1.19" maintainer="Nicolas Bertolissio" +#use wml::debian::translation-check translation="1.22" maintainer="Jean-Paul Guillonneau" # Premier traducteur : Christian Couder @@ -12,74 +12,38 @@ au miroir client qu'il doit se mettre à jour. </p> <p> -Les miroirs par repoussage demandent un peu plus d'effort à mettre en place car -les responsables des miroirs client et serveur doivent s'échanger des -informations. L'avantage est que le miroir serveur lance le processus de mise à -jour du client immédiatement après que son archive a été mise à jour. Cela -permet une propagation très rapide des changements de l'archive. +Les miroirs par repoussage demandent plus d'efforts de mise en place car les +responsables des miroirs amont et aval doivent s'échanger des informations. +L'avantage est que le miroir amont lance le processus de mise à jour du +miroir aval immédiatement après que son archive ait été mise à jour. Cela +permet une propagation rapide des changements de l'archive. </p> - -<h2>Explication de ce fonctionnement</h2> - -<p> -Tout d'abord quelques informations sur SSH. SSH permet de se connecter à des -comptes sur différentes machines d'une manière sûre. Non seulement les mots de -passe ne sont jamais transmis en clair, mais une fois que vous êtes connecté à -une machine vous êtes certain que les connexions futures se feront sur la même -machine. Cela empêche beaucoup d'attaques du type un-homme-au-milieu. -</p> - -<p> -Une possibilité que vous offre SSH est la faculté d'accepter la clé publique -d'identification d'un utilisateur d'une autre machine et de l'ajouter au -fichier des clés autorisées sur sa propre machine. Par défaut, l'utilisateur -sur l'autre machine (qui a la clé d'identification privée associée à la clé -d'identité publique qu'il a donnée) a alors le droit de se connecter sous votre -compte. Il est cependant possible de rajouter des options à une clé autorisée -pour restreindre le type d'accès d'une personne l'utilisant pour se connecter -sur votre machine. +<h2>Explication de la méthode</h2> + +<p>Les déclenchements sont faits en utilisant ssh. Le miroir poussant se +connecte par SSH dans le compte du miroir du serveur poussé en utilisant +une authentification par clef publique. La clef est définie de telle façon +de ne déclencher qu’une copie de miroir et non d’autres commandes. Le +serveur aval alors exécute ftpsync pour mettre à jour l’archive en +utilisant rsync comme d’habitude. +<br /> +L’échange de clefs et l’accès potentiel aux serveurs d’accès restreints +rsync demande une coordination entre l’opérateur du miroir et sa source +amont. </p> -<p> -Ainsi pour protéger le miroir client, des options sont ajoutées à une clé -fournie par le miroir serveur pour donner aux personnes qui accèdent à votre -compte un seul droit : celui de lancer sur votre machine le programme qui -met à jour votre miroir. Même si quelqu'un (un tiers malveillant) était capable -de casser les clés, il ne pourrait alors que lancer le programme de miroir sur -votre machine. Vous n'avez même pas à vous soucier de la possibilité d'avoir -plusieurs copies du programme lancées, car un fichier verrou est utilisé. -</p> - -<p> -Sur le miroir client, rsync peut être configuré pour restreindre par nom -d'utilisateur et mot de passe la possibilité de faire un miroir d'une zone -donnée. Ceux-ci sont complètement séparés de <kbd>/etc/passwd</kbd> de façon à -ce qu'un serveur de repoussage n'ait pas à se soucier de donner à d'autres -l'accès à sa machine. De la façon dont c'est configuré, le nom d'utilisateur et -le mot de passe sont transmis en clair. Cela ne devrait cependant pas être un -problème, car le pire qu'il puisse se produire est qu'un tiers ait la -possibilité de faire un miroir de Debian depuis ce site. -</p> - - <h2>Mettre en place un miroir par repoussage côté client</h2> <p> -Le mieux est de mettre en place tout cela en utilisant le compte d'un -utilisateur ordinaire, non superutilisateur. Le contenu de la clé SSH publique que le -miroir serveur vous donne devrait être placée dans -<kbd>~<user>/.ssh/authorized_keys</kbd>. -</p> - -<p> Pour devenir un client par repoussage de l'archive FTP, vous devez paramétrer la recopie en utilisant notre jeu de scripts <a href="ftpmirror#how">ftpsync</a> standards. - -Copiez ftpsync.conf.sample vers <code>ftpsync.conf</code> et modifiez-le -conformément à votre système et aux renseignements fournis en amont. -</p> +<br /> +Une fois que cela fonctionne, ajoutez la clef SSH publique de votre miroir +amont dans votre <code>~<utilisateur>/.ssh/authorized_keys</code> avec une +restriction <code>command="~/bin/ftpsync</code>. (Vous pouvez avoir ftpsync +dans un répertoire différent, à adapter selon les cas.)</p> <h2>Les sites par repoussage de type client primaire</h2> @@ -87,7 +51,8 @@ conformément à votre système et aux renseignements fournis en amont. <p> Les miroirs par repoussage de type client primaire, aussi appelés miroirs 1<sup>er</sup> tiers, <i>Tier-1</i>, sont les miroirs par repoussage de -type client qui sont autorisés à faire un miroir de nos archives principales. +type client qui se synchronisent directement à partir du réseau interne de +mandataires de synchronisation de Debian. </p> <p> @@ -95,49 +60,25 @@ Si votre site est <strong>très</strong> bien connecté (à la fois une très bo bande passante et bien connecté aux épines dorsales majeures du réseau) et que vous acceptez de laisser d'autres sites faire un miroir à partir de votre site, vous pouvez nous le faire savoir afin que nous envisagions d'en faire un miroir -de repoussage. Cependant, ne vous attendez pas à ce que ça se fasse rapidement -car nous avons déjà un bon nombre de miroirs 1<sup>er</sup> tiers. -</p> - -<p> -Si vous devenez un repousseur primaire de l'archive FTP, vous avez besoin d'un -des fichiers suivants : -</p> - -<ul> - <li><a href="id_rsa.pub.ftp-master">clef publique SSH2 utilisée par - ftp-master.debian.org</a></li> - <li><a href="id_rsa.pub.syncproxy.eu">clef publique SSH2 utilisée par - syncproxy.eu.debian.org</a></li> - <li><a href="id_rsa.pub.syncproxy.wna">clef publique SSH2 utilisée par - syncproxy.wna.debian.org</a></li> -</ul> - -<p> -Si vous devenez un repousseur primaire des pages du site, vous avez besoin de -la <a href="id_rsa.pub.www-master">clef publique SSH2 utilisée par -www-master.debian.org</a>. +de repoussage. Notez cependant, que nous ne pouvons pas accepter toutes les +demandes pour devenir un miroir de repoussage primaire, car nous avons déjà +un bon nombre de miroirs 1<sup>er</sup> tiers. </p> - <h2>Mettre en place un miroir de repoussage côté serveur</h2> <p> Étant donné le grand nombre de miroirs et la taille de l'archive Debian, il -n'est pas possible que tous les miroirs utilisent l'archive principale comme -source de la Debian (c'est-à-dire comme leur miroir de repoussage de type -serveur). Il est beaucoup plus efficace de distribuer la charge sur un certain -nombre de miroirs de repoussage répartis à travers le monde. -</p> - -<p> -Les miroirs de repoussage de type serveur doivent être des miroirs par -repoussage de type client de l'archive principale (ou éventuellement d'un autre -miroir de repoussage de type serveur), et doivent contenir un miroir de -l'ensemble de l'archive Debian. +n'est pas possible que tous les miroirs utilisent les mandataires de +synchronisation internes de Debian comme sources amont. Il est beaucoup plus +efficace de distribuer la charge sur un certain nombre de miroirs de +repoussage répartis à travers le monde. </p> <p> -Voyez les <a href="push_server">détails sur la mise en place d'un serveur de +Par conséquent, un certain nombre de serveurs primaires de repoussage sont, +à tour de rôle, des serveurs de repoussage pour les serveurs en aval. Si +vous voulez configurer votre site comme serveur de repoussage, consultez les +<a href="push_server">détails sur la mise en place d'un serveur de repoussage</a>. </p> |