Procédure de migration d'une boîte de courriels sans accès par ligne de commande sur les serveurs

Procédure si on a des accès en ligne de commande sur les serveurs

Cette documentation veut être une version générique de la /VieilleDocumentation qui était trop chaotique et spécifique à certaines configurations. On décrit d'abord une procédure générale et on précise avec certains setups connus.

DNS TTLs

Cette étape est facultative, mais ça permet d'accélérer grandement la migration et ça donne aussi un chemin de retour plus rapide en cas de problème. Donc il est fortement recommandé de le faire.

Avant tout, il faut avoir le contrôle sur le DNS. Donc il est possible de devoir demander l'accès aux client.e.s ou bien de se coordonner avec leur personne tech.

Baisser le TTL à 10 minutes (600 secondes) au moins 48h avant la migration finale.

Créer une redirection pour le webmail

Cette étape là n'est nécessaire que dans quelques cas spécifiques, par exemple si on migre l'adresse IP d'un serveur mail à un autre pour éviter beaucoup de migrations DNS client. Dans la majorité des cas, on peut simplement informer les client.e.s de la nouvelle adresse de webmail.

Si on doit conserver une redirection, noter quelle est présentement l'URL du webmail et créer une redirection permanente vers la nouvelle URL du webmail.

Créer chaque mailbox et alias sur le nouveau serveur

Ici, il faut s'assurer que le serveur de destination acceptera les courriels existants sur l'ancien site. Il faut créer chaque mailbox et alias dans Alternc. TODO: scripter la création automatique via l'API d'AlternC.

Ensuite, tester la livraison locale d'au moins 1 mailbox et 1 alias.

On peut utiliser swaks pour tester l'envoi d'un courriel vers la mailbox:

swaks --to courriel@domain.tld --server new.mailserver.tld

Dans certains cas (par exemple si la gestion du DNS est déjà sur notre serveur AlternC), il est impossible de créer des boîtes courriel tant que le MX pointe ailleurs. La solution ici est de basculer le MX rapidement vers notre serveur et immédiatement après remettre l'ancien MX dans le zonefile (/var/alternc/bind/zones/example.com) sans qu'AlternC ne soit au courant du retour du MX. On peut ensuite créer les mailboxes.

Importer les mots de passe

Cette étape là n'est p-e pas toujours faisable. On suppose ici qu'on migre vers un setup AlternC.

Si la plateforme d'origine vous permet d'extraire les mots de passe des mailboxes, il faut prévoir de les extraire de l'ancienne plateforme et les réimporter dans la nouvelle.

Selon la plateforme d'origine:

AlternC -- TODO importer ça dans un script dans un dépôt git au lieu d'ici:

Cette méthode fonctionne correctement entre les versions 3.11 et 3.5. Les comptes doivent avoir été préalablement créés dans le alternC de destination, et on doit avoir accès aux deux serveurs.

Sur le serveur d'origine, créer un fichier texte contenant les courriels à migrer, un par ligne. Puis exporter les mots de passe à l'aide de ce script (adapter la variable database au besoin):

#
# Export mailbox password to file for each email listed in input file
# Output: email password (one email by line)
# Args: path to file containing emails, path to output file

