Atividade Pratica – SNMP

Transcrição

Atividade Pratica – SNMP
Atividade Prática 02
Gerenciamento de Servidores GNU/Linux Utilizando SNMP v1 e v2c
A implementação do protocolo SNMP em Servidores Linux se dá geralmente através do netsnmp (http://www.net-snmp.org). Na distribuição CentOS (http://www.centos.org), utilizada durante
os exemplo práticos, temos 4 pacotes que fazem essa implementação:
•
net-snmp: Binários, arquivos de configuração, arquivos de inicialização e
documentação;
•
•
net-snmp-devel: Arquivos fontes;
net-snmp-utils: Binários adicionais, como snmpget, snmpgetnext, snmpset,
snmpwalk, etc; e arquivos man;
•
net-snmp-libs: Bibliotecas, documentações e MIBS default localizadas no
/usr/share/snmp/mibs.
1. Instalação dos binários
# yum -y install net-snmp net-snmp-devel net-snmp-utils net-snmplibs
2. Iniciar o serviço automaticamente
# ntsysv
Figura 1 - NTSYSV
Selecione as opções “snmpd” e “snmpdtrapd” e clique em “OK”.
3. Estrutura do net-snmp após a instalação dos binários
•
•
•
/etc/rc.d/init.d/: Arquivos de inicialização;
/etc/snmp: Arquivos de configuração;
/etc/sysconfig/snmpd: Arquivos de configuração
/var/run/snmpd.pid;
•
•
•
•
•
•
•
/usr/bin/ e /usr/sbin/: Binários do sistema;
/usr/include/net-snmp/: Arquivos fonte;
/usr/lib64/: Bibliotecas 64 bits;
/usr/share/doc/ e /usr/share/man/: Documentação;
/usr/share/snmp/: Arquivos e dados de configuração usados pelo sistema;
•
/var/run/net-snmp/: Previsto para armazenar dados temporários de execução que
descrevem o estado do sistema, como PIDs, por exemplo, que no caso do CentOS é
armazenado direto em /var/run/snmpd.pid.
de
sistema;
geram
o
/usr/share/snmp/mibs/: MIBs default;
/var/lib/net-snmp/: No momento em que o serviço é iniciado, carrega a configuração
do net-snmpd.conf e as mibs disponíveis no sistema;
4. Backup do arquivo de configuração original (snmpd.conf)
As boas práticas em administração de servidores nos sinalizam que é importante realizar um
backup dos arquivos de configuração originais de todo e qualquer serviço, antes de realizarmos
alterações nas condigurações padrão. A fora isso, no caso do snmpd.conf, o mesmo é uma exelente
fonte de estudos. Em nosso caso, vamos mover o arquivo, pois em todos os exemplos criaremos o
nosso próprio arquivo de configuração.
# mv /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.orig
5. Configuração Básica de um Agente SNMP v1/v2c
Para que um servidor responda às solicitações do protocolo SNMP v1 e v2c, ele só precisa de
uma linha no seguinte formato:
rocommunity nome_da_comunidade
Representa uma comunidade com direito de leitura.
rwcommunity nome_da_comunidade
Representa uma comunidade com direito de leitura e escrita.
Podem ser informadas apenas comunidades com direito de leitura, comunidades com direito
de escrita ou ambas; basta colocar uma informação por linha.
# cat snmpd.conf
# /etc/snmp/snmpd.conf v1/v2c básico (snmpd.conf.01)
#
rocommunity
public rwcommunity
private
Após alterar o arquivo, é necessário reiniciar o serviço:
# service snmpd restart
O status do serviço pode ser verificado através do comando:
# service snmpd status
6. Acessando um Agente SNMP v1/v2c
6.1. Comando snmpget
A leitura de informações de um host é feita através do comando snmpget:
# snmpget -v 1 -c public localhost sysContact.0
SNMPv2-MIB::sysContact.0 = STRING: root@localhost
# snmpget -v 2c -c public localhost sysContact.0
SNMPv2-MIB::sysContact.0 = STRING: root@localhost
8.6.1.1. Explicando o comando:
•
•
•
•
snmpget: Comando para ler informações do host;
-v: Versão do protocolo – pode ser 1 ou 2c;
-c: Comunidade, no nosso exemplo, public;
localhost: Endereço do host ao qual será solicitada a informação, sendo nome DNS
ou IP.
•
sysContact.0: Informação que será solicitada ao host.
Como pode ser observado acima, o servidor responde às solicitações da versão 1 e 2c do
protocolo SNMP. Nesse caso solicitamos a informação sysContact.0, que corresponde ao responsável
pelo host. Como isso não foi informado no arquivo de configuração, a resposta é a default do sistema.
Por que sysContact.0 e não apenas sysContact? Como já mencionamos anteriormente, cada
objeto possui uma identificação única, que é sua posição na árvore da MIB. No caso do contato,
teremos apenas um responsável cadastrado, mas se pensarmos, em interfaces de rede, por exemplo,
geralmente teremos mais de uma, e nesse caso poderíamos ler informações como:
A descrição da primeira interface de rede:
# snmpget -v 2c -c public localhost ifDescr.1
IF-MIB::ifDescr.1 = STRING: lo
A descrição da segunda interface de rede:
# snmpget -v 2c -c public localhost ifDescr.2
IF-MIB::ifDescr.2 = STRING: eth0
6.2. Comando snmpset
A alteração de informações de um host é feita através do comando snmpset, que vai
confirmar se a comunidade utilizada possui ou não privilégio suficiente para executar essa ação:
# snmpset -v 1 -c public localhost sysContact.0 s aulas Error
in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: SNMPv2-MIB::sysContact.0
# snmpset -v 2c -c public localhost sysContact.0 s aulas
Error in packet.
Reason: noAccess
Failed object: SNMPv2-MIB::sysContact.0
Observe que na versão 2c as mensagens se tornaram mais claras, por isso sempre que
o host possuir suporte, é aconselhável utilizar a versão 2c. Nesses exemplos o problema foi a
utilização da comunidade public, que tem direito apenas de leitura no host.
# snmpset -v 2c -c private localhost sysContact.0 s aulas
SNMPv2-MIB::sysContact.0 = STRING: aulas
6.2.1. Explicando o comando:
•
•
•
•
snmpset: Comando para alterar informações do host;
-v: Versão do protocolo – pode ser 1 ou 2c;
-c: Comunidade – no nosso exemplo private;
localhost: Endereço do host ao qual será solicitada a informação, sendo nome
DNS ou IP.
•
•
•
sysContact.0: Informação que será alterada no host;
s: Tipo de dado da informação, neste caso String;
aulas: Dado que será gravado no campo sysContact.0.
Observe que sempre que realizarmos uma alteração no host, receberemos uma
mensagem de retorno, que pode ser uma mensagem de falha ou a confirmação de que a
informação foi alterada, como no exemplo acima: “SNMPv2-MIB::sysContact.0 = STRING:
aulas”.
6.3. Comando snmpgetnetxt
Sabendo da existência de uma determinada informação, podemos solicitar ao host qual
é a próxima informação, e assim percorrer todas as informações daquele host, para isso
utilizamos o comando snmpgetnext:
# snmpgetnext -v 2c -c public localhost sysContact.0
SNMPv2-MIB::sysName.0 = STRING: aulas
O comando retorna que a próxima informação depois de sysContact.0 é sysName.0,
dado do tipo string, e que o valor atual é aulas: “SNMPv2-MIB::sysName.0 = STRING: aulas”.
sysName.0 é o campo que contém o nome que identifica este host.
Mais um exemplo:
# snmpgetnext -v 2c -c public localhost sysName.0
SNMPv2-MIB::sysLocation.0 = STRING: Unknown
O comando retorna que a próxima informação, depois de sysName.0, é sysLocation.0,
dado do tipo string e que o valor atual é desconhecido: “SNMPv2MIB::sysLocation.0 = STRING:
Unknown”. sysLocation.0 é o campo com a identificação da localização do host.
6.4. Comando snmpwalk
O comando snmpgetnext é útil quando desejamos conhecer uma ou duas informações
a partir de determinado ponto da árvore da MIB, mas para percorrermos um galho inteiro ou
mesmo toda a árvore, o mesmo se torna inviável. Para isso temos o comando snmpwalk:
# snmpwalk -v 2c -c public localhost system
SNMPv2-MIB::sysDescr.0 = STRING: Linux aulas 2.6.3271.29.1.el6.i686 #1 SMP Mon Jun 27 18:07:00 BST 2011 i686 SNMPv2MIB::sysObjectID.0 = OID: NET-SNMPMIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (88242)
0:14:42.42
SNMPv2-MIB::sysContact.0 = STRING: aulas
SNMPv2-MIB::sysName.0 = STRING: aulas
SNMPv2-MIB::sysLocation.0 = STRING: Unknown …
Neste exemplo percorremos todo o galho system; se o objetivo é ler todas as
informações do host, basta executar:
# snmpwalk -v 2c -c public localhost
6.5. Comando bulkget
Conforme visto nos capítulos anteriores, na versão 2c do protocolo SNMP foram
acrescentadas as funções de Bulk* (bulkget, bulkwalk), que ao invés de trazer uma única
informação, trazem um bloco de informações da tabela na qual a informação está contida, o
que torna a execução dos comandos mais eficiente e consequentemente mais rápida.
# snmpbulkget -v 2c -c public localhost system
SNMPv2-MIB::sysDescr.0 = STRING: Linux aulas 2.6.3271.29.1.el6.i686 #1 SMP Mon Jun 27 18:07:00 BST 2011 i686 SNMPv2MIB::sysObjectID.0 = OID: NET-SNMPMIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (146987)
0:24:29.87
SNMPv2-MIB::sysContact.0 = STRING: aulas
SNMPv2-MIB::sysName.0 = STRING: aulas
SNMPv2-MIB::sysLocation.0 = STRING: Unknown
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (14) 0:00:00.14
SNMPv2-MIB::sysORID.1 = OID: SNMP-MPDMIB::snmpMPDMIBObjects.3.1.1
SNMPv2-MIB::sysORID.2 = OID: SNMP-USER-BASED-SMMIB::usmMIBCompliance
SNMPv2-MIB::sysORID.3 = OID: SNMP-FRAMEWORKMIB::snmpFrameworkMIBCompliance
Nesse exemplo, o comando retornou as 10 primeiras linhas (default) da tabela system,
mas veja o que acontece ao solicitar uma única informação, sysLocation, por exemplo:
# snmpbulkget -v 2c -c public localhost sysLocation
SNMPv2-MIB::sysLocation.0 = STRING: Unknown
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (14) 0:00:00.14 SNMPv2MIB::sysORID.1 = OID: SNMP-MPDMIB::snmpMPDMIBObjects.3.1.1
SNMPv2-MIB::sysORID.2 = OID: SNMP-USER-BASED-SMMIB::usmMIBCompliance
SNMPv2-MIB::sysORID.3 = OID: SNMP-FRAMEWORKMIB::snmpFrameworkMIBCompliance
SNMPv2-MIB::sysORID.4 = OID: SNMPv2-MIB::snmpMIB
SNMPv2-MIB::sysORID.5 = OID: TCP-MIB::tcpMIB
SNMPv2-MIB::sysORID.6 = OID: IP-MIB::ip
SNMPv2-MIB::sysORID.7 = OID: UDP-MIB::udpMIB
SNMPv2-MIB::sysORID.8 = OID: SNMP-VIEW-BASED-ACMMIB::vacmBasicGroup
O bloco de informações começou na linha que continha a informação solicitada
“sysLocation.0”, e foi até sysORID.8, ao contrário da execução anterior, que foi até sysORID.3.
Podemos ainda especificar o número de linhas através da opção -Crn, onde “n”
representa o número de linhas:
# snmpbulkget -Cr20 -v 2c -c public localhost system
SNMPv2-MIB::sysDescr.0 = STRING: Linux aulas.snmp 2.6.32220.4.1.el6.i686 #1 SMP Mon Jan 23 22:37:12 GMT 2012 i686 SNMPv2MIB::sysObjectID.0 = OID: NET-SNMPMIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (3700)
0:00:37.00
SNMPv2-MIB::sysContact.0 = STRING: root@localhost
SNMPv2-MIB::sysName.0 = STRING: aulas.snmp
SNMPv2-MIB::sysLocation.0 = STRING: Unknown
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (2) 0:00:00.02
SNMPv2-MIB::sysORID.1 = OID: SNMP-MPDMIB::snmpMPDMIBObjects.3.1.1
SNMPv2-MIB::sysORID.2 = OID: SNMP-USER-BASED-SMMIB::usmMIBCompliance
SNMPv2-MIB::sysORID.3 = OID: SNMP-FRAMEWORKMIB::snmpFrameworkMIBCompliance
SNMPv2-MIB::sysORID.4 = OID: SNMPv2-MIB::snmpMIB
SNMPv2-MIB::sysORID.5 = OID: TCP-MIB::tcpMIB SNMPv2-MIB::sysORID.6
= OID: IP-MIB::ip
SNMPv2-MIB::sysORID.7 = OID: UDP-MIB::udpMIB
SNMPv2-MIB::sysORID.8 = OID: SNMP-VIEW-BASED-ACMMIB::vacmBasicGroup
SNMPv2-MIB::sysORDescr.1 = STRING: The MIB for Message Processing
and Dispatching.
SNMPv2-MIB::sysORDescr.2 = STRING: The MIB for Message Processing
and Dispatching.
SNMPv2-MIB::sysORDescr.3 = STRING: The SNMP Management Architecture
MIB.
SNMPv2-MIB::sysORDescr.4 = STRING: The MIB module for SNMPv2
entities
SNMPv2-MIB::sysORDescr.5 = STRING: The MIB module for managing TCP
implementations
6.6. Comando bulkwalk
Ao executarmos o comando snmpbulkwalk, o resultado será o mesmo da execução do
snmpwalk:
# snmpbulkwalk -v 2c -c public localhost system
SNMPv2-MIB::sysDescr.0 = STRING: Linux aulas 2.6.3271.29.1.el6.i686 #1 SMP Mon Jun 27 18:07:00 BST 2011 i686 SNMPv2MIB::sysObjectID.0 = OID: NET-SNMPMIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (199795)
0:33:17.95
SNMPv2-MIB::sysContact.0 = STRING: aulas
SNMPv2-MIB::sysName.0 = STRING: aulas
SNMPv2-MIB::sysLocation.0 = STRING: Unknown
Entretanto, o tempo de resposta e o consumo de recursos da máquina são muito
menores:
# time snmpwalk -v 2c -c public localhost system
SNMPv2-MIB::sysDescr.0 = STRING: Linux aulas 2.6.3271.29.1.el6.i686 #1 SMP Mon Jun 27 18:07:00 BST 2011 i686
SNMPv2-MIB::sysObjectID.0
=
OID:
NETSNMPMIB::netSnmpAgentOIDs.10
…
real
0m0.623s
user
0m0.111s
sys
0m0.192s
# time snmpbulkwalk -v 2c -c public localhost system
SNMPv2-MIB::sysDescr.0 = STRING: Linux aulas 2.6.3271.29.1.el6.i686 #1 SMP Mon Jun 27 18:07:00 BST 2011 i686
SNMPv2-MIB::sysObjectID.0
=
OID:
NETSNMPMIB::netSnmpAgentOIDs.10
…
real
0m0.348s
user
0m0.112s
sys
0m0.114s
6.7. Informações Adicionais
Vale a pena lembrar que esses comandos não são compatíveis com a versão 1 do
protocolo SNMP:
# snmpbulkget -v 1 -c public localhost system
snmpbulkget: Cannot send V2 PDU on V1 session (Sub-id not found:
(top) -> system)
# snmpbulkwalk -v 1 -c public localhost system
snmpbulkwalk: Cannot send V2 PDU on V1 session (Sub-id not found:
(top) -> system)
Mas e o que vem antes da informação: “SNMPv2-MIB::, IF-MIB::, DISMANEVENTMIB::”?. Esta informação nos diz quem foi a MIB que respondeu aquela solicitação. Lembre-se:
se eu não possuir a MIB do equipamento do qual estou solicitando as informações, poderei ler
o dado se souber a OID do objeto, mas não vou ter condições de interpreta-lo. Por exemplo:
# snmpget -v 2c -c public localhost .1.3.6.1.2.1.2.2.1.2.1
IF-MIB::ifDescr.1 = STRING: lo
O OID .1.3.6.1.2.1.2.2.1.2.1 representa o objeto ifDescr.1. Podemos observar acima que
a resposta foi a mesma da execução anterior.
Agora veja o que acontece se eu não possuir a MIB:
# snmpget -v 2c -c public localhost .1.3.6.1.2.1.2.2.1.2.1
SNMPv2-SMI::mib-2.2.2.1.2.1 = STRING: "lo"
Obtivemos a resposta “STRING: "lo"”, mas que dado é esse? Fica muito difícil
identificar, já se eu possuir a MIB, receberei a resposta “ifDescr.1 = STRING: lo”, muito mais fácil
de identificar o que é esse objeto. Além disso, aprenderemos um comando que consulta o
objeto na MIB e nos traz a descrição desse objeto, que nesse caso seria:
“A textual string containing information about the interface. This
string should include the name of the manufacturer, the product name
and the version of the interface hardware/software."
Por isso é tão importante possuir uma cópia da MIB de todos os equipamentos que você
deseja monitorar através do seu servidor de gerenciamento (Estação de gerenciamento).

Documentos relacionados