Implantação de Sistema de Inventário com múltiplas ferramentas

Diego Augusto Zeni, Flagner Vaz Camargo

Pós Graduação em Redes e Segurança de SistemasPontifícia Universidade Católica do Paraná

Curitiba, outubro de 2009

Resumo

O objetivo deste trabalho é descrever a implantação de um sistema de inventário com interface WEB escrita em PHP, utilizando-se do protocolo SNMP (snmpwalk e snmpget) para fazer a captura de informações dos servidores e switches, e do CACIC para a captura de informações das estações de trabalho. O CACIC é uma ferramenta de inventário de hardware e software desenvolvida em Software Livre e já está em uso na empresa. Todas as escolhas de tecnologias e itens a serem inventariados foram feitas com o intuito de facilitar o trabalho cotidiano da equipe de suporte de TI.

1 Introdução

A empresa onde trabalhamos possui diversos prédios espalhados pelo Brasil e cada um deles recebe o nome de Regional. Fazemos parte da equipe que presta serviços de Tecnologia da Informação (TI) na Regional do Paraná localizada em Curitiba.

Para fazer o gerenciamento de todo o parque computacional das regionais são utilizadas diversas ferramentas de monitoramento e inventario de forma centralizada por equipes em Brasília. Porém a TI das regionais e seus gerentes não tem o nível de acesso satisfatório a estas ferramentas para atender as necessidades de monitoramento e gerência locais. Além disso, nacionalmente são tratados servidores e estações de trabalho em sistemas distintos e por equipes também distintas, o que dificulta a visualização de todo o conjunto de recursos da rede local.

Com todas estas dificuldades, nossa gerência optava por coletar informações a respeito dos recursos de rede manualmente e guardá-las em planilhas o que dificultava sua consulta e manutenção, além de prejudicar sua consistência.

Para melhorar esse processo propusemos a criação de um ambiente WEB onde fosse possível reunir todas as informações de hardware e software do parque computacional da Regional Curitiba e padronizasse de alguma forma o seu registro e consultas, oferecendo um único ambiente para que a equipe técnica e gerencial pudessem registrar e consultar todas as informações necessárias sobre os recursos de TI da rede local. Esse sistema foi chamado de SIR (Sistema de Inventario Regional).

Este trabalho está organizado da seguinte forma: Na seção 2 descrevemos rapidamente a rede local; Na seção 3 as ferramentas aproveitadas como fonte de dados para nosso sistema, como por exemplo, o 389 Directory Service (antigo Fedora Directory Service) que prove autenticação e dados dos usuários através do protocolo LDAP e o CACIC que fornece informações das estações de trabalho dos usuários da regional; Na seção 4 descrevemos o sistema e suas funcionalidades; E por fim, na seção 5, as conclusões do trabalho.

2 Rede local

A rede local da regional Curitiba é composta por aproximadamente 500 estações de trabalho, 35 servidores com diversas utilidades, 1 switch core camada 3 e mais 14 switchs

distribuídos pelo prédio.O inventário das estações de trabalho é feito de forma centralizada em Brasília – DF e

utiliza-se do agente CACIC que captura informações das estações e as envia ao gerente CACIC que por sua vez armazena estas informações em um banco de dados. Esta ferramenta e seu funcionamento serão melhor descritos na seção 3. O acesso ao gerente CACIC e as suas informações somente é liberado para as equipes de monitoramento e segurança de redes. Algumas destas informações são úteis para a nossa equipe (de suporte regional) e nossa gerência, porém não temos acesso a elas.

O gerenciamento dos servidores é feita de forma manual e as informações sobre estes recursos são armazenadas em planilhas. Mensalmente – e também em casos esporádicos – são solicitadas informações sobre estes servidores como espaço em disco, backups, etc. Para obtê-las é preciso acessar cada servidor manualmente, coletá-las e organizar de forma a atender a solicitação.

Possuímos quatro faixas de IP classe C totalizando 1016 IPs disponíveis para uso na regional. A distribuição destes IPs é feita via DHCP e o controle de uso também é feito manualmente em planilhas. Não se pode depender do agente CACIC para obter tal informação, pois se existir uma máquina na rede que não tenha o agente instalado já não se sabe se o IP está ocupado ou não. E também os servidores, switchs e impressoras não possuem o agente instalado o que torna difícil o controle e o monitoramento destes endereços IP e sua utilização na rede.

