A. 3 Configurazione del supporto SNMP per Solaris 10 OS
Per impostazione predefinita, il monitoraggio SNMP è disabilitato all’interno di Messaging Server. Thisdefault è scelto nel tentativo di minimizzare il numero di servizi presentedby una configurazione di Messaging Server predefinita. Non interpretare questo defaultas significa che c’è una penalità di prestazioni sostenute utilizzando il monitoraggio SNMP.In effetti, il supporto SNMP di Messaging Server consuma pochissime risorse eè destinato ad avere un impatto minimo su messaging server. Il risultato di tutto questo è, ovviamente, che sono necessari passaggi di configurazione una tantum prima di utilizzare il supporto SNMP di Messaging Server. Inoltre, la configurazione predefinita dell’agente principale Net-SNMP della piattaforma, snmpd, richiede tipicamente di essere modificata per eseguire subagenti come i server di messaggistica. Thischange è l’argomento della prossima sezione.
A. 3.1 Configurazione Net-SNMP
Il subagente SNMP basato su Net-SNMP di Messaging Server utilizza il protocollo agentxper comunicare con l’agente master SNMP della piattaforma (RFC 2741). L’agente Net-SNMPmaster, snmpd, deve essere configurato per consentire l’uso del protocollo AgentX. Per fare questo, assicurarsi che snmpd della piattaforma.il file conf contiene la riga
master agentx
Se quella riga non è presente, aggiungila e riavvia il demone snmpd. Si noti che l’invio di un segnale SIGHUP al demone non èsufficiente. Una volta che il demone snmpd è stato riavviato, cercare il socket del dominio UNIX che snmpd crea per AgentXcommunications. Su sistemi Solaris e Linux, questo socket per impostazione predefinita appare come file speciale / var/agentx / master; tuttavia, la sua posizione e il suo nome possono essere modificati tramite snmpd.confile.
La configurazione snmpd del sistema operativo Solaris 10 è mostrata di seguito:
%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
Inoltre, su Red Hat Enterprise Linux COME 3 sistemi, il default snmpd.il file conf limita le informazioni che possono essere visualizzate dalla comunità SNMP “pubblica”. È quindi necessario rimuovere thatrestriction o estenderlo per includere i MIB serviti da Messaging serverssubagent. Per i test iniziali, si consiglia di eseguire quest’ultimo. Questo è realizzato includendo i sottoalberi OID mib-2.27 e mib-2.28 nella vista denominata “systemview”come mostrato di seguito. Per la distribuzione effettiva, ogni sito deve prendere in considerazione la propria politica di sicurezza generale. Si noti che le informazioni fornite dail subagente SNMP è “di sola lettura”.
% 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
Se si utilizzeranno nomi di contesto SNMP v3 per distinguere tra theMIBs di diverse istanze di Messaging Server in esecuzione contemporaneamente sullo stesso computer host, sarà inoltre necessario configurare almeno un nome utente e una password SNMPv3 da utilizzare con le query SNMP v3.
A. 3.2 Messaging Server Subagent Configuration
Per il funzionamento di base del subagente SNMP di Messaging Server, è necessario abilitarlo ed emettere un comando di avvio manuale una tantum. D’ora in poi, quando il server di messaggistica viene avviato o arrestato, il subagente verrà avviato o arrestato. I comandi necessari per effettuare questa configurazione su Solarisand Linux sono i seguenti:
% configutil -o local.snmp.enable -v 1% start-msg snmp
Una volta eseguito, è possibile testare il subagente dalla riga di comando con il comando snmpwalk. Vedere le schermate sotto un esempio appropriateto Solaris e Linux. Si noti che i file rfc2248.txt e rfc2249.txt sono copie dei servizi di rete e MTA MIB. OnSolaris systems, questi file possono anche essere trovati nella directory/etc/sma/snmp/ mib / sotto i nomi NETWORK-SERVICES-MIB.txt e MTA-MIB.txt. Non è necessario fornire questi file allo strumento snmpwalk; tuttavia, ciò consente a snmpwalk di selezionare i nomi per ciascuna delle variabili MIB piuttosto che i loro objectidentifiers (OID) numerici.
Test di base su 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...
Test di base su 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 Esecuzione come agente SNMP autonomo
Prima di configurare il subagente SNMP di Messaging Server per l’esecuzione come agente standaloneSNMP, è necessario prima decidere quale interfaccia Ethernet e porta UDP si desidera ascoltare per le richieste SNMP. Per impostazione predefinita, ascolterà tutte le interfacce Ethernet disponibili utilizzando la porta UDP 161. Nella maggior parte dei casi, si desidera modificare il numero di porta in modo da non interferire con l’agente master SSNMP della piattaforma, snmpd. In alcune circostanze, come il failover, si desidera anche modificare l’interfaccia Ethernet da all availableinterfaces INAD INADDR_ANY to a un’interfaccia specifica identificata dal suo indirizzo IP. Questi due concetti, interfaccia Ethernet e porta UDP, sono controllati tramite il locale.SNMP.listenaddr e locale.SNMP.opzioni porta.
Una volta scelte per l’interfaccia Ethernet e la porta UPD sono state fatte, il locale.SNMP.l’opzione standalone dovrebbe avere il suo valueset su uno e il subagente riavviato. Una volta riavviato, opererà come agente SNMP indipendente da snmpd e da eventuali subagenti.
Ad esempio, per eseguire come un agente standalone ascolto sulla porta UDP 9161dell’interfaccia Ethernet con indirizzo IP 10.53.1.37, emettere i comandi shownbelow.
Configurazione per l’esecuzione come agente autonomo:
% 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 Monitoraggio di più istanze di Messaging Server
Nel presente documento vengono discusse due tecniche per il monitoraggio di più istanze di Messaging Serverrunning sullo stesso computer host. La prima tecnica, che esegue il subagent in modalità standalone, è adatta alle configurazioni HA (high availabilityfailover) in cui le singole istanze di MessagingServer possono spostarsi dinamicamente tra i computer host. La seconda tecnica, l’uso di nomi di contesto SNMP v3, ha qualche beneficio limitato in situazioni in cui più istanze di Messaging Server sono limitate a un singolo sistema ed è auspicabile limitare il numero di indirizzi IP interrogati dal software di monitoraggio SNMP (ad esempio, quando la licenza del software di monitoraggio ha un componente di costo dell’indirizzo perIP). Quest’ultima tecnica può anche essere utilizzata in HA failoversettings ma richiederebbe il polling di altrettanti indirizzi IP come la tecnica standalonemode.
A. 3.5 Utilizzo di agenti autonomi per il failover ad alta disponibilità
In un’impostazione di failover ad alta disponibilità in cui si desidera il monitoraggio SNMP di MessagingServer, si consiglia di eseguire SNMPsubagent di Messaging Server come agente autonomo come descritto in A. 3.3 Esecuzione come agente SNMP autonomo. Quando i subagenti vengono eseguiti in standalonemode, ogni istanza HA di Messaging Server deve avere il suo locale.SNMP.opzione listenaddr impostata sul valore dell’IP di failover dell’istanza address.To semplificare la gestione, ogni istanza dovrebbe utilizzare la stessa porta UDP, ma thatport dovrebbe essere distinta da quelle utilizzate dai demoni snmpd che eseguono su ciascuno degli host del cluster fisico. In genere questi demoni useranno la porta UDP 161, quindi specificheranno esplicitamente un numero di porta diverso con il locale.SNMP.opzione porta.
Quando il supporto SNMP di Messaging Server è configurato come raccomandato qui,una stazione di monitoraggio può monitorare ogni istanza di Messaging Server tramite il suo indirizzo IP o il nome host, indipendentemente dal cluster fisico su cui è in esecuzione l’istanza. Inoltre, si è certi che gli agenti SNMP di Messaging Server standalone non entreranno in conflitto l’uno con l’altro poiché ogni listensonly sulla propria interfaccia Ethernet virtuale identificata dall’indirizzo IP uniquefailover di quell’istanza. (Queste interfacce Ethernet virtuali sono automaticallycreated dal framework HA failover.) A causa dell’attenta selezione della porta aUDP, gli agenti non sono in conflitto con i demoni snmpd che girano sui sistemi all’interno del cluster.
A. 3.6 Distinguere Più Istanze Tramite SNMP v3Context Nomi
Mentre non vi è alcuna controindicazione all’utilizzo di Server di Messaggistica SNMP supportin modalità standalone come descritto in A. 3.3 in Esecuzione come indipendente Agente SNMP, è riconosciuto che alcuni siti potrebbero preferire l’uso di un moretraditional subagente modalità, pur mantenendo la capacità di monitoringmultiple istanze di Server di Messaggistica in esecuzione contemporaneamente sullo stesso sistema.Ad esempio, un sistema di monitoraggio SNMP il cui modello di licenza limita il numero di indirizzi IP che possono essere interrogati. Per raggiungere questo obiettivo, continuare a eseguireil subagente SNMP del server Messaging con local.SNMP.standalone setto zero. Inoltre, configurare ogni istanza di Messaging Server per utilizzareun nome di contesto distinto SNMP v3 specificando un valore diverso da zero per il locale.SNMP.enablecontextname opzione. Se un nome di contesto diverso dal valore del servizio.defaultdomain è desiderato, quindi impostare il nome desiderato con il locale.SNMP.opzione contextname. Una volta riavviata ogni istanza del subagent SNMP di Messaging Server, possono essere monitorati tramite query SNMP v3 che includono i nomi di contesto appropriati. I MIB di due istanze di Messaging Server in esecuzione sullo stesso sistema si distinguono per il nome di contesto SNMP v3 dell’istanza e quindi non si verificheranno conflitti OID (MIB Object Identifier).
A. 3.7 Opzioni subagente SNMP basate su Net-SNMP di Messaging Server
Le seguenti opzioni si applicano solo al subagente SNMP basato su Net-SNMP di Messaging Server. Questo subagente viene utilizzato su piattaforme Solaris che eseguono Solaris10 e versioni successive, nonché su piattaforme Linux. Le opzioni descritte di seguito non si applicano al subagente SNMP legacy fornito per le piattaforme Solaris che eseguono Solaris9 e sistemi operativi precedenti.
Le opzioni descritte di seguito sono configutil options.As tali, i loro valori sono ispezionati con un comando del modulo:
% configutil -o option-name
dove option-name è il nome dell’opzioneper visualizzare il valore di. Per impostare o modificare il valore di un’opzione, utilizzare un comandodel modulo
% configutil -o option-name -v option-value
dove option-value è il valore da impostare.Le modifiche a queste opzioni richiedono un riavvio per avere effetto:
% stop-msg snmp% start-msg snmp
Quello che segue è una descrizione di ogni opzione insieme al suo defaultvalue.
Tabella A–1 Opzioni subagente SNMP
Opzione (Predefinita) |
Descrizione |
locale.SNMP.abilita(0) |
Il subagent SNMP di Messaging Server verrà eseguito solo quando questa opzione isgiven un valore di 1 o true in whichcase Messaging Server si fermerà automaticamente e avviare il subagent come partof sue normali procedure di avvio e di arresto. Per impostazione predefinita questa opzione è impostata su zero che disabilita il funzionamento del subagente. Prima di abilitare l’agente secondario,assicurarsi che l’agente principale della piattaforma sia stato configurato correttamente come descritto in A. 3.3 in esecuzione come agente SNMP autonomo. |
locale.SNMP.autonomo(0) |
Il supporto SNMP di Messaging Server viene normalmente eseguito come subagente SNMP, ricevendo richieste NMP tramite l’agente master SNMP della piattaforma, snmpd.Questa modalità operativa è quella predefinita e viene selezionata assegnando a questa opzione un valore pari a 0 o false. Tuttavia, come descritto in A. 3.3 In esecuzione come agente SNMP autonomo, l’agente secondario può essere eseguito in una modalità “standalone” in cui opera come agente SNMP indipendente da snmpd. Quando viene eseguito in modalità standalone, il subagente now nowa SNMP agent listens ascolta direttamente le richieste SNMP sull’interfaccia Ethernet e sulla porta UDP specificate rispettivamente dal locale.SNMP.listenaddr e locale.SNMP.opzioni porta. Per eseguire in questa modalità standalone, specificareun valore di 1 o TRUE per questa opzione. L’esecuzione in modalità standalone non interferisce con altri subagenti masteror SNMP in esecuzione sul sistema. |
locale.SNMP.listenaddr (INADDR_ANY) |
Nome host o indirizzo IP dell’interfaccia Ethernet per l’ascolto di SNMPrequests durante l’esecuzione in modalità standalone. Per impostazione predefinita, tutte le interfacce disponibilisono ascoltati. Questo corrisponde a specificare il valore INADDR_ANY.È possibile selezionare un’interfaccia specifica specificando l’indirizzo IP o il nomeost associato a tale interfaccia. L’interfaccia può essere un fisicointerfaccia o un’interfaccia virtuale. Questa opzione viene ignorata quando locale.SNMP.standalone isset a 0 o FALSE. |
locale.SNMP.cachettl(30) |
Time to live (TTL) in secondi per i dati di monitoraggio memorizzati nella cache. Questa opzione controlla per quanto tempo il subagente riporterà gli stessi dati di monitoraggio prima di aggiornare i dati con nuove informazioni ottenute da Messaging Server.Ad eccezione delle informazioni sul ciclo dei messaggi, i dati vengono memorizzati nella cache per non più di 30 secondi per impostazione predefinita. Informazioni loop, come determinato dalla scansione per .File DETENUTI, viene aggiornato solo una volta ogni 10 minuti. Che becauseof il costo delle risorse di scansione di tutte le code di messaggi su disco. Si noti che il subagente non aggiorna continuamente i suoi dati di monitoraggio:viene aggiornato solo al ricevimento di una richiesta SNMP e i dati memorizzati nella cache sono scaduti (ovvero sono sopravvissuti al TTL). Se il TTL è impostato su 30 secondi e SNMPrequests vengono effettuate solo ogni cinque minuti, quindi ogni richiesta SNMP causethe subagent per ottenere nuovi dati da Messaging Server. Cioè, i dati dail server di messaggistica sarà ottenuto solo una volta ogni cinque minuti. Se, d’altra parte, le richieste SNMP vengono effettuate ogni 10 secondi, il subagente risponderà ad alcune di quelle richieste con dati memorizzati nella cache di 29 secondi; MessagingServer verrà interrogato solo una volta ogni 30 secondi. |
locale.SNMP.servertimeout(5) |
Il subagente determina lo stato operativo di ciascun servizio monitorato, aprendo effettivamente le connessioni TCP a ciascun servizio e subendo un protocolexchange. Questo valore di timeout, misurato in secondi, controlla per quanto tempo il subagent attenderà una risposta ad ogni passaggio nello scambio di protocollo. Per impostazione predefinita, viene utilizzato un valore di timeout di cinque secondi. |
locale.SNMP.directoryscan(1) |
Utilizzare questa opzione per controllare se il subagente esegue scansof le code di messaggi su disco per .File di messaggi detenuti ei file di messaggi più vecchi. Tali informazioni corrispondono alle variabili MIB mtaGroupLoopsDetected, mtaGroupOldestMessageStored e mtaGroupOldestMessageId. Quando questa opzione ha il valore 1 o true, una cache di queste informazioni viene mantenuta e aggiornata secondo necessità. Siti con migliaia di messaggi in coda, che non sono interessati a queste variabili particularMIB dovrebbero considerare l’impostazione del valore di questa opzione su 0 o false. |
locale.SNMP.enablecontextname(0) |
Il subagente ha la possibilità di registrare i propri MIB con un nome di contesto SNMP v3. Quando ciò viene fatto, i MIB possono essere richiesti solo da un client SNMP v3 che specifica il nome del contesto nella sua richiesta SNMP.L’uso di nomi di contesto consente a più subagenti indipendenti di registrare NetworkServices e MTA MIBs sotto lo stesso albero OID (ovvero sotto lo stesso agente SNMPmaster). Vedere A. 3.4 Monitoraggio di più istanze di Messaging Server per ulteriori informazioni. Per abilitare l’uso dei nomi di contesto SNMP v3, specificare un valore pari a 1 o true per questa opzione. Quando ciò è fatto, il subagente sarà defaultto utilizzando il valore del servizio.opzione defaultdomain per il suo nome di contesto. Per utilizzare un valore diverso per il nome del contesto, utilizzare il locale.SNMP.opzione contextname. |
locale.SNMP.contextname (servizio.defaultdomain) |
Quando l’uso dei nomi di contesto SNMP v3 è stato abilitato con local.SNMP.enablecontextname, questa opzione può essere utilizzata per impostare esplicitamente il nome del contesto utilizzato dal subagente per i suoi MIB. I valori forniti per questa opzione sono stringvalues e devono essere appropriati per l’uso come nome di contesto SNMP v3. Questa opzioneè ignorato quando locale.SNMP.enablecontextname ha value0 o false. |