import d'article depuis pluxml

content/Réseaux/construisez-tunnel-ssh.md

@@ -0,0 +1,463 @@
+Title: Construisez un tunnel (ssh) de vos propres mains !!
+Date: 2013-01-17 20:58
+Modified: 2013-01-17 20:58
+Tags: ssh, tunnel, debian, sécurité
+keywords: ssh, tunnel, debian, sécurité
+Slug: construisez-tunnel-ssh
+Authors: Victor
+Status: published
+
+[TOC]
+
+## Un tunnel sans pelle
+
+<p>Et sans terre sur les mains. Classe non ?</p>
+
+<p>Et bien, c'est possible grâce à SSH. (entre autre hein, tunnel est un terme plutôt répandu en informatique, mais bon ça fait une bonne accroche)</p>
+
+<p>Pour parler plus directement, un tunnel ssh va vous permettre de communiquer via SSH avec un serveur distant, et plus pécisément de rediriger certains ports locaux vers ce serveur, qui en fera ce que vous voulez.</p>
+
+<p>&nbsp;</p>
+
+<p>Typiquement, rediriger un port VNC dans un tunnel SSH permet de se connecter sur une machine distante de manière sécurisée. Alors que VNC de base, c'est quand même tout en clair à l'arrache.</p>
+
+<p>Ce système permet de sécuriser la plupart des routages de ports sales que l'on peut faire sur une box pour rentrer dans son réseau. Bien sûr, il y a aussi des applications techniques plus intéressantes au niveau entreprise&nbsp;:-)</p>
+
+<p>L'un des gros intérêts également, c'est que ça peut être utilisé sur un smartphone (<a href="https://fr.wikipedia.org/wiki/Smartphone">ordiphone</a>) sans aucun hack (ou rootage, ou jailbreak), contrairement à OpenVPN par exemple.</p>
+
+## Il faut pas le dire
+
+<p>Avec cette technique, vous pouvez également (ouh, c'est mal) passer certaines protections ou proxy, par exemple en redirigeant toutes vos connexion HTTP (port 80) sur un tunnel ssh sur le port 443 (HTTPS très rarement filtré) vers votre serveur, qui ensuite vous redirigera vers le site que vous vouliez.</p>
+
+<p>Inconvenient : vous profitez de votre bande passante potentiellement pourrie, surtout si vous vous auto-hébergez (c'est le bien !), puisque où que vous soyiez, toutes vos requêtes Internet passeront par chez vous.</p>
+
+<p>Avantage : vous mettez un doigt dans l'os à tout ces "filtrages" pseudo sécurité qui en fait font chier que les gens honnêtes. (Dont vous faites bien sûr partie)</p>
+
+<p>Ce besoin qu'on a tous connu (ou qu'on imagine au moins) servira de contexte pour ce tuto.</p>
+
+<p>&nbsp;</p>
+
+## Le principe
+
+<p>Comme d'habitude, un petit rappel du principe technique de la chose.</p>
+
+<p>Nous allons mettre en place sur un serveur, placé où bon vous semble, ce qu'on appelle un shell SSH qui attendra des connexions extérieures.</p>
+
+<p>Ce système est sensé permettre un accès SSH à votre serveur. Comme ce n'est pas le but ici, nous allons détourner le problème en mettant en place un shell hyper restreint. De cette façon vous pourrez fournir la connexion à qui vous voulez, en étant sûr qu'ils ne feront pas de mauvaises choses avec votre serveur. (On ne sait jamais :-)&nbsp;)</p>
+
+<p>La connexion se fera grâce à un couple clef/mot de passe, pour une sécurité maximum. La connexion au tunnel sera interdite par tout autre moyen, ce qui permet de limiter les attaques par brute force notamment.</p>
+
+<p>Chaque personne voulant se connecter devra donc posséder un couple clef/mot de passe fourni par vous. Dans cette optique et pour suivre plus simplement qui a quoi, nous allons créer pour chaque compte un utilisateur du système, qui aura le droit d'utiliser le tunnel. Ces utilisateurs appartiendront tous au groupe tunnelssh.</p>
+
+<p>Ce système, même s'il peut créer beaucoup d'utilisateur, présente l'avantage d'être à la fois clair et d'avoir des logs faciles à lire (chaque tentative de connexion étant loggué par utilisateur)</p>
+
+<p>Le système de redirection de port sera à votre convenance. Comme dit plus haut, j'utiliserais pour ma part le port 443, le plus communément ouvert même dans des lieux "limitatifs" sur des wifi "ouverts".</p>
+
+<p>&nbsp;</p>
+
+## Matériels, connaissances, besoins divers
+
+<p>Comme toujours quand on est un gros hacker barbu, plusieurs choses s'imposent.</p>
+
+<p>Tout d'abord, il va vous falloir un serveur sous Linux, qui permettra d'installer la sortie du tunnel. Vous vous connecterez avec votre machine sur lui, qui se chargera de rediriger ce que vous voulez où vous voulez.</p>
+
+<p>Pour ma part, j'utilise debian, mais SSH étant plutôt répandu, ça ne posera pas de problème à transcrire ailleurs.</p>
+
+<p>Il vous faudra aussi une autre machine servant de client pour les tests (Ordiphone Android/Iphone, PC fixe, PC portable, tablette, ...)</p>
+
+<p>Il est conseillé de disposer d'un minimum de connaissances dans la ligne de commande, et connaître un peu le réseau (notamment les ports) est un plus apprécié. Cependant, il est possible de copier-coller les commandes, donc pas la peine de trembler si vous ne maitrisez pas le bousin&nbsp;:-)</p>
+
+<p>&nbsp;</p>
+
+<p>Enfin, comme l'objectif est de travailler honnêtement pour promouvoir un Internet plus libre, une bonne bière n'est pas de refus !</p>
+
+<p>&nbsp;</p>
+
+## Bien. On est parti.
+
+### configuration du tunnel
+
+<p>Pour commencer, connectez vous sur votre serveur, via un SSH classique. Si vous utilisez directement un écran/clavier/souris, il faudra vérifier qu'openSSH est correctement installé :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;">$ sudo aptitude install openssh-server</span></span></p>
+
+<p>Une fois cela fait, nous allons créer une deuxième instance d'OpenSSH server, qui va écouter sur le port 443 et qui servira exclusivement pour le tunnel. Pour ce faire, créez un fichier sshd_config_tunnel, placé dans /etc/ssh :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;">$ sudo nano /etc/ssh/sshd_config_tunnel</span></span></p>
+
+<p>A l'intérieur, copiez-collez ce qui suit :&nbsp;</p>
+
+<p style="margin-left: 40px;">Port <strong>443</strong><br />
+<br />
+#ListenAddress ::<br />
+#ListenAddress 0.0.0.0<br />
+Protocol 2<br />
+# HostKeys for protocol version 2<br />
+HostKey /etc/ssh/ssh_host_rsa_key<br />
+HostKey /etc/ssh/ssh_host_dsa_key<br />
+#Privilege Separation is turned on for security<br />
+UsePrivilegeSeparation yes<br />
+<br />
+KeyRegenerationInterval 3600<br />
+ServerKeyBits 768<br />
+<br />
+# Logging<br />
+SyslogFacility AUTH<br />
+LogLevel INFO<br />
+<br />
+# Authentication:<br />
+LoginGraceTime 120<br />
+<strong>PermitRootLogin no<br />
+AllowGroups tunnelssh</strong><br />
+StrictModes yes<br />
+<br />
+<strong>AllowTcpForwarding yes</strong><br />
+<strong>#PermitOpen IP_LOCALE:PORT_LOCAL</strong><br />
+AllowAgentForwarding no<br />
+<br />
+RSAAuthentication yes<br />
+PubkeyAuthentication yes<br />
+AuthorizedKeysFile %h/.ssh/authorized_keys<br />
+<br />
+IgnoreRhosts yes<br />
+RhostsRSAAuthentication no<br />
+<br />
+HostbasedAuthentication no<br />
+#IgnoreUserKnownHosts yes<br />
+<br />
+PermitEmptyPasswords no<br />
+<br />
+ChallengeResponseAuthentication no<br />
+<strong>PasswordAuthentication no</strong><br />
+<br />
+# Kerberos options<br />
+#KerberosAuthentication no<br />
+#KerberosGetAFSToken no<br />
+#KerberosOrLocalPasswd yes<br />
+#KerberosTicketCleanup yes<br />
+<br />
+# GSSAPI options<br />
+#GSSAPIAuthentication no<br />
+#GSSAPICleanupCredentials yes<br />
+<br />
+X11Forwarding no<br />
+X11DisplayOffset 10<br />
+PrintMotd no<br />
+PrintLastLog yes<br />
+TCPKeepAlive yes<br />
+#UseLogin no<br />
+<br />
+#MaxStartups 10:30:60<br />
+#Banner /etc/issue.net<br />
+<br />
+AcceptEnv LANG LC_*<br />
+<br />
+Subsystem sftp /usr/lib/openssh/sftp-server<br />
+<br />
+UsePAM yes</p>
+
+<p>C'est en fait un fichier de configuration ssh classique modifié pour notre usage. Je l'ai épuré des commentaires pour qu'il ne soit pas trop lourd, et j'ai mis en gras les morceaux importants :</p>
+
+<ul>
+	<li>Port 443 : c'est ici que vous allez définir sur quel port écoute votre serveur. Comme dit précedemment, j'utilise le port 443, mais vous mettez ce que vous voulez.</li>
+	<li>PermitRootLogin no : cette directive va interdire toute connexion au serveur avec l'utilisateur root.</li>
+	<li>AllowGroups tunnelssh : cela permet d'autoriser uniquement les utilisateurs appartenant au groupe tunnelssh de se connecter.</li>
+	<li>AllowTcpForwarding yes : cette directive va autoriser votre serveur SSH à transmettre ce qui lui arrive dessus vers une autre machine (typiquement vos requêtes Internet)</li>
+	<li>#PermitOpen IP_LOCALE:PORT_LOCAL : cette directive (ici commenté) peut vous servir si vous voulez utiliser votre tunnel pour accéder à une seule machine de votre réseau local. Par exemple, pour vous connecter sur votre PC avec VNC. Si vous désirez utilisez votre tunnel pour accéder à Internet, laissez cette ligne commentée.</li>
+	<li>PasswordAuthentication no : cette directive va imposer l'utilisation d'une clef SSH pour vous connecter au serveur.</li>
+</ul>
+
+<p>&nbsp;</p>
+
+<p>Il va également vous falloir lancer ce serveur en parallèle du vrai serveur SSH (que je vous conseille de laisser pour les accès "administratifs" dont vous pourriez avoir besoin).</p>
+
+<p>Pour ce faire, il suffit de créer dans le dossier /etc/init.d/ un nouveau fichier de lancement ssh :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;">$ sudo nano /etc/init.d/ssh_tunnel</span></span></p>
+
+<p>Dans lequel vous pouvez copiez-collez :</p>
+
+<p style="margin-left: 40px;">#! /bin/sh<br />
+<br />
+### BEGIN INIT INFO<br />
+# Provides: sshd_tunnel<br />
+# Required-Start: $remote_fs $syslog<br />
+# Required-Stop: $remote_fs $syslog<br />
+# Default-Start: 2 3 4 5<br />
+# Default-Stop: 0 1 6<br />
+# Short-Description: OpenBSD Secure Shell server<br />
+### END INIT INFO<br />
+<br />
+set -e<br />
+<br />
+# /etc/init.d/ssh: start and stop the OpenBSD "secure shell(tm)" daemon<br />
+<br />
+test -x /usr/sbin/sshd || exit 0<br />
+( /usr/sbin/sshd -\? 2&gt;&amp;1 | grep -q OpenSSH ) 2&gt;/dev/null || exit 0<br />
+<br />
+umask 022<br />
+<br />
+if test -f /etc/default/ssh; then<br />
+. /etc/default/ssh<br />
+fi<br />
+<br />
+. /lib/lsb/init-functions<br />
+<br />
+if [ -n "$2" ]; then<br />
+SSHD_OPTS="$SSHD_OPTS $2"<br />
+fi<br />
+<br />
+SSHD_OPTS="$SSHD_OPTS -f<strong> /etc/ssh/sshd_config_tunnel"</strong><br />
+<br />
+# Are we running from init?<br />
+run_by_init() {<br />
+([ "$previous" ] &amp;&amp; [ "$runlevel" ]) || [ "$runlevel" = S ]<br />
+}<br />
+<br />
+check_for_no_start() {<br />
+# forget it if we're trying to start, and /etc/ssh/sshd_not_to_be_run exists<br />
+if [ -e /etc/ssh/sshd_not_to_be_run ]; then<br />
+if [ "$1" = log_end_msg ]; then<br />
+log_end_msg 0<br />
+fi<br />
+if ! run_by_init; then<br />
+log_action_msg "OpenBSD Secure Shell server not in use (/etc/ssh/sshd_not_to_be_run)"<br />
+fi<br />
+exit 0<br />
+fi<br />
+}<br />
+<br />
+check_dev_null() {<br />
+if [ ! -c /dev/null ]; then<br />
+if [ "$1" = log_end_msg ]; then<br />
+log_end_msg 1 || true<br />
+fi<br />
+if ! run_by_init; then<br />
+log_action_msg "/dev/null is not a character device!"<br />
+fi<br />
+exit 1<br />
+fi<br />
+}<br />
+<br />
+check_privsep_dir() {<br />
+# Create the PrivSep empty dir if necessary<br />
+if [ ! -d /var/run/<strong>sshd_tunnel</strong> ]; then<br />
+mkdir /var/run/<strong>sshd_tunnel</strong><br />
+chmod 0755 /var/run/<strong>sshd_tunnel</strong><br />
+fi<br />
+}<br />
+<br />
+check_config() {<br />
+if [ ! -e /etc/ssh/sshd_not_to_be_run ]; then<br />
+/usr/sbin/sshd $SSHD_OPTS -t || exit 1<br />
+fi<br />
+}<br />
+<br />
+export PATH="${PATH:+$PATH:}/usr/sbin:/sbin"<br />
+<br />
+case "$1" in<br />
+start)<br />
+check_privsep_dir<br />
+check_for_no_start<br />
+check_dev_null<br />
+log_daemon_msg "Starting OpenBSD Secure Shell server" <strong>"sshd_tunnel"</strong><br />
+if start-stop-daemon --start --quiet --oknodo --pidfile /var/run/<strong>sshd_tunnel.pid</strong> --exec /usr/sbin/sshd -- $SSHD_OPTS; then<br />
+log_end_msg 0<br />
+else<br />
+log_end_msg 1<br />
+fi<br />
+;;<br />
+stop)<br />
+log_daemon_msg "Stopping OpenBSD Secure Shell server" <strong>"sshd_tunnel"</strong><br />
+if start-stop-daemon --stop --quiet --oknodo --pidfile /var/run/<strong>sshd_tunnel.pid</strong>; then<br />
+log_end_msg 0<br />
+else<br />
+log_end_msg 1<br />
+fi<br />
+;;<br />
+<br />
+reload|force-reload)<br />
+check_for_no_start<br />
+check_config<br />
+log_daemon_msg "Reloading OpenBSD Secure Shell server's configuration" <strong>"sshd_tunnel"</strong><br />
+if start-stop-daemon --stop --signal 1 --quiet --oknodo --pidfile /var/run/<strong>sshd_tunnel.pid</strong> --exec /usr/sbin/sshd; then<br />
+log_end_msg 0<br />
+else<br />
+log_end_msg 1<br />
+fi<br />
+;;<br />
+<br />
+restart)<br />
+check_privsep_dir<br />
+check_config<br />
+log_daemon_msg "Restarting OpenBSD Secure Shell server" "sshd"<br />
+start-stop-daemon --stop --quiet --oknodo --retry 30 --pidfile /var/run/<strong>sshd_tunnel.pid</strong><br />
+check_for_no_start log_end_msg<br />
+check_dev_null log_end_msg<br />
+if start-stop-daemon --start --quiet --oknodo --pidfile /var/run/<strong>sshd_tunnel.pid</strong> --exec /usr/sbin/sshd -- $SSHD_OPTS; then<br />
+log_end_msg 0<br />
+else<br />
+log_end_msg 1<br />
+fi<br />
+;;<br />
+<br />
+try-restart)<br />
+check_privsep_dir<br />
+check_config<br />
+log_daemon_msg "Restarting OpenBSD Secure Shell server" "sshd"<br />
+set +e<br />
+start-stop-daemon --stop --quiet --retry 30 --pidfile /var/run/<strong>sshd_tunnel.pid</strong><br />
+RET="$?"<br />
+set -e<br />
+case $RET in<br />
+0)<br />
+# old daemon stopped<br />
+check_for_no_start log_end_msg<br />
+check_dev_null log_end_msg<br />
+if start-stop-daemon --start --quiet --oknodo --pidfile /var/run/<strong>sshd_tunnel.pid</strong> --exec /usr/sbin/sshd -- $SSHD_OPTS; then<br />
+log_end_msg 0<br />
+else<br />
+log_end_msg 1<br />
+fi<br />
+;;<br />
+1)<br />
+# daemon not running<br />
+log_progress_msg "(not running)"<br />
+log_end_msg 0<br />
+;;<br />
+*)<br />
+# failed to stop<br />
+log_progress_msg "(failed to stop)"<br />
+log_end_msg 1<br />
+;;<br />
+esac<br />
+;;<br />
+<br />
+status)<br />
+status_of_proc -p /var/run/<strong>sshd_tunnel.pid</strong> /usr/sbin/sshd sshd &amp;&amp; exit 0 || exit $?<br />
+;;<br />
+<br />
+*)<br />
+log_action_msg "Usage: /etc/init.d/<strong>ssh_tunne</strong>l {start|stop|reload|force-reload|restart|try-restart|status}"<br />
+exit 1<br />
+esac<br />
+<br />
+exit 0</p>
+
+<p>Ce fichier est une copie du fichier /etc/init.d/ssh classique, mais modifié pour lancer le bon fichier de configuration et pour tourner en parallèle du serveur classique (notamment avec son propre pid)</p>
+
+<p>Les parties modifiées sont en gras.</p>
+
+<p>Enregistrez le fichier puis rendez-le exécutable.</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;">$ sudo chmod 755 /etc/init.d/ssh_tunnel</span></span></p>
+
+<p>Si vous le souhaitez, vous pouvez configurer le tunnel pour se lancer au démarrage :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;">$ sudo update-rc.d ssh_tunnel defaults</span></span></p>
+
+### Configuration du groupe d'utilisateur
+
+<p>Nous allons ensuite créer le groupe tunnelssh, qui sera utilisé pour toutes les connexions.</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;">$ sudo groupadd tunnelssh</span></span></p>
+
+<p>Il suffira ensuite de créer vos utilisateurs comme appartenant à ce groupe pour leur donner l'autorisation de se connecter au tunnel. Nous allons voir un script permettant de faire ça tout seul.&nbsp;:-)</p>
+
+### Configuration du shell
+
+<p>Afin que vos utilisateurs ne puissent pas se balader dans votre serveur via l'accès SSH du tunnel, nous allons créer un shell bidon. Cela permettra en plus d'afficher une jolie bannière pour l'utilisation du tunnel.</p>
+
+<p>En avant. Créez un fichier dans /usr/bin :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;">$ sudo nano /usr/bin/tunnelshell</span></span></p>
+
+<p>Qui contient quelque chose dans ce genre là :</p>
+
+<p style="margin-left: 40px;">#!/bin/bash<br />
+echo "Connexion limitée au tunnel SSH."<br />
+read -p "Appuyez sur ENTREE pour vous déconnecter..."</p>
+
+<p>Ainsi, toute personne se connectant sur votre tunnel verra apparaître ce message :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;">Connexion limitée au tunnel SSH.</span></span></p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;">Appuyez sur ENTREE pour vous déconnecter...</span></span></p>
+
+<p>Comme indiqué, une pression de la touche entrée provoque la déconnexion immédiate du tunnel.<br />
+Vous êtes bien sûr libre de changer le message !&nbsp;;-)</p>
+
+### On y est !
+
+<p>A ce stade, votre tunnel ssh est prêt à être utilisé. Il suffit de créer un utilisateur appartenant au groupe tunnelssh, de lui configurer comme shell /usr/bin/tunnelshell, puis de lui créer son couple clef/mot de passe.</p>
+
+<p>Comme je suis super sympa (mouahahah), je vous propose un petit script qui fait tout ça tout seul.</p>
+
+<p>Je vous conseille de le placer dans le dossier /root, ou à défaut dans un dossier à accès limité, puisqu'il contiendra tous les certificats de tous vos utilisateurs.</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;">$ sudo mkdir /root/tunnelSSH</span></span></p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;">$ sudo nano /root/tunnelSSH/Addsshtunneluser.sh</span></span></p>
+
+<p>Dans celui-ci, vous pouvez mettre :&nbsp;</p>
+
+<p style="margin-left: 40px;">#!/bin/bash<br />
+<br />
+if [ "$1" = "" ]; then<br />
+echo "Usage : Addsshtunneluser.sh name passphrase<br />
+fi<br />
+<br />
+if [ "$2" = "" ]; then<br />
+echo "Usage : Addsshtunneluser.sh name passphrase<br />
+fi<br />
+<br />
+mkdir /home/$1<br />
+mkdir /home/$1/.ssh<br />
+useradd $1 --home-dir /home/$1 --groups tunnelssh --no-user-group --shell /usr/bin/tunnelshell<br />
+ssh-keygen -t dsa -b 1024 -N $2 -f /home/$1/.ssh/id_dsa<br />
+cp /home/$1/.ssh/id_dsa.pub /home/$1/.ssh/authorized_keys<br />
+chmod 700 /home/$1/.ssh<br />
+chmod 600 /home/$1/.ssh/authorized_keys<br />
+chown -R $1:tunnelssh /home/$1<br />
+cp /home/$1/.ssh/id_dsa tunnelssh-$1</p>
+
+<p>Ce script s'exécute de la manière suivante :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;">$ sudo bash /root/tunnelSSH/Addsshtunneluser.sh UTILISATEUR MOTDEPASSE</span></span></p>
+
+<ul>
+	<li>UTILISATEUR est le nom du nouvel utilisateur à créer</li>
+	<li>MOTDEPASSE est le mot de passe à donner à l'utilisateur</li>
+</ul>
+
+<p>Le script va alors créer un utilisateur portant ce nom. L'utilisateur appartiendra au groupe tunnelssh, et disposera de son répertorie /home/UTILISATEUR</p>
+
+<p>Le script va ensuite créer la clef SSH à l'aide du MOTDEPASSE (on parle bien sûr d'un couple clef privée/clef publique). Il va ensuite copier la dite clef dans le dossier /root/tunnelSSH/ avec un nom du type tunnelssh-UTILISATEUR, ce qui va vous permettre de la récupérer facilement pour la transmettre à l'utilisateur concerné.</p>
+
+<p>Il lui faudra alors utiliser cette clef pour configurer son tunnel ssh de la manière suivante :</p>
+
+<ul>
+	<li>Adresse : l'adresse IP ou FQDN de votre serveur</li>
+	<li>Port : le port d'écoute de votre tunnel (ici 443)</li>
+	<li>Utilisateur : son nom d'utilisateur</li>
+	<li>Connexion par clef : avec la clef que vous lui avez transmis ainsi que le mot de passe associé</li>
+</ul>
+
+<p>Normalement, tout doit baigner !</p>
+
+## Voila, c'est creusé
+
+<p>Avec tout ça, vous devriez être à même de vous connecter depuis n'importe où sur votre serveur.</p>
+
+<p>A titre informatif, pour mettre en place le tunnel côté client :</p>
+
+<ul>
+	<li>Windows : utilisez <a href="http://www.putty.org/">Putty</a> (allié à PuttyGen pour transformer votre clef en format Putty)</li>
+	<li>Linux/MacOSX : utilisez simplement openssh&nbsp;:-)</li>
+	<li>Android : utilisez <a href="https://play.google.com/store/apps/details?id=org.connectbot">ConnectBot</a></li>
+	<li>iPhone : Payez... Mais vous l'avez choisi avec un tel téléphone !</li>
+</ul>
+
+<p>Si jamais j'ai des demandes, je me lancerai dans un petit tuto pour l'une ou l'autre des plateformes&nbsp;:-)</p>
+
+<p>Si vous avez des soucis, posez la question dans les commentaires !</p>