A Gerência Regional da TI necessita continuamente de relatórios qualitativos e quantitativos de uso de todos recursos da rede para apresentar aos demais setores que prestamos serviços e também para as diretorias. A confecção destes relatórios demanda muito trabalho manual. Na próxima seção será descrito como e com quais ferramentas pretendemos automatizar todo este trabalho manual.

3 Ferramentas de coleta

Já se sabe da existência de diversas ferramentas de inventário e monitoramento disponíveis tanto de forma livre como proprietária. Cada qual com suas especificidades e atendendo a maior ou menor quantidade de requisitos. Aproveitando das ferramentas existentes na empresa e utilizando de outras para coletas mais especificas, conseguimos reunir suficiente número de informações que atendam as necessidades da TI da regional Curitiba. Essas informações são armazenadas em uma base de dados MySQL da seguinte forma:

– Informações das estações de trabalho são coletadas através do CACIC, onde no sistema gerente não possuímos acesso integral as informações, assim conseguimos acesso a base de dados de leitura do gerente;

– Informações básicas dos funcionários, como por exemplo, matrícula, setor, ramal, e-mail, etc, são obtidas no servidor de diretório 389;

– Informações de servidores e switches são obtidas através do protocolo SNMP com as ferramentas snmpwalk e snmpget usadas em scripts shell.

3.1 CACIC

O CACIC (Configurador Automático e Coletor de Informações Computacionais) é o primeiro software público do Governo Federal, desenvolvido pela DATAPREV - Empresa de Tecnologia e Informações da Previdência Social.

O CACIC foi disponibilizado para a comunidade sob a licença GPL através do Portal do Software Público Brasileiro [1] e se propõe a realizar as seguintes tarefas:

– Coletar informações sobre os componentes de hardware instalados em cada computador e disponibilizá-las aos administradores de sistemas;

– Alertar os administradores de sistemas quando forem identificadas alterações na configuração dos componentes de hardware de cada computador;

– Coletar diversas informações sobre os softwares instalados em cada computador e disponibilizá-las aos administradores de sistemas;

– Identificar diretórios compartilhados considerados inseguros e aplicar as restrições de segurança necessárias;

– Coletar informações de Patrimônio (PIB, localização, etc.) de cada computador e disponibilizá-las aos administradores de sistemas;

– Alertar os administradores de sistemas quando forem identificadas alterações na localização física do computador;O servidor do CACIC (Módulo Gerente) usa o conjunto de softwares livres conhecido

como LAMP: Linux, Apache, MySQL e PHP. Já os agentes, são programas compilados que não necessitam de nenhum software adicional para que possam ser executados nas estações de trabalho. Dessa forma, qualquer empresa/órgão que queira utilizar o CACIC não necessitará adquirir nenhum software adicional para que possa implantar o sistema. Os agentes do CACIC para a plataforma Windows podem ser executados nas versões 95 OSR2, 98, 98 SE, ME, NT, 2000 e XP [1]. A versão 2.4 do CACIC já possui agente para Linux.

O CACIC é composto atualmente de três módulos (ou componentes) definidos: Módulo-Agente, Módulo-Gerente e Módulo Super-Gerente descritos em [1].

– Módulo AgenteO Módulo Agente é o componente de software (é um programa) compilado, que fica

permanentemente ativo na estação de trabalho do usuário. Esse módulo é responsável por coletar - com uma frequência definida pelo gerente – os dados de hardware, software e rede da estação de trabalho. Após cada coleta, os dados são enviados para o gerente.

– Módulo GerenteO Módulo Gerente é composto de um conjunto de softwares que devem ser instalados

em um servidor e que trabalham integrados com o objetivo de administrar os módulos agentes que estão instalados nas estações de trabalho dos usuários. Basicamente, são utilizados servidores Web Apache, banco de dados MySql e linguagem de programação PHP. O Módulo Gerente recebe os dados coletados dos agentes, organiza-os e disponibiliza em forma de relatórios e consultas, através da sua interface web. Além disso, a partir do Módulo Gerente é possível configurar algumas características de comportamento dos Módulos Agentes.

– Módulo Super-GerenteO Módulo Super-Gerente é composto de um conjunto de softwares que devem ser

