Migration de serveur mail

[rudddy]

Bonjour,

Je voudrais séparer les services de mon serveur web, dont le domaine est domaine.tld
mon serveur commence à surcharger, je voudrais donc migrer mon mail et mon mysql vers un autre serveur plus puissant

Commençons par le mail. je ne sais pas trop quelle procédure suivre. j'ai pensé à :

1- configurer le nouveau serveur (via webmin) pour ce domaine
2- créer les adresses email existantes (conserver les mêmes codes)
3- su le plesk du premier serveur, rediriger l'entrée MX du dns vers l'ip du 2ème serveur

qu'en pensez-vous ?

[dmathieu]

Bonne pioche ! Ainsi, tant que les DNS ne sont pas remis à jour tu a toujours tes mails qui sont redirigés par l'ancien serveur.

[rudddy]

Bonne pioche !

wopaaaaa du premier coup en plus !!!
je suis devenu administrateur serveur !!

sinon, en tant qu'admin diplomé, je pose une question, comment je configure le nouveau serveur dans webmin, je dois créer un nouveau domaine avec ovhm ?

[dmathieu]

La tu m'en demande trop. J'utilise Google Apps sur tous mes domaines

[rudddy]

merci qd même

[jcaron]

Il y a des variations suivant que tu es tout seul à recevoir du mail ou pas, que tu laisses ton mail sur le serveur ou pas, les softs de mail utilisés (sendmail, postfix...), etc.

Idéalement:

- tu réduis le TTL sur l'enregistrement DNS de ton MX et/ou du A qui correspond à 300 secondes (à faire <valeur actuelle de ton TTL> secondes avant la migration)
- tu configures le nouveau serveur de mail pour recevoir les mails pour ce domaine, avec tous les comptes, alias etc. qui vont bien.
- tu arrêtes ton serveur de mail sur la machine d'origine
- tu déplaces/copies le contenu de toutes les boîtes si nécessaire
- tu changes le MX et/ou le A associé
- tu configures ton serveur de mail d'origine pour qu'il accepte de relayer le mail pour le domaine, mais pour qu'il ne l'accepte plus
- tu t'assurer que le serveur de mail d'origine résoud correctement le MX (i.e. qu'il est à jour). Si tu utilises un named local, tu peux le relancer, par exemple.
- tu relances le serveur de mail d'origine
- tu remontes le TTL

Sans ça tu cours le risque (pas forcément gênant suivant le nombre de personnes qui reçoivent du mail) de recevoir une partie du mail d'un côté et une partie de l'autre. Il y a aussi le problème du mail envoyé par ton serveur web vers ton domaine qui continuerait à être reçu sur l'ancienne machine.

Jacques.

[rudddy]

si je change
mail.domaine.tld. A 91.xxx.xx.xx
en
mail.domaine.tld. A 122.xxx.xx.xx

c'est pas suffisant ?

[jcaron]

Si tu ne fais que ça, pendant la durée du TTL certains serveurs vont continuer à envoyer le mail pour ce domaine à l'ancien serveur, pendant que d'autres vont l'envoyer au nouveau. Et assez vraisemblablement, tout le mail émis par le serveur (formulaires de contact, par exemple) à destination de ce domaine continuera à être livré sur l'ancien serveur.

Jacques.

[rudddy]

le risque n'est que de quelques secondes, ou bien le problème risque de perdurer pour les mails internes au serveur (form de ocntact, ...) même après ce TTL ??

[jcaron]

Par défaut le TTL n'est pas de quelques secondes, mais plutôt de 24 heures ou plus...

Et si tu ne changes rien à la config de ton serveur de mail d'origine, sauf cas particulier (client mail qui cherche directement le MX tu serveur de destination plutôt que d'envoyer à son serveur de mail "local"), les mails générés localement sur le serveur risquent de continuer à rester sur ce serveur. Le script envoie au serveur local, qui est configuré pour recevoir le mail pour le domaine, donc il ne va pas chercher plus loin pour savoir s'il doit le transmettre à quelqu'un d'autre plutôt. Ca dépend probablement du serveur de mail employé (sendmail, postfix, qmail...) et de sa config, ceci dit.

Jacques.

[rudddy]

oulala ca commence à devenir compliqué

je sais que je suis sous qmail

pour résoudre les problèmes des mails internes, quelle solution envisages-tu ?

[jcaron]

Je n'ai jamais utilisé qmail, donc je ne vais pas pouvoir t'aider, mais il s'agit juste de changer la config (au bon moment) pour qu'il sache que le domaine en question n'est plus "local", et de vérifier qu'il trouve bien la nouvelle valeur du MX (cf instructions plus haut). Là il se contentera de relayer le mail vers la bonne destination, comme n'importe quel mail vers l'extérieur.

Comme je disais précédemment, idéalement tu veux (temporairement) l'autoriser à relayer les mails pour ce domaine même s'ils viennent de l'extérieur, comme ça s'il y a encore des mails qui atterissent de ce côté-là ils seront relayés, sinon ils seront rejetés.

Jacques.