content/Système/cluster-proxmox-distant-2.4-construction-cluster.md

@@ -0,0 +1,713 @@
+Title: Cluster Proxmox distant (2/4)
+subtitle: ; construction du cluster (openvpn)
+Date: 2013-02-02 13:35
+Modified: 2013-02-02 13:35
+Tags: proxmox, debian, iptables, linux, sécurité, tunnel, cluster, haute disponibilité
+keywords: proxmox, debian, iptables, linux, sécurité, tunnel, cluster, haute disponibilité
+Slug: cluster-proxmox-distant-2.4-construction-cluster
+Authors: Victor
+Status: published
+
+[TOC]
+
+## Commençons
+
+<p>Bien, cet article est la partie 2 de ma série d'articles sur la mise en place d'un cluster Proxmox.</p>
+
+<p>Dans cet article, je vais partir du début et parler de l'installation des 3 serveurs Proxmox dont nous allons avoir besoin.</p>
+
+<p>Pour rappel :&nbsp;</p>
+
+<ul>
+	<li>Un serveur principal, chargé de faire tourner les principaux services sous forme de machines virtuelles</li>
+	<li>Un serveur de secours, moins costaud mais suffisant pour faire tourner les services que vous considérez comme vitaux</li>
+	<li>Un 3ème serveur, pas forcément très performant, qui va principalement servir à assurer le quorum, afin que 3 machines soient dans le cluster</li>
+</ul>
+
+<p>Vous trouverez tous les détails dans la partie 1 de cette série,&nbsp;<a href="/2013/01/cluster-proxmox-distant-1.4-concept.html">Cluster Proxmox distant (1/4) : le concept</a></p>
+
+<p>&nbsp;</p>
+
+<p>Le petit schéma pour rappeler l'infrastructure et les noms des machines :</p>
+
+<p><img alt="" src="/images/schemaHA(1).png" style="width: 612px; height: 353px;" /></p>
+
+## &nbsp;
+
+## Matériel, serveurs, spécificités et autres joyeusetés
+
+<p>Comme dit plus haut, vous allez avoir besoin de 3 serveurs. Les 2 principaux, je conseille qu'ils soient physiques. De vrais serveurs avec les perfomances dont vous avez besoin.</p>
+
+<p>Le 3eme serveur, servant uniquement pour le quorum, peut être une simple machine virtuelle dans un coin. L'important est que vous puissiez installer proxmox dessus. (Pour ma part, c'est une KVM avec proxmox à l'intérieur, qui tourne sur une autre architecture Proxmox chez moi :) )</p>
+
+<p><strong>Par contre, ne montez pas votre Arbitre sur une KVM dans l'un des 2 premiers serveurs. Sinon vous perdez tout l'intérêt d'avoir un 3eme système indépendant des 2 autres pour assurer le quorum !</strong></p>
+
+<p>&nbsp;</p>
+
+<p>Vous allez également avoir besoin d'installer Proxmox sur vos serveurs. Dans ces articles, je me baserai sur l'installation de <a href="http://www.proxmox.com/downloads/proxmox-ve">Proxmox 2.X standard</a>, fournie par Proxmox et donc basée sur Debian Squeeze (actuellement Proxmox 2.2).</p>
+
+<p>L'installation de base présente l'avantage de proposer un partionnement des disques dur via <a href="http://fr.wikipedia.org/wiki/LVM">LVM</a>, qui est très pratique pour redimensionner les partitions et utiliser DRBD par la suite. Cependant, je détaillerai le partionnement nécessaire, afin que vous puissiez vous en tirer si vous souhaitez installer Proxmox par dessus une autre distribution Linux.</p>
+
+<p>OVH et Online proposent la distribution Proxmox à l'installation. OVH vous permet de choisir le partionnement via leur interface web, ce qui est assez pratique. Online par contre part sur un partionnement sans LVM qui ne vous permettra pas d'utiliser simplement DRBD par la suite.&nbsp;<strong>Attention donc chez Online, mieux vaut passer par leurs cartes ILO/iDrac pour installer Proxmox depuis l'ISO.</strong></p>
+
+<p>&nbsp;</p>
+
+<p>Enfin, vous allez avoir besoin d'un PC supportant le SSH pour vous connecter aux différents serveurs. Je vous conseillerai bien un Linux, parce que vous allez passer pas mal de temps connecté, donc un système supprotant bien le bash (et notamment l'encodage de caractère et les couleurs) est préférable. Cependant, Windows avec putty fonctionne aussi, donc à vous de voir.</p>
+
+<p><strong>Une dernière recommandation : pour monter le cluster, il est important qu'AUCUNE machine virtuelle ne soit présente sur les serveurs (pour éviter les conflits de VMID)</strong>. Si vous récupérez des serveurs existants, il va donc falloir basculer vos machines de droite à gauche pendant la mise en place du cluster. Si vous partez d'une installation neuve, attendez d'avoir monté le cluster pour réimporter vos machines virtuelles.</p>
+
+<p>&nbsp;</p>
+
+## Installation et partionnement
+
+<p>L'installation de l'ISO proxmox se fait toute seule, sans besoin d'intervention. Insérez le disque (ou la clef USB, maintenant supportée), bootez dessus et procédez à l'installation.</p>
+
+<p>Le partionnement de proxmox utilise LVM, et se décompose de la manière suivante :</p>
+
+<ul>
+	<li>Une partition physique dédiée au boot, /dev/sda1, d'environ 500Mo</li>
+	<li>Une parition physique entièrement formatée en LVM, avec le reste du disque</li>
+</ul>
+
+<p>C'est cette deuxième partition qui nous intéresse. Elle utilise LVM, et peut donc être redimensionné par nos soins plus tard. En prenant bien sûr les précautions nécessaires&nbsp;:-)</p>
+
+<ul>
+	<li>Un disque logique d'environ 30Go pour /.&nbsp;</li>
+	<li>Un disque logique servant de Swap, calculé à partir de la taille de votre RAM</li>
+	<li>Un disque logique utilisant tout le reste du disque (moins 4Mo), qui sera monté comme /var/lib/vz et qui servira à stocker vos VM, les backups, etc</li>
+</ul>
+
+<p>Pour être plus confortable, notamment au niveau du système, vous pouvez utiliser la technique suivante :</p>
+
+<ul>
+	<li>Lors du prompt au boot sur le CD, tapez "debug"</li>
+	<li>tapez :&nbsp;<span style="background-color:#000000;"><span style="color:#ffffff;">linux maxroot=100</span></span></li>
+</ul>
+
+<p>Cela va configurer la partition système pour utiliser 100Go. Il existe d'autre options, pour plus de détails, voyez&nbsp;<a href="http://pve.proxmox.com/wiki/Debugging_Installation">Debugging Installation</a>.</p>
+
+<p>Pour le reste, c'est correct.</p>
+
+<p>Si vous faites votre partionnement vous-même, veillez à utiliser LVM pour au moins /var/lib/vz. Cela nous permettra d'utiliser les snapshot LVM et de gérer l'espace facilement pour DRBD.</p>
+
+## Personnalisation et astuces
+
+<p>Bon, votre système est installé.</p>
+
+<p>Avant d'attaquer le vif du sujet, je vous propose quelques petits trucs pour faciliter la suite.</p>
+
+### Bash et couleurs
+
+<p>Pour faciliter la gestion de vos 3 serveurs, vous pouvez personnaliser votre bash pour utiliser plusieurs couleurs dans votre connexion SSH.</p>
+
+<p>Pour ce faire, vous pouvez éditer /etc/bash.bashrc</p>
+
+<p><span style="background-color:#000000;"><span style="color:#ffffff;"># nano /etc/bash.bashrc</span></span></p>
+
+<p>Pour ajouter des couleurs, ajoutez ceci à la fin du fichier :</p>
+
+<p style="margin-left: 40px;"># couleurs<br />
+<strong><em>C_RED="\[\e[1;31m\]"<br />
+C_BLUE="\[\e[1;34m\]"<br />
+C_GRAY="\[\e[1;30m\]"<br />
+C_WHITE="\[\e[1;37m\]"<br />
+C_YELLOW="\[\e[1;33m\]"</em></strong><br />
+C_DEF="\[\033[0m\]"<br />
+<br />
+mUID=`id -u`<br />
+MACHINE=`hostname -f`<br />
+<br />
+if [ "$mUID" = "0" ] ; then<br />
+PS1="${<strong>C_RED</strong>}\u${C_DEF}@${<strong>C_RED</strong>}${MACHINE}${C_DEF}:\w${<strong>C_RED</strong>}#${C_DEF} "<br />
+PS2="${<strong>C_RED</strong>}&gt;${C_DEF} "<br />
+else<br />
+PS1="${C_BLUE}\u${C_DEF}@${MACHINE}:\w${C_BLUE}\$ ${C_DEF}"<br />
+PS2="${C_BLUE}&gt;${C_DEF} "<br />
+fi<br />
+<br />
+export PS2<br />
+export PS1<br />
+<br />
+case $TERM in<br />
+xterm*)<br />
+PROMPT_COMMAND='echo -ne "\033]0;${USER}@${MACHINE}: ${PWD}\007"'<br />
+echo -ne "\033]0;${USER}@${MACHINE}: ${PWD}\007"<br />
+;;<br />
+*)<br />
+setterm -blength 0<br />
+;;<br />
+esac</p>
+
+<p>Ce fichier va automatiquement colorer votre nom d'utilisateur et le nom de la machine dans votre connexion SSH.</p>
+
+<p>Si vous êtes connectés avec un autre utilisateur que root, la couleur sera bleue.</p>
+
+<p>Il va également modifier dynamiquement le nom de votre fenêtre SSH selon le dossier où vous êtes. Le but est de ne pas se perdre pour éviter les bêtises&nbsp;;-)</p>
+
+<p>Je vous conseille de changer les parties en <strong>gras</strong> (C_RED) selon les machines (avec les couleurs disponibles en <em><strong>gras italique</strong></em> au dessus)</p>
+
+<p>N'hésitez pas à vous amuser pour trouver les combinaisons de couleurs qui vous plaisent.</p>
+
+<p>Une fois le fichier sauvegardé, vous pouvez activer les modifications pour tester les couleurs avec un :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># exec bash</span></span></p>
+
+<p>Vous pouvez également ajouter à la fin du fichier ces alias, qui peuvent être utiles :</p>
+
+<p style="margin-left: 40px;">alias l='ls -ahlF --color=yes --full-time --time-style=long-iso | more'<br />
+alias ll='ls -alhF --color=yes --full-time --time-style=long-iso'<br />
+alias cpav='cp -av'</p>
+
+<p>Une fois tout cela configuré selon votre souhait, faites une petite mise à jour de la machine, et redémarrez si nécessaire.</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># aptitude update &amp;&amp; aptitude safe-upgrade -y</span></span></p>
+
+## Configuration des interfaces réseaux
+
+<p>Pour utiliser openVPN et simplifier la gestion des adresses IP publiques entre les serveurs (toujours sympathique), nous allons créer diverses interfaces supplémentaires sur chacun de nos serveurs.</p>
+
+### Architecture interne des serveurs
+
+<p>Après une installation de Proxmox, vous devez disposer d'un bridge virtuel <strong>vmbr0.</strong></p>
+
+<p>Nous allons créer les interfaces suivantes :</p>
+
+<ul>
+	<li><strong>vmbr1</strong> : ce bridge permettra la communication en interne au serveur, notamment entre VM. Toutes vos VM devront avoir une interface dans vmbr1 pour discuter entre elles. C'est également cette interface qui permettra la liaison VPN, afin que vos VM puissent discuter entre serveurs, dès fois que vous ayiez plusieurs VM sur chacun de vos serveurs</li>
+	<li><strong>vmbr2</strong> : ce bridge un peu particulier permettra la discussion entre les machines "passerelles", qui portent les IP publiques, et les machines ayant besoin d'une connexion entrante ou sortante vers Internet. Ces machines, par exemple en HA, pourront avoir une carte réseau sur vmbr2 et une interface sur vmbr1. Avec une architecture identique sur les 2 serveurs principaux au niveau des VM publiques, les machines basculant en HA retrouveront directement leur connexion</li>
+	<li><strong>dummy1</strong> : cette interface "bidon" va permettre d'avoir une interface fixe pour "brancher" openvpn, qui a besoin d'une interface réseau physique pour se lancer correctement au démarrage du serveur</li>
+</ul>
+
+<p>Pour que cela soit plus clair, un schéma (le retour) est le bienvenu :</p>
+
+<p><img alt="" src="/images/SchemaInterneVM.png" style="height: 383px; width: 633px;" /><br />
+Les adresses IP sont indicatives, mais il est important que le réseau sur vmbr1 soit différent du réseau sur vmbr2. Il est également important que le réseau utilisé sur vmbr2 soit identique sur les 2 serveurs. Cela va permettre de basculer les machines en HA d'un serveur à l'autre sans changer aucune de leurs configurations internes. Il faut également que les passerelles soient équivalentes (sauf l'IP publique bien sûr).</p>
+
+<p>Si vous configurez des routages de ports entre votre passerelle et les machines en HA, il faudra avoir les même sur la passerelle du PRA, même s'ils pointent dans le vide tant que les machines HA ne sont pas sur le PRA.</p>
+
+### Configuration de dummy
+
+<p>Nous allons commencer par créer l'interface dummy nécessaire à OpenVPN. De base, Proxmox peut utiliser une interface dummy pour des usages internes, nous allons donc utiliser une deuxième par précaution :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># echo "options dummy numdummies=2" &gt; /etc/modprobe.d/dummy.conf</span></span></p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># modprobe dummy</span></span></p>
+
+<p>Pour vérifier que les interfaces ont bien été créées, tapez la commande suivante :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># ifconfig -a | grep Link | grep -v inet6</span></span></p>
+
+<p>Qui doit vous renvoyer quelque chose comme ça :</p>
+
+<p style="margin-left: 40px;">dummy0 : Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx<br />
+dummy1 : Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx<br />
+eth0 : Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx<br />
+lo : Link encap:Local Loopback<br />
+vmbr0 : Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx</p>
+
+### Configuration des interfaces
+
+<p>Nous allons aller toucher au fichier /etc/network/interfaces.</p>
+
+<p>Avant ça, sauvegardez le fichier :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># cpav /etc/network/interfaces /etc/network/interfaces.original</span></span></p>
+
+<p>Puis éditez le :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># nano /etc/network/interfaces</span></span></p>
+
+<p>Ajoutez vmbr1 :</p>
+
+<p style="margin-left: 40px;">auto vmbr1<br />
+iface vmbr1 inet static<br />
+address XXX.XXX.XXX.XXX<br />
+netmask 255.255.255.0<br />
+bridge_ports dummy1<br />
+bridge_stp off<br />
+bridge_fd 0<br />
+post-up route add -net 224.0.0.0 netmask 240.0.0.0 dev vmbr1</p>
+
+<p>Dans le schéma de mon exemple, j'utilise 192.168.11.1 pour le serveur principal, 192.168.11.2 pour le PRA, et 192.168.11.3 pour l'arbitre.</p>
+
+<p>Ajoutez vmbr2 :&nbsp;</p>
+
+<p style="margin-left: 40px;">auto vmbr2<br />
+iface vmbr2 inet static<br />
+address XXX.XXX.XXX.XXX<br />
+netmask 255.255.255.0<br />
+bridge_ports none<br />
+bridge_stp off<br />
+bridge_fd 0</p>
+
+<p>Dans le schéma de mon exemple, je prends 192.168.10.253. La passerelle portera par exemple 192.168.10.254.</p>
+
+<p>Pour appliquer les modifications, effectuez un :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># /etc/init.d/networking restart</span></span></p>
+
+<p>Pour vérifier que les nouvelles interfaces fonctionnent correctement, vous pouvez les pinguer :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># ping 192.168.10.253</span></span></p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># ping 192.168.11.1</span></span></p>
+
+### Configuration des services
+
+<p>Pour désactiver l'IPv6, si vous n'en avez pas besoin (pas de troll&nbsp;:-))</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;">#&nbsp;echo "options ipv6 disable=1" &gt; /etc/modprobe.d/disable-ipv6.conf</span></span></p>
+
+<p>Il faut configurer Proxmox pour écouter sur l'interface OpenVPN :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># nano /etc/hosts</span></span></p>
+
+<p>Vérifiez que c'est bien l'adresse de vmbr1 qui est configurée :</p>
+
+<p style="margin-left: 40px;">127.0.0.1 localhost.localdomain localhost<br />
+xxx.xxx.xxx.xxx serveurprincipal.mon-cluster.vpn pra pvelocalhost<br />
+[...]</p>
+
+<p>Où xxx.xxx.xxx.xxx est l'adresse que vous avez indiquée pour <strong>vmbr1</strong> (pour moi 192.168.11.1)</p>
+
+<p>Pour avoir des logs propres au démarrage (on sait jamais)</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># nano&nbsp;/etc/default/bootlogd&nbsp;</span></span></p>
+
+<p>Et modifiez :</p>
+
+<p style="margin-left: 40px;">BOOTLOGD_ENABLE=Yes</p>
+
+## Installation d'OpenVPN
+
+<p>On est parti ! Tout ce qui était avant va vous servir&nbsp;:-)</p>
+
+<p>Installons OpenVPN pour commencer :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># aptitude install openvpn</span></span></p>
+
+<p>Faites ceci sur tous vos serveurs.</p>
+
+### Préparation des certificats
+
+<p>Sur le serveur PRA, le serveur principal d'OpenVPN, nous allons générer les certificats serveurs et clients.</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># cpav /usr/share/doc/openvpn/examples/easy-rsa/2.0/ /etc/openvpn/easy-rsa/<br />
+<br />
+# cd /etc/openvpn/easy-rsa/<br />
+<br />
+# cpav vars vars.original</span></span></p>
+
+<p>Editez le fichier vars, tout à la fin du fichier, pour modifier les variables globales. Ainsi votre génération de clef se fera automatiquement. Sinon, vous devrez indiquer les informations à chaque génération.</p>
+
+<p>Puis :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># source ./vars</span></span></p>
+
+<p style="margin-left: 40px;">NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/keys</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># ./clean-all</span><br />
+<span style="background-color:#000000;"># ./build-dh</span></span></p>
+
+<p style="margin-left: 40px;">Generating DH parameters, 1024 bit long safe prime, generator 2<br />
+This is going to take a long time<br />
+........................................................+......<br />
+..+............+...............................................<br />
+...............................................................<br />
+...+............................................++*++*++*</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># ./pkitool --initca</span></span></p>
+
+<p style="margin-left: 40px;">Using CA Common Name: Mon organisation CA<br />
+Generating a 1024 bit RSA private key<br />
+...++++++<br />
+................++++++<br />
+writing new private key to 'ca.key'<br />
+-----</p>
+
+### Générez la clef serveur
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># ./pkitool --server server</span></span></p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># openvpn --genkey --secret ./keys/ta.key</span></span></p>
+
+### Générez les clefs clients
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># ./pkitool clientPrincipal</span></span></p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># ./pkitool clientArbitre</span></span></p>
+
+<p>Vous pouvez également en profiter pour générer d'autres clefs clients si vous souhaitez vous connecter vous-même au VPN, pour sécuriser à fond vos accès SSH par exemple.</p>
+
+### Sauvegarde des clefs
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># cd /etc/openvpn/easy-rsa/keys/</span><br />
+<br />
+<span style="background-color:#000000;"># tar cvzf /root/server-keys.tar.gz server.crt server.key ca.crt dh1024.pem ta.key</span><br />
+<br />
+<span style="background-color:#000000;"># tar cvzf /root/clientPrincipal-keys.tar.gz clientPrincipal.crt clientPrincipal.key ca.crt ta.key</span></span></p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># tar cvzf /root/clientArbitre-keys.tar.gz clientArbitre.crt clientPrincipal.key ca.crt ta.key</span></span></p>
+
+### Configuration des serveurs
+
+<p>Pour mettre en place le fameux triangle OpenVPN permettant un quorum solide, nous allons devoir configurer à la fois le serveur principal ET le serveur PRA comme serveurs OpenVPN.</p>
+
+<p>La différence se jouera dans les fichiers de configurations des clients.</p>
+
+<p>Sur chacune des machines, importez le fichier de configuration par défaut :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># cd /etc/openvpn/<br />
+<br />
+# zcat /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz &gt; server.conf<br />
+<br />
+# cpav server.conf server.conf.original</span></span></p>
+
+<p>Pour une configuration idéale (d'après mes tests de robustesse personnels), le fichier doit ressemble à ça sans ses commentaires :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># cat server.conf | grep -v -e '^;' | grep -v -e '^#' | grep -v -e '^$'</span></span></p>
+
+<p style="margin-left: 40px;"><strong>local IP_PUBLIQUE_SERVEUR</strong><br />
+<strong>port 4450</strong><br />
+proto tcp<br />
+dev tap0<br />
+ca ca.crt<br />
+cert server.crt<br />
+key server.key # This file should be kept secret<br />
+dh dh1024.pem<br />
+<strong>server-bridge XXX.XXX.XXX.XXX 255.255.255.0 YYY.YYY.YYY.YYY TTT.TTT.TTT.TTT</strong><br />
+client-to-client<br />
+duplicate-cn<br />
+keepalive 10 120<br />
+tls-auth /etc/openvpn/ta.key 0 # This file is secret<br />
+comp-lzo<br />
+max-clients 4<br />
+user nobody<br />
+group nogroup<br />
+persist-key<br />
+persist-tun<br />
+status openvpn-status.log<br />
+log-append openvpn.log<br />
+verb 3<br />
+mode server<br />
+tls-server<br />
+script-security 2<br />
+up "/etc/openvpn/up.sh"<br />
+down "/etc/openvpn/down.sh"</p>
+
+<p>Les choses à modifier selon le serveur sont en gras :</p>
+
+<ul>
+	<li>local IP_PUBLIQUE_SERVEUR : remplacez par l'adresse IP publique de votre serveur, pour écouter en VPN sur cette adresse. Cette adresse est a priori différente selon le serveur !&nbsp;;-)</li>
+	<li>Le port d'écoute. Par défaut 1194, mais il est conseillé de le changer pour éviter d'être reconnu direct comme un VPN</li>
+	<li>XXX.XXX.XXX.XXX : remplacez par l'adresse privée du <strong>vmbr1</strong> du serveur. Attention à ne pas vous tromper !</li>
+	<li>YYY.YYY.YYY.YYY : cette IP est le début de la plage allouée pour OpenVPN. Pour ma part, je prend 4 clients possibles. Les 2 serveurs et 2 autres (pour vos connexions de gestion par exemple)</li>
+	<li>TTT.TTT.TTT.TTT : Cette IP est la fin de la plage allouée commencée par YYY.YYY.YYY.YYY. Cette plage doit contenir les IP de vos serveurs, mais comme ceux-ci sont en IP fixe, pas de risque d'allocation se marchant dessus.</li>
+</ul>
+
+### Scripts up.sh et down.sh (pour les serveurs)
+
+<p>Ces scripts vont permettre d'ajouter l'interface OpenVPN (tap0) au bridge vmbr1 à chaque démarrage du serveur VPN. Et bien sûr de le retirer à l'arrêt du serveur VPN (faisons les choses bien&nbsp;:-))</p>
+
+<p>Ces scripts seront sensiblement différents pour les clients, nous verrons ça plus bas.</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># nano /etc/openvpn/up.sh</span></span></p>
+
+<p style="margin-left: 40px;">#!/bin/bash<br />
+/sbin/ifconfig vmbr1 promisc<br />
+/sbin/ifconfig tap0 up promisc<br />
+/usr/sbin/brctl addif vmbr1 tap0</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># nano /etc/openvpn/down.sh</span></span></p>
+
+<p style="margin-left: 40px;">#!/bin/bash<br />
+/usr/sbin/brctl delif vmbr1 tap0<br />
+/sbin/ifconfig tap0 down -promisc<br />
+#/sbin/ifconfig vmbr1 -promisc</p>
+
+### Installation des clefs serveurs
+
+<p>Chacun des serveur devra disposer du set de clef serveur que nous avons généré plus haut. Sans quoi, ils n'accepteront pas les connexions du client.</p>
+
+<p>Physiquement, le client ne sera connecté qu'à un serveur à la fois, mais il faut que les 2 serveurs tournent en permanence pour que le client puisse basculer facilement en cas de souci sur le PRA.</p>
+
+<p>Sur le PRA, où vous avez généré les clefs, il suffit de les placer dans le dossier openVPN puis de les extraire :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># cd /etc/openvpn</span></span></p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># tar xvzf /root/</span></span><span style="color:#ffffff;"><span style="background-color:#000000;">server-keys.tar.gz</span></span></p>
+
+<p>Sur le serveur principal, il va d'abord falloir envoyer les clefs via scp :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># scp&nbsp;</span></span><span style="color:#ffffff;"><span style="background-color:#000000;">/root/</span></span><span style="color:#ffffff;"><span style="background-color:#000000;">server-keys.tar.gz root@IP_PUBLIQUE_SERVEUR:</span></span></p>
+
+<p><strong>Note : il n'est pas très propre d'utiliser root pour le transfert, mais c'est malheureusement la technique la plus simple sur Proxmox, où quasi-tout doit se faire en root. Vous pouvez cependant créer un autre utilisateur qui ne servira que pour les transferts. De toute façon, le cluster discute avec le compte root, donc le SSH sur le port 22 en root devra au moins être autorisé dans le tunnel OpenVPN. Je vous laisse gérer votre niveau de sécurité&nbsp;:-)</strong></p>
+
+<p>Puis extraire les clefs :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># cd /etc/openvpn</span></span></p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># tar xvzf /root/</span></span><span style="color:#ffffff;"><span style="background-color:#000000;">server-keys.tar.gz</span></span></p>
+
+<p>Une fois ceci fait, vous pouvez redémarrer OpenVPN sur les 2 serveurs :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># /etc/init.d/openvpn restart</span></span></p>
+
+<p>Normalement, il doit démarrer sans erreurs des deux côtés. Les logs s'écrivent dans /etc/openvpn/openvpn.log</p>
+
+<p>Un démarrage réussit doit se terminer par&nbsp;</p>
+
+<p style="margin-left: 40px;">Initialization sequence completed</p>
+
+<p>Sinon, vérifiez bien les adresses IP que vous avez indiquée (problème de bind) et la synthaxe des paramètres dans le fichier de conf (problème de "unknown parameter")</p>
+
+### Configuration des clients
+
+<p>A ce stade, nous avons uniquement les serveurs VPN qui tournent. Il va vous falloir configurer les clients qui s'y connectent.</p>
+
+<p>Au nombre des clients, nous avons donc l'arbitre, et le serveur principal qui je le rappelle est à la fois client ET serveur.</p>
+
+<p>Nous allons configurer l'arbitre pour qu'il tente en premier lieu de se connecter au PRA, et s'il échoue qu'il tente de se connecter au serveur principal. Nous allons également indiquer dans sa configuration que si sa connexion saute, il doit réessayer immédiatement de se reconnecter.</p>
+
+<p>Par contre, le serveur principal n'essaiera de se connecter qu'au PRA.</p>
+
+<p>Voici le fichier de configuration. La spécificité de l'arbitre est en <span style="color:#ff0000;">rouge</span> :</p>
+
+<p style="margin-left: 40px;">client<br />
+<strong>dev tap1</strong><br />
+proto tcp<br />
+<strong>remote IP_PUBLIQUE_PRA PORT_VPN<br />
+<span style="color:#ff0000;">remote IP_PUBLIQUE_SERVEUR_PRINCIPAL PORT_VPN</span></strong><br />
+resolv-retry infinite<br />
+nobind<br />
+persist-key<br />
+persist-tun<br />
+ca ca.crt<br />
+<strong>cert CLIENT.crt<br />
+key CLIENT.key</strong><br />
+ns-cert-type server<br />
+tls-auth ta.key 1<br />
+comp-lzo<br />
+verb 3<br />
+<strong>log-append openvpnclient.log</strong><br />
+script-security 2<br />
+<strong>up "/etc/openvpn/upclient.sh"<br />
+down "/etc/openvpn/downclient.sh</strong>"<br />
+<strong>keepalive 30 120</strong><br />
+float</p>
+
+<p>Les paramètres à adapter sont en <strong>gras</strong> :</p>
+
+<ul>
+	<li>dev tapX : c'est l'interface que crééra openvpn pour sa connexion. Il est important de ne pas mettre tap0, qui est déjà utilisé pour le serveur VPN sur le serveur principal. Pour uniformiser, mieux vaut utiliser la même interface sur les 2 clients</li>
+	<li>remote .... : c'est là que vous indiquez sur quel serveur se connecter. Indiquez l'adresse IP du PRA ainsi que le port que vous avez choisi. Sur l'arbitre, rajoutez une ligne avec l'adresse IP du serveur principal. OpenVPN essaiera toujours la première ligne, puis si elle échoue il passera à la deuxième.</li>
+	<li>cert, key : c'est là que vous définirez les certificats et les clefs à utiliser pour la connexion client (clientPrincipale ou clientArbitre) que nous allons rapatrier via scp.</li>
+	<li>log-append : &nbsp;indique le fichier dans lequel les logs de connexion seront écrits. Indiquez un nom de fichier différent de celui du serveur pour avoir des logs bien séparés</li>
+	<li>up, down : les fichiers up.sh et down.sh sont différents entre les serveurs et les clients, donc indiquez là aussi des noms différents ce ceux dans le fichier de conf du serveur</li>
+	<li>keepalive 30 120 : cette directive va indiquer aux clients qu'il doivent tenter de relancer leur connexion si jamais elle tombe (On ping toutes les 30s, on redémarre au bout de 120s si pas de réponse). Dans le cas du serveur principal, il essaiera en boucle de se reconnecter sur le PRA. Dans le cas de l'arbitre, il alternera entre le PRA et le serveur principal jusqu'à ce qu'une connexion réussisse</li>
+</ul>
+
+### Scripts upclient et downclient
+
+<p>Les fichiers up.sh et down.sh sont différents pour les clients. Comme le serveur principal possède déjà up.sh et down.sh, on les nomme upclient.sh et downclient.sh pour qu'ils ne se marchent pas dessus (quelle imagination !&nbsp;<img alt="devil" height="20" src="http://blog.héry.com/plugins/ckeditor/ckeditor/plugins/smiley/images/devil_smile.gif" title="devil" width="20" />)</p>
+
+<p>Donc, upclient.sh :</p>
+
+<p style="margin-left: 40px;">#!/bin/bash<br />
+/sbin/ifconfig vmbr1 promisc<br />
+/sbin/ifconfig tap1 up promisc<br />
+/usr/sbin/brctl addif vmbr1 tap1<br />
+/sbin/ifconfig tap1 0</p>
+
+<p>Et downclient.sh :</p>
+
+<p style="margin-left: 40px;">#!/bin/bash<br />
+/sbin/ifconfig vmbr1 -promisc</p>
+
+<p>La principale différence est le nom des interfaces à bridger (tap1 dans mon cas). Le down client ne doit également pas sortir le tap1 du bridge, sinon il risque de générer une erreur qui va bloquer la tentative de connexion en boucle du client. Et donc rendre inefficace le mode de secours. (Un petit souci de gestion de bridge avec OpenVPN vis à vis de tous les bridges/tap qu'on utilise ici...)</p>
+
+### Récupération des clefs clients
+
+<p>Bien, il ne reste plus qu'à transmettre les clefs openvpn à qui de droit. Depuis le PRA qui les a générées, envoyez les tar.gz grâce à scp :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># scp&nbsp;/root/clientPrincipal-keys.tar.gz root@IP_PUBLIQUE_SERVEURPRINCIPAL:</span></span></p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># scp&nbsp;/root/clientArbitre-keys.tar.gz&nbsp;root@IP_PUBLIQUE_ARBITRE:</span></span></p>
+
+<p>Puis sur chaque serveur, extrayez les clefs dans /etc/openvpn :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># cd /etc/openvpn</span></span></p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># tar xvzf /root/client{Principal,Arbitre}-keys.tar.gz</span></span></p>
+
+<p>Et enfin, redémarrez openvpn.</p>
+
+<p>La connexion va s'établir. Là encore, les logs s'écrivent dans /etc/openvpn, dans le fichier openvpnclient.log spécifé dans le fichier de configuration.</p>
+
+<p>Si tout se passe bien, vous pourrez y voir apparaitre un "Initialization sequence completed".</p>
+
+<p>C'est également dans ce fichier que vous pouvez vérifier si la reconnexion se fait bien.</p>
+
+## Tests du triangle openvpn
+
+<p>Il est important de tester votre système de connexion/reconnexion.</p>
+
+<p>A l'étape précédente, la connexion de base a dû bien fonctionner. Sinon, faites en sorte que ce soit le cas. Si jamais vous avez des soucis particuliers, faites m'en part dans les commentaires&nbsp;:-)</p>
+
+<p>Pour tester, effectuez quelques ping sur les adresse vmbr1 de chaque serveur :</p>
+
+<ul>
+	<li>Sur le serveur principal, pinguez le vmbr1 du PRA et de l'arbitre</li>
+	<li>Sur le PRA, pinguez le vmbr1 du serveur principal et de l'arbitre</li>
+	<li>sur l'arbitre, pinguez le vmbr1 du serveur principal et du PRA</li>
+</ul>
+
+<p>&nbsp;</p>
+
+<p>Pour tester que la reconnexion fonctionne bien, nous allons essayer de couper le serveur VPN du PRA et voir comment tout cela se comporte.</p>
+
+<p>Ouvrez 3 connexions SSH, une par serveur.</p>
+
+<ul>
+	<li>Sur l'arbitre et le serveur principal, lancez une surveillance du client OpenVPN :</li>
+</ul>
+
+<p style="margin-left: 40px;"><span style="color:#ffffff;"><span style="background-color:#000000;"># less /etc/openvpn/openvpnclient.log</span></span></p>
+
+<p style="margin-left: 40px;">Puis effectuez la combinaison de touche "maj + F" qui va permettre une mise à jour en temps réel du fichier. Vous verrez ainsi tout ce qui s'y écrit</p>
+
+<ul>
+	<li>Sur le PRA, coupez openvpn avec un&nbsp;</li>
+</ul>
+
+<p style="margin-left: 40px;"><span style="color:#ffffff;"><span style="background-color:#000000;"># /etc/init.d/openvpn stop</span></span></p>
+
+<p>Normalement, vous devriez rapidement voir dans les fichiers de log que la connexion s'est interrompue. Sur le serveur Principal, la connexion va tenter en boucle de s'établir à nouveau.</p>
+
+<p>Sur l'arbitre, vous devriez voir rapidement une tentative de connexion sur le serveur principal, qui doit réussir.</p>
+
+<p>Là encore, vous pouvez vérifier avec quelques ping que tout va bien.</p>
+
+<p>Relancez ensuite le serveur VPN sur le PRA. Vous devez observer que le serveur principal revient s'y connecter.</p>
+
+<p><strong>A ce moment là, l'arbitre est connecté sur le serveur principal. Il ne va pas essayer de se reconnecter sur le PRA sauf si le serveur principal tombe.</strong></p>
+
+<p>Pour achever nos tests, coupez le serveur VPN sur le serveur principal, ce qui devrait provoquer la reconnexion de l'arbitre sur le PRA.</p>
+
+<p>Si tout ça fonctionne, on commence à être vraiment bon !&nbsp;:-)</p>
+
+## Mise en place du cluster
+
+<p>Avant de mettre en place le cluster, nous allons vérifier que le multicast passe bien dans le VPN.</p>
+
+<p>Pour ce faire, sur chaque machine, installez l'outil suivant :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># aptitude install ssmping</span></span></p>
+
+<p>Ensuite, nous allons tester les serveurs 2 par 2. L'un essaiera de joindre l'autre en multicast, pendant que la cible écoutera les connexions.</p>
+
+<p>Bon je vais pas écrire toutes les combinaisons possibles pour les tests. Sachez qu'il vous faut lancer sur un serveur pour le mettre en écoute :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;">#&nbsp;ssmpingd</span></span></p>
+
+<p>Puis depuis un autre, lancez le test :</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># asmping 224.0.2.1 IP_SERVEUR_TEST</span></span></p>
+
+<p>Vous devez voir passer sur le serveur en écoute des messages de ce type :</p>
+
+<p style="margin-left: 40px;">asmping joined (S,G) = (*,224.0.2.234)<br />
+pinging IP_SERVEUR_TEST from IP_SERVEUR_SOURCE<br />
+unicast from IP_SERVEUR_TEST, seq=1 dist=0 time=38.699 ms<br />
+multicast from IP_SERVEUR_TEST, seq=1 dist=0 time=76.405 ms<br />
+unicast from IP_SERVEUR_TEST, seq=2 dist=0 time=38.802 ms<br />
+multicast from IP_SERVEUR_TEST, seq=2 dist=0 time=76.238 ms</p>
+
+<p>Les lignes importantes à repérer sont celles du multicast,&nbsp;<strong>que vous devez impérativement constater pour le bon fonctionnement du cluster !</strong></p>
+
+<p>C'est également le bon moment pour vérifier le fichier /etc/hosts.</p>
+
+<p>Vous devez avoir indiqué l'adresse IP du vmbr1. C'est l'adresse dont se sert Proxmox comme information lors du contact avec les autres membres du cluster.</p>
+
+### Création du cluster
+
+<p>Pour le cluster, nous allons effectuer sa création depuis le PRA, puis nous allons y ajouter les 2 autres serveurs.</p>
+
+<p><strong>Je vous rappelle qu'il ne doit y avoir aucune VM sur le serveur principal et sur l'arbitre ! </strong>Si votre système a déjà des VM en fonctionnement, migrez les temporairement sur le PRA le temps de créer le cluster. Cette limitation a pour but de s'assurer qu'aucun VMID ne sera en conflit au sein du cluster.</p>
+
+<p>Le nom du cluster est important, &nbsp;dans le sens où une fois le cluster créé, vous ne pourrez plus changer ce nom. Choisissez le bien !</p>
+
+<p>Sur le PRA :&nbsp;</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># pvecm create NOM_DU_CLUSTER</span></span></p>
+
+<p>qui doit vous renvoyer :</p>
+
+<p style="margin-left: 40px;"><br />
+Generating public/private rsa key pair.<br />
+Your identification has been saved in /root/.ssh/id_rsa.<br />
+Your public key has been saved in /root/.ssh/id_rsa.pub.<br />
+The key fingerprint is:<br />
+xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx root@proxmox-server-1<br />
+The key's randomart image is:<br />
++--[ RSA 2048]----+<br />
+| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br />
+| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br />
+| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br />
+| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;<br />
+| &nbsp; &nbsp; &nbsp;&nbsp; . &nbsp; So &nbsp;&nbsp; o &nbsp; &nbsp; &nbsp; &nbsp;|<br />
+| . &nbsp; &nbsp; &nbsp;.. &nbsp; &nbsp; &nbsp;.O &nbsp; &nbsp;o &nbsp; &nbsp; |<br />
+<br />
+| .. &nbsp; . &nbsp;&nbsp; o* &nbsp; &nbsp; = &nbsp; &nbsp; &nbsp; &nbsp; |<br />
+|&nbsp; &nbsp; +o &nbsp; &nbsp; &nbsp; o.=.. &nbsp; &nbsp; &nbsp; &nbsp;|<br />
+| . &nbsp; &nbsp; +E &nbsp;* &nbsp;o &nbsp; &nbsp;o . &nbsp; |<br />
++----------------------+<br />
+Restarting pve cluster filesystem: pve-cluster[dcdb] crit: unable to read cluster config file '/etc/cluster/cluster.conf' - Failed to open file '/etc/cluster/cluster.conf': No such file or directory<br />
+[dcdb] notice: wrote new cluster config '/etc/cluster/cluster.conf'<br />
+[dcdb] crit: cman_tool version failed with exit code 1#010<br />
+.<br />
+Starting cluster:<br />
+Checking if cluster has been disabled at boot... [ OK ]<br />
+Checking Network Manager... [ OK ]<br />
+Global setup... [ OK ]<br />
+Loading kernel modules... [ OK ]<br />
+Mounting configfs... [ OK ]<br />
+Starting cman... [ OK ]<br />
+Waiting for quorum... [ OK ]<br />
+Starting fenced... [ OK ]<br />
+Starting dlm_controld... [ OK ]<br />
+Unfencing self... [ OK ]</p>
+
+<p>Puis, sur chacun des autres serveurs :</p>
+
+<p># pvecm add IP_VMBR1_PRA</p>
+
+<p>qui doit vous renvoyer à peu près la même chose qu'au dessus.</p>
+
+### Etat du cluster
+
+<p>La commande pvecm vous permettra d'avoir plusieurs infos sur le cluster.</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># pvecm n</span></span></p>
+
+<p>vous donnera un aperçu des nodes (date de connexion, état, etc)</p>
+
+<p><span style="color:#ffffff;"><span style="background-color:#000000;"># pvecm s</span></span></p>
+
+<p>vous donnera des informations sur le cluster lui-même (état du qorum, nombre de node, nombre de vote, etc)</p>
+
+<p>Nous verrons plus tard des commandes plus spécifiques au HA.</p>
+
+## Bon, je crois que j'ai rien oublié
+
+<p>Et bien voila qui conclut la création de notre système de cluster !</p>
+
+<p>A la fin de ce tutoriel, vous avez normalement un cluster de 3 nodes, donc avec un quorum qui fonctionne, et des paritions manipulables facilement.</p>
+
+<p>Vous êtes prêts à mettre en place le système de disque répliqué, puis le HA lui-même.</p>
+
+<p>Ces deux étapes seront le sujet des prochains articles.</p>
+
+<p>En attendant, n'hésitez pas à me poser des questions dans les commentaires !</p>
+
+<p>&nbsp;</p>