instalados em um servidor e que trabalham integrando as informações consolidadas dos diversos Módulos Gerentes instalados na rede. O Super-Gerente possui uma visão global de todo o parque computacional instalado e distribuído pela organização. Atualmente a tecnologia adotada para integração é através de webservice.

Detalhes de instalação e configuração, assim como os instaladores, podem ser obtidos no Portal do Software Público Brasileiro na comunidade CACIC em [2]. Algumas dificuldades que tivemos e não conseguimos solução é com relação a incompatibilidade de versões entre o gerente versão 2.2 e os agentes 2.4. E também na instalação do gerente versão 2.4 onde no acesso apresentou um erro de que precisava instalar o phpTranslator.

3.2 Serviço de Diretório 389

Para efetuar a autenticação de usuários no SIR (Sistema de Inventario Regional) e obter um certo nível de segurança nas consultas e alterações de informações foi utilizado o Serviço de Diretório 389 que está instalado no sistema operacional Debian Lenny e que já provê autenticação para os usuários da rede local.

A empresa possui um servidor de autenticação em cada regional sendo estes secundários que replicam dados com os servidores primários localizados em três pontos do

Brasil. Então todos os servidores tem informações de todos os funcionários de todas as Regionais. A autenticação dos funcionários é feita com o usuário e senha (que expira a cada 30 dias).

O Serviço de diretório 389 trabalha sobre LDAP (Lightweight Directory Access Protocol) e foi desenvolvido pela Red Hat, sendo distribuído gratuitamente sob a licença GPL. Este serviço de diretório 389 é idêntico ao RHDS (Red Hat Directory Service), apenas em versão livre. O nome 389 é derivado do número da porta do LDAP utilizada pelo serviço. O Serviço de Diretório 389 está sendo construído sobre o sistema operacional Fedora, mas é portável para diversos outros sistemas operacionais incluindo o Red Hat Enterprise Linux 3 e posteriores, Debian, Solaris 8 e posteriores, e HP-UX 11i. [3]

Para fazer a comunicação entre o Servidor LDAP 389 e o sistema SIR foram utilizadas algumas funções do PHP como: ldap_connect, ldap_bind, ldap_search, ldap_first_entry, ldap_get_values, ldap_get_attributes que serão descritas na seção 4.

3.3 SNMP e Net-SNMP

Para realizar a captura de informações dos servidores foi utilizado o protocolo SNMP (Simple Network Management Protocol).

O SNMP é um protocolo de gerência de redes TCP/IP que trabalha na camada de aplicação do modelo OSI facilitando a troca de informações entre dispositivos de rede possibilitando assim a administração destes dispositivos [6].

O SNMP assim como outros softwares de gerência de redes funciona de forma inversa aos demais softwares do modelo cliente-servidor, ou seja, para as operações GET e SET o computador onde são concentradas as informações coletadas dos dispositivos da rede se comporta como cliente e o dispositivo de rede a ser analisado ou monitorado se comporta como servidor, enquanto que na operação TRAP ocorre o oposto, pois no envio de alarmes é o dispositivo gerenciado que toma iniciativa da comunicação. Por conta disso, os sistemas de gerência de redes evitam os termos 'cliente' e 'servidor' e optam por usar "gerente" para a aplicação que roda no computador onde são concentradas as informações sobre os dispositivos de rede e "agente" para a aplicação que roda no dispositivo de rede a ser gerenciado ou monitorado. [6]

As partes dos equipamentos a serem monitorados são chamados de objetos. Para identificar objetos a serem monitoradas nos ativos de rede e estabelecer uma comunicação padronizada entre os Agentes e Gerentes, o SNMP baseia-se em MIBs (Management Information Base) que nada mais são do que dicionários para identificação destes objetos. As MIBs somente devem seguir um padrão em sua escrita e com isto, podem ser criadas de forma personalizada para cada tipo de ativo de rede, independentemente do protocolo SNMP ou da arquitetura do dispositivo de rede.

Com o tempo o protocolo SNMP foi evoluindo em suas versões e sofrendo aprimoramentos. Na prática, as implementações do SNMP oferecem suporte para as múltiplas versões (RFC 3584), tipicamente SNMPv1, SNMPv2c e SNMPv3. [6]

No SIR utilizamos apenas as operações GET, o SNMPv1 e as ferramentas snmpget e snmpwalk da suíte Net-SNMP.

