Indisponibilité majeure…

Vous avez pu vous en rendre compte, nous avons eu deux longues soirées d’indisponibilité sur la plateforme (dimanche 6 et lundi 7 décembre).

Avant les explications sur ce qui c’est passé, un petit rappel concernant la plateforme.

En dehors des serveurs de backup (hébergés à Montpellier), toute la plateforme est hébergée dans un rack unique (donc dans une salle unique dans un datacentre unique), dans le centre de Paris (derrière le Grand Rex).

Cette plateforme c’est un châssis (Dell M1000E) avec des lames (Dell M610) et des systèmes de stockage (Equallogic PS6100E et PS6100XS) avec le réseau pour que tout ça communique.

Le châssis intègre sa propre redondance physique : seize emplacements pour des lames, deux cartes de gestion, deux systèmes de réseau (chaque lame ayant six cartes réseaux), neuf ventilateurs et six alimentations.
Il peut fonctionner avec seulement trois alimentations, une seule carte de gestion et six ventilateurs (tout ça étant bien sûr « hot plug »).

Le système de stockage, c’est la même chose : chaque baie de stockage a une double alimentation et un double contrôleur et peut fonctionner avec seulement une alimentation et/ou un seul contrôleur. Chaque baie est configurée en RAID6, avec deux disques de spare.

C’est la même chose pour le réseau. Le réseau de gestion est double (deux switches gigabits intégrés au châssis) double connecté entre eux et à deux cartes réseaux sur chaque lame, le réseau de stockage utilise deux switches gigabit externes (eux aussi double connectés entre eux et à deux cartes par lames) et, bien entendu, c’est la même chose pour le réseau « logique » (deux switches 10 Gbps dans le châssis et deux cartes 10 Gbps dans chaque lame), le tout doublement connecté.

Sur le plan applicatif, la redondance est gérée grâce aux lames en surnombre (l’ensemble des VM hébergées pourrait tourner sur seulement trois lames), avec bascule automatique en cas de soucis sur une lame.

Bref, tout est prévu. En théorie.

Parce que, pour la pratique, on s’appuie sur l’extérieur, en l’occurrence le datacentre. Datacentre qui est en théorie entièrement redondé lui aussi : double alimentation électrique, double système d’onduleurs, double climatisation et le tout séparé pour chaque salle.

Mais il y a les maintenances. Obligatoires. Qui obligent à stopper, dans le cas qui nous intéresse, une des armoires de climatisation de la salle qui perd donc la redondance « froid ».

Et ce qui avait peu de chance d’arriver est néanmoins arrivé : dimanche l’armoire de climatisation qui fonctionnait (la seule) s’est arrêtée, de 16h20 à 17h30 environ (ré-enclenchement manuel par l’équipe d’astreinte).

La température est bien entendu montée très vite et très haut : mesurée au niveau de cartes mères, on passe de 45 à 90° en une trentaine de minutes. Résultat, une des baies de stockage et le châssis se sont mis en sécurité (température trop haute) et se sont éteints. Tout simplement.

Une fois la climatisation ré-enclenchée, la température redescend (moins vite qu’elle ne monte), le châssis a redémarré seul mais pas la baie de stockage.

Il a donc fallu une intervention « Remote Hands » pour la démarrer et commencer à relancer les machines virtuelles. Et se rendre compte que certaines étaient, même démarrées, inaccessibles.

Un des switches 10 Gbps du châssis apparaissait « en alerte », tout comme deux des alimentations du châssis.

Après une nouvelle intervention « Remote Hands » qui a confirmé que le switch semblait HS, y compris après un reseat, nous avons modifié la topologie réseau et la configuration globale du châssis pour forcer l’utilisation du second switch.

Les services ont donc été rétablis aux alentours de minuit (certaines VM ont nécessité des fsck, d’autres ont du être redémarrées et certains services spécifiques également). Quelques services n’ont été accessibles que lundi matin.

Lundi vers 18h nous sommes intervenu physiquement sur la plateforme afin de vérifier le switch qui semblait HS et effectuer un re-seat des alimentations elles-même en « warning ».

Là encore, il s’est passé ce qui ne devrait pas se passer : alors que le châssis est capable de fonctionner avec seulement trois alimentations, en débranchant un des alimentations en « warning » et en la rebranchant, il s’est éteint.

Il a donc fallu tout redémarrer une fois de plus…

Les VM ont bien redémarré mais certaines fonctionnaient très mal (ça ramait, beaucoup) alors que d’autres fonctionnaient normalement.
Après investigation, il est apparu que deux lames fonctionnaient normalement alors que les quatre autres « ramaient ».

Une des lames a été libérée de ses VM et rebootée, même chose (un reboot de lame, c’est 20 minutes environ).

Nous avons alors tenté le re-seat (physique) de lame et après son boot (encore 20 minutes), les VM déplacées sur cette lame fonctionnaient correctement.

Le re-seat des trois lames restantes a ensuite été effectué (une par une pour éviter un nouveau soucis), les VM vérifiées et les services étaient de retour à 23h.

