• Articles
• admin

Par défaut, la surveillance SNMP est désactivée dans le serveur de messagerie. Thisdefault est choisi dans le but de minimiser le nombre de services présentés par une configuration de serveur de messagerie par défaut. N’interprétez pas ce défaut, ce qui signifie qu’il y a une pénalité de performance encourue en utilisant la surveillance SNMP.En effet, le support SNMP du serveur de messagerie consomme très peu de ressources et est destiné à avoir un impact minimal sur le serveur de messagerie. Le résultat de tout cela est, bien sûr, que des étapes de configuration uniques sont nécessaires avant d’utiliser le support SNMP du serveur de messagerie. De plus, la configuration par défaut de l’agent maître Net-SNMP de la plate-forme, snmpd, doit généralement être modifiée afin d’exécuter des sous-agents tels que des serveurs de messagerie. Ce changement est le sujet de la section suivante.

A.3.1 Configuration Net-SNMP

Le sous-agent SNMP basé sur Net-SNMP du serveur de messagerie utilise le protocole AgentX pour communiquer avec l’agent maître SNMP de la plate-forme (RFC 2741). L’agent Net-SNMPmaster, snmpd, doit être configuré pour permettre l’utilisation du protocole AgentX. Pour ce faire, assurez-vous que le snmpd de la plate-forme.le fichier conf contient la ligne

master agentx

Si cette ligne n’est pas présente, ajoutez-la puis redémarrez le démon snmpd. Notez que l’envoi d’un signal SIGHUP au démon n’est pas suffisant. Une fois le démon snmpd redémarré, recherchez le socket de domaine UNIX créé par snmpd pour AgentXcommunications. Sur les systèmes Solaris et Linux, ce socket apparaît par défaut comme le fichier spécial /var/agentx/master ; cependant, son emplacement et son nom peuvent être modifiés via le snmpd.confite.

La configuration snmpd du système d’exploitation Solaris 10 est présentée ci-dessous:

%cp /etc/sma/snmp/snmpd.conf /etc/sma/snmp/snmpd.conf.save% cat >> /etc/sma/snmp/snmpd.conf# Messaging Server's subagent requires the AgentX protocolmaster agentx^D% cat >> /etc/sma/snmp/snmpd.conf% ls -al /var/agentx/srwxrwxrwx 1 root root 0 Aug 9 13:58 /var/agentx/master

De plus, sur les systèmes Red Hat Enterprise Linux AS 3, le snmpd par défaut.le fichier conf limite les informations qui peuvent être consultées par la communauté SNMP « publique ». Il est donc nécessaire de supprimer cette restriction ou de l’étendre pour inclure les MIB servis par le sous-agent du serveur de messagerie. Pour les tests initiaux, il est recommandé de faire ce dernier. Ceci est accompli en incluant les sous-arbres O mib-2.27 et mib-2.28 dans la vue nommée « systemview » comme indiqué ci-dessous. Pour un déploiement réel, chaque site doit prendre en compte sa politique de sécurité globale. Notez que les informations fournies par le sous-agent SNMP sont « en lecture seule ».

% cp /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.save% cat >>/etc/snmp/snmpd.conf# Messaging Server's subagent requires the AgentX protocolmaster agentx# Messaging Server's subagent exports mib-2.27 and .28# Add the mib-2.27 and .28 OID subtrees to the systemviewview systemview included .1.3.6.1.2.1.27view systemview included .1.3.6.1.2.1.28^D% /sbin/service snmpd restart% ls -al /var/agentx/mastersrwxr-xr-x 1 root root 0 Aug 8 21:20 /var/agentx/master

Si vous utilisez des noms de contexte SNMP v3 pour distinguer les bits de différentes instances de serveur de messagerie s’exécutant simultanément sur le même ordinateur hôte, vous devrez également configurer au moins un nom d’utilisateur et un mot de passe SNMPv3 à utiliser avec vos requêtes SNMP v3.

A.3.2 Configuration du sous-agent du serveur de messagerie

