• Articles
• admin

De forma predeterminada, la supervisión de SNMP está deshabilitada dentro del Servidor de mensajería. Esta opción predeterminada se elige en un intento de minimizar el número de servicios presentados por una configuración de servidor de mensajería predeterminada. No interprete estos valores predeterminados en el sentido de que hay una penalización de rendimiento incurrida por el uso de la supervisión SNMP.De hecho, el soporte SNMP de Messaging Server consume muy pocos recursos y está destinado a tener un impacto mínimo en el servidor de mensajería. El resultado de todo esto es, por supuesto, que se requieren pasos de configuración únicos antes de usar el soporte SNMP de Messaging Server. Además, la configuración predeterminada del agente maestro Net-SNMP de la plataforma, snmpd, normalmente debe cambiarse para ejecutar subagentes, como servidores de mensajería. Este cambio es el tema de la siguiente sección.

A. 3.1 Configuración Net-SNMP

El subagente SNMP basado en Net-SNMP del servidor de mensajería utiliza el protocolo AgentX para comunicarse con el agente maestro SNMP de la plataforma (RFC 2741). El agente Net-SNMPmaster, snmpd, debe estar configurado para permitir el uso del protocolo AgentX. Para hacer esto, asegúrese de que el snmpd de la plataforma.el archivo conf contiene la línea

master agentx

Si esa línea no está presente, agréguela y reinicie el demonio snmpd. Tenga en cuenta que enviar una señal SIGHUP al demonio no es suficiente. Una vez reiniciado el demonio snmpd, busque el socket de dominio UNIX que crea snmpd para AgentXcommunications. En los sistemas Solaris y Linux, este socket por defecto aparece como el archivo especial / var/agentx / master; sin embargo, su ubicación y nombre se pueden cambiar a través del snmpd.confile.

La configuración de Solaris 10 OS snmpd se muestra a continuación:

%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

Además, en los sistemas Red Hat Enterprise Linux AS 3, el snmpd predeterminado.el archivo conf restringe la información que puede ser vista por la comunidad SNMP «pública». Por lo tanto, es necesario eliminar esa restricción o ampliarla para incluir los MIB servidos por el subagente del servidor de mensajería. Para la prueba inicial, se recomienda hacer la última. Esto se logra mediante la inclusión de los subárboles OID mib-2.27 y mib-2.28 en la vista denominada «systemview», como se muestra a continuación. Para la implementación real, cada sitio debe tener en cuenta su política de seguridad general. Tenga en cuenta que la información proporcionada por el subagente SNMP es de «solo lectura».

% 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 va a usar nombres de contexto SNMP v3 para distinguir entre las diferentes instancias del Servidor de mensajería que se ejecutan simultáneamente en el mismo equipo host, también necesitará configurar al menos un nombre de usuario y contraseña SNMPv3 para usar con sus consultas SNMP v3.

A. 3. 2 Configuración del subagente del servidor de mensajería

Para el funcionamiento básico del subagente SNMP del servidor de mensajería, solo necesita activarlo y emitir un comando de inicio manual de una sola vez. De ahora en adelante, cuando se inicie o detenga cualquier servidor de mensajería, el subagente también se iniciará o se detendrá. Los comandos necesarios para efectuar esta configuración en Solaris y Linux son los siguientes:

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

Una vez que se ejecuta, puede probar el subagente desde la línea de comandos con el comando snmpwalk. Vea las capturas de pantalla a continuación un ejemplo apropiado para Solaris y Linux. Tenga en cuenta que los archivos rfc2248.txt y rfc2249.txt son copias de los Servicios de Red y MIB de MTA. Sistemasololaris, estos archivos también se pueden encontrar en el directorio/etc/sma/snmp/ mibs / bajo los nombres NETWORK-SERVICES-MIB.txt y MTA-MIB.txt. No es necesario proporcionar estos archivos a la herramienta snmpwalk; sin embargo, al hacerlo, permite imprimir nombres snmpwalk para cada una de las variables MIB en lugar de sus identificadores de objetos numéricos (OID).

pruebas Básicas en 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...

pruebas Básicas en 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 Ejecutándose como agente SNMP independiente