Là encore quelques services ont nécessité une nouvelle intervention mardi matin.
La topologie réseau a été corrigée et des switches « spare » ont été commandés.

Et normalement, tout devrait fonctionner sans soucis pendant quelques années.
Jusqu’à la prochaine coupure électrique (vécu à Redbus Interhouse et Overlap) ou de climatisation, que vous pourrez suivre en live via notre compte Twitter : https://twitter.com/NetworkStudioFR.

Pour la petite histoire, la maintenance de climatisation devait être terminée vendredi dernier…
Elle a finalement été terminée mardi.

La mise en place d’une plateforme mirrorée (avec un autre datacentre) est tout à fait envisageable mais pose clairement un problème de coût (nous n’avons pas la masse critique pour que cela se fasse sans une augmentation importante des tarifs).

Mise à jour règles SpamAssassin dans MailCleaner

Tant qu’on y est (voir l’article sur l’apprentissage MailCleaner avec Zimbra), voici un petit script qui va mettre à jour les règles SpamAssassin (Spamc) dans MailCleaner.

Plusieurs sources sont utilisées, le script est à lancer une fois par jour (ou plus), sous le user root.

#!/bin/bash
cd /tmp

/usr/local/bin/sa-update --nogpg \
--channel sought.rules.yerp.org \
--channel sa.sosdg.org \
--channel updates.spamassassin.org \
--channel spamassassin.heinlein-support.de \
--updatedir /usr/mailcleaner/share/spamassassin
wget http://www.pccc.com/downloads/SpamAssassin/contrib/KAM.cf
mv -f KAM.cf /usr/mailcleaner/share/spamassassin/KAM.cf

/usr/mailcleaner/etc/init.d/mailscanner restart

Là encore, c’est une base : à vous de l’adapter (en particulier en réactivant gpg pour la vérification des signatures).

Apprentissage MailCleaner (avec Zimbra)

Nous utilisons quelques MailCleaner en interne (devant nos plateformes SaaS) et nous en déployons régulièrement chez des clients.
Un des intérêts de la solution est que MailCleaner est capable d’apprendre depuis les classements HAM et SHAM réalisés sur une plateforme Zimbra (ou autre mais dans cet article, on va parler de Zimbra).

Pour mettre en place cet apprentissage, il faut passer par quelques étapes.
Ce qui est indiqué ci-dessous peut certainement être amélioré (utilisation d’IMAPs, une seule récupération des mails par compte, etc) et doit être adapté à vos propres règles/habitudes.

On commence par récupérer les noms des comptes HAM et SPAM de la plateforme Zimbra.
Sur un des serveurs de la plateforme :

# su - zimbra
zimbra@zimbra:~$ zmprov gacf |grep -i spamaccount
zimbraSpamIsNotSpamAccount: nxigt5q7@zimbra.domain.tld
zimbraSpamIsSpamAccount: yd_8isft@zimbra.domain.tld

Le premier, c’est le compte qui récupère les HAM (faux positifs) et le second, le compte qui récupèrent les SPAM (messages non taggés alors qu’ils auraient du l’être).

Ensuite, via l’interface web (ou la CLI), attribuer à ces comptes des mots de passe et vérifier qu’ils sont accessibles en IMAP.
Ca… Je vous laisse faire. Dans notre cas, on va attribuer les mots de passe passwordHAM et passwordSPAM.

On continue, sur le serveur MailCleaner cette fois, en installant les outils nécessaires :

root@mailcleaner:~# apt-get install fetchmail

Vérifiez dans /etc/default/fetchmail que la dernière ligne est bien : START_DAEMON=no
On ne veut pas que fetchmail tourne en daemon mais uniquement utiliser l’outil en CLI.

On crée ensuite, dans le homedir de root, un fichier .netrc qui sera utilisé par fetchmail.
Ce fichier va contenir deux entrées, une pour chaque compte (HAM et SPAM).
La valeur machine correspond à votre serveur Zimbra (ou zimbra-proxy en multi-serveurs), login c’est le compte et password, je vous laisse deviner.

machine zimbra.domain.tld
login nxigt5q7@zimbra.domain.tld
password passwordHAM

machine zimbra.domain.tld
login yd_8isft@zimbra.domain.tld
password passwordSPAM

Puis, toujours dans le homedir de root, on va créer le script sa-learn.sh (n’oubliez pas de le rendre exécutable).
Ce script utilise fetchmail pour se connecter aux deux boites (en IMAP), récupérer les messages de chaque boite et faire le double apprentissage pour SpamAssassin (Spamc) et BogoFilter (NiceBayes) :