Pour le fonctionnement de base du sous-agent SNMP du serveur de messagerie, il vous suffit de l’activer et d’émettre une commande de démarrage manuel unique. Désormais, lorsque le serveur de messagerie est démarré ou arrêté, le sous-agent sera également démarré ou arrêté. Les commandes nécessaires pour effectuer cette configuration sur Solaris et Linux sont les suivantes:

% configutil -o local.snmp.enable -v 1% start-msg snmp

Une fois exécuté, vous pouvez tester le sous-agent à partir de la ligne de commande avec la commande snmpwalk. Voir les captures d’écran ci-dessous un exemple approprié pour Solaris et Linux. Notez que les fichiers rfc2248.txt et rfc2249.txt sont des copies des Services réseau et des MIB MTA. Sur les systèmesololaris, ces fichiers se trouvent également dans le répertoire /etc/sma/snmp/mibs/ sous les noms NETWORK-SERVICES-MIB.txt et MTA-MIB.txt. Il n’est pas nécessaire de fournir ces fichiers à l’outil snmpwalk ; cependant, cela permet des noms de toprint snmpwalk pour chacune des variables MIB plutôt que leurs identificateurs d’objectifs numériques (O).

Tests de base sur Solaris:

% D=/opt/SUNWmsgsr/examples/mibs /usr/sfw/bin/snmpwalk -v 1 -c public \ -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.27NETWORK-SERVICES-MIB::applName.1 = STRING: /opt/SUNWmsgsr MTA on mail.siroe.com...% D=/opt/SUNWmsgsr/examples/mibs /usr/sfw/bin/snmpwalk -v 1 -c public \ -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.28MTA-MIB::mtaReceivedMessages.1 = Counter32: 1452MTA-MIB::mtaStoredMessages.1 = Gauge32: 21...

Tests de base sur Linux:

% export D=/opt/sun/messaging/examples/mibs% /usr/bin/snmpwalk -v 1 -c public \ -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.27NETWORK-SERVICES-MIB::applName.1 = STRING: /opt/sun/messaging MTA on mail.siroe.com...% /usr/bin/snmpwalk -v 1 -c public \ -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.28MTA-MIB::mtaReceivedMessages.1 = Counter32: 21278MTA-MIB::mtaStoredMessages.1 = Gauge32: 7...

A.3.3 Exécution en tant qu’Agent SNMP autonome

Avant de configurer le sous-agent SNMP du serveur de messagerie pour qu’il s’exécute en tant qu’agent standaloneSNMP, vous devez d’abord décider de l’interface Ethernet et du port UDP que vous souhaitez qu’il écoute pour les requêtes SNMP. Par défaut, il écoutera toutes les interfaces Ethernet disponibles en utilisant le port UDP 161. Dans la plupart des cas, vous souhaiterez changer le numéro de port afin de ne pas interférer avec l’agent maître snmpd de la plate-forme. Dans certaines circonstances telles qu’un basculement, vous voudrez également changer l’interface Ethernet de toutes les interfaces disponibles INAD INADDR_ANY to en une interface spécifique identifiée par son adresse IP. Ces deux concepts, l’interface Ethernet et le port UDP, sont contrôlés via le local.SNMP.listenaddr et local.SNMP.options de port.

Une fois que les choix pour l’interface Ethernet et le port UPD ont été faits, le local.SNMP.l’option autonome devrait avoir sa valeur définie sur un et le sous-agent redémarré. Une fois redémarré, il fonctionnera comme un agent SNMP indépendant de snmpd et de tous les sous-agents.

Par exemple, pour fonctionner en tant qu’agent autonome écoutant sur le port UDP 9161 de l’interface Ethernet avec l’adresse IP 10.53.1.37, émettez les commandes montrées ci-dessous.

Configuration de l’exécution en tant qu’agent autonome:

% configutil -o local.snmp.port -v 9161% configutil -o local.snmp.listenaddr -v 10.53.1.37% configutil -o local.snmp.standalone -v 1% stop-msg snmp% start-msg snmp% snmpwalk -v 1 -c public 10.53.1.37:9161 .SNMPv2-SMI::mib-2.27.1.1.2.1 = STRING: "/opt/SUNWmsgsr MTA on mail.siroe.com"...