content/comments/cluster-proxmox-distant-1.4-concept/0.md

@@ -0,0 +1,24 @@
+email: tranxene50@developpeur-neurasthenique.fr
+date: 2013-01-17T00:10+01:00
+author: tranxene50
+website: http://blog.developpeur-neurasthenique.fr/
+
+Hello !
+
+Ouh punaise... J'attends la suite (technique) avec impatience !
+
+Je crois que je n'ai jamais lu un article aussi didactique (en français) et notamment en ce qui concerne la notion de quorum avec Proxmox.
+
+Pour le fencing, c'est clair qu'une solution matérielle est a privilégier mais il est possible (me semble-t-il) de tricher avec un "fence device" virtuel (à creuser, cela implique quelques sacrifices).
+
+Au niveau de DRBD, même si cela fonctionne correctement, je pense qu'il va y avoir un souci avec les applications qui utilisent massivement la mémoire (cache/buffer), par exemple MySQL.
+
+Ce que je veux dire c'est que, répliquer les fichiers Innodb ne suffit pas pour garantir l'intégrité des bases : si le serveur de secours démarre, il y aura forcément un recovery des BDD. (A tester dans la vie réelle, MySQL se démerde plutôt bien dans ce cas de figure).
+
+De tout ce que j'ai lire, pour migrer des containers OpenVZ sans aucune perte de données, il faut impérativement sauvegarder l'état de la mémoire (checkpointing).
+
+Concernant les IP fail over, quand on utilise des serveurs dédiés via des prestataires différent, c'est clairement la plaie (marche pas...).
+
+Je cherche toujours une solution a ce problème mais, de ce que j'ai pu comprendre, il faudrait passer un prestataire tiers qui reroute le trafic (donc c'est du transit) là où il faut. Le souci c'est qu'on utilise leur bande passante (logique) et donc, il facturent cela.
+
+A+

