Mettre en place des sauvegardes redondantes de MX et NS entre plusieurs panneaux de contrôles DTC

  • 1. Pourquoi dois-je sauvegarder les MX et NS?

Un des services les plus importants dont vous avez besoins, est un serveur MX failover (un serveur MX est simplement un serveur SMTP qui reçoit les mails pour votre domaine). Votre service d'hébergement web peut être down, mais à aucun moment votre service mail doit être hors service, et pourquoi la plupart des serveurs mette en place une redondance.

Lorsque qu'un serveur SMTP envoie un mail vers un autre serveur SMTP, il regarde l'enregistrement MX du domaine sur lequel le mail est envoyé. Cela veut dire qu'il envoie une requête DNS sur le panneau de contrôle DTC pour lequel il veut envoyer un mail. Si ce domaine est down, alors il devrait envoyer le mail sur le MX de secours, c'est d'ailleurs pourquoi vous devez avoir un serveur NS des secours si vous désirez un MX de secours.

De plus, vous devrez faire en sorte que le serveur de secours ne soit pas sur le même réseau que votre serveur principal, autrement c'est un serveur de secours, et pas un réseau de secours (et votre réglage est à moitié bon, à moitié mauvais). Ce qui est sympa ici, c'est que si vous avez un ami qui à un serveur géré via DTC, vous pouvez lui demander si vous pouvez échanger vos backup de services NS/MX, de ce fait c'est plutôt sure et sécurisé.

  • 2. Vérification d'IP, identifiant et mot de passe: pourquoi et comment ?

Nous parlons donc du champs 'Autoriser les serveurs suivants à lister les domaines pour les backuper'.

Le serveur de sauvegarde que vous aller utiliser doit connaitre le noms de des domaine pour lesquels il va assurer le secours. Cette liste est transféré avec le protocole HTTPS. S'il y a bien une chose que la plupart des serveurs ne veulent pas, c'est dévoiler au monde la liste de leur clients (et pour cause). C'est pour cela qu'il y a à la foie une vérification d'IP checks, et des identifiant et mot de passe.

La voie la plus simple est d'utiliser un même login/pass de chaque côté (Sur le serveur final et sur le serveur de secours), de cette façon vous ne les mélangerez pas. En fait, dans la dernière version (en date) de DTC, vous DEVEZ régler la vérification IP des deux côtés avec le même identifiant et mot de passe, autrement la mise à jour va échouer. Puisqu'il s'agit du mot de passe vous ne l'utiliserez qu'une fois lors de l'installation, nous vous suggérons d'en générer un automatiquement via le générateur de DTC (l'icône d'engrenage).