A suíte Net-SNMP é um conjunto de utilitários que operam sobre o protocolo SNMP, licenciada sob a GPL e disponibilizado para a comunidade. O Net-SNMP está disponível para uso em diversos sistemas operacionais como Unix, Unix-like como diversos Linux e Microsoft Windows e além disso suporta uma imensa variedade de MIBs [7].

O utilitário snmpget comunica-se com ativos de rede através das requisições do comando nativo SNMPGET do protocolo SNMP. Com ele é possível na linha de comando utilizar-se simultaneamente de vários identificadores de objetos e variáveis como argumentos do comando, facilitando assim a confecção de scripts para automatizar a troca de informações entre os agentes e gerentes SNMP.

Já o utilitário snmpwalk faz uso das requisições SNMP GETNEXT, também nativas do protocolo SNMP, para criar árvores com conjuntos de informações sobre entidades de rede gerenciadas. Utilizando-se de um OID (object identifier) específico é possível criar uma árvore com todos os subitens deste objeto. Com isto é possível obter conjuntos de informações a respeito de determinado ativo de rede com simples linhas de comando em scripts.

É preciso tomar cuidado com este utilitário pois, caso não seja explicitado o OID na linha de comando, ele interpretará como uma solicitação de TODOS os valores da MIB do dispositivo gerenciado e pode gerar um grande volume de informações podendo causar problemas de tráfego na rede ou travamento tanto do equipamento onde está instalado o agente quanto o gerente. O mesmo problema pode ocorrer caso o OID seja muito abrangente, ou contemple um grande número valores de MIB.

Toda a documentação sobre a suíte Net-SNMP e seus utilitários está disponível juntamente com seus códigos fonte no Sourceforge. [7]

4 SIR - Sistema de Inventário Regional

O SIR é um sistema de inventário simples com interface WEB, desenvolvido em HTML e PHP e com persistência em MySQL. Seu objetivo é centralizar as informações sobre o parque computacional para uso da equipe de suporte de TI da regional.

A coleta de informações das estações de trabalho se dá através do CACIC que já é utilizado na empresa e que foi descrito na seção anterior, já no caso dos servidores e outros ativos de rede a coleta é feita com scripts shell que através dos utilitários snmpget e snmpwalk capturam informações destes equipamentos. A autenticação (logon) e consulta a informações dos usuários é provida através do servidor de diretório 389 também descrito na seção anterior.

O desenvolvimento deste ambiente será continuado, já que nem todos os requisitos foram levantados já no início do projeto. A análise de requisitos inicial para este sistema levou em conta o que vinha sendo feito manualmente (em planilhas) relacionado ao cadastro de ativos de rede (computadores, servidores e switches), distribuição de endereços IP, provisão de relatórios para fins diversos, etc.

A seguir será descrito como as ferramentas foram utilizadas e configuradas para fazer a coleta e apresentação das informações.

Figura 1: Tela inicial do sistema

4.1 Autenticação

Para utilizar-se de qualquer uma das funcionalidades que impliquem em cadastro ou alteração de informações o usuário terá de se autenticar, proporcionando maior confiabilidade ao sistema.

A autenticação é feita da seguinte forma:– É verificado se o login do usuário está cadastrado no arquivo admin/usuarios-

permitidos.txt :function verifica_usuario($usuario){ $arquivo = fopen ("admin/usuarios-permitidos.txt", "r"); while (!feof ($arquivo)) { $linha = trim(fgets($arquivo)); if ($linha == $usuario) { fclose($arquivo); return TRUE; } } fclose ($arquivo); return FALSE;}

– Se a verificação anterior for verdadeira, o login e senha do usuário são testados no Servidor LDAP 389.

function autentica_ldap($usuario,$senha){ $servidor = "10.200.112.20"; $porta = 389; $opcoes = 'ou=reg,ou=regcta,dc=serpro,dc=gov,dc=br'; $dn = 'uid=' . $usuario . ',' . $opcoes;

if (!($ds=@ldap_connect($servidor,$porta))) { return FALSE; }

if (@ldap_bind($ds, $dn, $senha)) { ldap_close($ds); return TRUE; } else return FALSE;}

A função ldap_connect estabelece uma conexão no servidor e porta fornecido. A função ldap_bind faz a autenticação do usuário com uma conexão já estabelecida. E a função ldap_close fecha uma conexão.