A.3.4 Surveillance de plusieurs instances de Messaging Server

Deux techniques de surveillance de plusieurs instances de Messaging Serverrunning sur le même ordinateur hôte sont décrites ici. La première technique, l’exécution du sous-agent en mode autonome, est bien adaptée aux configurations à haute disponibilité (HA) dans lesquelles les instances individuelles de MessagingServer peuvent se déplacer dynamiquement entre les ordinateurs hôtes. La deuxième technique, l’utilisation de noms de contexte SNMP v3, présente un avantage limité dans des situations où plusieurs instances de serveur de messagerie sont confinées à un seul système et il est souhaitable de limiter le nombre d’adresses IP interrogées par le logiciel de surveillance SNMP (par exemple, lorsque la licence du logiciel de surveillance comporte une composante de coût d’adresse pérIP). Cette dernière technique peut également être utilisée dans les paramètres de basculement HA, mais nécessiterait d’interroger autant d’adresses IP que la technique du mode standard.

A.3.5 Utilisation d’Agents Autonomes pour le Basculement Haute disponibilité

Dans un paramètre de basculement haute disponibilité où la surveillance SNMP de MessagingServer est souhaitée, il est recommandé d’exécuter SNMPsubagent du Serveur de messagerie en tant qu’agent autonome, comme décrit dans A.3.3 S’exécutant en tant qu’Agent SNMP autonome. Lorsque les sous-agents sont exécutés en mode standard, chaque instance HA du serveur de messagerie doit avoir son local.SNMP.option listenaddr définie sur la valeur de l’IP de basculement de cette instance address.To simplifiez la gestion, chaque instance doit utiliser le même port UDP, mais ce port doit être distinct de ceux utilisés par les démons snmpd qui exécutent sur chacun des hôtes de cluster physiques. Typiquement, ces démons utiliseront le port UDP 161, donc spécifiez explicitement un numéro de port différent avec le local.SNMP.option de port.

Lorsque la prise en charge SNMP du serveur de messagerie est configurée comme recommandé ici, une station de surveillance peut surveiller chaque instance du serveur de messagerie via son adresse IP ou son nom d’hôte, quel que soit l’hôte de cluster physique sur lequel l’instance s’exécute. De plus, vous êtes assuré que les agents SNMP standard du serveur de messagerie ne seront pas en conflit les uns avec les autres car chacun s’écoute uniquement sur sa propre interface Ethernet virtuelle identifiée par l’adresse IP unique de cette instance. (Ces interfaces Ethernet virtuelles sont automatiquement créées par le framework de basculement HA.) En raison de la sélection minutieuse du port aUDP, les agents n’entrent pas en conflit avec les démons snmpd qui fonctionnent sur les systèmes du cluster.

A.3.6 Distinguer Plusieurs Instances Via des noms de texte SNMP V3

Bien qu’il n’y ait aucun inconvénient à utiliser le support SNMP du Serveur de messagerie en mode autonome comme décrit dans A.3.3 S’exécutant en tant qu’Agent SNMP autonome, il est reconnu que certains sites peuvent préférer utiliser un mode sous-agent plus traditionnel tout en conservant la capacité de surveiller plusieurs instances du Serveur de messagerie s’exécutant simultanément sur le même système.Par exemple, un système de surveillance SNMP dont le modèle de licence limite le nombre d’adresses IP qui peuvent être interrogées. Pour atteindre cet objectif, continuez à exécuter le sous-agent SNMP du serveur de messagerie avec local.SNMP.setto zéro autonome. De plus, configurez chaque instance de serveur de messagerie pour qu’elle utiliseun nom de contexte SNMP v3 distinct en spécifiant une valeur non nulle pour le local.SNMP.enablecontextname option. Si un nom de contexte différent de la valeur du service.defaultdomain est souhaité, puis définissez le nom souhaité avec le local.SNMP.option contextname. Une fois que chaque instance du sous-agent SNMP du serveur de messagerie est redémarrée, elles peuvent ensuite être surveillées via des requêtes SNMP v3 qui incluent les noms de contexte appropriés. Les MIB de deux instances de serveur de messagerie s’exécutant sur le même système se distinguent par le nom de contexte SNMP v3 de l’instance et par conséquent, aucun conflit d’identifiant d’objet MIB (O) ne se produira.

