aboutsummaryrefslogtreecommitdiffstats
path: root/french/mirror
diff options
context:
space:
mode:
authorJean Paul Guillonneau <jptha-guest>2017-02-21 08:29:34 +0000
committerJean Paul Guillonneau <jptha-guest>2017-02-21 08:29:34 +0000
commit69915b6d62dcb09bdda70609b2efc4d3609bc5eb (patch)
tree3479e7f026522e78f8ff8659f35d4ab71273da8c /french/mirror
parent3fbd31d4177a2c2f37503f3de55a46e3b65b9be2 (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.wml131
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&nbsp;: 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>~&lt;user&gt;/.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>&nbsp;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>&nbsp; tiers.
-</p>
-
-<p>
-Si vous devenez un repousseur primaire de l'archive FTP, vous avez besoin d'un
-des fichiers suivants&nbsp;:
-</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>&nbsp; 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>

© 2014-2024 Faster IT GmbH | imprint | privacy policy