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).