Antes de configurar el subagente SNMP del Servidor de mensajería para que se ejecute como agente NMP estándar, primero debe decidir qué interfaz Ethernet y puerto UDP desea que escuche solicitudes SNMP. De forma predeterminada, escuchará todas las interfaces Ethernet disponibles utilizando el puerto UDP 161. En la mayoría de los casos, querrá cambiar el número de puerto para no interferir con el agente maestro SNMP de la plataforma, snmpd. En algunas circunstancias, como la conmutación por error de HA, también querrá cambiar la interfaz Ethernet de todas las interfaces disponibles INAD INADDR_ANY to a una interfaz específica identificada por su dirección IP. Estos dos conceptos, interfaz Ethernet y puerto UDP, se controlan a través del local.snmp.listenaddr y local.snmp.opciones de puertos.

Una vez que se hayan hecho las elecciones para la interfaz Ethernet y el puerto UPD,el local.snmp.la opción independiente debe tener su conjunto de valores en uno y el subagente debe reiniciarse. Una vez reiniciado, operará como agente SNMP independiente de snmpd y de cualquier subagente.

Por ejemplo, para ejecutar como agente independiente escuchando en el puerto UDP 9161 de la interfaz Ethernet con dirección IP 10.53.1.37, ejecute los comandos mostrados a continuación.

Configurando para ejecutarse como agente independiente:

% 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 Supervisión de varias instancias del Servidor de Mensajería

En el presente documento se describen dos técnicas para supervisar varias instancias del funcionamiento del Servidor de mensajería en el mismo equipo host. La primera técnica, ejecutar el subagente en modo independiente, es adecuada para configuraciones de alta disponibilidad (HA) en las que las instancias individuales de MessagingServer pueden moverse dinámicamente entre equipos host. La segunda técnica, el uso de nombres de contexto SNMP v3, tiene algún beneficio limitado en situaciones en las que múltiples instancias de Servidor de mensajería se limitan a un solo sistema y es deseable limitar el número de direcciones IP encuestadas por el software de monitoreo SNMP (por ejemplo, cuando la licencia del software de monitoreo tiene un componente de costo de dirección perIP). Esta última técnica también se puede usar en configuraciones de conmutación por error de HA, pero requeriría el sondeo de tantas direcciones IP como la técnica standalonemode.

A. 3.5 Uso de agentes independientes para Conmutación por error de alta disponibilidad

En una configuración de conmutación por error de alta disponibilidad en la que se desee la supervisión SNMP de MessagingServer, se recomienda ejecutar SNMPsubagent de Messaging Server como agente independiente, como se describe en A. 3.3 En ejecución como Agente SNMP independiente. Cuando los subagentes se ejecutan en modo standalonemode, cada instancia de HA del Servidor de mensajería debe tener su local.snmp.opción listenaddr establecida en el valor de la IP de conmutación por error de esa instancia address.To simplifique la administración, cada instancia debe usar el mismo puerto UDP, pero ese puerto debe ser distinto de los utilizados por el procesamiento de demonios snmpd en cada uno de los hosts físicos del clúster. Por lo general, esos demonios usarán el puerto UDP 161, por lo que especificarán explícitamente un número de puerto diferente con el local.snmp.opción de puerto.

Cuando la compatibilidad con SNMP del servidor de mensajería está configurada como se recomienda aquí, una estación de monitoreo puede monitorear cada instancia del Servidor de mensajería a través de su dirección IP de transferencia de correo o nombre de host, independientemente del host de clúster físico en el que se esté ejecutando la instancia. Además, está seguro de que los agentes SNMP individuales del servidor de mensajería no entrarán en conflicto entre sí, ya que cada uno solo escucha en su propia interfaz Ethernet virtual identificada por la dirección IP de filtrado de correo única de esa instancia. (Estas interfaces Ethernet virtuales son creadas automáticamente por el marco de conmutación por error de HA.) Debido a la cuidadosa selección del puerto aUDP, los agentes no entran en conflicto con el procesamiento de demonios snmpd en sistemas dentro del clúster.

A. 3.6 Distinguir varias instancias a través de Nombres de texto SNMP V3