content/comments/cluster-proxmox-distant-1.4-concept/10.md

@@ -0,0 +1,16 @@
+email: lecorvaisier.jerome@gmail.com
+date: 2013-02-10T05:14+01:00
+author: Jérôme
+website:
+replyto: 4md
+
+Bonsoir,
+
+Veuillez s'il vous plait continuez à régler le problème par commentaire, ça m'intéresse beaucoup. En effet je suis aussi en train de mettre Proxmox en place en environnement de test pour le moment seulement je ne dispose pas encore de suffisamment de serveurs pour tester le fencing en fonctionnement réel. J'utilise le mode "human" qui indique que c'est aux admins de s'occuper du fencing.
+
+Utilisant DRBD pour synchroniser le disque, j'ai une petite question. Est-ce qu'on doit utiliser (dans mon cas /var/lib/vz) le mode master-slave ou master-master ? Car la aussi, si on utilise DRBD en master-slave il doit y avoir des options de fencing pour que le noeud slave prenne la main sur la ressource n'est-ce pas ? Ca m'arrangerait bien que vous validiez mes dires :)
+
+Victor vous avez l'air vraiment documenté sur le sujet. Les commentaires sont vraiment constructifs.
+
+Merci à vous pour cette mine d'informations!   
+Bien cordialement

