Atividade Prática 02 Gerenciamento de Servidores GNU/Linux Utilizando SNMP v1 e v2c

Transcrição

1 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 ( Na distribuição CentOS ( 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.

2 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 de sistema; geram 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; /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; /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. 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:

3 # 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 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

4 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 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 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

5 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 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 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 el6.i686 #1 SMP Mon Jun 27 18:07:00 BST 2011 i686 SNMPv2- MIB::sysObjectID.0 = OID: NET-SNMP- MIB::netSnmpAgentOIDs.10 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (88242) 0:14:42.42 SNMPv2-MIB::sysContact.0 = STRING: aulas SNMPv2-MIB::sysName.0 = STRING: aulas 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

6 SNMPv2-MIB::sysDescr.0 = STRING: Linux aulas el6.i686 #1 SMP Mon Jun 27 18:07:00 BST 2011 i686 SNMPv2- MIB::sysObjectID.0 = OID: NET-SNMP- MIB::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::sysORLastChange.0 = Timeticks: (14) 0:00:00.14 SNMPv2-MIB::sysORID.1 = OID: SNMP-MPD- MIB::snmpMPDMIBObjects SNMPv2-MIB::sysORID.2 = OID: SNMP-USER-BASED-SM- MIB::usmMIBCompliance SNMPv2-MIB::sysORID.3 = OID: SNMP-FRAMEWORK- MIB::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::sysORLastChange.0 = Timeticks: (14) 0:00:00.14 SNMPv2- MIB::sysORID.1 = OID: SNMP-MPD- MIB::snmpMPDMIBObjects SNMPv2-MIB::sysORID.2 = OID: SNMP-USER-BASED-SM- MIB::usmMIBCompliance SNMPv2-MIB::sysORID.3 = OID: SNMP-FRAMEWORK- MIB::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-ACM- MIB::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

7 SNMPv2-MIB::sysDescr.0 = STRING: Linux aulas.snmp el6.i686 #1 SMP Mon Jan 23 22:37:12 GMT 2012 i686 SNMPv2- MIB::sysObjectID.0 = OID: NET-SNMP- MIB::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::sysORLastChange.0 = Timeticks: (2) 0:00:00.02 SNMPv2-MIB::sysORID.1 = OID: SNMP-MPD- MIB::snmpMPDMIBObjects SNMPv2-MIB::sysORID.2 = OID: SNMP-USER-BASED-SM- MIB::usmMIBCompliance SNMPv2-MIB::sysORID.3 = OID: SNMP-FRAMEWORK- MIB::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-ACM- MIB::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 el6.i686 #1 SMP Mon Jun 27 18:07:00 BST 2011 i686 SNMPv2- MIB::sysObjectID.0 = OID: NET-SNMP- MIB::netSnmpAgentOIDs.10 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (199795) 0:33:17.95 SNMPv2-MIB::sysContact.0 = STRING: aulas SNMPv2-MIB::sysName.0 = STRING: aulas

8 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 el6.i686 #1 SMP Mon Jun 27 18:07:00 BST 2011 i686 SNMPv2-MIB::sysObjectID.0 = OID: NET- SNMPMIB::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 el6.i686 #1 SMP Mon Jun 27 18:07:00 BST 2011 i686 SNMPv2-MIB::sysObjectID.0 = OID: NET- SNMPMIB::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::, DISMANEVENT- MIB::?. 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 IF-MIB::ifDescr.1 = STRING: lo O OID representa o objeto ifdescr.1. Podemos observar acima que a resposta foi a mesma da execução anterior.

9 Agora veja o que acontece se eu não possuir a MIB: # snmpget -v 2c -c public localhost SNMPv2-SMI::mib = 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).