-- .~. Nicolas Bertolissio /V\ [EMAIL PROTECTED] // \\ /( )\ ^`~'^ Debian GNU/Linux
#use wml::debian::template title="Explication des miroirs par repoussage"
#use wml::debian::translation-check translation="1.13" maintainer="Nicolas Bertolissio"
# Premier traducteur : Christian Couder
<p>
Les miroirs par repoussage sont une forme de miroirs qui minimisent le temps
que mettent les changements de l'archive principale pour atteindre les miroirs.
Le miroir serveur 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 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.
</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 des pages 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 root. 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 script <a href="anonftpsync">anonftpsync</a>
standard, avec quelques modifications. Éditez la partie du script concernant
les configurations protégées par mot de passe en décommentant l'inclusion du
fichier <a href="ftpsync.conf">ftpsync.conf</a>. Éditez ftpsync.conf et suivez
les indications qui se trouvent à l'intérieur en utilisant les informations qui
vous sont données par le miroir serveur.
</p>
# Ces fichiers ont des noms différents de façon à ce que vous puissiez
# utiliser le même compte pour faire un miroir des deux archives.
<p>
Pour devenir un client par repoussage des pages du site, vous avez besoin des
fichiers <a href="websync">websync</a> et <a href="websync.conf">\
websync.conf</a>. Éditez websync.conf et suivez les indications qui se trouvent
à l'intérieur en utilisant les informations qui vous sont données par le miroir
serveur.
</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 sont autorisés à faire un miroir de nos archives principales.
</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. 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_dsa.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.
</p>
<p>
Voyez les <a href="push_server">détails sur la mise en place d'un serveur de
repoussage</a>.
</p>
#use wml::debian::template title="Mettre en place un serveur de repoussage" #use wml::debian::translation-check translation="1.16" maintainer="Nicolas Bertolissio" # Traducteur précédant : Christian Couder # Premier traducteur : Christophe Lebars <p> Mettre en place un serveur de repoussage se résume à effectuer deux tâches relativement simples : mettre en place un accès rsync (comme pour faire un miroir par aspiration standard) et mettre en place un mécanisme déclencheur utilisant ssh (pour déclencher la mise à jour du miroir par repoussage). </p> <p> <small>Pour plus d'information sur ce qu'est un serveur de repoussage, merci de lire <a href="push_mirroring">l'explication des miroirs par repoussage</a>.</small> </p> <toc-display /> <toc-add-entry name="rsync">Mettre en place rsync</toc-add-entry> <p> Installez <code>rsync</code> 2.1.1 ou une version supérieure. Si votre site tourne sous Debian, installez simplement le dernier paquet <a href="http://packages.debian.org/stable/net/rsync";>rsync</a>. </p> <p> Créez un fichier <code>rsyncd.conf</code> et mettez quelque chose comme ceci dans celui-ci : </p> <pre> uid = nobody gid = nogroup max connections = 25 socket options = SO_KEEPALIVE [debian] path = /srv/debian/mirror comment = The Debian Archive (~250 GB) auth users = compte_autorisé1,compte_autorisé2,compte_autoriséN read only = true secrets file = /etc/rsyncd/debian.secrets </pre> <p> Pour chaque site dont vous faites un miroir par repoussage, ajoutez une entrée au fichier <code>/etc/rsyncd/debian.secrets</code> : </p> <pre> compte_autorisé1:un_mot_de_passe compte_autorisé2:autre_mot_de_passe compte_autoriséN:_mot_de_passe </pre> <p> Vous avez alors donné accès à l'archive se trouvant sur votre machine aux miroirs clients de votre machine. </p> <p> Vous voudrez probablement lancer le démon rsync depuis inetd. Pour cela, vous devez d'abord ajouter le service rsync dans le fichier <code>/etc/services</code> (s'il n'y est pas déjà), comme ceci : </p> <pre> rsync 873/tcp </pre> <p> Pour lancer le démon avec inetd, ajoutez ce qui suit à votre fichier <code>/etc/inetd.conf</code> : </p> <pre> rsync stream tcp nowait root /usr/bin/rsync rsyncd --daemon </pre> <p> N'oubliez pas d'envoyer à inetd un signal HUP pour lui dire de relire son fichier de configuration après que vous l'avez modifié. </p> <toc-add-entry name="sshtrigger">Mettre en place un mécanisme déclencheur ssh</toc-add-entry> <p> Créez une nouvelle clé ssh pour le compte que vous utilisez pour faire un miroir de Debian. Faites attention à ne pas écraser votre clé ssh originale et pour cela utilisez l'option -f, par exemple : </p> <pre> ssh-keygen -f ~/.ssh/identite.monsite </pre> <p> Vérifiez que la nouvelle clé publique (~/.ssh/identite.monsite.pub) contient ceci au début du fichier : </p> <pre> no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="~/sync &" </pre> <p> Vous devez aussi mettre en place le script qui contactera les miroirs clients. Créez un fichier nommé <code>signal</code>, contenant ceci : </p> <protect> <pre> #!/bin/sh # Ce script est appelé pour signaler à l'hôte distant qu'il est temps de # mettre à jour le miroir à partir de l'archive. echo Signalling $1 ssh -o"BatchMode yes" -o"user $2" "$1" -i $HOME/.ssh/identite.monsite sleep 1 </pre> </protect> <p> Ce script va se connecter sur un hôte distant en utilisant la clé ssh spéciale que vous avez créée ci-dessus, à condition que chaque opérateur de miroir client ajoute cette clef à son propre fichier ~/.ssh/authorized_keys (en remplaçant également <q>sync</q> par <q>ftpsync</q> ou autre selon le nom de sa commande de lancement de la recopie). Ce script ne fait rien d'utile à distance en lui-même, la commande unique sera lancée comme spécifié par le paramétrage de la clef. </p> <p> Pour déclencher effectivement les miroirs, vous devez lancer la commande <code>./signal <site> <username></code> après avoir réalisé votre propre synchronisation. De cette façon, dès que votre site a terminé de mettre à jour son miroir à partir de son serveur, vous allez déclencher la mise à jour des sites clients de votre serveur. </p> <p> Ce nouveau script, <code>runmirrors</code>, devrait contenir quelque chose comme ceci : </p> <p> Vous pouvez placer ces commandes soit à la fin de votre script <code>ftpsync</code>, ou si vous préférez, dans un autre script et lancer ce script à partir de <code>ftpsync</code>, par exemple de la façon suivante : </p> <protect> <pre> #!/bin/sh # Ce script est appelé par websync pour déclencher les miroirs clients. ./signal un.autre.site archvsync ./signal et.un.autre.site autrecompte </pre> </protect> <p> Si vous avez le moindre problème avec ceci, <a href="mailto:[EMAIL PROTECTED]">contactez-nous</a>. </p>
signature.asc
Description: Digital signature