content/comments/cluster-proxmox-distant-1.4-concept/12.md

@@ -0,0 +1,15 @@
+email: lecorvaisier.jerome@gmail.com
+date: 2013-02-11T10:00+01:00
+author: Jérôme
+website:
+replyto: 4md
+
+Bonjour,
+
+Le problème de Gégé m'interpelle, admettons qu'on dispose d'un cluster Proxmox en HA (principal, secondaire, arbitre) avec une partition logique DRBD repliquée entre le serveur principal et secondaire. La solution est basé sur du fencing au niveau node, carte de management uniquement.
+
+Si un des noeuds est coupé électriquement, l'arbitre et le secondaire s'arrange pour "fencer" le noeud principal via sa carte de management qui n'est plus alimentée et donc... va attendre indéfiniment qu'il revienne dans le cluster pour le killer ? ...
+
+Les deux serveurs secondaire et arbitre n'auront donc jamais démarré les services du principal ?
+
+Y'a bon ou je suis vraiment à côté ? :)

content/comments/cluster-proxmox-distant-1.4-concept/13.md

@@ -0,0 +1,16 @@
+email: courriel@victor-hery.com
+date: 2013-02-12T17:35+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 4md
+
+Hello,
+
+Je confirme, c'est effectivement le cas. Si le système de fencing est en rade, et que du coup le fencing échoue en boucle sur l'arbitre et/ou le serveur de secours, alors les services en HA ne démarreront jamais.  
+Et en plus dès que le serveur principal se fera de nouveau alimenté, il sera fencé direct.  
+C'est pourquoi il est conseillé par Proxmox (et Red Hat) d'avoir plusieurs systèmes de fencing pour gérer tous les types de pannes.  
+En l'occurrence, je pense qu'il est possible d'alimenter indépendamment une carte iDrac ou ILO ? (je ne connais pas bien ce matériel)  
+
+Pour ma part, j'ai remplacé un script de fencing (le script de node assassin) par un script envoyant un courriel et se terminant par exit 0 pour que la node ait l'impression de réussir le fencing. Surement pas la solution idéale, mais à distance... Enfin j'en ai déjà parlé :)
+
+A plush'

content/comments/cluster-proxmox-distant-1.4-concept/14.md

