Relancer les services mail en release 2 OVH

Un petit billet en vitesse à destination des clients OVH qui administrent leur serveur en release 2 via Webmin.

Il arrive régulièrement qu’on doive relancer certains services sur un serveur dédié, ne fût-ce que quand on fait la moindre modification sur un fichier de configuration. Ceux qui ont l’habitude d’administrer leur serveur en SSH connaissent bien le répertoire /etc/init.d/ pour avoir déjà tapé au moins 100.000 fois des commandes du genre /etc/init.d/mysql restart.

Ceux qui connaissent moins bien SSH passent par Webmin pour administrer leur serveur. Là aussi il est possible de relancer les services :

  • Le bouton “Appliquer les changements” dans Bind
  • Le bouton “Stop MySQL server” (suivi bien sûr de “Start”) dans MySQL
  • L’onglet “Appliquer les changements” dans Apache
  • Le lien “Redemarrer tous les services (pour prendre en compte les changements)” dans OVHm (qui relance à la fois Bind et Apache)
  • Etc, etc.

Tous fonctionnent et permettent de relancer proprement les services … tous sauf un : QMail. Ceux qui ont eu un jour la curiosité de cliquer sur le bouton “Stop QMail Processes” (ou bien dont le serveur de mail a bêtement planté) ont probablement eu la désagréable surprise de ne pas pouvoir relancer le serveur de mail.

On a beau cliquer sur “Start QMail Processes”, ça ne redémarre pas.

Et pourquoi ça ne marche pas ? C’est tout simplement dû à l’installation du serveur de mail sur la release OVH : le trio QMail – Spamassassin – ClamAV (serveur de mail – antispam – antivirus) est une installation OVH “maison” et Webmin a un peu de mal à le prendre en charge.

Alors que faire ? Pas le choix, il faut passer en SSH (par pitié, ne cédez pas à la tentation du reboot : rebooter un serveur linux, c’est mal !) et lancer les commandes suivantes dans l’ordre :

/etc/init.d/clamd stop
/etc/init.d/spamd stop
/etc/init.d/qmail stop
/etc/init.d/qmail start
/etc/init.d/clamd start
/etc/init.d/spamd start

Voilà qui devrait faire l’affaire. Rien ne vous empêche d’ailleurs de vous faire un petit script perso qui vous permette de lancer toutes ces commandes automatiquement les unes après les autres.

Release OVH : spamassassin et le bug de l’an 2010

Un bug connu depuis belle lurette déclenche encore pas mal de faux-positifs sur certains spamassassin. C’est dû au fait qu’une des règles utilisées fai(sai)t que tout mail qui a une date éloignée dans le futur voit sa probabilité d’être considéré comme spam augmenter fortement. Jusque là, rien que de très normal : il est louche de voir passer des mails dont la date est en avance de plusieurs années sur le date présente. Oui mais voilà, la règle en question (assez ancienne) stipulait que 2010 est une année éloignée dans le futur … suffisamment éloignée pour titiller spamassassin. Pas de bol, on y est finalement arrivés en 2010 !

Ce bug a été très vite mis à jour dès le début de cette année, à vrai dire dès qu’un grand nombre d’admin ont commencé a voir passer des cargaisons entières de faux-positifs (des mails classés abusivement comme spam par spamassassin). Le bug a été rapidement corrigé et la situation est revenue à la normale. Cela supposait cependant de faire la mise à jour qui va bien … ce qui n’a toujours pas été fait à l’heure actuelle sur la distribution phare d’OVH : la release 2.

Pour ceux qui utilisent cette distribution et qui se servent de spamassassin, il convient donc de faire le mini-patch suivant : dans le fichier /usr/share/spamassassin/72_active.cf (ligne 565), remplacer :

header   FH_DATE_PAST_20XX    Date =~ /20[1-9][0-9]/ [if-unset: 2006]

Par :

header   FH_DATE_PAST_20XX    Date =~ /20[2-9][0-9]/ [if-unset: 2006]

Votre spamassassin considérera alors comme “futur éloigné” les dates de 2020 à 2099 (et non plus 2010 à 2099).