#!/bin/bash
/usr/bin/fetchmail -p IMAP zimbra.domain.tld -u yd_8isft@zimbra.domain.tld -a -k -s -n --folder INBOX -m '/usr/local/bin/sa-learn -p /usr/mailcleaner/etc/mailscanner/spam.assassin.prefs.conf --siteconfigpath /usr/mailcleaner/share/spamassassin --no-sync --spam'
/usr/bin/fetchmail -p IMAP zimbra.domain.tld  -u nxigt5q7@zimbra.domain.tld -a -k -s -n --folder INBOX -m '/usr/local/bin/sa-learn -p /usr/mailcleaner/etc/mailscanner/spam.assassin.prefs.conf --siteconfigpath /usr/mailcleaner/share/spamassassin --no-sync --ham'
/usr/local/bin/sa-learn -p /usr/mailcleaner/etc/mailscanner/spam.assassin.prefs.conf --siteconfigpath /usr/mailcleaner/share/spamassassin --sync

/usr/bin/fetchmail -p IMAP zimbra.domain.tld  -u yd_8isft@zimbra.domain.tld -a -k -s -n --folder INBOX -m '/opt/bogofilter/bin/bogofilter -s '
/usr/bin/fetchmail -p IMAP zimbra.domain.tld  -u nxigt5q7@zimbra.domain.tld -a -k -s -n --folder INBOX -m '/opt/bogofilter/bin/bogofilter -n '

L’exécution du script est assez verbeuse et il est intéressant de récupérer les informations dans un fichier (sa-learn.log, toujours dans le homedir root).
Dans notre example, on va récupérer les informations et supprimer le log précédéent à chaque exécution, via la crontab. Pour cela, il suffit d’ajouter dans /etc/crontab :

15 22 * * *     root    rm -f /root/sa-learn.log ; /root/sa-learn.sh >> /root/sa-learn.log

Bloquer un compte qui spamme…

En général c’est lié à une campagne de phishing qui a fait son job…
Quelques centaines de mails à la minute si on a une plateforme qui tient le coup qui partent à travers des sessions SMTP en provenance de plein d’IP différentes (et avec des « from » aléatoires, histoire d’être encore plus pénible).

On peut faire tourner un script sur le MTA sortant (ZCS) qui va parser zimbra.log pour y trouver toutes les connexions SMTP authentifiées et agir (en bloquant le compte) s’il y en a trop par minute.
Ce script gère une whitelist, envoie un mail au support lorsqu’un compte est bloqué et peut être lancé chaque cinq minutes (par root) via la crontab.
Il ne s’agit que d’une base, à adapter selon vos besoins…

#!/bin/bash

logfile="/var/log/zimbra.log"
maxmails="100"
mydomain="mondomaine.tld"
support="support@$mydomain"
accounts="/tmp/active_accounts"
log="/home/zimbra/closed.log"
WL="/root/whitelist.txt"
redemarre=false

su - zimbra -c "/opt/zimbra/bin/zmaccts" | grep "@" | grep active | awk '{print $1}' > $accounts

zgrep -i "sasl_method=LOGIN, sasl_username" $logfile | sed 's/  / /g' | awk -F"[ :]" '{print $3":"$4,$13;}' | sed 's/sasl_username=//g' | sort | uniq -c | sort -n |\
while read line
do
  count=`echo ${line} | cut -d' ' -f 1`
  userid=`echo ${line} | cut -d' ' -f 3`
  userid=${userid,,}
  timestamp=`echo ${line} | cut -d' ' -f 2`
  active=`grep -i "$userid@$mydomain" $accounts`

  if [ "$count" -gt "$maxmails" ] && [ "$active" == "$userid@$mydomain" ];
  then
    # On vient de détecter un utilisateur
    if zgrep --quiet -i $userid $WL;
    then
      # WhiteList
      # A vous de définir les opérations à réaliser si whitelist...
    else
      # On envoie le mail d'alerte et on bloque le compte
      subject="Compte $userid détecté - trop de connexions SMTP"
      message="/tmp/emailmessage.txt"
      echo "Le compte $userid a été verrouillé : $count connexions en une minute à $timestamp."> $message
      /bin/mail -r "postmaster@$mydomain" -s "$subject" "$support" < $message
      su - zimbra -c "/opt/zimbra/bin/zmprov ma $userid@$mydomain zimbraAccountStatus locked"
      echo $timestamp  ' - ' $userid >> $log
      redemarre=true
    fi

    rm -f $message

    #update list of active accounts
    su - zimbra -c "/opt/zimbra/bin/zmaccts" | grep "@" | grep active | awk '{print $1}' > $accounts
  fi
done

rm -f $accounts

if [ $redemarre = true ];
then
  su - zimbra -c "postfix stop ; postfix start"
fi

Mise en ligne : www.network-studio.com

Nouvelle version du site network-studio.com
ns-home

Mise en ligne : alexismunoz.com

Version Responsive Web Design du site alexismunoz.com
munoz-home-desktop

Mise en ligne : blog.alexismunoz.com

Responsive Web Design optimisé pour navigation tactile
blog-alexis_blog

Mise en ligne : www.cliniquedentaireavignon.fr

Responsive Web Design
espace-23_blog

Mise en ligne : www.network-studio.com

7ème version, fluide et responsive

Nouvelle infrastructure ZCS chez Mozilla

C’est devenu scalable… Et sérieux !

https://blog.mozilla.org/it/2012/04/06/re-imagining-zimbra-email-at-mozilla/