@@ -0,0 +1,20 @@
+email: lecorvaisier.jerome@gmail.com
+date: 2013-02-13T11:34+01:00
+author: Jérôme
+website:
+replyto: 4md
+
+Bonjour,
+
+Je re-confirme, après en avoir discuté avec d'autres personnes sur freenode.org, il m'a été dit que ce genre de pannes n'était pas pris en charge, il est donc vivement conseillé de disposer d'un système de fencing au niveau node de type PDU, onduleur manageable plutôt que des cartes de management, ou du moins, en plus du fencing avec les cartes.
+
+Je commence de plus en plus à me demander, comment le HA de VMware fonctionne. Il s'agit d'environ 80% du parc de virtualisation qui est fournit par VMware, est-ce que le fencing est-il aussi abordé qu'avec Proxmox ?
+
+Je ne sais pas si c'est de vous, ou de quelqu'un d'autre mais il me semble avoir entendu que les noeuds se suicident dans les systèmes HA de VMware, en savez-vous davantage? Et si oui, quel est votre point de vue entre ces deux types de fencing ?
+
+Pour ma part, ce problème d'alimentation des cartes de management n'est pas en soi un problème étant donné que c'est aux administrateurs d'intervenir sur les systèmes pour promouvoir un master pour DRBD, activer les volumes LVM et démarrer la VM mais c'est des notions très intéressantes qui montrent combien le fencing peut être contraignants (selon le point de vue de chacun :)) et combien le HA de Proxmox ne se permet pas de créer des situations de split brain.
+
+Voyez, moi aussi je suis très verbeux :)
+
+Bien cordialement
+Jérôme

content/comments/cluster-proxmox-distant-1.4-concept/15.md

@@ -0,0 +1,20 @@
+email: courriel@victor-hery.com
+date: 2013-02-14T13:34+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 4md
+
+Hello,
+
+Ah, je ne pense pas que cette affirmation sur VMWare vienne de moi. Là, je dois bien admettre mon manque (total ? :s) de connaissance sur VMWare.  
+Je n'ai encore jamais eu l'occasion d'y toucher, sans parler du temps. Ceci dit, c'est effectivement intéressant de confronter les fonctionnements vis à vis du HA, qui est un système critique mais en même temps extrêmement difficile à gérer.
+
+A ce sujet là Proxmox est très limitatif, et autant ça peut parfois être bloquant, autant c'est un fonctionnement qui peut se comprendre. Après, si on l'outrepasse, il faut également être conscient des risques ;)
+Et puis sur ce genre de principe de cluster en HA, il y aura toujours (toujours !) des cas qu'on n'aura pas pu tester, ou auxquels on n'aura même pas pensé...
+
+Des noeuds qui se suicident sont une solution intéressante, mais c'est quand même étrange, comment font-ils sans alimentation (par exemple) ? Et comment les nodes restantes peuvent-elles être sûres que c'est le cas ?
+Ou alors, en partant du fait que sans le quorum, la node DOIT se suicider, alors les nodes restantes sont sûres que c'est bien le cas, et si jamais elle n'a pas pu le faire (alimentation, encore) c'est qu'elle n'est de toute façon plus en état de fournir le service. Pourquoi pas en effet, c'est une vision inverse de Proxmox mais qui a ses arguments :)
+
+Merci de m'avoir signalé ça tiens !
+
+A plush'

content/comments/cluster-proxmox-distant-1.4-concept/16.md

@@ -0,0 +1,21 @@
+email: lecorvaisier.jerome@gmail.com
+date: 2013-02-16T16:04+01:00
+author: Jérôme
+website:
+replyto: 4md
+
+Bonjour :)
+
+Oui, la notion peut paraître déroutante... Si ce n'est pas de vous, c'est en dévorant des blogs ou des sites qui parlent de libre où j'ai du voir ça... Il me semble que c'était soufflé sans affirmation, aucunes.
+
+Dans le principe, le noeud ne peut plus transmettre au cluster (pas de réponses au multicast par exemple), il ping la passerelle, s'il n'obtient pas de réponses, alors il désactive ses services du cluster en se disant que les autres noeuds du cluster vont activer les services qu'il proposait auparavant... Il se suicide via un reboot, une extinction, je ne sais pas vraiment... en ce qui concerne un problème réseau par exemple...
+
+En ce qui concerne une panne d'alimentation... Le cluster fonctionne normalement, un des noeuds vient à sortir du cluster (il ne répond plus à ses pairs), ses services sont donc considéré comme éteint/libre par le cluster et il va alors s'arranger pour les démarrer sur les noeuds restants....
+
+
+Voilà.. voilà.. mais encore une fois, ce n'est là en aucune manière une affirmation du fonctionnement du HA de VMware... Enfin, les hypothèses sont vraiment intéressante. Il serait sympa de pouvoir choisir dans les modes de fonctionnement du HA de Proxmox, afin de pouvoir coller avec toutes les situations... ;)
+
+A proposer dans la roadmap ;)
+
+Bien cordialement  
+Jérôme

content/comments/cluster-proxmox-distant-1.4-concept/17.md

@@ -0,0 +1,9 @@
+email: bentien@live.fr
+date: 2013-04-17T15:35+01:00
+author: Ozzi
+website:
+
+Bonjour,  
+Tout d'abord merci pour votre explication très claire des notions de quorum et de fencing et pour votre article en général !   
+Vous dites qu'utiliser drbd avec openVZ n'est pas réalisable, est-ce vraiment le cas ? Je suis actuellement le tuto de nedProduction que vous citez au début de l'article et il me semble que toutes ses VM sont en openVZ lorsqu'il met en place drbd.  
+D'ailleurs pensez vous bientôt publier votre 3ème article dans lequel vous aborderez drbd ? :)

content/comments/cluster-proxmox-distant-1.4-concept/19.md

@@ -0,0 +1,11 @@
+email: bentien@live.fr
+date: 2013-04-19T11:06+01:00
+author: Ozzi
+website:
+replyto: 17md
+
+Bonjour !  
+Oui le problème est beaucoup plus clair maintenant, merci pour l'explication :)  
+C'est très embêtant pour moi car nous n'avons que des container OpenVZ et qu'on me demande de mettre en place de la HA... Mais on trouvera une solution ! 
+
+Bonne continuation pour vos tutos en tout cas ;)

content/comments/cluster-proxmox-distant-1.4-concept/2.md

@@ -0,0 +1,22 @@
+email: lecorvaisier.jerome@gmail.com
+date: 2013-01-23T11:05+01:00
+author: Jérôme
+website:
+
+Bonjour,
+
+Alors, on commence quand ? :)
+
+Je suis actuellement en train de réfléchir à mettre en place une solution basé sur Proxmox HA/DRBD mais non pas entre différents hébergeurs sur une ligne à forte latence mais en LAN.
+
+Je risque d'avoir au moins autant de problèmes que vous étant donné que je n'ai encore aucunes solutions pour tromper le fencing et que le projet partait avec 2 noeuds dans le cluster et non 3.
+
+
+Je vous remercie pour les détails que vous avez apporté notamment sur les notions de quorum et de fencing pas très simple à comprendre à la première approche.
+
+En ce qui me concerne, la solution me servira à mettre des serveurs M$ SQL donc des machines KVM synchronisés via DRBD mais comme le fait remarquer tranxene50 et à juste titre, il risque d'y avoir quelques / nombreuses incohérences dans les données.... Vous faites d'ailleurs remarqué que vous n'avez pas eu de soucis lors de vos tests, faisiez vous des nombreuses requêtes sur le serveur SQL avant de le copier et de couper subitement le serveur principal ?
+
+Ceci étant dit, j'attend la suite avec impatience, la pub commence à se faire longue :)
+
+Bonne journée à vous
+Bien cordialement

content/comments/cluster-proxmox-distant-1.4-concept/22.md

@@ -0,0 +1,14 @@
+email:
+date: 2013-05-22T17:14+01:00
+author: Arnaud
+website:
+
+Bonjour,
+
+Merci beaucoup pour ton article t ;)
+
+Cependant j'ai quelque question  .
+Pourquoi à ton besoin de LVM ? pour les snapshot ?   
+Et pour NFS, il y a un intérêt ou pas ?   
+
+Merci pour vos futurs réponses.

content/comments/cluster-proxmox-distant-1.4-concept/23.md

@@ -0,0 +1,14 @@
+email: briensc@hotmail.com
+date: 2013-06-03T01:09+01:00
+author: Damien
+website:
+
+Bonjour!
+
+Merci pour le tuto qui est très bien rédigé!  
+je suis entrain de construire un projet de test via: vmware workstation. j'aurais voulu tester la HA de proxmox. le seul problème c'est comment fencer une vm via vmware? ou alors tromper le fencing, pour lui faire croire que c'est bon.
+
+j'ai pour l'instant 3 node proxmox + 2 drbd avec server nfs en cluster(en actif/passif), qui tourne sur workstation 9.
+
+si vous avez une petite idée?   
+merci!

content/comments/cluster-proxmox-distant-1.4-concept/24.md

@@ -0,0 +1,19 @@
+email: courriel@victor-hery.com
+date: 2013-06-17T12:00+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 22md
+
+Hello,
+
+Désolé pour la latence dans la réponse :s
+
+LVM être très intéressant pour utiliser DRBD derrière.  
+D'abord parce qu'il va permettre de redimensionner et de libérer facilement de la place pour le disque DRBD (et de laisser de la souplesse si plus tard tu as besoin de changer ces espaces disques).  
+Ensuite parce que DRBD aime bien LVM en ce sens qu'il peut utiliser les snapshot pour faire des "points de cohérence". C'est à dire que lors de la synchronisation des disques DRBD entre-eux, il utilise l'espace libre LVM pour optimiser la synchronisation afin que les données soient toujours au maximum cohérentes :)  
+
+Pour NFS, je ne sais pas trop si LVM apporte un réel intérêt, à part encore la possibilité d'être souple sur le dimensionnement des partitions et des disques (Enfin ça, c'est l'avantage inhérent à LVM :) )
+
+J'espère avoir répondu à ta question.
+
+A plush'

content/comments/cluster-proxmox-distant-1.4-concept/25.md

@@ -0,0 +1,25 @@
+email: courriel@victor-hery.com
+date: 2013-06-17T12:08+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 23md
+
+Hello Damien,
+
+Désolé, je ne connais pas du tout vmware.
+
+A l'instinct, je te dirais de chercher si via ton hyperviseur vmware tu peux envoyer des signaux de simulation type "extinction physique de la machine virtuelle" pour faire croire à proxmox que c'est bon la node est bien éteinte.
+
+Une façon universelle de le tromper sinon, ça peut être de permettre aux nodes de se connecter sur ton vmware en ssh/telnet/ipmi, et de faire sur le vmware un script appelé par le fencing qui couperait la node demandée :  
+ - La node 1 est en défaut  
+ - La node 2 demande le fencing, elle contacte l'hyperviseur en lui demandant de couper la node 1  
+ - L'hyperviseur effectue un shutdown de la node 1  
+ - L'hyperviseur répond par le biais sur script qu'il a correctement coupé la node 1 (code de retour 0)  
+Ca devrait suffire à faire croire au HA que le fencing a fonctionné.  
+Pour la réalisation technique par contre, ça dépendra beaucoup de comment une node peut comuniquer avec l'hyperviseur, je n'en sais pas plus :s  
+
+Ca reste du bidouillage, en production je te conseille quand même du proxmox sur des machines physiques :)
+
+Bon courage.
+
+A plush'

content/comments/cluster-proxmox-distant-1.4-concept/26.md

@@ -0,0 +1,19 @@
+email: mcmyst@hotmail.fr
+date: 2013-10-11T09:29+01:00
+author: matthieu
+website:
+
+Bonjour,
+
+Merci pour cet article intéressant.
+
+J'ai une interrogation que j'aimerai confirmer auprès de vous:  
+Le fencing est utile uniquement dans le cas où, le serveur hôte ne répond plus sur son interface de management (système figé), mais que les VM continu de fonctionner. Dans ce cas, pour éviter d'avoir deux hyperviseurs qui accède au stockage partagé le fencing rentre en action pour tuer l'hôte planté.  
+
+Mais sérieusement, dans combien de cas cette situation arrive ?
+
+Corrigez moi si je dis une bêtise, mais de mon point de vue, dans 90% des cas, le mécanisme quorum doit suffire. Je m'explique, notre hôte principale se trouve isolé du réseau suite à une panne d'un switch.   
+Dans ce cas, le fencing de l'autre neoud ne peut rien y faire et tourne en boucle, mais le serveur va automatiquement détecter qu'il a perdu le quorum et stopper automatiquement les ressources HA.  
+J'aimerai bien avoir un retour sur combien de personne se sont trouvé dans des situations ou le fencing a été plus utile que le quorum.  
+
+Merci

content/comments/cluster-proxmox-distant-1.4-concept/27.md

@@ -0,0 +1,20 @@
+email: courriel@victor-hery.com
+date: 2013-10-16T22:46+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 26md
+
+Bonjour Matthieu,
+
+Je suis tout à fait d'accord, le fencing est plutôt rarement utile, et souvent même une source d'ennui.
+
+Cependant, les 10% de cas où il s'avère utile (hyperviseur planté mais VM continuant de tourner), il est absolument nécessaire car 2 machines qui écrivent au même instant sur un disque, c'est le plantage définitif assuré, avec peu d'espoir de réparer.  
+Du coup, restauration de sauvegardes, remise en route, tout ça tout ça. A condition d'avoir bien géré ces parties bien sûr :)
+
+Du coup, même si le fencing est parfois compliqué à gérer (notamment sur des clusters distant), il est absolument nécessaire. Au début, je pensais aussi que c'était vraiment une perte de temps pour pas grand chose, j'ai mis un peu d'eau dans mon vin depuis après avoir rencontré quelque cas d'écritures concurrentes comme dis au dessus.
+
+Il est parfois préférable que le cluster décide de ne pas remettre en route les machines s'il ne peut pas être sûr qu'elles sont effectivement coupées, et envoie un message à l'administrateur pour le prévenir de son indécision, plutôt qu'il prenne une décision catastrophique au niveau des machines.
+
+En nombre de cas, le fencing est sans doute "peu" utile. Par contre comparativement à la difficulté de régler un cas où il n'a pas fonctionné, je pense que ça vaut le coup de s'y pencher quand même.
+
+Voila pour mon avis, j'espère qu'il aura été constructif :)

content/comments/cluster-proxmox-distant-1.4-concept/28.md

@@ -0,0 +1,6 @@
+email: fetra.randriamiranto@wamada.com
+date: 2014-04-01T10:07+01:00
+author: belou
+website: http://malagasy-admin.com
+
+euh, un an après, tu n'arrive plus à ecrirer l suite, je hate de voire le technique pour tromper fence device

content/comments/cluster-proxmox-distant-1.4-concept/29.md