Si bien no hay inconveniente en usar el soporte SNMP de Messaging Server en modo independiente como se describe en A. 3.3 que se ejecuta como un agente SNMP Independiente, se reconoce que algunos sitios pueden preferir usar un modo subagente más tradicional mientras mantienen la capacidad de monitorear múltiples instancias de Messaging Server que se ejecutan simultáneamente en el mismo sistema.Por ejemplo, un sistema de monitoreo SNMP cuyo modelo de licencia limita el número de direcciones IP que se pueden sondear. Para lograr este objetivo, continúe ejecutando el subagente SNMP del servidor de mensajes con local.snmp.set independiente a cero. Además, configure cada instancia del servidor de mensajería para que utilice un nombre de contexto SNMP v3 distinto especificando un valor distinto de cero para el local.snmp.opción enablecontextname. Si es un nombre de contexto diferente al valor de servicio.se desea dominio predeterminado, luego establezca el nombre deseado con el local.snmp.opción contextname. Una vez que se reinicie cada instancia del subagente SNMP del servidor de mensajería, se pueden monitorear a través de consultas SNMP v3 que incluyen los nombres de contexto adecuados. Los MIB de dos instancias del Servidor de mensajería ejecutándose en el mismo sistema se distinguen por el nombre de contexto SNMP v3 de la instancia, por lo que no surgirán conflictos de identificador de objeto MIB (OID).

A. 3.7 Opciones de subagente SNMP basado en SNMP de red del servidor de mensajería

Las siguientes opciones se aplican solo al subagente SNMP basado en SNMP de red del servidor de Mensajería. Ese subagente se usa en plataformas Solaris que ejecutan Solaris10 y versiones posteriores, así como en plataformas Linux. Las opciones que se describen a continuación no se aplican al subagente SNMP heredado suministrado para plataformas Solaris que ejecutan Solaris9 y sistemas operativos anteriores.

Las opciones que se describen a continuación son configutil options.As tales, sus valores se inspeccionan con un comando de la forma:

% configutil -o option-name

donde option-name es el nombre de la opciónpara mostrar el valor de. Para establecer o cambiar el valor de una opción, utilice un comando del formulario

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

donde option-value es el valor a establecer.Los cambios en estas opciones requieren un reinicio para que surtan efecto:

% stop-msg snmp% start-msg snmp

Lo que sigue es una descripción de cada opción junto con su valor predeterminado.

Opciones de Subagente SNMP de la Tabla A–1