Une foie que vous avez réglez les mots de passe et identifiants sur chaque serveur (le maître et l'esclave), vous devez saisir l'IP du serveur. L'IP que vous allez utilisez n'est autre que l'IP 'maître' de votre serveur (regarder eth0 par exemple). Ce n'est certainement pas l'IP du panneau de contrôle elle-même, et ce n'est pas non plus les IP de vos NS1/NS2. C'est l'IP que php va parcourir avec, la plupart du temps la première IP de votre config lorsque vous tapez ifconfig sur le shell. Ce peut être une IP différente, faites donc attention.

  • 3. Editer votre /etc/hosts

Cette étape n'est pas obligatoire, mais recommandée.

La chose la plus commune est de régler ns1/ns2 du même domaine sur des serveurs différents. Si vous faites cela, souvenez vous que vous devez régler /etc/hosts avec l'IP de votre autre serveur (des deux côtés), autrement il n'y aura aucune possibilité pour le script de télécharger la liste des domaines à télécharger (il est nécessaire de télécharger la liste pour être en mesure de sauvegarder celle-ci). Ce dont nous avons besoins ici est de dire 'dtc.backup.your-domain.com' sur le serveur 'dtc.main.your-domain.com', et 'dtc.main.your-domain.com' sur 'dtc.backup.your-domain.com'. En d'autres termes, votre serveur doit connaître l'IP de celui avec lequel il doit dialoguer. Ce devrait donner quelque chose comme:

   root@GPLHost:testVPS>_ ~# cat /etc/hosts
   # Local loopback
   127.0.0.1       localhost.localdomain   localhost
   # My own IP
   1.2.3.4         testvps.gplhost.com
   # The IP of the control panel that will do backup MX.
   203.174.86.120  dtc.node6503.gplhost.com
   66.251.193.20   dtc.gplhost.com

Dans ce cas, nous voulons que le panneau de contrôle effectue une requête sur dtc.gplhost.com et dtc.node6503.gplhost.com qui sont les deux panneaux de contrôles qui vont effectuer les sauvegardes NS (ns1.gplhost.com et ns2.gplhost.com).

Si vous faites cela, c'est plus sûre, parce que vous savez que même si le DNS est en panne, c'est encore résolu, ce qui est nécessaire si vous souhaitez faire des transferts liste de domaine avant que les zones sont effectivement chargés.

Répétez cette opération sur tous vos backup NS.

  • 4. L'insertion d'URL de demande de mise à jour au serveur de sauvegarde

Une fois que les vérification IP et /etc/hosts sont réglés, vous pouvez commencer à ajouter chaque nouveau serveur. Sur le serveur "maître", vous devez entrer l'URL du premier backup dans le champs 'Prévenir les serveurs suivant quand un domaine est ajouté ou supprimer'

Si votre serveur de secours utilise Postfix, vous devrez saisir exactement la même chose dans 'Prévenir les serveurs suivant quand un email est ajouté ou supprimer'. Vous n'aurez pas besoins de le faire si votre serveur utilise Qmail, car Qmail ne peut vérifier l'existence des utilisateur lors de sauvegarde.

  • 5. Demandez au serveur de sauvegarde d'agir à titre de sauvegarde NS et MX

Sur votre serveur de secours, dans le champs 'Ce serveur servira de backup MX pour les serveurs suivants' entrer 'https://dtc.main.your-domain.com(approve sites)', saisissez le mot de passe et identifiant, et sauvegardez. Faite de même pour les DNS. Bien sûr, utilisez les même identifiants et mots de passe que ceux utilisés pour les vérification IP.

  • 6. Configuration des fichiers de zones

Vous devrez faire très attention en réglant cela. Tous les champs doivent être remplis avec les bonnes valeurs, et spécialement 'Listez ici les IPs des serveurs DNS habilités a faire des zone transfert'. Si vous ne le faite pas, votre serveur de secours NS, sera incapable de réaliser le transfert des zonefiles. Souvenez vous que les zones ne SONT PAS transférées par DTC en lui même, mais uniquement la liste des domaines. Les zones seront transférées par named, c'est donc pourquoi vous devez informer named des serveurs autorisés à réaliser des transferts.

  • 7. Derniers mots

Ce qui est expliquer ici est un système utilisant deux serveurs. Mais vous pouvez jouer avec beaucoup plus de serveurs, et avoir des sauvegardes comme vous le souhaitez, d'exploitation dont vous avez besoin. Il n'y a pas de restriction, cela peut aller de n'importe quel serveur à n'importe quel serveur, avec un nombre pratiquement illimité de serveurs de noms et serveurs MX.

De même, après avoir réaliser votre réglage, nous vous encourageons FORTEMENT à réaliser des tests. Vous devriez aller d'abord sur l'onglet 'Génération des configurations', et demander la régénération des mails et DNS, et vous pourrez donc voir la sortie dans la 'console de sortie'. Vous pouvez également cd dans DTC_PATH/admin et lancer un 'php cron.php' pour voir ce qu'il se passe. Vous pouvez aussi vérifier votre syslog après le lancement du cron: cela va afficher toutes les requêtes de transferts de fichiers de zone et les transferts en eux même. Si vous voyez que named renvoie des erreurs concernant les transferts de zonefiles, cela peut vouloir dire que vous n'avez pas correctement remplis le champs 'Listez ici les IPs des serveurs DNS habilités a faire des zone transfert' (dans l'onglet zonefile named).

Lorsque vous avez terminé le réglage, tous les domaines seront automatiquement ajoutés sur le serveur de secours pour effectuer la sauvegarde (pas besoins de faire quoi que se soit). Donc, les scripts vont essayer encore et encore jusqu'à ce que les messages soient envoyés, vous n'avez donc pas à vous occuper des erreurs réseau qui peuvent survenir (ou de tout autre chose mettant votre serveur hors service).

  • 8. Utilisez un backup de NS autre que DTC

Comme il y a parfois des raisons pour ne pas utiliser une instance complète DTC sur le serveur de noms secondaire, ou secondaire MX, vous pouvez automatiser ceci à partir d'un script comme suit.

Créer un cron à exécuter toutes les 5 (ou 10) minutes:

  /etc/cron.d/slavezoneupdate

  */5 * * * * root (/usr/local/bin/updateslavezones.sh)

Créer le script en lui même, en remplaçant DTCHOSTNAME, BACKUSERNAME et BACKUPPASSWORD:

  /usr/local/bin/updateslavezones.sh

  #!/bin/bash
  /usr/bin/wget --no-check-certificate -O /tmp/slave_zones "https://DTCHOSTNAME/dtc/list_domains.php?login=BACKUSERNAME&pass=BACKUPPASSWORD&action=list_dns(approve sites)"

  # s'assurer d'autoriser les requêtes
  /bin/cat /tmp/slave_zones | /bin/sed -e 's/\(type slave;\)/\1\n\tallow-query { any; };/' > /tmp/named.slavezones.conf

  /bin/cp /etc/bind/named.slavezones.conf /etc/bind/named.slavezones.conf.bak
  FILESIZE=0
  FILESIZE=$(/usr//bin/stat -c%s "/tmp/named.slavezones.conf")
  # ne pas écraser slavezones.conf qui fonctionne si la génération est de zéro byte
  if [ $FILESIZE -gt 0 ]; then
	/bin/mv /tmp/named.slavezones.conf /etc/bind/named.slavezones.conf
	/usr/sbin/rndc reload
  fi

Notez que ce script se trouve dans le répertoire /usr/share/doc/contrib si vous voulez le recopier.

Page last modified on October 02, 2010, at 11:41 AM EST