@@ -0,0 +1,8 @@
+email:
+date: 2015-02-16T14:31+01:00
+author: Pier
+website: http://cavepopo.hd.free.fr
+
+Bonjour,
+
+Merci pour cet article (je ne l'ai pas encore terminé), j'ai une suggestion pour la traduction de fencing (ca me permet également de vérifier que j'ai bien compris le concept), on pourrait traduire fencing par "cloisonnement" , non ?

content/comments/cluster-proxmox-distant-1.4-concept/3.md

@@ -0,0 +1,21 @@
+email: courriel@victor-hery.com
+date: 2013-01-23T11:39+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 2md
+
+Hello,
+
+En fait, j'ai des brouillons en cours, mais je prend pas mal de temps à retester chaque chose que j'écris et à essayer que ça ne soit pas trop abstrait, donc ça me prend un peu de temps. (Et de motivation)
+Ceci dit, vu qu'effectivement ça a l'air d'intéresser, ça va me pousser un peu en avant (ça fait jamais de mal ^^)
+
+J'espère pouvoir sortir la série d'ici la fin février, mais ça dépends de mon temps libre donc c'est toujours sujet à caution...
+
+Pour ce qui est du reste, mes tests se sont fait en Mysql sur une BDD de quelques Go. Ce n'est pas une base SQL en frontend pour un site de plusieurs milliers d'utilisateur, donc elle n'est pas intensément utilisée, mais ceci dit j'ai effectivement fait des tests en coupant les machines et en les redémarrant, ça ne m'a pas posé de problème.
+
+Ceci dit le problème est plus conceptuel. En pratique, vu que la HA prend le secours d'une machine en panne, la machine principale s'est en général fait couper "mochement", et donc s'il y avait du SQL en cache, il est perdu. La machine en HA redémarre complètement (ce n'est pas une live migration ou un resume), donc la base SQL lance ses patch correctifs s'il y a lieu. En tout cas, c'est ce que j'ai constaté avec Mysql, je ne connais pas assez SQL server.
+
+Si vous êtes en LAN, je ne saurais trop vous conseiller de trouver un moyen de faire du fencing matériel. Si vous avez la main sur le matériel, un onduleur manageable est très envisageable. Ceci dit, j'ai eu à faire face à ces contraintes donc je ne vous jetterai pas la pierre :)  
+Par contre, 3 noeuds restent conseillés pour bien gérer le HA. Ceci dit, le wiki proxmox a été mis à jour assez récemment pour supporter un disque de quorum (en fait, juste un petit disque ISCSI servant d'arbitre), c'est un concept qui peut être intéressant dans votre cas en LAN (Sur Internet, OpenVPN est nécessaire) : <a href="http://pve.proxmox.com/wiki/Two-Node_High_Availability_Cluster#Quorum_Disk_Configuration">Quorum disk Proxmox</a>
+
+A plush'

content/comments/cluster-proxmox-distant-1.4-concept/30.md

@@ -0,0 +1,15 @@
+email: courriel@victor-hery.com
+date: 2015-02-18T12:56+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 29md
+
+Bonjour Pier,
+
+Question intéressante pour la traduction, je ne suis pas fan de "cloisonnement" dans le sens ou tu ne cloisonne pas vraiment le serveur (tu ne l'empêche pas vraiment de fonctionner), mais plutot tu t'assures qu'il soit vraiment coupé.
+
+Ca peut être effectivement en coupant son réseau (donc en le cloisonnant), mais aussi en lui coupant l'alimentation, en lui disant "sors du cluster", etc
+
+A ce titre il faut avouer que c'est un mot qui prête un peu à confusion.
+
+(mais il est vrai que la traduction littérale de fence en français correct serait clôture)

content/comments/cluster-proxmox-distant-1.4-concept/31.md

@@ -0,0 +1,10 @@
+email:
+date: 2016-07-02T12:30+01:00
+author: Simon
+website: http://reseauxeasyandfree.simonlena.com/
+
+Article vraiment génial !! J'éspère que cela donnera envie a certain de passer a proxmox !
+
+Le petit vocablaire en début d'article est assez utile, de plus nous n'avons p-e pas tous les mêmes conception de certains termes.
+
+A +

content/comments/cluster-proxmox-distant-1.4-concept/4.md

@@ -0,0 +1,15 @@
+email:
+date: 2013-02-01T14:06+01:00
+author: Gégé
+website:
+
+Bonjour,
+
+j'ai trouvé votre article très intéressant et assez précis pour répondre à pas mal de questions sur le cluster HA de Proxmox.  
+Je suis moi-même en train de monter un cluster à trois noeuds avec HA et je retrouve dans votre article quelques réponses à mon questionnement.  
+J'en ai pourtant encore quelques unes (des questions) qui n'ont pas encore trouvé de réponse.  
+exemple: dans un cluster ha proxmox quelle doit être l'attitude des noeuds valides lorsqu'un troisième noeuds à perdu le contact (perte alimentation par exemple) . Dan mon cas lors de la perte totale d'un noeud il ne se passe rien jusqu'au retour du noeud arrêté . Les VM configurées avec HA et présentes sur ce noeud migrent à ce moment là. Je ne pense pas que ce soit un fonctionnement normal.  
+J' ajoute que mes test de fencing (notamment avec l'outil fence_node ou en debranchant le reseau d'un des noeuds)  ont donnés des résultats satisfaisant.  
+si vous avez un petit moment de libre à consacrer a ce problème,  je vous en serais très reconnaissant .  
+merci d'avance  
+cordialement

content/comments/cluster-proxmox-distant-1.4-concept/6.md

@@ -0,0 +1,19 @@
+email:
+date: 2013-02-04T11:48+01:00
+author: Gégé
+website:
+replyto: 4md
+
+Bonjour et merci pour ta réponse.
+
+j'ai réitéré la manip .  
+le pvecm n me met bien le node arrété en status X  
+le pvecm s prend bien en compte que 2 nodes avec un quorum de 2  
+le clustat m'indique bien que le node arrété est "Offline" le rgmanager est bien arrété  le service qui concerne la VM (pvevm:100) me donne le dernier possesseur mais son état est "started"
+
+en ce qui concerne le syslog il y a une erreur dans  le fencing du node arrété ( peut-être que mon fencing n'est pas tout a fait OK, ou peut être est ce normal).  
+je me permet de t'envoyer le partie du syslog intéressante . J'espère ne  pas trop abuser de ton temps .  
+En tous cas merci pour tout.  
+A bientôt  
+
+Gégé

content/comments/cluster-proxmox-distant-1.4-concept/7.md

@@ -0,0 +1,39 @@
+email:
+date: 2013-02-04T13:25+01:00
+author: Gégé
+website:
+replyto: 4md
+
+Oups!  
+ça ira mieux si j'envoie  le fichier.
+
+    machine-proxmox2 corosync[2327]:   [TOTEM ] A processor joined or left the membership and a new membership was formed.
+    machine-proxmox2 rgmanager[2541]: State change: machine-proxmox1 DOWN
+    machine-proxmox2 kernel: dlm: closing connection to node 2
+    machine-proxmox2 corosync[2327]:   [CPG   ] chosen downlist: sender r(0) ip(10.XX.XX.169) ; members(old:3 left:1)
+    machine-proxmox2 pmxcfs[2216]: [dcdb] notice: members: 1/2216, 3/1989
+    machine-proxmox2 pmxcfs[2216]: [dcdb] notice: starting data syncronisation
+    machine-proxmox2 corosync[2327]:   [MAIN  ] Completed service synchronization, ready to provide service.
+    machine-proxmox2 fenced[2390]: fencing node machine-proxmox1
+    machine-proxmox2 pmxcfs[2216]: [status] notice: cpg_send_message retried 1 times
+    machine-proxmox2 pmxcfs[2216]: [dcdb] notice: members: 1/2216, 3/1989
+    machine-proxmox2 pmxcfs[2216]: [dcdb] notice: starting data syncronisation
+    machine-proxmox2 pmxcfs[2216]: [dcdb] notice: received sync request (epoch 1/2216/00000004)
+    machine-proxmox2 pmxcfs[2216]: [dcdb] notice: received sync request (epoch 1/2216/00000004)
+    machine-proxmox2 pmxcfs[2216]: [dcdb] notice: received all states
+    machine-proxmox2 pmxcfs[2216]: [dcdb] notice: leader is 1/2216
+    machine-proxmox2 pmxcfs[2216]: [dcdb] notice: synced members: 1/2216, 3/1989
+    machine-proxmox2 pmxcfs[2216]: [dcdb] notice: start sending inode updates
+    machine-proxmox2 pmxcfs[2216]: [dcdb] notice: sent all (0) updates
+    machine-proxmox2 pmxcfs[2216]: [dcdb] notice: all data is up to date
+    machine-proxmox2 pmxcfs[2216]: [dcdb] notice: received all states
+    machine-proxmox2 pmxcfs[2216]: [dcdb] notice: all data is up to date
+    machine-proxmox2 fenced[2390]: fence machine-proxmox1 dev 0.0 agent fence_ilo3 result: error from agent
+    machine-proxmox2 fenced[2390]: fence machine-proxmox1 failed
+    machine-proxmox2 fenced[2390]: fencing node machine-proxmox1
+    machine-proxmox2 fenced[2390]: fence machine-proxmox1 dev 0.0 agent fence_ilo3 result: error from agent
+    machine-proxmox2 fenced[2390]: fence machine-proxmox1 failed
+    machine-proxmox2 fenced[2390]: fencing node machine-proxmox1
+
+encore merci  
+GG

content/comments/cluster-proxmox-distant-1.4-concept/8.md

@@ -0,0 +1,25 @@
+email: courriel@victor-hery.com
+date: 2013-02-04T13:43+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 4md
+
+Hello,
+
+Si tu veux, je t'invite à mettre ton adresse courriel dans tes commentaires, elle ne sera visible que par moi, et ça sera plus pratique pour discuter :)  
+(En attendant que je répare mon formulaire de contact ^^")
+
+Pour ce qui est des logs, il semble bien que c'est le fencing qui pose problème.  
+la machine-proxmox1 (qui est node 2 si je lis bien) disparait, et donc machine-proxmox2 essaye le fencing.  
+On voit bien qu'il échoue en boucle, dans ce cas là, aucun service HA ne se lancera. En effet, le cluster considère qu'il ne peut pas être sûr que la node est vraiment "morte", et donc que peut être les VM tournent encore dessus. Pour éviter des corruptions sur le disque de données synchronisé (DRBD, NFS, SAN, ...), le cluster ne peut pas relancer les VM en HA tant qu'il n'est pas sûr que l'hôte est down.  
+
+Après, si ton fencing marche quand tu débranches des câbles, et pas en cas de coupure de courant, il faudrait peut être brancher ta carte ILO sur une alimentation séparée ? Voir avec un onduleur séparé ?  
+Est ce que en lançant un fencing à la main avec le fence_agent ça fonctionne bien ? Même si le courant est coupé ?  
+
+En tout cas, ton problème semble venir de là :)
+
+Bon courage
+
+A plush'
+
+Victor

content/comments/cluster-proxmox-distant-1.4-concept/9.md

@@ -0,0 +1,18 @@
+email: gerard.ormieres@free.fr
+date: 2013-02-04T14:49+01:00
+author: Gégé
+website:
+replyto: 4md
+
+Hello aussi,
+
+j'ai desalimenté un node ,puis j'ai tenté le fencing de ce node en essayant:  
+    fence_node machine-proxmox1
+mais j'ai un retour failed   
+quand je l'execute machine allumée c'est OK.
+
+Ah Dur! Dur! le fencing  
+je sens que j'y suis presque mais il me manque toujours un petit truc pour valider un HA digne de ce nom  
+en tout cas merci pour ton aide  
+
+Gégé

content/comments/cluster-proxmox-distant-2.4-construction-cluster/0.md

@@ -0,0 +1,6 @@
+email: ebourg@apache.org
+date: 2013-02-15T23:40+01:00
+author: Manu
+website:
+
+Question bête, est-ce qu'on pourrait faire la même chose avec IPsec à la place d'OpenVPN ? Il me semble que dans ce cas il n'y aurait plus de distinction client/serveur. On aurait alors 3 liens symétriques entre les machines du cluster.

content/comments/cluster-proxmox-distant-2.4-construction-cluster/1.md

@@ -0,0 +1,19 @@
+email: courriel@victor-hery.com
+date: 2013-02-14T14:51+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 0md
+
+Hello,  
+Je connais moins IPSec qu'OpenVPN, mais j'avais fait des tests avec il y a quelques temps. Le principal problème que je rencontrais est qu'IPSec est difficile à interfacer avec un bridge. Or, Proxmox fonctionne principalement sur ce type de système. En plus à l'époque c'était Proxmox 1.X, dont le système de cluster était de type maitre/esclave, moyennement adapté à IPSec.  
+Sur Proxmox V2 et dans l'optique de ce cluster, je vois plusieurs soucis à utiliser IPSec :   
+ - Il faudra faire passer du Multicast dans le tunnel. Pas sûr de voir comment faire avec IPSec, il faudrait chercher la viabilité et la possibilité de router le multicast à travers le tunnel  
+ - En montant un vrai "triangle" IPSec, il y aurait un risque de spanning tree je pense (je l'ai rencontré en faisant un triangle OpenVPN au début). IPSec peut-il gérer ça ?  
+ - Pour IPSec, il faut déclarer chaque plage d'IP qui est derrière le tunnel, donc impossible de mettre les même plages de chaque côtés, ce qui risque de compliquer le basculement des machines en HA, à moins de prévoir un canal de communication exprès pour la gestion du cluster (ce qui n'est pas déconnant je l'accorde :) )  
+ - Dans mon cas particulier où l'arbitre est juste une machine virtuelle dans un coin, il y a le problème du NAT, jamais très apprécié par IPSec. Ce problème ne se pose pas si les 3 machines sont de vrais serveurs avec IP publiques  
+ - Globalement, je n'aime pas trop IPSec, que je trouve plus complexe et moins robuste qu'OpenVPN (trop de contraintes...) (Pas de troll ! :D)  
+ - Le système avec OpenVPN fonctionne plutôt bien, en étant simple à mettre en place ;)  
+
+Cependant si tu as des arguments, j'aimerai les entendre, je suis amené à utiliser IPSec de temps en temps, et si je peux améliorer mes connaissances dessus je suis preneur ! (De même que pour améliorer ces tutos ;) )
+
+A plush'

content/comments/cluster-proxmox-distant-2.4-construction-cluster/10.md

@@ -0,0 +1,6 @@
+email: prigent.yohann@gmail.com
+date: 2013-06-23T21:35+01:00
+author: Yohann P
+website:
+
+Hello ! A quand la suite ? j'ai hâte, super bien expliqué !

content/comments/cluster-proxmox-distant-2.4-construction-cluster/11.md

@@ -0,0 +1,13 @@
+email: fabrice.cardinale@adi-informatique.fr
+date: 2013-09-20T11:51+01:00
+author: Fabrice
+website: www.adi-informatique.fr
+
+Bonjour,
+
+La réplication entre les cluster se fait combien de fois par jours? La HA éteint-elle la VM ou elle reste allumé comme la solution de Fault Tolerance chez VMWare avec un VCPU?  
+Peux ton faire de la HA en direct avec un cable réseau entre deux machines comme le fait les NAS Synology?
+
+Cordialement
+
+Fabrice

content/comments/cluster-proxmox-distant-2.4-construction-cluster/12.md

@@ -0,0 +1,20 @@
+email: courriel@victor-hery.com
+date: 2013-09-20T14:17+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 11md
+
+Bonjour,
+
+Pour répondre à tes questions :   
+1) Avec le système DRBD, la réplication se fait en temps réel, car DRBD permet de faire un système de RAID 1, mais via le réseau. Du coup, tout ce qui est écrit à droite est immédiatement écrit à gauche, à la latence prêt.  
+Ici, dans le cadre d'un cluster distant, la réplication se fera comme si on utilisait un disque de vitesse égale à la bande passante (pour simplifier). Il est donc préférable de ne pas mettre de machines trop gourmandes en I/O. Pas de souci par contre pour une configuration de ce type sur un réseau local (en gigabits)  
+
+2) L'idée du HA est que la machine soit basculée sans coupure. Dans les faits avec ce système, c'est effectivement le cas, la machine bascule sans se rendre compte qu'elle a changée de côté. Il y a par contre forcément une latence pour la joindre (le temps que les ARP se recalent). Cette latence est de nouveau beaucoup plus limitée en cas de configuration sur un réseau local, et quasi nulle si on peut disposer d'IP failover.
+
+3) Du coup, découlant de mes réponses au dessus oui, on peut tout à fait faire ça avec un câble en direct :)  
+C'est même beaucoup plus performant, et on peut se passer de toute la partie OpenVPN puisque le réseau est direct (l'intérêt de l'OpenVPN étant principalement de donner la possibilité de faire du multicast sur Internet de manière propre, et de chiffrer la discussion DRBD). Par contre du coup, ce qui t'intéresserait plus, c'est la config du DRBD, qui est la suite de ces articles (Et qui arrivera un jour, je ne désespère pas ! :s)
+
+A plush'
+
+Victor

