philpep's blog - tag postfix

Réplication de tables PostgreSQL avec londiste

Sat, 14 Aug 2010 00:00:00 GMT

Je me suis mis un petit mx secondaire, ce n'est pas vraiment utile dans mon cas, mais j'ai des pulsions d'admin en ce moment je ne peux pas résister.

Et j'ai même fait pire en termes de simplicité, ma liste d'adresse n'étant pas très mouvante répliquer les tables postgresql est vraiment inutile dans mon cas. Mais le sujet m'intéresse alors allons y.

Les besoins :

master/slave (pas d'écriture sur la table répliquée)
Quand le master tombe (même pendant plusieurs jours) on doit pouvoir lire sur le slave
Quand le slave tombe, ça ne doit pas empêcher d'écrire sur le master

Donc il me fallait un système asynchrone, facile à utiliser et à resynchroniser quand un des deux serveurs tombe.

En gros pour répondre à ces besoins il y a deux systèmes de réplication PostgreSQL, slony et londiste. Slony m'avait l'air assez complexe à utiliser, et la resynchronisation après une panne risquée, londiste fait partie des Skytools un ensemble d'utilitaires en python, dont PGQ un système de réplication des résultats basés sur les trigger postgresql.

Quand on écrit sur le master, via les trigger ça met dans une queue, et un daemon s'occupe de donner les résultat de la queue aux slaves qui le demandent (tout ce fait à travers postgresql). Du coup en termes de réseau, il faut juste que les slaves aient accès aux tables répliquées.

Une utilisation sympa de londiste, c'est pour migrer de version postgresql. Si la base est grosse, faire un pg_dump/pg_restore prend du temps et si l'application est critique et fait beaucoup d'écritures, le dump est déjà obsolète quand il est fait. Pour éviter d'avoir à bloquer l'application pendant la migration, on peut faire une réplication (vers un slave avec la nouvelle version de PostgreSQL), qui prendra son temps mais une fois finie, on aura deux base identiques (à quelques secondes près). Alors on peut faire une basculement sur le slave et la coupure du service ne dure que quelques minutes.

Moi je veux juste répliquer une table (les alias de postfix), entre mon mx primaire et secondaire, avec deux serveurs sous FreeBSD, il faut installer skytools (sur les deux) :

[root] % portmaster databases/skytools

Ensuite créer un utilisateur (ou utiliser un déjà existant).

[pgsql] % createuser -S -D -R -P replication
Enter password for new role: rirififiloulou

On va répliquer la table alias de la base postfix, il faut créer la base et la table sur le slave et donner des droits sur le master. La base et la table peuvent avoir des noms différents sur les deux serveurs (ce n'est pas le cas ici).

[pgsql] % psql -d postfix
postfix# GRANT ALL ON alias TO replication;

Autoriser la connexion du slave vers le master. (à faire sur le master naturellement)

[root] % $EDITOR ~pgsql/data/pg_hba.conf
host    postfix    replication    IP_SLAVE/32    md5

Faites en sorte que le firewall laisse passer tout ça

Depuis le slave, créez la base et copiez le schéma de la table, on en profite pour rajouter une entrée dans le ~pgsql/.pgpass pour ne plus avoir besoin du password :

[pgsql] % cat >> .pgpass << EOF
MASTER:PORT:postfix:replication:rirififiloulou
EOF
[pgsql] % createdb postfix
[pgsql] % pg_dump -h MASTER -p PORT -U replication -d postfix -t alias -s | pgsql -d postfix

Ensuite créez la configuration du daemon pgq (à lancer sur le master, avec l'user pgsql), dans ~pgsql/postfix.ini

[pgqadm]
job_name = postfix_ticker

db = dbname=postfix
# how often to run maintenance [seconds]
maint_delay = 600

# how often to check for activity [seconds]
loop_delay = 0.1
logfile = ~/%(job_name)s.log
pidfile = ~/%(job_name)s.pid

Install de pgq sur la base et lancement du daemon :

[pgsql] % pgqadm.py postfix.ini install
[pgsql] % pgqadm.py postfix.ini ticker -d

Maintenant sur le slave, configuration de londiste (toujours avec l'user pgsql), postfix.ini

[londiste]
job_name = postfix_alias

provider_db = dbname=postfix port=PORT host=MASTER user=replication
subscriber_db = dbname=postfix port 5432 host=localhost
pgq_queue_name = postfix
logfile = ~/%(job_name)s.log
pidfile = ~/%(job_name)s.pid

On installe (qu'une seule fois) et on lance le daemon londiste (toujours depuis le slave) :

[pgsql] % londiste.py postfix.ini provider install
[pgsql] % londiste.py postfix.ini subscriber install
[pgsql] % londiste.py postfix.ini replay -d

Ensuite on peut ajouter des tables à la réplication (aussi des séquences avec add-sec) :

[pgsql] % londiste.py postfix.ini provider add public.alias
[pgsql] % londiste.py postfix.ini subscriber add public.alias

Et voilà la réplication lancée, il y a un tas d'autres commandes sympa, notamment repair/compare qui permet une resynchronisation.

% man pgqadm
% man londiste

Et un tuto bien sympa ainsi qu'une publication dans GNU/Linux magazine.

Ssmtp pour remplacer sendmail

Mon, 04 Jan 2010 23:10:53 GMT

Sur mon serveur FreeBSD j'ai 4 jails et par défaut le système envoie régulièrement des security run output à root@localhost pour l'informer de ce qu'il se passe sur le système (nouveau fichiers etc). Tout ça c'est très bien sauf que un hote et 4 jails ça fait 5 compte mail à visiter, c'est pas trop convi et en plus on a pas envie de faire tourner sendmail juste pour ça.

J'ai donc décidé d'utiliser un MTA très simple appelé (devinez comment) : Simple smtp agent. Chaque mail envoyé depuis la machine (en appelant sendmail) partira vers un serveur smtp de mon choix, ainsi je récupère tous les mails sur mon compte mail usuel.

# cd /usr/ports/mail/ssmtp
# make install
Information for ssmtp-2.62.3:
Install notice:
sSMTP has been installed successfully.
To replace sendmail with ssmtp type "make replace"
# make replace

Ensuite j'ai crée mon /usr/local/etc/ssmtp/ssmtp.conf :

# Serveur de mail à contacter pour l'envoi + le port
# par defaut c'est le port 25
mailhub=mail.philpep.org:578
# Domaine d'où semble venir le mail
rewriteDomain=philpep.org
# Domaine à donner pendant le HELO
# À accorder avec le reverse DNS de votre machine
# vu depuis le serveur de mail.
hostname=shen.philpep.org

Arrangez vous pour que le serveur de mail accepte de vous relayer, moi c'est le cas parce que je suis en local et mon postfix relaie ce qui vient du réseau local. Mais si ce n'est pas le cas (genre vous utilisez le serveur mail de votre fournisseur de mail), on peut configurer l'authentification SMTP, SSL/TLS et tout le reste.

Ensuite désactivez sendmail dans /etc/rc.conf puisqu'il ne sert plus :

sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"

Pour tester l'envoi :

$ dmesg | mail -s "works ?" lapin@barreenfer.com
$ if [[ $? -ne 0 ]]; then man ssmtp; fi

EDIT 5/01/10 17:15

client smtp -> MTA

Spamd

Sat, 31 Oct 2009 13:50:31 GMT

Spamd ou comment bloquer les spams sans discriminer à priori des adresses IPs et sans remettre en cause la neutralité du réseau.

J'ai écrit une page sur spamd sur le principe de fonctionnement et sa mise en place sur OpenBSD.

Ce tout nouveau wiki cogéré par philpep.org et bender-labs.org est plus adapté que mon blog pour ce genre de choses car vous pouvez aussi apporter votre contribution pour faire part de votre expérience (ne serait-ce que pour corriger d'éventuelles fautes d'orthographes et de grammaires :-) ).

Comment passer outre le blacklist de son serveur SMTP

Fri, 11 Sep 2009 16:53:24 GMT

Souvent, la mise en place d'un serveur sur votre propre ligne ADSL pose de nombreux petits problèmes.

Un d'entre eux est certainement le blacklist systématique des serveurs de mail (SMTP) qui ont une IP d'un particulier. Quelques uns des plus gros opérateurs de mail sur Internet refusent tout simplement toute connexion SMTP provenant d'une IP d'un abonné ADSL de free, orange, neuf etc. Mais ce blacklist peut être aussi post connexion en déclarant votre mail comme étant du SPAM.

Mais pourquoi diable font il cela ? La réponse est simple, pour éviter le spam justement. La plupart des virus que nos chers amis utilisateurs de Windows ont sur leurs PC servent à envoyer du spam ou bien à lancer des attaque de type DDos.

Donc, devant le manque de sécurité apparent d'un système d'exploitation, nous voici tous dans le même bateau. Impossible d'envoyer un mail vers aol.com par exemple. Mise de votre mail dans le dossier SPAM par yahoo.com, j'en passe et des meilleures.

Pour vous donner une idée de la manière dont on traite quelqu'un qui s'auto-héberge.

$ host -t mx aol.com
aol.com                 MX      15 mailin-01.mx.aol.com
aol.com                 MX      15 mailin-02.mx.aol.com
aol.com                 MX      15 mailin-03.mx.aol.com
aol.com                 MX      15 mailin-04.mx.aol.com

$ telnet mailin-01.mx.aol.com 25
Trying 64.12.222.197...
Connected to mailin-01.mx.aol.com.
Escape character is '^]'.
554- (RTR:BB)  http://postmaster.info.aol.com/errors/554rtrbb.html
554  Connecting IP: 82.234.40.34
Connection closed by foreign host.

$ wtf

Ils disent qu'il n'acceptent pas les connexions de votre IP parce qu'il est difficile de savoir qui est responsable du mail qui provient de cette IP.

C'est comme si on interdisait aux gens de discuter dans le train parce qu'il y a trop de monde pour entendre ce que vous avez à dire et que vous risquez de dire des choses irresponsables comme critiquer le PDG et les amis de la SNCF, par mesure de précaution seuls les contrôleurs sont habilités à s'exprimer. (Si ça ne vous parait pas évident, ici les contrôleurs c'est gmail.com, yahoo.com, hotmail.com, la SNCF c'est aol.com et celui qui prends le train c'est 82.234.40.34).

Attention, ici je ne parle pas de blacklist de votre domaine (philpep.org en l'occurence) mais de l'IP d'où provient la connexion (82.234.40.34).

Donc on peut passer outre ce filtrage en se faisant relayer par un SMTP réputé "propre", celui de votre FAI par exemple.

C'est ce que nous allons faire avec postfix, il est possible de relayer les mails en destination de aol.com, yahoo.com par votre FAI, mais de s'adresser directement aux autres SMTP.

Here is the conf :

transport_maps = hash:/usr/local/etc/postfix/transport

Ici j'utilise la syntaxe BSD (/usr/local/etc/postfix/) sous linux c'est souvent (/etc/postfix)

Donc nous devons créer ce fichier /usr/local/etc/postfix/transport

yahoo.com       relay:[smtp.free.fr]
yahoo.fr        relay:[smtp.free.fr]
aol.com         relay:[smtp.free.fr]

Ici quand mon serveur reçoit un mail en destination de aol ou yahoo, il l'envoie à smtp.free.fr (le SMTP de mon FAI). Celui ci étant reconnu comme fiable par nos deux gros opérateurs passe sans problème.

Pour finir, générez un fichier DB pour postfix avec ce fichier et relancez postfix (BSD syntaxe ici aussi)

$ postmap /usr/local/etc/postfix/transport
$ /usr/local/etc/rc.d/postfix restart

Si vous connaissez des problèmes avec d'autres opérateurs, n'hésitez pas en m'en faire part en commentaire. Ce serait bien d'avoir une liste de domaines qui utilisent un tel filtrage.