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

• Voir en français : https://www.koumbit.org/fr/content/comment-migrer-une-boite-de-courriel-chez-koumbit

• Voir en anglais : https://www.koumbit.org/en/content/how-migrate-mailbox-koumbit

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

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:

• qmail + vpopmail : voir les scripts dans ssh://git@git.koumbit.net/migrate_qmail_to_alternc.git sous le projet Clients > 514 Hébergement

• autres sources: TODO -- besoin de scripter l'extraction et la céation via l'API d'AlternC ou alors vers un format sql compatible à AlternC

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:

• roundcube : Utiliser le script dans koumbit-scripts] et suivre les instructions de setup dans le texte en haut du script.

• autres sources: TODO -- besoin de scripter l'extraction vers un format compatible avec roundcube

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.

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

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

• pour debian: https://imapsync.lamiral.info/INSTALL.d/INSTALL.Debian.txt

• aussi disponible pour archlinux (AUR)

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!!

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

• --dry : Just print output. Do nothing
• --justlogin : Just login to both host1 and host2 with users credentials, then exit.
• --justconnect : Just connect to both servers and print useful information. Need only --host1 and --host2 options.

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:

• Assurez vous d'avoir les mêmes configurations entre les 2 serveurs dovecot:

  • section namespace inbox pour les separator et prefix

  • activer les plugins de compression comme documenter dans DovecotConfiguration

• La commande a planté à cause des configurations de sieves qui sont présente, en supprimant la configuration de sieve sur l'origine la syncronisation se fait bien.

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

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

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.

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 :

• Les listes mailman ne sont pas effacées : il faut demander aux clientEs si iels veulent conserver les archives. Les listes sont inutilisables sans MX, mais elles sont encore là.
• Les courriels systèmes (ex.: catchall) ne sont pas effacés. C'est un problème parce que si on vient de faire le changement de MX pour "abc.org" et qu'un client Koumbit écrit à "abc.org", alors le catchall peut ramasser ce courriel et le livrer ... probablement à /dev/null. Oups !

  • les catchall sont gérés depuis la page Gestion de la configuration du Catch-All (accessible depuis le bouton juste à droite de celui pour ajouter un courriel). Si GESMX=0, alors le menu courriels n'est plus là, donc plus de bouton! Mais on peut y accéder quand même par l'URL en donnant le bon domaine ID en param: https://alternc.exemple.org/mail_manage_catchall.php?domain_id=XXX

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!

Procédure de migration de courriels d'un compte HAG vers un autre compte HAG

Voir https://wiki.koumbit.net/HagMaintenance/MigrerEntresComptes#Migration_des_courriels

CategoryMigration CatergoryProcedure