content/comments/cluster-proxmox-distant-2.4-construction-cluster/13.md

@@ -0,0 +1,7 @@
+email: nicolas@paccaud.com
+date: 2013-10-02T18:27+01:00
+author: Nicolas
+website: www.np-solutions.fr
+
+Bravo pour cette série d'article. Cependant quand est-il de la suite ? (qui m'intéresse le plus au final, histoire de comparer nos pratiques :) )
+Merci

content/comments/cluster-proxmox-distant-2.4-construction-cluster/14.md

@@ -0,0 +1,10 @@
+email: kriss.free@free.fr
+date: 2013-10-04T11:21+01:00
+author: Kriss
+website:
+
+Mama mia, on attend avec impatience les articles suivants. Peut-être en rajoutant une 25è heure à tes journées? :)
+
+Une question: les fonctionnalités de cluster et de HA sont-elle spécifiques à Proxmox, ou bien sont-ce des fonctionnalités offertes par openvz/kvm (voire par d'autres packages)? Dit différemment, pourrait-on faire la même chose sans proxmox?
+
+Je pose la question car c'est toujours intéressant de garder une certaine autonomie par rapport à une solution dont la société porteuse Proxmox AG a une politique pas forcément très visible ou pérenne.

content/comments/cluster-proxmox-distant-2.4-construction-cluster/15.md

@@ -0,0 +1,16 @@
+email: ibasaw@gmail.com
+date: 2014-01-16T17:24+01:00
+author: ibasaw
+website:
+
+Bonjour,
+
+Super intéressant !
+
+Faudra que j'essaye de faire tout le tuto !!!!
+
+J'attend la suite avec impatience, vu que je n'y connais rien du tout.
+
+Est ce prévu ou c'est un projet abandonné ?
+
+++

content/comments/cluster-proxmox-distant-2.4-construction-cluster/17.md

@@ -0,0 +1,8 @@
+email: giraudsa@gmail.com
+date: 2014-05-27T19:38+01:00
+author: giraudsa
+website: https://www.chronosave.com
+
+Bonjour et merci beaucoup pour toutes ces explications. Effectivement, on attend la suite :)
+Une petite question me taraude, je n'ai peut être pas bien saisi la différence, mais serait il possible de faire la même chose avec Ceph plutôt que DRDB ? En fait, je ne comprends pas bien la différence entre ces deux solutions ?!  
+@+

content/comments/cluster-proxmox-distant-2.4-construction-cluster/18.md

@@ -0,0 +1,9 @@
+email: courriel@victor-hery.com
+date: 2014-07-17T17:44+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 17md
+
+Bonjour,  
+Je ne connais absolument pas Ceph, du coup il m'est impossible de te répondre de manière construite ^^"  
+Si Ceph permet également de synchroniser 2 partitions entre 2 serveurs via le réseau, j'imagine qu'il devrait pouvoir faire le job

content/comments/cluster-proxmox-distant-2.4-construction-cluster/19.md

@@ -0,0 +1,8 @@
+email:
+date: 2015-03-12T21:58+01:00
+author: Cédric
+website:
+
+Bonjour et un grand merci pour ce tuto vraiment bien expliqué.
+
+La suite se fait toujours attendre.

content/comments/cluster-proxmox-distant-2.4-construction-cluster/20.md

@@ -0,0 +1,48 @@
+email:
+date: 2015-10-25T12:52+01:00
+author: NL
+website:
+
+Super article !
+
+je m'en suis servi pour créer un LAN entre mes 2 hyperviseurs qui ont uniquement un eth0 sur internet (serveurs SOYOUSTART ovh).
+
+J'ajouterais  qu'il est possible de faire du VLAN tagging sur l'interface VPN tapX et les bridger sur les VMs . Cela permet d'avoir des LAN étanches pour les VMs si on veut cloisonner certaines VMs.
+
+    # cat /etc/modules-load.d/8021q.conf
+    8021q
+
+Du coup voici un update de up.sh qui va créé un VLAN 10 et VLAN 20 sur lequel j'associe 192.168.10.X et 192.168.20.X.
+(les tapX.10 et tapX.20 peuvent etre mise a 0 une fois les tests validés et que tout fonctionne).
+
+    # Legacy - TAP1 generic encapsulé dans le bridge vmbr1
+    /sbin/ifconfig vmbr1 promisc
+    /sbin/ifconfig tap1 up promisc
+    /usr/sbin/brctl addif vmbr1 tap1
+    /sbin/ifconfig tap1 0
+
+    # CONF VLAN (VM)
+    vconfig add tap1 10
+    vconfig add tap1 20
+    brctl addbr br10
+    brctl addbr br20
+    brctl addif br10 tap1.10
+    brctl addif br20 tap1.20
+    ifconfig tap1.10 promisc
+    ifconfig tap1.20 promisc
+    ifconfig tap1.10 up
+    ifconfig tap1.20 up
+    ifconfig br10 192.168.10.1
+    ifconfig br20 192.168.20.1
+
+idem pour le client avec 10.2 et 20.2
+
+Enfin je recommande l'usage d'une VM pfsense qui fait office de GW  pour toutes les VM (FW+NAT+routage) en ayant une  NIC dans chaque bridge.
+
+Sinon promox; je trouve trop usine a gaz, surtout avec le fuse sur /etc/pve et le symlink de /root/.ssh/authorized_keys vers /etc/pve et enfin le kernel modifié. Ca reste trop intrusif et on perd la flexibilité de la libvirt.
+
+Je recommande libvirt avec webvirtmgr ou webvirtcloud qui est très simple, interface épurée. RIEN à installer sur les hyperviseurs à part la libvirtd configuré pour le TCP.  
+Partage storage en GLUSTERFS of course !  
+Et le monitoring avec XYMON.  
+
+Encore merci pour ce partage !

content/comments/cluster-proxmox-distant-2.4-construction-cluster/3.md

@@ -0,0 +1,8 @@
+email: guillaume.melon@gmail.com
+date: 2013-02-21T15:33+01:00
+author: Guillaume
+website:
+
+Hello,
+
+Perso j'ai plutôt choisis une solution OpenVPN sans certificats avec simplement des clés partagées. Avantage on suprime monsieur l'arbitre ( SPOF ) !  Configuré en mode tap entre chaque serveur avec un up.sh qui ajoute l'interface tap0 tap1 un sur une interface bridge, Au final la configuration est plutôt simple et efficace d'après moi.

content/comments/cluster-proxmox-distant-2.4-construction-cluster/4.md

@@ -0,0 +1,12 @@
+email: courriel@victor-hery.com
+date: 2013-02-22T13:56+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 3md
+
+Hello,  
+Dans la configuration du tuto, l'arbitre n'est pas un SPOF, puisque s'il tombe, ça ne stoppe pas les services. L'objectif de l'arbitre est uniquement d'avoir un nombre impair de nodes, ce qui est nécessaire dans le cluster pour prendre des décisions automatiquement (je ne parle pas de la possibilité de forcer 2 nodes, qui n'est pas cohérent ici :) )  
+Ceci dit, ta solution m'intéresse, que veux tu dire par utiliser OpenVPN avec des clefs partagés ? L'ajout des interfaces tap a l'air d'être à peu près ce que je fais ici, mais si tu as seulement 2 serveurs, je ne saisis pas bien quel est l'avantage ?  
+De la même façon, si tu peux détailler pourquoi tu penses que l'arbitre est un SPOF, ça m'intéresse, j'ai peut être loupé quelque chose dans mon concept, je suis pas infaillible ;)  
+
+A plush'

content/comments/cluster-proxmox-distant-2.4-construction-cluster/5.md

@@ -0,0 +1,22 @@
+email: guillaume.melon@gmail.com
+date: 2013-02-28T16:02+01:00
+author: Guillaume
+website:
+replyto: 3md
+
+Hello,
+
+Toute mes excuses j'ai du lire le tuto en diagonale !  Finalement la seule différence entre nos configurations est l'utilisation pour ma part de openvpn un plus simplement.
+
+Je crée une clé partagé avec la commande  
+    openvpn --genkey --secret static.key
+
+Cette clé est présente sur chaque serveur et identique, ensuite dans la conf client ou serveur il suffit de mettre l'option "secret /etc/openvpn/static.key".   
+Ca évite de gérer les certificats.
+
+Au niveau de la sécurité on peut il me semble générer des clés plus robuste.
+
+Je pense que le choix entre ces deux solutions dépend de l'importance du projet.
+
+Plus d'info sur le site:  
+http://openvpn.net/index.php/open-source/documentation/miscellaneous/78-static-key-mini-howto.html

content/comments/cluster-proxmox-distant-2.4-construction-cluster/6.md

@@ -0,0 +1,7 @@
+email: guillaume.melon@gmail.com
+date: 2013-02-28T16:16+01:00
+author: Guillaume
+website:
+replyto: 3md
+
+En tout cas ! Félicitation pour ce tuto qui je pense est le plus complet dans la langue de Molière ! J'attend avec impatience de voir comment vous abordez la gestion du stockage drbd ! Personnellement je préfère attendre la version 9.1 qui permettra la mise en place de plus de deux noeuds primaires simultanément. En attendant je suis passé sur une solution ceph. Bonne continuation pour vos articles !

content/comments/cluster-proxmox-distant-2.4-construction-cluster/7.md

@@ -0,0 +1,9 @@
+email: jufoyer@laposte.net
+date: 2013-06-12T12:11+01:00
+author: FOYER Julien
+website:
+
+Bonjour,  
+Tout d'abord merci pour se tuto. afin de continuer et faire des tests j'aurais une question pour DRDB vous utiliser une interface réseau particulière j'ai lu a plusieurs reprise qu'il lui faudrait une interface réseau dédié pour la réplication ?  
+Si quelqu'un peut m'aiguillé ou me dire si il faut utilisé VMBR1 dans la configuration de drbd. Merci d'avance.  
+Cordialement et bonne continuation.  

content/comments/cluster-proxmox-distant-2.4-construction-cluster/8.md

@@ -0,0 +1,20 @@
+email: courriel@victor-hery.com
+date: 2013-06-17T12:13+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 7md
+
+Bonjour Julien,
+
+Pas de soucis pour le tuto :)  
+Et désolé pour mon temps de réaction longuet.
+
+Pour répondre à ta question, dans une configuration idéale, il vaut mieux en effet avoir une interface dédiée pour DRBD, histoire d'avoir le meilleur débit possible tout en ne paralysant pas les interfaces habituelles de l'hyperviseur.  
+Cependant dans le cadre du tuto, on a uniquement une connexion Internet entre les 2 serveurs (cluster Distant entre 2 data center), et donc on va être obligé d'utiliser vmbr1 pour cette liaison, à travers le VPN monté dans la partie 2.  
+Le débit n'est pas du coup pas exceptionnel et peut provoquer quelques latences au niveau des VM (si tu en as beaucoup ou si elles ont des BDD lourdement utilisées).  
+Dans les faits je n'ai pas constaté de réels ralentissement avec une dizaine de KVM faisant du VPN et du site web interne.  
+En data center on peut s'attendre à quand même 100Mbps de débit (théorique), c'est normalement suffisant pour s'amuser un peu ;)  
+
+J'espère t'avoir répondu.
+
+A plush' !

content/comments/cluster-proxmox-distant-2.4-construction-cluster/9.md

@@ -0,0 +1,12 @@
+email: rochdi@fogits.com
+date: 2013-06-17T16:47+01:00
+author: ROchdi
+website:
+
+Bonjour,
+
+Super ton tuto :)
+
+Est ce que on va voir très prochainement la publication des parties restantes ?
+
+Rochdi

content/comments/construisez-tunnel-ssh/0.md

@@ -0,0 +1,6 @@
+email: alban.ermope@hotmail.fr
+date: 2015-10-26T12:23+01:00
+author: Alban
+website: 
+
+Pendant un moment j'ai cru qu'il s'agissait d'un tuto pour s'échapper de prison ^^