Opción (Predeterminada)	Descripción
local.snmp.habilitar(0)	El subagente SNMP del servidor de mensajería solo se ejecutará cuando esta opción tenga un valor de 1 o true, en cuyo caso el servidor de mensajería se detendrá e iniciará automáticamente el subagente como parte de sus procedimientos normales de inicio y apagado. De forma predeterminada, esta opción se establece en cero, lo que deshabilita el funcionamiento del subagente. Antes de habilitar el subagente,asegúrese de que el agente maestro de la plataforma se ha configurado correctamente como se describe en A. 3.3 Que se ejecuta como Agente SNMP independiente.
local.snmp.independiente(0)	El soporte SNMP del servidor de mensajería normalmente se ejecuta como un subagente SNMP, que recibe solicitudes SNMP a través del agente maestro SNMP de la plataforma, snmpd.Este modo operativo es el predeterminado y se selecciona dando a esta opciónun valor de 0 o false. Sin embargo, como se describe en la sección A. 3.3 que se ejecuta como un agente SNMP Independiente, el subagente puede ejecutarse en modo «independiente» en el que opera como un agente SNMP independiente de snmpd. Cuando se ejecuta en modo independiente, el subagente now nowa agente SNMP listens escucha directamente las solicitudes SNMP en la interfaz Ethernet y el puerto UDP especificados por, respectivamente, el local.snmp.listenaddr y local.snmp.opciones de puertos. Para ejecutarse en este modo independiente, especifique un valor de 1 o TRUE para esta opción. La ejecución en modo independiente no interfiere con otros subagentes o maestros SNMP que se ejecutan en el sistema.
local.snmp.listenaddr (INADDR_ANY)	Nombre de host o dirección IP de la interfaz Ethernet para escuchar las preferencias de SNM cuando se ejecuta en modo independiente. De forma predeterminada, se escuchan todas las interfaces disponibles. Esto corresponde a especificar el valor INADDR_ANY.Se puede seleccionar una interfaz específica especificando la dirección IP o el nombre de host asociado a esa interfaz. La interfaz puede ser una interfaz física o una interfaz virtual. Esta opción se ignora cuando es local.snmp.isset independiente a 0 o FALSE.
local.snmp.cachettl(30)	Tiempo de vida (TTL) en segundos para los datos de monitoreo almacenados en caché. Esta opción controla durante cuánto tiempo el subagente reportará los mismos datos de monitoreo antes de actualizar esos datos con nueva información obtenida del servidor de mensajería.Con la excepción de la información de bucle de mensajes, los datos se almacenan en caché durante no más de 30 segundos de forma predeterminada. Información de bucle, según lo determinado por el escaneo .Archivos EN ESPERA, se actualiza solo una vez cada 10 minutos. Eso se debe al costo de recursos de escanear todas las colas de mensajes en el disco. Tenga en cuenta que el subagente no actualiza continuamente sus datos de monitoreo:solo se actualiza al recibir una solicitud SNMP y los datos almacenados en caché han expirado (es decir, han sobrevivido a su TTL). Si el TTL se establece en 30 segundos y las peticiones SNM se realizan solo cada cinco minutos, entonces cada solicitud SNMP hará que el subagente obtenga datos nuevos del servidor de mensajería. Es decir, los datos del servidor de mensajería se obtendrán solo una vez cada cinco minutos. Si, por otro lado, las solicitudes SNMP se realizan cada 10 segundos, el subagente responderá a algunas de esas solicitudes con datos almacenados en caché de tan solo 29 segundos; el servidor de mensajes se sondeará solo una vez cada 30 segundos.
local.snmp.tiempo de espera del servidor(5)	El subagente determina el estado operativo de cada servicio monitoreado al abrir realmente conexiones TCP a cada servicio y someterse a un intercambio de protocolo. Este valor de tiempo de espera, medido en segundos, controla cuánto tiempo esperará el subagente una respuesta a cada paso en el intercambio de protocolos. De forma predeterminada,se utiliza un valor de tiempo de espera de cinco segundos.
local.snmp.directoryscan(1)	Utilice esta opción para controlar si el subagente realiza o no escaneos de las colas de mensajes en disco para las que se realizan .Archivos de mensajes EN espera y los archivos de mensajes más antiguos. Esa información corresponde a las variables MIB mtaGroupLoopsDetected, mtaGroupOldestMessageStored y mtaGroupOldestMessageId. Cuando esta opción tiene el valor 1 o true,se mantiene y actualiza una caché de esta información según sea necesario. Los sitios con miles de mensajes en cola, que no están interesados en estas variables de memoria en particular, deberían considerar establecer el valor de esta opción en 0 o false.
local.snmp.enablecontextname(0)	El subagente tiene la capacidad de registrar sus MIBs bajo un nombre de contexto SNMP v3. Cuando esto se hace, los MIBs solo pueden ser solicitados por un cliente SNMP v3 que especifique el nombre de contexto en su solicitud SNMP.El uso de nombres de contexto permite que varios subagentes independientes registren NetworkServices y MIB de MTA bajo el mismo árbol de OID (es decir, bajo el mismo agente SNMPmaster). Consulte A. 3.4 Supervisión de varias instancias del Servidor de mensajería para obtener más información. Para habilitar el uso de nombres de contexto SNMP v3, especifique un valor de 1 o true para esta opción. Una vez hecho esto, el subagente utilizará de forma predeterminada el valor del servicio.opción de dominio predeterminado para su nombre de contexto. Para usar un valor diferente para el nombre de contexto, use el local.snmp.opción contextname.
local.snmp.contextname (service.dominio predeterminado)	Cuando se ha habilitado el uso de nombres de contexto SNMP v3 con local.snmp.enablecontextname, esta opción se puede usar para establecer explícitamente el nombre de contexto utilizado por el subagente para sus MIB. Los valores suministrados para esta opción son valores de cadena y deben ser apropiados para su uso como nombre de contexto SNMP v3. Esta opción se ignora cuando es local.snmp.enablecontextname tiene el valor 0 o false.