A.3.7 Options du sous-agent SNMP basé sur Net-SNMP du Serveur de messagerie

Les options suivantes s’appliquent uniquement au sous-agent SNMP basé sur Net-SNMP du serveur de messagerie. Ce sous-agent est utilisé sur les plates-formes Solaris exécutant Solaris10 et versions ultérieures ainsi que sur les plates-formes Linux. Les options décrites ci-dessous ne s’appliquent pas au sous-agent SNMP hérité fourni pour les plates-formes Solaris exécutant Solaris9 et les systèmes d’exploitation antérieurs.

Les options décrites ci-dessous sont configurables options.As telles, leurs valeurs sont inspectées avec une commande de la forme:

% configutil -o option-name

où option-name est le nom de l’optionpour afficher la valeur de. Pour définir ou modifier la valeur d’une option, utilisez une commande du formulaire

% configutil -o option-name -v option-value

où option-value est la valeur à définir.Les modifications apportées à ces options nécessitent un redémarrage pour prendre effet:

% stop-msg snmp% start-msg snmp

Ce qui suit est une description de chaque option avec sa valeur par défaut.

Options du Sous–agent SNMP du Tableau A-1

Option (Par défaut)	Description
local.SNMP.activer(0)	Le sous-agent SNMP du serveur de messagerie ne s’exécutera que lorsque cette option aura une valeur de 1 ou true dans le cas où le serveur de messagerie s’arrêtera et démarrera automatiquement le sous-agent en tant que partie de ses procédures normales de démarrage et d’arrêt. Par défaut, cette option est définie à zéro, ce qui désactive le fonctionnement du sous-agent. Avant d’activer le sous-agent, assurez-vous que l’agent maître de la plate-forme a été correctement configuré comme décrit dans A.3.3 S’exécutant en tant qu’agent SNMP autonome.
local.SNMP.autonome(0)	La prise en charge SNMP du serveur de messagerie s’exécute normalement en tant que sous-agent SNMP, recevant des demandes NMP via l’agent maître SNMP de la plate-forme, snmpd.Ce mode opérationnel est le mode par défaut et est sélectionné en donnant à cette optiona la valeur 0 ou false. Cependant, comme décrit dans A.3.3 S’exécutant en tant qu’Agent SNMP autonome, le sous-agent peut s’exécuter en mode « autonome » dans lequel il fonctionne en tant qu’agent SNMP indépendant de snmpd. Lorsqu’il est exécuté en mode autonome, le sous-agent – nowa SNMP agent – écoute directement les requêtes SNMP sur l’interface Ethernet et le port UDP spécifiés respectivement par le local.SNMP.listenaddr et local.SNMP.options de port. Pour exécuter ce mode autonome, spécifiez une valeur de 1 ou TRUE pour cette option. L’exécution en mode autonome n’interfère pas avec les autres sous-agents maîtres SNMP exécutés sur le système.
local.SNMP.listenaddr (INADDR_TOUT)	Nom d’hôte ou adresse IP de l’interface Ethernet pour écouter les requêtes SNM lors de l’exécution en mode autonome. Par défaut, toutes les interfaces disponibles sont écoutées. Cela correspond à la spécification de la valeur INADDR_ANY.Une interface spécifique peut être sélectionnée en spécifiant l’adresse IP ou le nom d’utilisateur associé à cette interface. L’interface peut être une interface physique ou une interface virtuelle. Cette option est ignorée lorsqu’elle est locale.SNMP.standalone est défini sur 0 ou FALSE.
local.SNMP.cachettl(30)	Durée de vie (TTL) en secondes pour les données de surveillance mises en cache. Cette option contrôle la durée pendant laquelle le sous-agent rapportera les mêmes données de surveillance avant de les remplacer par de nouvelles informations obtenues à partir du serveur de messagerie.À l’exception des informations de boucle de message, les données ne sont mises en cache que pendant 30 secondes par défaut. Informations de boucle, telles que déterminées en recherchant.Les fichiers détenus ne sont mis à jour qu’une fois toutes les 10 minutes. Cela en raison du coût des ressources de l’analyse de toutes les files d’attente de messages sur le disque. Notez que le sous-agent ne met pas continuellement à jour ses données de surveillance : il n’est mis à jour qu’à la réception d’une demande SNMP et que les données mises en cache ont expiré (c’est-à-dire qu’elles ont survécu à leur TTL). Si le TTL est réglé sur 30 secondes et que les requêtes SNM ne sont effectuées que toutes les cinq minutes, chaque requête SNMP obligera le sous-agent à obtenir de nouvelles données du serveur de messagerie. Autrement dit, les données du serveur de messagerie ne seront obtenues qu’une fois toutes les cinq minutes. Si, d’autre part, des requêtes SNMP sont effectuées toutes les 10 secondes, le sous-agent répondra à certaines de ces requêtes avec des données mises en cache aussi anciennes que 29 secondes ; MessagingServer ne sera interrogé qu’une fois toutes les 30 secondes.
local.SNMP.servertimeout(5)	Le sous-agent détermine l’état opérationnel de chaque service surveillé en ouvrant réellement des connexions TCP à chaque service et en subissant un échange de protocole. Cette valeur de délai d’attente, mesurée en secondes, contrôle combien de temps le sous-agent attendra une réponse à chaque étape de l’échange de protocole. Par défaut, une valeur de délai d’attente de cinq secondes est utilisée.
local.SNMP.directeurscan(1)	Utilisez cette option pour contrôler si le sous-agent effectue ou non des analyses des files d’attente de messages sur le disque.Fichiers de messages détenus et les fichiers de messages les plus anciens. Ces informations correspondent aux variables MIB mtaGroupLoopsDetected, mtaGroupOldestMessageStored et mtaGroupOldestMessageId. Lorsque cette option a la valeur 1 ou true, un cache de ces informations est maintenu et mis à jour selon les besoins. Sitesavec des milliers de messages en file d’attente, qui ne sont pas intéressés par ces variables particularMIB devraient envisager de définir la valeur de cette option sur 0 ou false.
local.SNMP.nom du contact activable(0)	Le sous-agent a la possibilité d’enregistrer ses MIB sous un nom de contexte SNMP v3. Lorsque cela est fait, les MIB ne peuvent être demandés que par un client SNMP v3 qui spécifie le nom du contexte dans sa requête SNMP.L’utilisation de noms de contexte permet à plusieurs sous-agents indépendants d’enregistrer des services réseau et des MIB MTA sous la même arborescence O (c’est-à-dire sous le même agent SNMPmaster). Voir A.3.4 Surveillance de plusieurs instances du serveur de messagerie pour plus d’informations. Pour activer l’utilisation des noms de contexte SNMP v3, spécifiez une valeur de 1 ou true pour cette option. Lorsque cela est fait, le sous-agent utilisera par défaut la valeur du service.option defaultdomainpour son nom de contexte. Pour utiliser une valeur différente pour le nom du contexte, utilisez le local.SNMP.option contextname.
local.SNMP.contextname (service.domaine par défaut)	Lorsque l’utilisation des noms de contexte SNMP v3 a été activée avec local.SNMP.enablecontextname, cette option peut être utilisée pour définir explicitement le nom de contexte utilisé par le sous-agent pour ses MIB. Les valeurs fournies pour cette option sont des valeurs de chaîne et doivent être appropriées pour être utilisées comme nom de contexte SNMP v3. Cette option est ignorée lorsqu’elle est locale.SNMP.enablecontextname a la valeur 0 ou false.