– Se o teste retornar verdadeiro o usuário estará autenticado. Caso contrário será exibida uma mensagem de falha de autenticação.

4.2 Cadastro

Permite o cadastramento de um novo equipamento que venha a ser adicionado na rede local. Para as estações de trabalho os dados são capturados pelo CACIC, bastando apenas associar estes dados aos dados do usuário e preencher alguns campos que não são obtidos automaticamente, como setor, patrimônio da CPU quando não capturado e dados do monitor. O agente CACIC (a partir da versão 2.4) instalado nas estações de trabalho solicita que o usuário preencha a informação de patrimônio em seu primeiro logon, porém nem todos os usuários o fazem.

Os dados que precisamos da base de dados do CACIC ficam guardados nas tabelas computadores e unidades_disco que durante o cadastro são obtidos da seguinte forma:function dados_cacic (){ $con = mysql_connect("IP_CACIC","cta","senha"); mysql_select_db("cacic",$con); $sql="select c.te_node_address mac,c.te_nome_computador nome,c.te_ip ip,c.qt_mem_ram mem,c.te_cpu_freq cpu, sum(nu_capacidade) disco from computadores c,unidades_disco ud where (c.id_ip_rede='10.200.112.0' or c.id_ip_rede='10.200.111.0' or c.id_ip_rede='10.200.189.0' or c.id_ip_rede='10.200.232.0') and c.te_node_address=ud.te_node_address and ud.id_tipo_unid_disco=2 group by(ud.te_node_address)"; $result = mysql_query($sql,$con); $rs = mysql_fetch_array($result); mysql_close($con); return($rs);}

Os servidores e switches precisam ser cadastrados, pois é a partir do cadastro que o scripts shell começará a capturar informações.

4.3 Alteração

Permite a alteração de informações de equipamentos já cadastrados. Isto somente será possível após autenticação do usuário se este possuir acesso liberado ao SIR.

4.4 Relatórios

Permite a emissão de diversos tipos de relatórios com informações dos equipamentos de rede cadastrados. Os relatórios disponíveis atualmente são: por setor, por tipo de equipamento (switch, servidor, estação, etc), por sistema operacional e geral. Existe a opção de gerar um relatório personalizado, escolhendo os campos que deseja mostrar e os filtros para cada campo.

4.5 Pesquisa

Permite a consulta das informações de um determinado equipamento cadastrado.

Figura 2: Tela de pesquisa de equipamentos

4.6 Usuários

Mostra detalhes da conta do usuário cadastrada no Servidor LDAP 389. A consulta ao

servidor é feita da seguinte forma:function usuario_ldap($cpf){ global $info; $servidor = "10.200.112.20"; $porta = 389; $dn = 'ou=reg,ou=regcta,dc=serpro,dc=gov,dc=br'; $ds = @ldap_connect($servidor,$porta); $filtro = "(|(uid=$cpf))"; $atributos = array("cn","accountStatus","uid","employeeNumber","telephoneNumber","ou","mail","usrfuncao","usrdtnascimento","usrdtadmissao","usrcargo","usrespecializacao"); $sr = ldap_search($ds, $dn, $filtro, $atributos); $entrada = ldap_first_entry($ds, $sr); $valor_attrs = ldap_get_attributes($ds, $entrada); for ($i=0; $i < $valor_attrs["count"]; $i++) { $valores = ldap_get_values($ds, $entrada, $valor_attrs[$i]); $info[$i] = $valores[0]; }}

Com a função ldap_search foi feita uma busca no Servidor LDAP, tendo como parâmetro uma conexão pré estabelecida, o caminho da árvore onde a pesquisa é feita, o filtro por usuário e os atributos procurados. A função ldap_first_entry pega a primeira entrada do resultado da busca. A função ldap_get_attributes retorna os atributos disponíveis para a entrada capturada. E por fim a função ldap_get_values pega os valores do atributo fornecido. O resultado é como mostra a figura 3.

Figura 3: Tela de informações dos funcionários

4.7 Switches

Permite consultar informações sobre os switches. Estas informações são obtidas através de um script shell que faz a coleta via SNMP. Os scripts são executados em períodos agendados (usando o cron do sistema operacional) para não haver trafego excessivo na rede. A partir do momento em que o switch é cadastrado no SIR o script coletará informações a partir da próxima execução agendada. Nos switches foi habilitado o SNMP e criado uma comunidade chamada ctaser somente de leitura, isto é necessário para que o agente responda as requisições feitas pelo script. O script shell é o seguinte:#!/bin/bashsnmp () { IFSBKP="$IFS"

IFS=$'\n' marca=`snmpget -v1 -c ctaser $ip sysDescr.0 | grep SNMP | cut -d: -f4 | cut -d" " -f2` uptime=`snmpget -v1 -c ctaser $ip sysUpTimeInstance | cut -d\) -f2 | cut -c2- | sed 's/day/dia/'`

#### NOME PORTA #### cont=1 if [ "$marca" = "Cisco" ] then for i in `snmpwalk -v1 -c ctaser $ip ifDescr` do nome[$cont]=`echo $i | cut -d: -f4 | cut -c2-` cont=$(($cont + 1)) done

... fi #### STATUS #### cont=1 for i in `snmpwalk -v1 -c ctaser $ip ifAdminStatus` do status[$cont]=`echo $i | cut -d: -f4 | cut -c2-` cont=$(($cont + 1)) done #### CABO #### cont=1 for i in `snmpwalk -v1 -c ctaser $ip ifOperStatus` do cabo[$cont]=`echo $i | cut -d: -f4 | cut -c2-` cont=$(($cont + 1)) done #### Ultima mudanca #### cont=1 for i in `snmpwalk -v1 -c ctaser $ip ifLastChange` do ult_altera[$cont]=`echo $i | cut -d\) -f2 | cut -c2- | sed 's/day/dia/'` cont=$(($cont + 1)) done #### VELOCIDADE #### cont=1 for i in `snmpwalk -v1 -c ctaser $ip ifSpeed` do velocidade[$cont]=$((`echo $i | cut -d: -f4 |cut -c2-` / 1000000)) cont=$(($cont + 1)) done ##### MAC ##### paste -d= <(snmpwalk -v1 -c ctaser $ip .1.3.6.1.2.1.17.4.3.1.1 | cut -d: -f4 | cut -c2-18 | tr -s " " :) <(snmpwalk -v1 -c ctaser $ip .1.3.6.1.2.1.17.4.3.1.2 | cut -d: -f4 | cut -c2-) > /tmp/lista.tmp #Atribui os MACs as portas ... IFS="$IFSBKP"}ips=`mysql -u usuario -psenha -e "SELECT ip FROM inventario where tipo='Switch' group by patrimonio" base | grep -v '^ip'`> /rede/www/html/tigre/script/snmp-switch.logfor ip in $ips do if snmpget -v1 -c ctaser $ip sysDescr.0 > /dev/null then

echo "`date +%d/%m/%Y-%H:%M` - IP $ip OK!" >> /rede/www/html/tigre/script/snmp-switch.log snmp #Isere informacoes capturadas no banco ... else echo "`date +%d/%m/%Y-%H:%M` - Switch $ip desligado ou sem SNMP!" >> /rede/www/html/tigre/script/snmp-switch.log fidoneexit 0

Para encontrar a identificação dos objetos (OID) que procuramos obter informações, executamos o comando:snmpwalk -v1 -c public <ip>quando não passamos a identificação do objeto, por padrão o snmpwalk captura todas as informações da subárvore de gerenciamento 1.3.6.1.2 ou iso.org.dod.internet.mgmt. Assim descobrimos o nome do grupo de pesquisa que usamos no script.

Utilizamos o snmpwalk para capturar dados de toda a subárvore do nome do grupo pesquisado e o snmpget utilizamos para capturar dados de uma identificação de objeto única. O parâmetro OID no snmpget é obrigatório. Detalhes do uso das ferramentas snmpget e snmpwalk podem ser obtidas na sua documentação on-line [7].

Depois de capturados todos os dados que precisamos, cadastramos no banco e mostramos pela interface WEB conforme figura 4.

Figura 4: Tela das informações capturadas do switch

4.7 Servidores

Para a captura automatizada das informações dos servidores também utilizamos dos recursos do script shell. A coleta nos servidores é feita uma vez por dia e de forma agendada no período da noite aproveitando-se da ociosidade da rede. Os servidores além de serem cadastrados, devem ser cadastrados na tabela servidores para que os scripts comecem a coletar informações. Esse cadastro a mais é preciso ser feito, pois nem todos os servidores precisam ou podem ser monitorados. Existem servidores que não possuímos acesso, assim não podemos instalar o daemon SNMP, porém eles figuram na lista de equipamentos inventariados da regional.

Nos servidores com sistema operacional Linux é instalado o daemon snmp. A configuração nestes casos é feita conforme abaixo, o arquivo é o /etc/snmp/snmpd.conf:com2sec tigre 10.200.232.6 publicgroup grupoRO v1 tigreview internet included 1.3.6.1 access grupoRO "" v1 noauth exact internet none none

syslocation Sala dos Servidoresdisk /disk /rededisk /var

Na primeira linha mapeamos um nome de comunidade a um nome de segurança e definimos a origem da solicitação, por motivos de segurança. Na segunda linha associamos o nome de segurança a um grupo, definindo o modelo de SNMP utilizado, neste caso versão 1. Em seguida definimos tudo que será mostrado pelo agente, no caso foi liberada toda a subárvore iso.org.dod.internet. Na próxima linha permitimos o acesso do grupo na versão 1 do SNMP, sem autenticação, para ler a view internet e não poder escrever. Mais detalhes da configuração do snmpd.conf pode ser obtida nas manpages [8]. O parâmetro disk verifica o espaço em disco das partições selecionadas e disponibiliza para consulta.

Nos servidores com sistema operacional Microsoft Windows basta instalar o componente do Windows acessando o Painel de Controle, Adicionar ou Remover Programas, Adicionar/Remover Componentes do Windows, Ferramentas de Gerenciamento e Monitoramento e marcar a opção Simple Network Management Protocol:

Figura 5: Instalar SNMP no WindowsNo caso do Microsoft Windows 2003 é necessário fazer a seguinte configuração: no

Painel de Controle, Ferramentas Administrativas, Serviços e em SNMP Service tem que adicionar uma comunidade e o IP de quem vai capturar as informações da estação conforme figura abaixo:

Figura 6: Configuração do SNMP no Windows 2003Por padrão o Windows libera para consulta toda a subárvore iso.org.dod.internet. Para

a realizar a captura o script é o seguinte:#!/bin/bashsnmp ()