if [ $# -ne 2 ]
then
echo Arguments missing \! - Usage: export_mail_pwd.sh [path_to_file containing emails one by line] [output_file]
exit
fi

database='alternc'

while read email
do
echo Processing $email
address=`echo $email | awk -F @ {'print $1'}`
domain=`echo $email | awk -F @ {'print $2'}`
password=`mysql -N --database="$database" --execute "SELECT password FROM address LEFT JOIN domaines ON address.domain_id=domaines.id WHERE address='$address' AND domaine='$domain';"`
echo $email $password >> $2
done < $1

Copier le fichier créé par le script sur le serveur de destination et rouler le script d'import (adapter la variable database au besoin):

#
# Import mailbox password to table address in alternc database
# Args: path to file containing emails and password, one by line (format: email password)

if [ $# -ne 1 ]
then
echo An argument is missing \! - Usage: import_mail_pwd.sh [path_to_file containing emails and passwords one by line]
exit
fi

database='system'

while read email_password
do
email=`echo $email_password | awk -F ' ' {'print $1'}`
password=`echo $email_password | awk -F ' ' {'print $2'}`
echo Processing $email
address=`echo $email | awk -F @ {'print $1'}`
domain=`echo $email | awk -F @ {'print $2'}`
# Update mysql
mysql --database="$database" --execute "UPDATE address SET password='$password' LEFT JOIN domaines ON address.domain_id=domaines.id WHERE address='$address' AND domaine='$domain';"
done < $1

Importer les contacts dans roundcube, au besoin

Cette étape là n'est p-e pas toujours faisable. On suppose ici qu'on migre vers un setup AlternC + roundcube.

S'il est possible d'extraire les contacts des adresses email de la plateforme d'origine, c'est bien de les migrer aussi. Pour ça il faut scripter l'export d'un côté et le réimport de l'autre, après avoir re-mappé les users et autres IDs aux bons endroits.

Selon la plateforme d'origine:

Préparer un backup de toutes les mailboxes au cas où

Cette étape-ci est importante. S'il arrive quoi que ce soit pendant la migration, ça nous prend un moyen de ramener les morceaux manquant!

Si l'ancienne plateforme a un mécanisme pour ça, roulez la job de backup maintenant.

Stopper la livraison vers l'ancienne plateforme

On est pret.e à faire la migration finale des emails. Si c'est possible, on peut fermer les services sur l'ancien serveur de courriel pour éviter que des mails se retrouvent sur l'ancienne plateforme après le sync et aussi pour éviter que des mails soient livrés sur la nouvelle plateforme pendant le sync, ce qui risquerait de les écraser.

La coupure de service de emails commence ici!

Entre ce point-ci et l'autre notice qui dit que le service revient, dans la section où on modifie le MX, on veut aller le plus vite possible.

Exemples selon la plateforme d'origine:

postfix + dovecot:

service postfix@- stop
service dovecot stop

qmail + svc + dovecot compilé manuellement:

# Vérifier la liste des services dans /service (ou autre emplacement utilisé par svc)
# pour trouver la liste des services et ajuster les éléments de la boucle.
# Vous pouvez aussi vérifier avec `ps aux | grep supervise`
#
for i in smtp smtp-ssl send spamd; do svc -d "/service/qmail-$i"; done
/usr/local/dovecot/bin/doveadm stop

S'il est impossible de stopper les services sur l'ancienne plateforme, par exemple sur une plateforme SaaS, il faut à ce moment là migrer les MX vers le nouveau serveur, mais stopper les services postfix et dovecot sur le nouveau serveur.

Pour chaque mailbox

Migrer le contenu des mailboxes IMAP, collecter les messages POP

Il y a plusieurs façon de migrer les courriels enter les serveurs.

Sans accès shell aux serveurs mais vous avez accès au mot de passe

larch

pas encore tester

  1. Installation:

    apt install larch

Pros: support le ssl, tls, pause/connection coupé

Imapcopy
  1. Installation:

    apt install imapcopy
    • N.B. imapcopy support pas le ssl/tls, mais c'est possible d'utiliser stunnel pour le faire au besoin

    • N.B. ça semble utiliser pas mal de réseau en local pour la xfer, donc il est avisé d'utiliser d'un endroit avec une connection haut débit

  2. Créer un fichier de configuration, imapcopy.cfg:

    SourceServer mail.example.com
    SourcePort 143
    DestServer mail.koumbit.net
    DestPort 143
    
    DenyFlags "\Recent"
    converttimezone "UTC" "+0000"
    converttimezone "UT"  "+0000"
    
    Copy    "info@example.com"         "password"       "info@example.com"        "password1"
    Copy    "info@x.org"            "xxxx"       "info@x.org"           "xxxx"
  3. Tester les connections:

    imapcopy -t
  4. Rouler la migration:

    imapcopy -e -s
    • N.B. C'est pas parallèle, donc tu pourrais créer plusieurs dossiers avec des fichiers de configuration pour rouler la migration des boîtes en parallèle

ImapSync

https://imapsync.lamiral.info/

Imapsync est un outils permettant de synchroniser le contenu des boîtes courriels (courriels, dossiers)

Il est disponible en 2 versions:

Version installable
Version en ligne (pour les clients)

https://imapsync.lamiral.info/X/

L'utilisation est assez simple:

pour migrer source@exemple.net vers dest12@exemple.net

imapsync \
--host1 imap.sourcehost.net --user1 source@exemple.net --password1 1ns3kure!p4ss!! \
--host2 imap.desthost12.net --user2 dest12@exemple.net --password2 1ns3kure!p4ss!!

ATTENTION!

Les mots de passe seront visible dans l'historique et dans le process en cours! On peut utiliser --passfile1 au lieu (voir man pages)

On peut utiliser plusieurs options pour faire tests au préalable:

Dovecot : si vous avez accès shell/root aux 2 serveurs de courriels

Vérifier les détails de chaque paramètres et faire des tests! Ça peut être mortel.

serveurdisnation# doveadm sync -u user@fqdn -R ssh remote_server doveadm dsync-server -u user@fqdn

Il y a quelques détails à prendre en compte:

Rsync : si vous avez un accès shell/root aux 2 serveurs de courriels

Si les formats de stockage sont différents, donc s'il ne s'agit pas de répertoires Maildir sur l'ancienne plateforme, on doit passer par un protocole commun (par exemple IMAP) en utilisant un logiciel comme imapcopy, offlineimap ou mutt au lieu de rsync.

S'il s'agit de dossiers Maildir standards, un rsync peut suffire:

rsync -rz /old/user/Maildir/ new.example.com:/path/to/user/Maildir/

(TODO: ?? le titre dit qu'on a accès ssh ... qu'est-ce que POP3 change?) Pour les boîtes POP, il faut aller chercher les mails en POP pour s'assurer qu'il ne reste plus de courriers sur le serveur.

Transférer le MX

En cas de panique totale à cette étape-ci (e.g. perdu plein de données, rien ne fonctionne, réparer les choses prendrait vraiment longtemps) vous pouvez revenir en arrière en re-pointant le MX vers l'ancien serveur et/ou en repartant les services de livraison de email sur le serveur d'origine.

Si vous n'avez pas déjà eu besoin de le faire avant le transfert des mailboxes, c'est maintenant le temps de modifier le MX pour le faire pointer sur le nouveau serveur.

Si le MX avait déjà été changé, c'est maintenant le temps de démarrer les services postfix et dovecot sur le nouveau serveur.

La coupure de service pour les emails se termine ici!

Vous devriez commencer à voir de l'activité dans /var/log/mail.log. Surveillez les erreurs là dedans et réparer les problèmes au besoin.

Bogue dans AlternC : certaines boîtes de courriels ne sont pas effacées

Quand on ferme les MX du côté d'AlternC, toutes les boîtes de courriels devraient être effacées. Cependant il va en rester :

Pour voir ça, il faut aller dans MySQL : select * from domaines where domaine = 'abc.org';

Cela vs nous permettre d'avoir la valeur d'id du domaine (ex.: 1234). Et on peut obtenir les adresses encore associées au domaine avec : select * from address where domain_id = 1234;

Et cela devrait vous donner les adresses qui restent pour le domaine et leur type.

Il est possible aussi de voir des courriels qui ont des "mail_action" de type "DELETE" ou "DELETING", ce qui n'est pas normal non plus. On peut voir ces entrées problématiques avec :

SELECT * from address WHERE mail_action="DELETE";
SELECT * from address WHERE mail_action="DELETING";

Et on peut voir d'autres entrées parfois problématiques (GESMX à 0 mais qui possède des courriels) avec :

SELECT d.id, d.gesmx, r.recipients, a.id mail_id, a.mail_action FROM domaines d, address a, recipient r where d.gesmx = 0 AND a.domain_id = d.id AND r.address_id = a.id;

Ce n'est pas toujours une erreur : les courriels Koumbit sont dans ce cas, de même que certains courriels qui doivent avoir une adresse dans AlternC mais dont les boîtes sont sur une VPS (je crois).

Évidemment, ça serait mieux de corriger le code dans AlternC, mais en attendant ...

Créer un certificat SSL pour le MX

Dans le cas où AlternC n'a pas déjà géré ce détail là, il faut créer un certificat pour couvrir le hostname qui sera utilisé par le MX.

1. Si le hostname utilisé pour le MX correspond à la configuration DEFAULT_MX dans /etc/alternc/local.sh, AlternC devrait déjà avoir créé un certificat. Sinon, on peut utiliser aternc.install pour que le certificat soit créé et installé en place.

2. Si le hostname du MX n'est pas le même que le DEFAULT_MX (ça ne devrait arriver que dans quelques cas très spécifiques), il faut étendre le certificat pour couvrir le hostname additionnel et ensuite demander à alternc.install de réinstaller le certificat:

# ici alterncmx.com correspond à la valeur dans DEFAULT_MX
certbot certonly --extend -d alterncmx.com -d nouveaumx.com
atlernc.install

Remonter les TTLs

Quand on est certain.e que la livraison et le contenu des mailboxes et tout fonctionnel, on peut remonter le TTL à la valeur par défaut d'AlternC d'une heure (3600 secondes).

La migration est maintenant terminée!


CategoryMigration CatergoryProcedure

MigrationCourriels (last edited 2024-01-05 15:31:35 by mathieul)