J’ai récemment été confronté à une situation complexe sur une architecture Symantec Messaging Gateway composée de trois nœuds :

• Deux boitiers scanners
• Un boitier control center

Le boitier control center était hors service (interface Web inaccessible); or, au même moment l’un de deux boitiers scanner était victime d’un problème de remise de messages (files d’attente Inbound et Outbound avec plusieurs milliers de messages en attente de traitement).

Dans ce cas de figure la seule méthode disponible pour administrer le boitier scanner (en l’absence de l’interface Web habituellement disponible sur le control center) consiste à prendre en la main en mode console (soit physiquement sur le serveur, soit à distance avec un client SSH comme putty).

Dans ce cas de figure, les trois commandes les plus importantes pour gérer les files d’attente sont les suivantes :

• mta-control qui permet de gérer les files d’attente et de reconfigurer la pile MTA
• monitor qui permet d’afficher le statut des files d’attente ainsi que le nombre de mail dans chaque file
• service qui est une commande Linux standard permettant de redémarrer les services (dont le service MTA)

Voici quelques exemples de commandes :

mta-control pause-mode status (permet d’afficher le statut de la pile MTA)

mta-control pause-mode pause-accept (reconfigure la pile MTA pour ne plus accepter les nouveaux messages; les messages toujours en file sont scannés, puis envoyés)

mta-control pause-mode resume-accept (permet de revenir en arrière)

monitor mta (permet d’afficher l’état des différentes files; i_qmsgs correspond au nombre de message dans la file Inbound, o_qmsgs correspond au nombre de message dans la file Outbound et enfin d_qmsgs correspond au nombre de messages dans la file Delivery)

mta-control delivery flush (permet de forcer la réémission des messages bloqués dans la file d’attente Delivery)

service mta restart (permet de redémarrer le service MTA)