Catégories
Debian mails planet-libre.org

mailing-lists multi-domaine avec mailman sur un postfix « virtuel » (mysql)

Nouvel article pour compléter tous ceux sur l’installation d’un serveur de mails bien complet (voir ces tags).
Cette fois il s’agit d’ajouter un outil de gestion de mailing-lists avec inscription, désinscription, modération etc.
Bref, au choix, je pensais à « sympa » (dont j’ai déjà un peu parlé) ou mailman, que je ne connaissais pas.

  • « sympa » en mode multi-domaine, arrêtez-moi si je me trompe, sur une installation postfix « virtuelle » (utilisateurs en base MySQL), c’était loin d’être gagné. Mal documenté à mon goût sur la partie multi-domaine.
  • « mailman » semblait pouvoir faire tout ça, avec une interface web (et ligne de commande) assez ancestrale, mais suffisante, efficace et qui marche 🙂

Deux points de détails à bien regarder, qui m’ont fait faire cet article afin de ne pas oublier tout ça et que ça puisse resservir :

  • l’interconnexion de mailman avec la partie Mysql de postfix
  • le multi-domaine, afin de pouvoir gérer des listes genre liste1@domaine1.fr et liste2@domaine2.com, ces 2 domaines étant hébergés sur la même machine, la même installation postfix

Allez hop, c’est parti pour l’installation et les détails de configuration.
Voyez d’abord mes articles sur l’installation complète postfix/mysql/amavis/spamassassin/etc histoire de situer de quoi je parle.

Catégories
autres outils Debian mails planet-libre.org

Pense-bête pour migrer « sympa », l’outil de mailing-lists

Salut,

J’ai eu à déplacer l’outil sympa – très bien pour gérer des mailings-lists avec modération – d’un serveur à un autre.
L’outil était sur le backend de mail, avec la conf apache de sympa, la base de données de sympa et évidemment les binaires (le package sympa).
Le but était de déplacer la partie binaire, apache et base de données ; en conservant les boîtes mails et alias sur le backend de départ.

Je vous livre un petit retour d’expérience car c’est un poil plus compliqué que de déplacer une application LAMP classique.
Je partais d’une version Debian/stable, donc package sympa 5.2.3-1.2+etch1 et la cible était la même.

Je considère que vous avez déjà un Apache2 et MySQL sur la machine cible – et une machine cible capable de relayer des mails (recevoir et envoyer) sur postfix

La migration classique

La base reste la même :
1) Sur la machine cible, installez l’application – même version évidemment, packagée.
2) Reprenez (à la main ou en écrasant) la conf /etc/apache2/conf.d/sympa d’un serveur à l’autre
3) Reprenez ou adaptez /etc/sympa
4) Exportez/importez la base de données « sympa », comme une brute, par exemple :

machine_depart:$> mysqldump -u votre_user_qui_va_bien -p -B sympa > migr_sympa.sql
puis
machine_cible:$> mysql -u user -p < migr_sympa.sql

5) Assurez-vous d'avoir les bons identifiants de login de l'application sympa dans les tables "mysql" de Mysql (= les tables du schéma mysql. Pigé ? il doit y avoir notamment une ligne dans la table mysql.user concernant le User sympa) :

use mysql ; SELECT * from user where User = 'sympa';

La partie spécifique "sympa"

Ce qui est ci-dessus est ce que vous auriez à faire avec une appli LAMP typique qui stocke tout en base.
Manque de chance, sympa - au moins dans la version 5.2 (actuellement 5.4 dispo, pas essayé) - stocke tout un tas d'informations dans /var/lib/sympa, /usr/lib/sympa etc. Sans compter les alias mails qui permettent de transmettre les mails aux processus de gestion de sympa.
Donc il vous reste à faire :

La redirection des alias mail

Normalement, sur votre serveur de départ, vous devriez avoir tout un tas d'alias de mail dans /etc/aliases, genre :

sympa:             "| /usr/lib/sympa/bin/queue sympa"
listmaster:        "| /usr/lib/sympa/bin/queue listmaster"
sympa-request:     postmaster
sympa-owner:       postmaster
maliste1:          "| /usr/lib/sympa/bin/queue maliste1"
maliste1-request:  "| /usr/lib/sympa/bin/queue maliste1-request"
maliste1-owner:    "| /usr/lib/sympa/bin/bouncequeue maliste1"
maliste2.....

Il faut reprendre cette configuration telle quelle sur la machine cible et s'assurer sur la première - qui reste la machine de backend de mail (mon MX en gros), donc celle qui reçoit le mail - qu'elle sache faire suivre tout ça à la machine cible qui est devenue celle qui gère sympa.
Donc dans la machine de départ, vous trafiquerez tout de la sorte :

sympa:             "sympa@machinecible.com"
listmaster:        "listmaster@machinecible.com"
sympa-request:     postmaster (j'ai laissé tel quel, c'est un choix)
sympa-owner:       postmaster (j'ai laissé tel quel, c'est un choix)
maliste1:  "maliste1@machinecible.com"
maliste1-request:  "maliste1-request@machinecible.com"
maliste1-owner:  "maliste1-owner@machinecible.com"
maliste2.....

A la recherche du bordel éparpillé partout

Ensuite, je m'étais arrêté là - ahahah, erreur.
Sur l'interface web (la nouvelle), je ne voyais plus mes listes. La raison est que "sympa" stocke les listes, les archives etc hors de la base, dans des répertoires comme /usr/lib/sympa et /var/lib/sympa.
Donc, il faut reprendre tout ça sur la machine cible (des bêtes "tar" avec conservation des permissions suffisent).
Finalement, j'ai opté pour un joli :

dpkg -L sympa | less

De là, je suis passé dans tous les répertoires nommés (sauf les doc, le "man" etc - faut pas pousser) et je me suis assuré qu'il n'y ait pas de différence - attention à certains droits en setuid/setgid au nom de "sympa:sympa".

Ensuite, vous envoyez la purée auprès de vos utilisateurs pour leur indiquer que le système est à nouveau dispo, sur une liste modérée tant qu'à faire, afin de bien faire tous les tests.
Si rien n'arrive, c'est pas grave, vous avez raté un truc.
Si vous recevez la demande de modération, c'est que ça semble bien parti 🙂

Le nettoyage

Lorsque vous ferez le DROP DATABASE sympa sur l'ancienne machine et le aptitude purge sympa, ça vous confirmera ce que je vous racontais sur le stockage des archives, des listes etc :