[RFR2] wml://mirror/push_mirroring.wml
Bonjour,
le Tue, 21 Feb 2017 09:22:56 +0100, Baptiste Jammet
<baptiste@mailoo.org> a écrit :
>Quelques suggestions.
Merci, appliquées.
>« après que » + indicatif (http://www.academie-francaise.fr/apres-que)
>est ce que ma correction est juste ?
« La tendance parait irrésistible même si l’indicatif appartient au bon
toujours au bon usage » (Le français correct, Maurice Grevisse).
Merci d’avance pour vos autres relectures.
Amicalement.
--
Jean-Paul
#use wml::debian::template title="Explication des miroirs par repoussage"
#use wml::debian::translation-check translation="1.22" maintainer="Jean-Paul Guillonneau"
# Premier traducteur : Christian Couder
<p>
Les miroirs par repoussage sont une forme de miroirs qui minimisent le temps
que mettent les modifications de l'archive pour atteindre les miroirs.
Le serveur maître utilise un mécanisme déclencheur pour indiquer immédiatement
au miroir client qu'il doit se mettre à jour.
</p>
<p>
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 a été mise à jour. Cela
permet une propagation rapide des changements de l'archive.
</p>
<h2>Explication de la méthode</h2>
<p>Les déclenchements sont faits en utilisant ssh. Le miroir poussant se
connecte par SSH sur le compte du miroir du serveur poussé en utilisant
une authentification par clef publique. La clef est définie de façon
à ne déclencher quâ??une copie de miroir et non dâ??autres commandes. Le
serveur aval exécute alors ftpsync pour mettre à jour lâ??archive en
utilisant rsync comme dâ??habitude.
<br />
Lâ??échange de clefs et lâ??accès potentiel aux serveurs rsync dâ??accès restreints
demande une coordination entre lâ??opérateur du miroir et sa source
amont.
</p>
<h2>Mettre en place un miroir par repoussage côté client</h2>
<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.
<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>
<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 se synchronisent directement à partir du réseau interne de
mandataires de synchronisation de Debian.
</p>
<p>
Si votre site est <strong>très</strong> bien connecté (à la fois une très bonne
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. 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 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>
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>
--- push_mirroring_1.19.wml 2017-02-20 12:54:39.694181245 +0100
+++ push_mirroring.wml 2017-02-21 10:34:02.371396463 +0100
@@ -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 @@
</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 a été mise à jour. Cela
+permet une propagation rapide des changements de l'archive.
+</p>
+
+<h2>Explication de la méthode</h2>
+
+<p>Les déclenchements sont faits en utilisant ssh. Le miroir poussant se
+connecte par SSH sur le compte du miroir du serveur poussé en utilisant
+une authentification par clef publique. La clef est définie de façon
+à ne déclencher quâ??une copie de miroir et non dâ??autres commandes. Le
+serveur aval exécute alors ftpsync pour mettre à jour lâ??archive en
+utilisant rsync comme dâ??habitude.
+<br />
+Lâ??échange de clefs et lâ??accès potentiel aux serveurs rsync dâ??accès restreints
+demande une coordination entre lâ??opérateur du miroir et sa source
+amont.
</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.
-</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 @@
<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 @@
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.
+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>
-<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>.
-</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>
Reply to: