Gerência de Redes (diário 2012-1)

Calendário pós-greve: http://tele.sj.ifsc.edu.br/arquivos/publicos/Horarios2012-1_PosGreve/

O formato da apostila é EPUB, que fora publicado semanalmente até a metade da disciplina. Ele foi produzido usando o aplicativo Sigil.

Há diversos dispositivos para leitura desse formato. No Linux, o aplicativo calibre (para Ubuntu está disponível pelo seu repositório oficial) lê e converte para esse formato.

Diretamente na rede há as seguintes opções:

• Addon EPUBReader para Firefox.
• O sítio MagicScroll, isolado ou como aplicativo para Google Chrome.
• O Aldiko Book Reader para celulares com Android.

Script para facilitar o uso do GIT:

!/bin/bash if [ "$(id -u)" = "0" ] then echo -e "\033[44;37;1mEste programa executou uma operação ilegal e será fechado. Motivo: Você é root!\033[m" exit fi help () { echo "" echo "[c] - Cria um arquivo." echo "[e] - Editar um arquivo." echo "[:] - Abre linha de comando." echo "[send] - Envia as alterações." echo "[exit] - Sair do programa sem salvar." echo "[conflito] - Resolver conflito de arquivos." echo "[help] - Lista os comandos válidos." echo "" } criar () { echo -n "Nome do arquivo: " read nome gedit $nome } editar () { ls -lR |more echo -n "Escolha o arquivo: " read arquivo gedit $arquivo } clear echo "Baixando arquivos do github" git pull while true do echo -e -n "Digite \033[44;37;1m[c]\033[m\c" echo -e -n " para criar ou \033[41;37;1m[e]\033[m\c" echo " para editar um arquivo." echo "Digite help para ajuda." echo "" read opcao case $opcao in "c") criar ;; "e") editar ;; "send") git add * git commit -a git push echo "Comentario adicionado e enviado." echo "" exit ;; ":") while true do bash=$(pwd) echo -n "$bash/ " read comando $comando done ;; "conflito") echo "Resolvendo conflito de arquivo(s)" git stash 1>/dev/null git pull git stash pop 1>/dev/null echo "Conflito resolvido." ;; "help") help ;; "exit") exit ;; *) echo "Opção inválida." echo "" ;; esac done </syntaxhighlight>

Método de Avaliação

• Serão 4 provas, uma por mês:
  • Abril
  • Maio
  • Junho
  • Setembro

onde serão avaliados, de forma prática, todos os conteúdos até a aula anterior.

• A composição final do conceito se dará da seguinte forma:
  • 4 A: A;
  • No máximo 1 C e nenhum D: B;
  • No máximo 1 D: C;
  • Demais casos: D.

Ambiente de Trabalho

Link para cadastro no github: https://github.com/signup/free

NetKit

Eduardo Guse, João Carlos Warmling e Thiago Cunha

Foi usada a versão do netkit do professor Marcelo Sobral(gnome-netkit) disponível aqui.

• Repositório Git do projeto no github

Anderson Rosa e Ricardo Martins

Nós também utilizamos a versão gnome-netkit do Professor Marcelo Sobral

• cenario_ger.rar (desatualizado)
• Repositório do GitHub
  

Marcelo,Gilberto,Paulo Alves e Liamari

Usamos tambem o gnome-netkit do professor Marcelo Sobral

• Lab.conf, dhcp.conf e interfaces : Repositorio do GitHub

Bruna Amante

• Repositório no GitHub

Helton Luiz Porto, Emerson Gomes, Fernando

Utilizado gnome-netkit do professor Marcelo Sobral

• Lab.conf

Renato, Carlos Alberto, Rafael Pereira

• Repositório no GitHub

Anderson Felisbino, Bolivar Lagos e Renan Hames

• Repositório no GitHub

Michel Fernandes, Guilherme Bilbao, Jean Cesar

• Repositório no GitHub

Rafael Luchi Luz

• Repositório no GitHub

Carlos Moisés Araldi Maciel

• Repositório no GitHub

Anderson Pereira, Paulo Vitor, Rafael Togo

• Repositório no GitHub

Scripts e Arquivos de Configuração

Capítulo 1

• Item "Juntando as Peças..":

#!/bin/bash
#
# 20120320 Ederson Torresini: uma proposta de solução do item "Juntando as Peças..."

# Variáveis globais
TMP="/tmp/.saida"

enter()
{
	echo ""
	echo -n "Tecle [ENTER] para avançar..."
	read enter
}

arquivosLocais()
{
	echo ""
	echo "Arquivos do tipo 'named pipe'. Por favor, aguarde..."
	find / -type p -ls 2> /dev/null
	enter
	echo ""
	echo "Arquivos do tipo UNIX 'socket'. Por favor, aguarde..."
	find / -type s -ls 2> /dev/null
	enter
}

sockets()
{
	case ${1} in
		"1")
			lsof -n -P | grep TCP | grep LISTEN > ${TMP}
			lsof -n -P | grep UDP | grep LISTEN >> ${TMP}
			cat ${TMP} | sort
			enter
			;;
		"2"|"3")
			lsof -n -P | grep TCP | grep LISTEN > ${TMP}
			lsof -n -P | grep UDP | grep LISTEN >> ${TMP}
			cat ${TMP} | grep ${2} |sort
			enter
			;;
	esac
}

cat /dev/null > ${TMP}
chmod 600 ${TMP}
if [ "$(id -u)" != "0" ]
then
	echo "Rodando como usuário não privilegiado."
	echo "Os resultados poderão estar incompletos."
	enter
fi
while true
do
	clear
	echo "Por favor, escolha uma opção:"
	echo "1) Arquivos locais (IPC)."
	echo "2) 'Sockets'."
	echo "n) Encerrar programa."
	echo -n "Digite a sua opção: "
	read opcao
	case ${opcao} in
		"1")
			arquivosLocais
			;;
		"2")
			echo ""
			echo "Listar serviços por nome de processo, dono ou porta?"
			echo "1) Processo."
			echo "2) Dono."
			echo "3) Porta."
			echo -n "Digite a sua opção: "
			read opcao
			case ${opcao} in
				"2")
					echo ""
					echo -n "Digite o nome do usuário: "
					read subopcao
					;;
				"3")
					echo ""
					echo -n "Digite o número da porta: "
					read subopcao
					;;
			esac
			sockets ${opcao} ${subopcao}
			;;
		"n")
			rm -f ${TMP}
			exit
			;;
		*)
			echo "Escolha opção válida."
	esac
done

LAMP

O termo LAMP se refere a Linux + Apache + MySQL + PHP. Vamos aos passos para a instalação e configuração das aplicações de acordo com as necessidades.

Sempre será considerado o cenário visto em sala:

1. Servidor DMZ 0: bora-bora
   • IP: 192.168.3.1
   • Serviço: MySQL
2. Servidor DMZ 1: tuvalu
   • IP: 192.168.3.2
   • Serviço: HTTP

Blog

O CMS escolhido para o blog foi o Wordpress, um dos mais utilizados. De acordo com o cenário, o banco de dados será instalado no primeiro servidor, bora-bora, enquanto que o servidor Web será no segundo, Tuvalu.

Servidor 0: Bora-bora

Primeiro, a instalação do servidor MySQL:

aptitude install mysql-server

Depois, a configuração de um banco de dados para o blog. É criado um usuário webmaster, com a senha 'secret4', cujo acesso se dará a partir do servidor Web (informado pelo seu IP):

mysql -uroot -p mysql

Uma vez dentro do CLI do banco, através dos comandos SQL são criados tanto o usuário quanto o banco - incluindo seus relacionamentos:

CREATE DATABASE wordpress;
GRANT ALL PRIVILEGES ON wordpress.* TO 'webmaster'@'192.168.3.2' IDENTIFIED BY 'secret4';
FLUSH PRIVILEGES;

Servidor 1: Tuvalu

No servidor Web, é instalado o servidor Web e o interpretador PHP - já com suporte a MySQL:

aptitude install apache2 php5 php5-mysql

Em seguida, é descarregado o código do Wordpress (última versão = 3.3.2) no diretório de publicação, /var/www, para compor a URL /blog:

cd /var/www
wget http://br.wordpress.org/wordpress-3.3.2-pt_BR.tar.gz
tar xzf wordpress-3.3.2-pt_BR.tar.gz
rm -f wordpress-3.3.2-pt_BR.tar.gz
mv wordpress blog

Depois, são aplicadas as permissões e propriedades para o total controle da aplicação:

 
chown -R www-data:www-data blog
find blog -type d -exec chmod 700 {} \;
find blog -type f -exec chmod 600 {} \;

Após a configuração do blog, pode-se facilitar o acesso ao código para o webmaster utilizando o WebDAV, que expande os métodos HTTP. Primeiro, é ativado o módulo do Apache e reiniciado o serviço:

a2enmod dav dav_fs dav_lock
service apache2 restart

O diretório do blog deve, pois, ter permissões especiais. É criado um arquivo de configuração para tal:

vi /etc/apache2/conf.d/blog

com o conteúdo:

<Directory /var/www/blog>
   Dav On
</Directory>

Porém, por questões de segurança, deve-se restringir ao máximo tal diretório, permitindo que apenas o código PHP seja executado sem problemas. O arquivo fica assim:

<Directory /var/www/blog>
   Options None
   AllowOverride None
   Dav On
</Directory>

Ainda assim, não haverá acesso externo. Isso acontece porque nas novas versões o Apache bloqueia por padrão (ou omissão). Deve-se liberar o acesso para qualquer IP:

<Directory /var/www/blog>
   Options None
   AllowOverride None
   Dav On
   Order allow,deny
   Allow from all
</Directory>

E se o blog pudesse estar visível apenas via HTTPS? Bom, ativa-se o módulo SSL e redireciona todo o tráfego HTTP para HTTPS:

a2enmod ssl
a2ensite default-ssl
vi /etc/apache2/sites-enabled/000-default

onde adiciona-se a seguinte linha após a definição do VirtualHost:

RedirectMatch ^/(.*) https://www.rtfm.com.br/blog/

Cria-se um certificado auto-assinado para confirmar a identidade do sítio:

openssl req -new -x509 -nodes -days 365 -out /etc/ssl/certs/apache2.pem -keyout /etc/ssl/certs/apache2.pem

Na configuração do servidor Web via HTTPS, altera-se o certificado antigo por esse. No arquivo /etc/apache2/sites-enabled/default-ssl deve-se trocar as linhas:

SSLCertificateFile    /etc/ssl/certs/ssl-cert-snakeoil.pem
SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

por

SSLCertificateFile    /etc/ssl/certs/apache2.pem
SSLCertificateKeyFile /etc/ssl/certs/apache2.pem

Até o presente momento, o blog está publicado na Web, com tráfego HTTPS disponível. Contudo, qualquer pessoa, inclusive o webmaster pode alterar o código PHP. Para controlar esse acesso, é adicionado um esquema de autenticação para limitar os métodos HTTP. Exceto os métodos básicos GET e POST, todos os outros métodos irão requerer autenticação:

<Directory /var/www/blog>
   Options None
   AllowOverride None
   Dav On
   Order allow,deny
   Allow from all

   <LimitExcept GET POST>
      AuthType Basic
      AuthName "Acesso Restrito."
      AuthUserFile /etc/apache2/blog-senhas
      Require valid-user
   </LimitExcept
</Directory>

E, por fim, é criado o arquivo de senhas, /etc/apache2/blog-senhas com o comando htpasswd, e um primeiro chamado webmaster:

htpasswd -c -s /etc/apache2/blog-senhas webmaster

Embora se pergunte se ainda será possível ver o código PHP do Wordpress, ou mesmo os arquivos de usuário enviados via upload, usando WebDAV, a resposta é sim. Mas como o código já é software livre, e as imagens já estão disponíveis, qual a diferença?

Se quiser, pode-se utilizar outros métodos mais sofisticados, como WebDAV via HTTPS e acesso regular ao blog via HTTP. Assim, para todo o tráfego HTTPS é preciso autenticação do webmaster, tornando a solução mais segura.

O blog de Tele tem um cenário semelhante:

• HTTP sem WebDAV e sem senha:
  • Blog: http://tele.sj.ifsc.edu.br/blog.
  • Leitura de arquivo públicos: http://tele.sj.ifsc.edu.br/arquivos/alunos e http://tele.sj.ifsc.edu.br/arquivos/publicos/.
• HTTPS com WebDAV e com senha:
  • Leitura e Escrita de arquivos públicos e restritos: todos os arquivos públicos, https://tele.sj.ifsc.edu.br/arquivos/cotel e https://tele.sj.ifsc.edu.br/arquivos/tele/.

<graphviz>

digraph HTTP {

subgraph clusterHTTP
{
 label="HTTP"
 Blog [shape=Mrecord]
 "Leitura de arquivos" [shape=Mrecord]
}
subgraph clusterHTTPS
{
 label="HTTPS" [shape=Mrecord]
 "Escrita de arquivos" [shape=Mrecord]
}
Blog -> "Leitura de arquivos"
Blog -> "Escrita de arquivos" [label="Redir"]
"Leitura de arquivos" -> "Escrita de arquivos" [label="Redir"]
"Escrita de arquivos" -> "Leitura de arquivos" [label="Redir"]

}

</graphviz>

Resumo

Servidor 0: Bora-bora:

• Pacotes instalados:

mysql-server

• Comandos executados:

mysql -u root-p

Servidor 1: Tuvalu

• Pacotes instalados:

apache2
php5
php5-mysql

• Comandos executados:

a2enmod dav dav_fs dav_lock
a2enmod ssl
a2ensite ssl
service apache2 restart

• Arquivos/diretórios modificados:

/var/www/blog/
/etc/apache2/sites-enable/000-default
/etc/apache2/sites-enable/default-ssl
/etc/apache2/conf.d/blog
/etc/apache2/blog-senhas

<graphviz>

digraph DHTML {

rankdir=LR
Cliente [shape=plaintext]
subgraph clusterBoraBora
{
 label="Bora-Bora"
 MySQL [shape=Mrecord]
}
subgraph clusterTuvalu
{
 label="Tuvalu"
 Apache [shape=Mrecord]
 PHP [shape=Mrecord]
}
Cliente -> Apache [color=blue,label="HTTP"]
Apache -> PHP [color=green,label="Aplicação"]
PHP -> MySQL [color=red,label="SQL"]

}

</graphviz>

Webmail

A aplicação Web escolhida foi RoundCube, que implementa uma interface amigável ao usuário final, como arrastar e soltar mensagens de uma caixa a outra (embora isso soe antigo, é bom lembrar que ainda há usuários com navegador sem suporte a tais funcionalidades). De acordo com o cenário, assim como o blog, o banco de dados será criado no servidor bora-bora e a aplicação Web em tuvalu.

Servidor 0: Bora-bora

Com o servidor MySQL já instalado, é preciso apenas cria a base:

mysql -uroot -p

E dentro da CLI do serviço:

CREATE DATABASE roundcube;
GRANT ALL PRIVILEGES ON roundcube.* TO 'webmaster'@'192.168.3.2';
FLUSH PRIVILEGES;

Não é necessário associar, dessa vez, a senha ao usuário, uma vez que a tupla máquina-usuário-senha já existe. O que faltava, nesse caso, era relacionar o par máquina-usuário à base.

Servidor 1: Tuvalu

O servidor Web também será de SMTP e de IMAP, permitindo que, futuramente, seja permitido apenas o webmail em detrimento das aplicações locais (desktop).

Assim, para instalar o servidor SMTP, optou-se pelo Postfix por questões didáticas: documentação e facilidade de configuração e integração com outras aplicações. Dica: atenção especial aos parâmetros que iniciam por my.

aptitude install postfix

Uma vez instalado, o principal arquivo de configuração, /etc/postfix/main.cf, fica assim:

# Geral
myhostname = mail.rtfm.com.br
mydomain = rtfm.com.br
#
# MTA* -> MTA
myorigin = @myhostname
mynetworks = 127.0.0.0/8 [::1]/128 192.168.0.0/24 192.168.3.0/24
#
# MTA -> MTA*
inet_interfaces = all
mydestination = rtfm.com.br, mail.rtfm.com.br, smtp.rtfm.com.br, localhost, localhost.localdomain
relayhost =
alias_maps = /etc/aliases

Como a ênfase está no webmail, ao invés da aplicação de desktop, será utilizado um servidor simples de IMAP, com a intenção de acesso exclusivo via Web:

aptitude install dovecot-imapd

E pronto! Não é necessário qualquer configuração. Lembrando que a configuração apresentada para ambos os serviços prevê usuários locais do sistema instalado; ou seja, todos aqueles listados nas fontes de busca (/etc/nsswitch.conf).

Agora sim, os pré-requisitos do RoundCube foram atendidos: LAMP + SMTP + IMAP. Próximo passo: descarregar o código PHP da aplicação. A última versão disponível é 0.7.2

cd /var/www/
wget http://downloads.sourceforge.net/project/roundcubemail/roundcubemail/0.7.2/roundcubemail-0.7.2.tar.gz
tar xzf roundcubemail-0.7.2.tar.gz
rm -f roundcubemail-0.7.2.tar.gz
mv roundcube webmail
chown -R www-data:www-data webmail
find webmail -type d -exec chmod 700 {} \;
find webmail -type f -exec chmod 400 {} \;

Embora as permissões não sejam as ideais (ainda é possível valores mais agressivos), isso permite a continuação da aplicação via interface Web:

http://www.rtfm.com.br/webmail/installer

Segundo o guia oficial de instalação, é importante adicionar algumas permissões à aplicação (AllowOverride), uma vez que a mesma utiliza arquivos .htaccess para reduzir o acesso em alguns diretórios. Portanto, deve ser criado um arquivo de configuração para o Apache:

cat > /etc/apache2/conf.d/webmail << EOF
<Directory /var/www/webmail/>
    Options None
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>
EOF
service apache2 restart

E, por fim, adicionar as linhas referentes ao serviço de email no serviço DNS, mas especificamente no final do arquivo /etc/bind/rtfm.com.br:

@    IN MX 0  mail.rtfm.com.br.
mail IN A     192.168.3.2
smtp IN CNAME mail.rtfm.com.br.
imap IN CNAME mail.rtmf.com.br.

E, claro, reiniciar o serviço:

service bind9 restart

Ou, para aqueles que já conhecem o rndc:

rndc reload

Gerência de Rede

A gerência de rede, embora vista oficialmente apenas no último mês de aula, é vista ao longo de toda a disciplina - por isso o seu nome. No modelo OSI, é utilizado o padrão FCAPS:

• Monitoramento (fault): o recurso está disponível?
• Configuração (configuration): o recurso está bem configurado?
• Contabilização (accounting): quanto do recurso está sendo utilizado?
• Desempenho (performance): o recurso está sendo bem usado?
• Segurança (security): o recurso está protegido?

Desses itens acima listados, por questões de tempo e didática, serão abordados Monitoramento e Contabilização. Havendo tempo hábil, os demais também serão abordados.

Monitoramento

O termo recurso pode se aplicar, em termos de monitoramento, a um equipamento de rede ou serviço oferecido em rede. Isso implica a sua disponibilidade e um sistema monitor, que testa regularmente para saber do estado daquele. Havendo alguma falha no teste, será disparada uma ação específica e pré-programada, que pode ser desde um alerta ou mesmo uma ação corretiva sem a intervenção do admnistrador.

O monitoramento pode ser realizado a partir de ferramentas próprias do administrador (scripts sob rotina), porém há aplicações desenvolvidas para tal, como por exemplo Nagios, Zenoss e outros.

Um script:

#!/bin/bash

# Tem um endereço para testar?
if [ "${1}" = "" ]
then
	echo "Use: ${0} <IP>"
	exit
fi

# Coleta dos dados: quantidade de pings respondidos
RESPOSTA=$(ping -c 3 ${1} | grep received | cut -d , -f 2 | cut -d r -f 1)

# Teste: pelo menos um ping retornou?
if [ "${RESPOSTA}" -gt "0" ]
then
	echo "No ar."
else
	echo "Fora do ar."
fi

Contabilização

Uma vez o recurso disponível em rede, pode-se contabilizar o seu uso; ou seja, quanto do recurso é utilizado. Na arquitetura TCP/IP, o protocolo mais usado para tal é o Simple Network Management Protocol (SNMP), documentado ao longo de várias RFCs. Nesse protocolo, há as entidades principais: o dispositivo a ser monitorado, deve possuir um agente, uma aplicação simples que responde a requisições de consulta (GET) e de escrita (SET), e o gerente que realiza tais operações remotas (network management system - NMS).

Cabe, portanto, ao gerente SNMP realizar, periodicamente, consultas aos vários agentes rodando nos dispositivos sob monitoramento. Esse processo regular se chama polling. Porém, como cada agente possui informações específicas, como a tabela de roteamento de um roteador ou a quantidade de usuários conectados em um sistema UNIX-like, não há um modelo rígido de quais dados serão fornecidos. Ao invés disso, há um conjunto de documentos que definem quais informações estão disponíveis e como acessá-las: as Management Information Bases (MIBs). As MIBs organizam os dados de forma hierárquica, em árvore, onde cada um desses objetos (object identifier - OID) possui:

• Uma localização numérica.
• Uma descrição textual.
• O tipo de dado a ser armazenado: número, data, texto, etc.
• O valor do dado.

Pelo fato de ser uma árvore, uma MIB pode, assim, estender a árvore global a partir de um ramo de outra MIB (lembrando: a árvore é uma estrutura de dados recursiva...). O subconjunto de MIBs utilizadas para um dispositivo (e seu agente) definem que informações podem ser coletadas pelo gerente. A título de exemplo, na documentação de uma aplicação da Oracle nota-se a extensão da árvore (nó .1.3.6.1.4.1) para atender a detalhes específicos do programa em questão.

Para visualizar as informações, pode-se instalar alguns comandos de consulta e escrita SNMP:

aptitude install snmp

Contudo, os comandos se aplicam apenas a operações básicas e acessando diretamente os dados. Para fazer pleno uso, i.e., utilizando as MIBs como referência, deve-se instalar também a lista atualizada das mesmas (e atualizar o arquivo de configuração snmp.conf):

aptitude install snmp-mibs-downloader
download-mibs
sed -i 's/^mibs\ :/#mibs\ :/g' /etc/snmp/snmp.conf

Agora, pode-se realizar consultas aos agentes.

Um último conceito: a troca de dados entre agente e gerente se dá quando ambos pertencem a um mesmo agrupamento, ou comunidade. Na versão 3 do SNMP, é possível adicionar ainda autenticação ao processo. Geralmente, utilizam-se as versões 1 (equipamentos antigos ou de poucas funcionalidades) ou 2c. Os comandos a seguir perfazem toda a árvore do dispositivo (sequências de consultas: GETNEXT) alvo de forma sequencial do equipamento 192.168.1.1 e que pertence à comunidade ifsc:

snmpwalk -v 2c -c ifsc 192.168.1.1
snmpwalk -Of -v 2c -c ifsc 192.168.1.1
snmpwalk -On -v 2c -c ifsc 192.168.1.1

O primeiro é o comando convencional. O segundo apresenta o nó da árvore de acordo com a descrição da MIB correspondente. O terceiro, por fim, apresenta todos os elementos com seu "endereço" numérico. Para saber mais sobre a correspondência entre número e descrição, há o comando translate:

snmptranslate -Of .1.3.6.1.4.1
snmptranslate -Oa .1.3.6.1.4.1

O primeiro comando "traduz" o seu valor, enquanto que o segundo identifica qual a MIB que o documenta.

Cenário

No nosso cenário, é interessante que todos os equipamentos importantes na rede estejam conm seus agentes operando e respondendo, regularmente, ao gerente central. Para fins didáticos, será utilizado o Cacti como gerente, o qual é implementado em plataforma AMP; logo, pode-se aproveitar toda a infraestrutura de serviço Web e MySQL dos servidores da DMZ (Matriz). Embora sua documentação seja suficiente no auxílio de uma instalação manual, a instalação automatizada também o é:

aptitude install cacti

A configuração não será o foco deste tópico, uma vez que há documentação disponível para tal. Ao invés, haverá a ênfase no SNMP em si.

No caso dos agentes, em sistemas variantes do UNIX, pode-se utilizar a implementação mais comum:

aptitude install snmpd

Inicialmente, pode ser utilizada uma configuração bastante simples: um agente que define uma única comunidade somente-leitura para gerente remoto - no caso, a comunidade ifsc. Além disso, é bastante recomendado informar onde está e quem é o responsável pelo dispositivo monitorado, de forma que seja possível, em termos de tempo hábil, corrigir ou prevenir uma falha. Esses são os objetos SNMPv2-MIB::sysLocation.0 (.1.3.6.1.2.1.1.6.0) e SNMPv2-MIB::sysContact.0 (.1.3.6.1.2.1.1.4.0), respectivamente.

cat > /etc/snmp/snmpd.conf << EOF
rocommunity ifsc
sysLocation IFSC Sao Jose - Laboratorio de Redes I
sysContact etorresini@ifsc.edu.br
EOF
sed -i 's/\ 127.0.0.1//g' /etc/default/snmpd
service snmpd restart

O primeiro comando aplica toda a configuração do agente SNMP. O segundo comando permite conexões remotas (além de loopback). O último, por fim, reinicia o serviço agente.

Para testar, pode-se realizar os comandos no mesmo servidor onde está instalado o gerente (Web), consultando desde o tempo no ar do agente (uptime), bem como os parâmetros definidos manualmente no arquivo acima. Assumindo que o agente está no computador com o IP 192.168.1.1:

snmpget -v 2c -c ifsc 192.168.1.1 sysUpTimeInstance
snmpget -v 2c -c ifsc 192.168.1.1 sysLocation.0
snmpget -v 2c -c ifsc 192.168.1.1 sysContact.0

Ou, com o endereço na árvore de objetos:

snmpget -On -v 2c -c ifsc 192.168.1.1 sysUpTimeInstance
snmpget -On -v 2c -c ifsc 192.168.1.1 sysLocation.0
snmpget -On -v 2c -c ifsc 192.168.1.1 sysContact.0

O que se percebe, com os resultados acima, é que tais objetos está próximos na árvore:

• Tempo: .1.3.6.1.2.1.1.3.0
• Local: .1.3.6.1.2.1.1.4.0
• Responsável: .1.3.6.1.2.1.1.6.0

Logo, pode-se varrer (walk) um ramo superior da árvore comum a todos (.1.3.6.1.2.1.1), mostrando esses objetos próximos:

snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1.3.6.1.2.1.1

E, como uma árvore é um conceito recursivo, esse efeito se prolonga até o ramo principal, a raiz, mostrando mais e mais objetos:

snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1.3.6.1.2.1.1
snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1.3.6.1.2.1
snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1.3.6.1.2
snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1.3.6.1
snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1.3.6
snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1.3
snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1

Dito isso, pode-se agora dizer que os objetos são indexados; ou seja, cada ramo da árvore possui um conjunto de informações relativamente próximas. Isso significa que os nomes de interface de rede estarão reunidos em um ramo:

snmpwalk -v 2c -c ifsc 192.168.1.1 IF-MIB::ifDescr
snmpwalk -v 2c -c ifsc 192.168.1.1 .1.3.6.1.2.1.2.2.1.2

Enquanto que estatísticas de uso em outro, como quantidade de pacotes unicast transmitidos em outro, conferindo escalabilidade da árvore global:

snmpwalk -v 2c -c ifsc 192.168.1.1 IF-MIB::ifOutUcastPkts
snmpwalk -v 2c -c ifsc 192.168.1.1 .1.3.6.1.2.1.2.2.1.17

Porém, como já dito, esses objetivos estão próximos, mais especificamente visíveis todos um nível acima:

snmpwalk -v 2c -c ifsc 192.168.1.1 .1.3.6.1.2.1.2.2.1

Nota-se, em todos os casos, o índice designando cada interface: geralmente a interface loopback é a primeira (sufixo 1), seguida pelas demais - e seus sufixos ou terminações na sequência: eth0 (2), eth1 (3), eth2 (4) e assim por diante.

A ferramenta Cisco SNMP Object Navigator pode ser útil para navegar pela árvore e sua definição através das MIBs.

Por fim, uma tarefa a ser realizada: instalar e configurar o agente em todos os servidores da matriz e adicioná-las à contabilização do gerente Cacti no servidor Web.