{ #### NOME/DOMINIO #### nome_completo=`snmpget -v1 -c public $ip sysName.0 | cut -d: -f4- | cut -c2-` nome=`echo $nome_completo | cut -d. -f1` dominio=`echo $nome_completo | cut -d. -f2-` #### MEMORIA #### [ memoria=`snmpwalk -v1 -c public $ip hrmemory | cut -d: -f4 | cut -d" " -f2` ] && memoria=$(($memoria / 1024 )) #### UPTIME #### uptime=`snmpget -v1 -c public $ip hrSystemUptime.0 | cut -d\) -f2 | cut -c2- | sed 's/day/dia/'` #### COLETA #### coleta=`snmpget -v1 -c public $ip hrSystemDate.0 |cut -d: -f4-|cut -c2-` dia=`echo $coleta | cut -d, -f1 | cut -d- -f3` mes=`echo $coleta | cut -d- -f2` ano=`echo $coleta | cut -d- -f1` data="$dia/$mes/$ano `echo $coleta | cut -d, -f2`"}disco_linux (){ #### DISCO TOTAL ##### total=0 for i in `snmpwalk -v1 -c public $ip dskTotal | cut -d: -f4 | cut -c2-` do total=$(($total + $i)) done total=$(($total / 1024 / 1024)) #### DISCO USADO #### usado=0 for i in `snmpwalk -v1 -c public $ip dskUsed | cut -d: -f4 | cut -c2-` do usado=$(($usado + $i)) done usado=$(($usado / 1024 / 1024))}disco_win (){ #### DISCO TOTAL/USADO #### snmpwalk -v1 -c public $ip hrStorageSize | cut -d: -f4- | cut -c2- > /tmp/total snmpwalk -v1 -c public $ip hrStorageUsed | cut -d: -f4- | cut -c2- > /tmp/usado snmpwalk -v1 -c public $ip hrStorageAllocationUnits | cut -d: -f4- | cut -d" " -f2 > /tmp/unit total=$((`paste -d\* /tmp/total /tmp/unit | bc | paste -sd\+ | bc` / 1024 / 1024 / 1024)) usado=$((`paste -d\* /tmp/usado /tmp/unit | bc | paste -sd\+ | bc` / 1024 / 1024 / 1024)) rm -f /tmp/total /tmp/unit /tmp/usado}> /rede/www/html/tigre/script/snmp-serv.logips=`mysql -u usuario -psenha -e "SELECT ip FROM servidores" base | grep -v 'ip'`

for ip in $ips do if snmpwalk -v1 -c public $ip > /dev/null then snmp

so=`mysql -u usuario -psenha -e "SELECT so FROM servidores WHERE ip='$ip'" base | grep -v "^so"` if [ "$so" = "Linux" ] then disco_linux else disco_win fi #Insere no banco os dados capturados ... else echo -e "Servidor $ip desligado ou sem SNMP! \n" >> /rede/www/html/tigre/script/snmp-serv.log fidoneexit 0

Neste script utilizamos a mesma estratégia de captura de dados dos switches, primeiro executamos um snmpwalk, porém passamos a subárvore internet (1.3.6.1) porque no snmpd.conf foi configurado a clausula disk que fica fora da subárvore de gerenciamento:snmpwalk -v1 -c public <ip> 1.3.6.1

Depois de obtido os nomes das subárvores necessárias, verificamos na base todos servidores cadastrados e realizamos a busca dos dados e cadastramos na base.

Figura 7: Detalhes dos servidores

4.8 IPs

Para mantermos um controle dos IPs livres e utilizados, criamos uma tabela que contém todos os 1016 endereços disponíveis, cada um com seu status (livre, ocupado ou reservado). Nos endereços com status “livre” é feita uma verificação se eles não estão realmente sendo utilizados. Para isso foi feito um script com teste de ping:

#!/bin/bashfor i in `mysql -u usuario -psenha -e "SELECT ip FROM ips WHERE situacao='Livre'" base` do if [ $i != "ip" ] then if ping -c2 -W1 $i > /dev/null

thenmysql -u usuario -psenha -e "UPDATE ips SET status='on' WHERE

ip='$i'" base else mysql -u usuario -psenha -e "UPDATE ips SET status='off' WHERE ip='$i'" base fi fidone

Figura 8: Tela de IPs livres

5 Conclusões

Um dos objetivos deste trabalho foi mostrar como é possível, de forma simples, integrar ferramentas de Software Livre para gerenciamento de redes, que em conjunto possam coletar informações, unificá-las em uma base de dados e disponibilizá-las em um ambiente WEB para todos que precisem utilizar.

No inicio do projeto quando tivemos a ideia de desenvolver o SIR sabíamos que o resultado seria uma melhora na agilidade e qualidade da consulta e armazenamento das informações referentes a toda a rede local por nós administrada. Porém os resultados apresentados até o momento são superiores aos esperados satisfazendo tanto a equipe técnica como a área gerencial.

Como já mencionado, o produto deste TCC (o SIR) terá um desenvolvimento continuado de acordo com a solicitação de novos requisitos pela equipe que o opera e dele se utiliza.

Notamos neste momento inicial um grande ganho na rapidez de consulta das informações referentes aos ativos de rede por nós gerenciados, o que proporcionou para nossa gerência uma visão mais clara e detalhada da situação da rede em tempo real.

A implantação do SIR na rede local não gerou nenhuma queda de performance devido as trocas de informações entre ele e os ativos de rede, tornando-se assim transparente a sua atuação no desempenho da rede.

Bibliografia

[1] http://www.softwarepublico.gov.br/dotlrn/clubs/cacic/file-storage/download/manual_implanta_introducao_v0.pdf?file_id=7286543 - acesso em 17/09/2009

[2] http://www.softwarepublico.gov.br/dotlrn/clubs/cacic/one-community?page_num=0 - acesso em 17/09/2009

[3] http://en.wikipedia.org/wiki/389_Directory_Server - acesso em 17/09/2009

[4] http://directory.fedoraproject.org/wiki/FAQ - acesso em 17/09/2009

[5] http://www.ietf.org/ - acesso em 14/18/2009

[6] http://pt.wikipedia.org/wiki/Simple_Network_Management_Protocol – acesso em 14/09/2009

[7] http://net-snmp.sourceforge.net/ – acesso 14/09/2009

[8] http://www.debianhelp.co.uk/manpages/defaultsnmpd.txt - acesso em 29/09/2009