ISPTools: Ferramenta Brasileira online para testes de rede (externos)

Dica rápida: como você testa externamente suas aplicações e serviços?

Como saber quais os registros DNS seus servidores estão retornando?

Como testar tudo através de fontes diferentes (vários provedores)?

Simples: utilize o ISPTools!

Ferramenta criada pelo Brasileiro GIOVANE HELENO para resolução de vários problemas expostos na lista “CAIU?“, reuni em um portal web uma série de ferramentas simples para que você, administrador de redes/sistemas, possa tirar suas próprias conclusões sobre o status de sua estrutura de forma independente, fugindo da máxima “aqui está tudo normal, o problema deve ser aí!”.

Como funciona

O portal conta com o auxílio de vários provedores de serviços espalhados pelo Brasil (e alguns fora também), para que os diversos testes possam ser o mais conclusivos possíveis. Cada um destes provedores precisar ser um A.S. Um exemplo da serventia deste teste é: meu site está acessível através da Oi (TELEMAR), mas não está através da GVT.

Acessando o portal, é possível ver uma lista de ferramentas disponíveis:

ISPTools - ferramentas

Para utilizar qualquer uma das ferramentas, é preciso logar com uma das contas dos serviços indicados:

ISPTools - ferramentas - loginO portal alerta que não reutiliza/repassa os dados do usuário. A informação é somente para que a coisa não vire bagunça:

É necessário se registrar para realizar os testes. Nos comprometemos a não utilizar suas informações para nenhuma finalidade além de estatística e controle de acesso. As informações serão disponibilizadas somente de acordo com a lei nº 12.965 (Marco Civil Brasileiro).

Exemplo de um teste: DNS

ISPTools - Teste de DNS

Como apoiar

É possível se juntar à lista de provedores e integrar mais um ponto de testes. Para isso, veja mais detalhes aqui. Outro apoio é o financeiro: o Giovane criou e  disponibilizou esta excelente ferramenta de forma totalmente gratuita, porém, tem custos com registro, hospedagem e desenvolvimento (tempo = R$). Então, se utiliza e gosta de ferramenta, dê uma forcinha lá!

Abraço!

Anúncios

UniFi AP manager: como monitorar Wireless Ubiquiti (Unifi APs) via Zabbix

UniFi AP manager: como monitorar Wireless Ubiquiti (Unifi APs) via Zabbix

A Ubiquiti fornece uma gama de produtos Wireless geralmente utilizados por pequenos provedores de acesso à internet. Além da área de comercialização de Acessos à internet, ela vem bastante agressiva para atendimento à área empresarial. Para todos os casos, a empresa apela fortemente ao custo benefício em relação a qualidade x preço: Hardware muito barato, potente e estável, além de Software grátis (para aquisição, uso e atualização).

Controlador Ubiquiti

Controlador Ubiquiti – gerenciador de APs Unifi

Neste tutorial nos focaremos na plataforma Wireless Unifi. Aqui integrarei o Unifi Manager ao Zabbix, trazendo melhorias à gerência Wireless permitindo extrair, visualizar e guardar dados importantes sobre a utilização deste importante parque.

Para melhor aproveitamento deste tutorial é preciso ter experiência com Templates, LLD (configuração no Zabbix) e conhecimento básico de Shell Script (bash).

Motivação

Se já existe um software para gerência fornecido pelo fabricante, porquê reinventar a roda?

  • Para gerência, ele é perfeito:
    • Configuração de todos os APs de forma central (adoção, configuração, atualização, reboot, reset);
    • Análise do parque (área de cobertura, versão dos APs, atividade de clientes);
    • Análise de clientes (conexão atual, histórico e tempos de permanência);
    • Bloqueio de clientes (aplicado uma vez, repassado a todos os APs do parque);
  • Para monitoramento, nem tanto:
    • Os gráficos não são conclusivos;
    • Gráficos são estáticos e limitados (tanto em disposição na tela, quanto mostram dados incorretos);
    • Não é possível ver os dados “granulados” (somente diário e mensal);
    • Não é possível ver nos últimos minutos, dados sobre clientes por SSID;
    • Dados históricos “bagunçados”.

Foco

Neste tutorial, demonstrarei a capacidade do Zabbix monitorar os seguinte itens:

  • Relacionado aos APs:
    • Lista completa de APs (texto);
    • Quantidade total de APs;
    • Quantidade de APs ativos;
    • Estado dos APs (via ICMP-ping).
  • Relacionado aos SSIDs (WLANs):
    • Quantidade total de SSIDs;
    • Lista completa de SSIDs (texto);
  • Em relação aos clientes:
    • Quantidade total de Clientes (considerando todo o parque);
    • Quantidade de clientes em cada AP;
    • Quantidade de clientes em cada SSID (independente da quantidade de APs no SSID).

Recursos

Para viabilizar o acesso aos dados, foram utilizados os seguintes recursos:

  • Controlador Unifi instalado em um CentOS 6.6 (x86_64)
    • Testado nas versões do Unifi 3.2.1 , 3.2.5 , 3.2.7 e 3.2.10, com algumas alterações à partir da 3.2.7 (que serão comentadas adiante);
    • Cliente Zabbix (testado nas versões 2.2.5 e 2.4.5) instalado no mesmo servidor que roda o Controlador Unifi (também pode ser utilizado outro computador para pegar os dados do controlador);
    • Diretório scripts criando dentro da raiz de instalação do Zabbix (por exemplo: /etc/zabbix/scripts ou outro, de acordo com a sua instalação);
    • Python 2.6 (talvez funcione com versões mais novas);
    • pip (um gerenciador de pacotes para Python);
    • Pacote Python unifi (instalado via ‘pip’): aplicação desenvolvida em Python para acesso aos dados da API Unifi;
  • Scripts, desenvolvidos por mim, que acessam os dados do controlador e devolvem ao servidor Zabbix
    • Utilização de LLD (Low Leve Discovery) para descoberta automática de novos itens;
    • Descoberta automática de novas WLANs e novos APs.
  • Arquivo com “UserParameter” para ativar as novas funcionalidades (novos itens do Zabbix)
    • Arquivo com as chamadas aos Scripts citados acima para recuperação de informações.
  • API UNIFI (aberta, por padrão)
    • Fonte de dados fornecida pela Ubiquiti (no controlador) para estender as capacidades e possibilidades de seus Softwares.
  • Servidor Zabbix (testado nas versões 2.2.5 e 2.4.5)
    • Sendo o primeiro teste, recomenda-se utilizar uma instalação do Zabbix server específica para testes com o intuito de não ter nenhum tipo de problema com o server de produção;
    • Com um template criado especificamente para monitoramento do controlador Unifi.

Atenção 1: Os scripts não conseguem trabalhar com nomes (para APs ou WLANs) que possuam dois pontos (“:”), acentos ou caracteres especiais (como “Salão de Festas 01” ou “AP do Terraço”, por exemplo). Antes de prosseguir, altere todos os identificadores.

Atenção 2: De acordo com alguns testes, não foi possível integrar a solução quando o controlador está instalando em Windows (reportado pelo usuário Victor nos comentários).

Preparação/Instalação

Com o controlador instalado e funcionando, será preciso instalar as dependências (logado como root ou utilizando o ‘sudo’).

Instalando o ‘pip’:

yum install -y python-pip

Resultado:

Dependências resolvidas
=================================================================================
 Pacote Arq. Versão Repo Tam.
=================================================================================
Instalando:
 python-pip noarch 1.3.1-4.el6 epel 330 k
Instalando para as dependências:
 python-setuptools noarch 0.6.10-3.el6 base 336 k
Resumo da transação
=================================================================================
Install 2 Package(s)

Obs: Para ver uma lista de comandos suportados pelo ‘pip’, utilize “pip -h”.

Instalando pacote ‘unifi’ via ‘pip’:

pip install unifi

Resultado:

Downloading/unpacking unifi
 Downloading unifi-1.2.2.tar.gz
 Running setup.py egg_info for package unifi
Installing collected packages: unifi
 Running setup.py install for unifi
 changing mode of build/scripts-2.6/unifi-low-snr-reconnect from 644 to 755
 changing mode of build/scripts-2.6/unifi-ls-clients from 644 to 755
 changing mode of build/scripts-2.6/unifi-save-statistics from 644 to 755
 changing mode of build/scripts-2.6/unifi-log-roaming from 644 to 755
 changing mode of /usr/bin/unifi-ls-clients to 755
 changing mode of /usr/bin/unifi-low-snr-reconnect to 755
 changing mode of /usr/bin/unifi-save-statistics to 755
 changing mode of /usr/bin/unifi-log-roaming to 755
Successfully installed unifi
Cleaning up...

Com tudo instalado, vamos aos testes.

Obs: Para versões do controlador a partir da 3.2.7, será preciso editar o arquivo “/usr/lib/python2.6/site-packages/unifi/controller.py” antes de prosseguir com os testes.

Neste arquivo, comente a seguinte linha, salvando a alteração:

_ssl.PROTOCOL_SSLv23 = _ssl.PROTOCOL_SSLv3

Baixando scripts e conf

No CentOS (controlador Unifi), faça o download destes arquivos e descompacte-os no diretório scripts (comentado na área de Recursos). No caso desta instalação, ficou em “/usr/local/zabbix/scripts/”. Depois de descompactado o arquivo, a lista de arquivos resultantes deve ser:

ubiquiti (diretório)
  \
   --> aps.py (arquivo)
  \
   --> clients.py (arquivo)
  \
   --> wlans.py (arquivo)
unifi-discovery.sh (arquivo)
unifi-monitor.sh (arquivo)

Ainda no controlador, faça também o download deste aquivo conf, (unifi.conf) salvando-o no diretório de configurações extras do seu cliente Zabbix (onde ficam os UserParameters). No caso desta instalação, ele ficou no diretório “/usr/local/zabbix/etc/zabbix_agentd.conf.d/”.

Obs: Para ativar a leitura destas configurações pelo Agente Zabbix (no controlador unifi), edite o arquivo de configuração do Agente (zabbix_agentd.conf), procure a linha Include e informe o diretório utilizado para guardar os ‘UserParameter’. No caso desta instalação ficou assim:

Include=/usr/local/zabbix/etc/zabbix_agentd.conf.d/*.conf

Edite o ‘unifi.conf’ alterando a linha que chama os Script ‘unifi-monitor.sh’, para o diretório em que vocês os salvou (baseado nos itens anteriores). Neste caso, a linha ficou desta forma:

UserParameter=up.unifi[*],/usr/local/zabbix/scripts/unifi-monitor.sh $1 $2 "$3" $4

Depois disto, reinicie o agente Zabbix no controlador Unifi para validar o novo item (up.unifi).

O que são e o que fazem estes Scripts:

Tendo navegado até o diretório escolhido para descompactar, será possível verificar alguns aquivos (no diretório ubiquiti): ‘aps.py’, ‘clients.py’ e ‘wlans.py’. Estes são os Scripts Python base para todas as consultas. Estes Scripts são utilizados pelos Scripts ‘unifi-monitor.sh’ e ‘unifi-discovery.sh’ fornecendo os dados brutos. Os Scripts “unifi-monitor.sh” e “unifi-discovery.sh” trabalham os dados e os trazem no formato entendível pelo Zabbix e de acordo com os itens utilizados nas consultas.

A imagem a seguir, ilustrar o roteamento e dependência entre os Scripts:

OBS: Para facilitar, todos os Scripts (Python ou Shell) possuem comentários internos.

A imagem vale mais que mil palavras: toda a interação do servidor Zabbix é feita inicialmente com o Script “unifi-monitor.sh”. Dependendo da necessidade, ele irá buscar serviços no “unifi-discovery.sh” ou diretamente num dos três Scripts Python (aps.py, wlans.py e clients.py).

Primeiro teste (validador das configurações): Listando os APs.

Edite o arquivo “aps.py”, procurando pela linha abaixo, preenchendo com as informações do seu Setup:

c = Controller('endereco-controlador-unifi', 'Usuario', 'Senha', 'v3', 'Site')

Esta configuração será lida pelo Software que acessa a API do Unifi, todas as vezes que um dos Scripts for executado.

Explicação dos parâmetros

  1. Primeiro: IP ou nome do controlador Ubiquiti (aqui, ‘localhost’ que tanto é a máquina onde está o controlador, quanto é a máquina que fará a coleta dos dados);
  2. Segundo: Usuário devidamente cadastrado no controlador;
  3. Terceiro: Senha do usuário informado;
  4. Quarto: versão base do controlador;
  5. Quinto: Nome do site (nas versões mais novas, existe a possibilidade de gerência multi-sites).

Depois de preenchidas as informações, a linha ficaria mais ou menos assim:

c = Controller('localhost', 'Admin', '123lab123', 'v3', 'Site-padrao')

Para testar, no servidor onde estão os Scripts, execute o Script Python “aps.py”:

python /usr/src/unifi/ubiquiti/aps.py

A saída deve ser a lista de APs (algo neste formato):

UniFi LR - Corredor sala01 - SW24-Pt01;10.1.3.102;24:a4:3c:00:00:01;1
Unifi LR - Sala dos Professores - SW39-Pt15;10.1.3.74;24:a4:3c:00:00:02;1
UniFi LR - Reitoria - SW45-Pt05;10.13.3.70;24:a4:3c:00:00:03;None
(...)

Os valores devem chegar em quatro colunas, divididas por “;”:

  1. Nome do AP (conforme configurado no controlador (via interface WEB));
  2. IP do AP;
  3. MAC do AP;
  4. Estado do AP: 1 para ativo e “None” para inativo.

Caso obtenha êxito neste teste, prossiga com a mesma alteração (da linha que informa o endereço do servidor, usuário e senha), para os arquivos “clients.py” e “wlans.py”. Aproveite para testar as saídas dos dois Scripts também.

Testando os Scripts ‘unifi-monitor.sh’ e ‘unifi-discovery.sh’:

Antes de configurar tudo no Zabbix, é importante testar o funcionamento de todos os Scripts, evitando problemas básicos que muitas vezes nos levam à ideia de que o Zabbix não está configurado corretamente. Com todos os Scripts base (‘aps.py’, ‘wlans.py’ e ‘clients.py’) testados, execute o Script ‘unifi-monitor.sh’:

./unifi-monitor.sh

A saída deve ser algo como:

É preciso informar ao menos um parametro! -> aps | clients | wlans

Assim, teste cada um dos três parâmetros e veja se obtém dados corretos. Visualizando o conteúdo do Script é possível ver as variações e filtros de cada um dos parâmetros. É interessante checar  todos eles para que no momento da configuração no Zabbix, não ocorram surpresas.

Se você está acompanhando atentamente o Tutorial e viu a imagem do roteamento de mensagens, percebeu que não é preciso testar diretamente o Script ‘unifi-discovery.sh’, pois o ‘monitor’ utiliza os serviços dele para o ‘LLD’. Assim, se os ‘LLD’ do ‘monitor’ estiverem Ok, o Script ‘discovery’ estará Ok também!

Se qualquer um deles retornar erros, possivelmente não foi seguido algum dos cuidados e configurações expostas acima (incluindo configurações de usuário/URL/senha). Volte um pouco e revise-as confirmando cada passo.

Testando o acesso aos dados pelo Zabbix

Neste ponto você deve estar ávido por colocar logo pra funcionar. Bem, vamos com calma… Só assim conseguiremos garantir que “erros malucos inexplicáveis” não aparecerão na hora H.

Para testar o retorno de dados pelo Servidor Zabbix, podermos utilizar o utilitário “zabbix_get”. Ele está presente em qualquer instalação e precisar apenas ter seu caminho verificado pois, a exemplo da instalação via pacotes (RPM ou DPKG), é possível que o caminho seja diferente. A instalação utilizada como exemplo aqui, tem como raiz o diretório “/usr/local/zabbix”. Assim, o utilitário “zabbix_get” pode ser encontrado em “/usr/local/zabbix/bin”.

Para testar a consulta aos dados do controlador via linha de comandos, execute:

/usr/local/zabbix/bin/zabbix_get -s 10.13.3.49 -k up.unifi[wlans]

O retorno deve ser a lista completa de suas WLANs, como em (IP do controlador onde estão os Scripts):

[root@zabbix-server bin]# /usr/local/zabbix/bin/zabbix_get -s 10.1.3.49 -k up.unifi[wlans]
Sala de aulas 01;Ativo
Area de convivencia;Ativo
Auditorio;Ativo
Biblioteca;Ativo
Ensino Fundamental;Ativo
Professores;Ativo

Para certificar e ver mais resultados, utilize as chaves “up.unifi[aps]” e “up.unifi[clients]”.

Importando os templates

Com todos os testes executados, é chegada a tão esperada hora: A importação dos templates para ver a coisa acontecer. Faça o download deste template e importe-o para o Zabbix.

  1. Cadastre seu host controlador Unifi;
  2. Atrele ele ao template importado acima;
  3. Aguarde por volta de cinco minutos e vá até “Lastest Data” (ou Dados Recentes, de acordo com o idioma utilizado no Zabbix).

Os dados recentes devem se parecer com isto:

Lastest Data - informações dos primeiros itens

Cerca de quinze minutos depois da configuração, será possível ver a lista de gráficos gerados:

Lista de gráficos

Gráfico do panorama:

Panorama Wireless - template unifi

Gráfico de um AP:

Gráfico de um AP

Conclusão

Quais são as capacidades do Zabbix?

Quais são os limites do Zabbix?

Resposta: sua imaginação!

Para mais perguntas e respostas, sinta-se a vontade para nos visitar:

Pendências:

  • Tornar o script LLD multi-sites automático (solicitação Eid Victor);
  • Monitorar dados de consumo dos APs (UP/Download).

Abraço!

Monitoramento de Blacklists (DNS-BL) com Zabbix

Autoria: Werneck Costa / Revisão e dicas: Aécio Pires

Em geral, todo domínio na Internet (Ex.: zabbix.com) possui no mínimo um servidor MX (Mail Exchanger). Este servidor possui um registro DNS específico e responde pelas comunicações via e-mail deste domínio.

Para quem administra este tipo de servidor, existe uma preocupação constante: a entrada destes IPs em Blacklists. Este processo, normalmente, se dá quando uma ou mais contas do domínio é ‘invadida’, passando a fazer parte de uma Rede de SPAMMERS normalmente enviando centenas ou milhares de e-mails mundo afora.

Como saber se meu servidor está listado com Servidor de SPAM?

R.: Existem vários sites que pesquisam isto de forma simples, bastando informar o IP de um MX. Exemplos: Multirbl, MXToolBox, WhatIsMyIP e DNSBL.

Dica: verificar o que são DNSBL.

Qual a implicação de ter meu servidor de e-mails listado?

R.: Praticamente todos os serviços e servidores de e-mail, consultam Blacklists para saber se seus remetentes são maliciosos ou não. Se seu servidor estiver listado (dependendo da Lista), seus usuários não conseguirão se comunicar com Gmail, Hotmail, Yahoo além de vários domínios particulares (de clientes, de fornecedores e etc).

Em alguns dos sites acima, existem mais de 200 listas de SPAM a serem consultadas, ou seja, com uma consulta dá pra se ter uma noção de como está a saúde do(s) seu(s) servidor(es) de e-mail.

O processo de remoção de uma Blacklist não é padronizado e geralmente leva algumas horas ou até dias. Em resumo, se seu servidor estiver listado, o quanto antes você souber e iniciar o processo de remoção, melhor (quanto mais tempo listado, menos e-mails trocados e mais reclamação de TODOS os usuários de seu domínio).

No final do Post, veja as dicas de como verificar quem são seus servidores MX e de como testar os sites de Blacklists com IPs de Servidores listados como SPAM senders.

O que o Zabbix tem a ver com toda essa história?

Simples:

  1. Quanto mais tempo em uma Blacklist, mais reclamações e problemas;
  2. O SysAdmin tem mais coisas a fazer do que ficar consultando Blacklists manualmente de hora em hora…
  3. O que você acha de ter “alguém” consultando isto pra você e te avisando em caso de IP listado?

Ambiente:

  1. Servidor e cliente Zabbix nas versões 2.2.0 e 2.2.2 (versões mais recentes devem funcionar sem problemas).

Mão na massa: Como fazer o Zabbix monitorar as Blacklists.

Primeira tentativa

O esquema de consulta à Blacklist via DNSBL (ou RBL) é feito através de uma consulta DNS, com algumas particularidades. Mas ainda assim, é ‘apenas’ uma consulta DNS. O problema do ‘fazer’ via Zabbix era encontrar a fonte das consultas e montar uma rotina que consultasse a lista e informasse a situação do IP em todas as Blacklists.

Na pesquisa, procurei fontes que provessem alguma API de forma que eu passasse o IP e ela me retornasse SIM ou NÃO. Assim, conheci a NeutrinoAPI que integra uma grande série de consultas diferentes e fornece respostas em formato JSON, ideal pra se trabalhar da forma que pensei (é necessário criar uma conta e gerar uma Chave de acesso usada na API).

NeutrinoAPI

OBS: é possível executar os diversos testes da imagem acima direto pelo Navegador.

Pra tratar esses dados, aproveitei a Dica do grande André Déo, onde comenta sobre o Software JQ, que recebe dados em JSON e permite que se altere posições, nomes de campos e etc. No fim, minha intensão era gerar uma Lista com as Blacklists e consultar uma a uma, mas não deu certo.

Motivos:

  1. Ao consultar um IP que havia saído de certa Blacklist, a API continuava retornando como se ainda estivesse listado (problemas de cache DNS, informado ao Suporte deles);
  2. O tratamento dos dados exigia algumas “camadas” de conversão (o JQ não aceitou nomes de campos com hífen).

Melhor formato para resolver a situação

O primeiro problema (e o maior deles) era criar uma lista com as Blacklists. Na verdade, se tratava de copiar de algum lugar central e com isso preparar os demais comandos a usarem essa lista. Eu já utilizava com certa frequência o site MultiRBL para as consultas manuais, mas não havia explorado o link “Info about all RBLs“. Nele, está a chave para o sucesso! 😀 – Uma super-lista com as Blacklists mais famosas contendo, dentre outras coisas, o nome (2) e o servidor (3) que responde à consulta DNS para RBL. Excelente!

MultiRBL.valli.org - Informação sobre todas as Blacklists

Próximo passo: criação de um Script que “sugue”, transforme os dados e crie uma lista só com as informações importantes. Este processo é feito por um script que utiliza o “$ wget” e o desconhecido (por mim, até então) “$ html2text”. Para transformar isso em funções e dados concretos, criei três arquivos:

  1. O script (shell/bash) “dnsbl.sh“: acessa a página com as Blacklists, faz o Download do HTML, converte com o “html2text” e salva a lista tratada;
  2. O arquivo “ignorar-blacklists.txt” trata alguns erros nas Blacklists como por exemplo, a APEWS que está fora do jogo há tempos, mas que não sai das consultas, além de outras listas em que é preciso ter um cadastro específico para poder consultar. É possível adicionar manualmente as entradas que queira remover das consultas;
  3. O script “dnsbl-discovery.sh” que, como o próprio nome diz, cuida do LLD para que seja gerado um item para cada Blacklist e nossos IPs possam ser consultados em todas elas;
  4. O arquivo “dnsbl.conf” contém os UserParameters necessários aos novos itens relacionados às Blacklists.

OBS: Estou monitorando as Blacklists como itens do meu servidor de e-mails (MX do domínio), ou seja, as configurações à seguir precisam ser feitas nele. Para quem for seguir o tutorial, é possível configurar a gosto (minha instalação de agente segue o seguinte caminho: “/usr/local/zabbix/“).

Para fazer tudo isso funcionar, é preciso acertar algumas coisas:

  1. Instalar o “html2text” (apt-get install html2text ou yum install html2text -> Debian/Ubuntu ou CentOS/RedHat, respectivamente);
  2. Editar o arquivo “zabbix_agentd.conf”, e habilite o ‘include’ (descomentando a diretiva) que aponta para o diretório “zabbix_agentd.conf.d”. No meu caso, ficou assim: “Include=/usr/local/zabbix/etc/zabbix_agentd.conf.d/“. É dentro deste diretório, que adicionaremos os UserParameters, como em outros tutoriais. É necessário a reinicialização do processo “zabbix_agented” (/etc/init.d/zabbix-agent restart;ps aux|grep -i zabbix) para aplicar as alterações no .conf;
  3. Dentro do diretório /usr/local/zabbix/etc/zabbix_agentd.conf.d/ descompacte o arquivo “dnsbl.conf.gz”;
  4. Crie os diretórios scripts e temp (no meu caso, dentro de /usr/local/zabbix/) e dê permissões ao Usuário/grupo zabbix de leitura e execução;
  5. Dentro do diretório scripts, descompactar os arquivos “dnsbl-discovery.sh.gz” e “dnsbl.sh.gz” e dê permissão de execução para ambos. Nestes arquivos, procure a variável “ZABBIX_HOME=/usr/local/zabbix” e altere para a pasta base de sua instalação;
  6. Dentro do diretório temp, descompactar o arquivo “ignorar-blacklists.txt.gz”.

O arquivo “dnsbl.conf” possui os novos itens relacionados às Blacklists. Estes itens é que serão cadastrados no Zabbix. Itens disponíveis:

up.dnsbl.discovery
up.dnsbl.ml
up.dnsbl.co
up.dnsbl.ls
up.dnsbl.cl[*]
up.dnsbl.ct[*]
up.dnsbl.h

Vamos aos primeiros testes.

Atenção: todos os testes à seguir, devem ser executados com o usuário zabbix. Este usuário é usado nas execuções que contém UserParameters e afins, por tanto, deve ter um shell válido no sistema e acesso aos diretórios citados abaixo.

Para comprovar que os passos anteriores deram certo, no diretório scripts, execute o script “dnsbl.sh” (sem passar nenhum parâmetro). A saída deve ser como esta:

./dnsbl.sh

Script para testar listas de DNS-BL afim de verificar se certo IP está listado como Remetente de SPAM.
-> Uso:
ml|montar_lista # Efetua o Download da lista em HMLT, converte para texto puro e monta em um formato "consultável" pelo Scripts.
co|contar_lista # Informa o tamanho da lista atual. Serve para controlar o Loop e pode ser utilizado como item informativo do Zabbix.
cl|consultar_dnsbl # Consulta um IP - informado como parâmetro 2 - em uma BlackList -informada como parâmetro 3-.
ct|consultar_dnsbl_todas # Consulta um IP -informada como parâmetro 2- todas as BlackList.
ls|listar_lista # Lista a lista com todas as Blacklists. Utilizado no Discovery e pode ser utilizado como item informativo do Zabbix.
ds|discover # Executa o discovery, devolvendo os Nomes e URLs das Blacklists -utilizadas no Zabbix- para criação de itens dinâmicos.
h|help # Mostra este Help
OBS: Todas as opções podem ser utilizadas em siglas ou completas.

Na execução sem parâmetros, o script retorna o “help”. Nele, as opções são auto-explicativas.

Para começar o trabalho, será preciso executar o script com a opção ml (ou montar_lista). Ela fará o Download e conversão dos dados no formato “consumível” pelo Zabbix.

./dnsbl.sh ml

O resultado deve ser algo como:

Captura de tela de 2014-11-12 22:45:47

Para saber se realmente deu certo, acesse o diretório temp (no meu caso “/usr/local/zabbix/temp”) e verifique a presença do arquivo “blacklists.result”. Leia-o. Seu formato deve ser algo como:

Captura de tela de 2014-11-12 22:34:41

OBS: Note que o arquivo tem três colunas (separadas por Pipes -> |). A primeira ainda é proveniente do Filtro inicial (para Info, WhiteList e BlackList). A segunda é o nome e a terceira o endereço pelo qual a Blacklist responde às consultas.

Seguindo a linha de testes, é interessante testar todos os possíveis parâmetros do script (com exceção do cl e ct por enquanto):

./dnsbl.sh co
retorno -> 250 (pode ser mais ou menos)
./dnsbl.sh ls
retorno -> todos as entradas da lista
./dnsbl.sh ds
retorno -> todos os elementos da lista no formato JSON (para LLD Zabbix)

Os parâmetros cl e ct servem para efetuar a consulta propriamente dita. O cl consulta uma lista, usando o IP passado como parâmetro. Exemplo:

./dnsbl.sh cl 111.224.250.131 bl.technovision.dk
Possíveis resultados:
0 -> IP não está listado na Blacklist especificada;
1 -> IP está listado na Blacklist
255 -> Erro ao processar a consulta (ou lista não existe ou erro do comando 'dig').
./dnsbl.sh ct 111.224.250.131
Retorno: uma sequência de números da consulta anterior. Como o Script consulta todas as listas em "/usr/local/zabbix/temp/blacklists.result", mostrará uma sequência de 0's, 1's ou 255's (misturados entre si). 

Exemplo:

Captura de tela de 2014-11-12 23:00:39

O teste final é feito com o binário do Agente Zabbix. Pra isso, localize o diretório sbin de sua instalação Zabbix (no meu caso “/usr/local/zabbix/sbin”). Lá, execute o seguinte comando:

./zabbix_agentd -t up.dnsbl.co
Resultado deve ser algo como:
up.dnsbl.co                                   [t|250]

Experimente executar com os outros UserParameters encontrados em “/usr/local/zabbix/etc/zabbix_agentd.conf.d/dnsbl.conf” para verificar se o agente responderia e como responderia aos novos itens.

Com isso, encerramos os testes e podemos partir para o Zabbix! (até que enfim! :D).

OBS: se algo não funcionou volte, releia e refaça os passos principalmente com relação aos locais, edição de variáveis e permissões de arquivos.

Configuração do Zabbix

Importante: Antes de prosseguir com a criação dos itens, verifique num dos sites para consulta de Blacklists, se o IP do seu servidor está marcado como SPAMMER (o MultiRBL é o mais interessante).

Criação do mapeamento de valores (Value mapping): vá até Administração (Administration) -> Geral (General) -> Mapeamento de Valores (Value mapping):

Value-mapping01

Value-mapping02

crie um novo “Value mapping” com os seguintes dados:

Value-mapping03

Criação de uma regra de Discovery (LLD): a regra irá gerar ao menos um item que é a consulta em todas as Blacklists para um determinado IP. Tentei criar essa regra e o item em um Template (algo como Template_servidor_emails), mas não dá certo devido a alteração do protótipo de item não ser possível a nível de Host (que será atrelado ao Template). Então, é criar direto no Host mesmo:

Zabbix - UNIRN: Configuration of discovery rules

Este LLD retorna as seguinte macros:

  1. {#LISTA_NOME} – nome da lista indicado por campo 2 do arquivo “blacklists.result”. Para fins de cadastro de item com nome amigável no Zabbix;
  2. {#LISTA_URL} – URL da lista indicado por campo 3 do arquivo “blacklists.result”. Para consulta DNS e verificação da Blacklist

Alterei o “Update interval” para cinco minutos (300 segundos), para que vejamos mais rapidamente os dados sendo coletados. Porém, como o processo de buscar a lista completa é oneroso e não tem necessidade de se repetir muitas vezes, um valor razoável para este parâmetro seria 3600 (uma hora).

Criação do protótipo de item: este item não é nada mais que um modelo para ser preenchido pelos dados provenientes do Discovery LLD.

Item-prototype01

A chave “up.dnsbl.cl[IP-DO-MX,{#LISTA_URL}]” deve conter o IP do MX como primeiro parâmetro. Em “Show value” deverá conter o “Value mapping” configurado anteriormente. O “New application” servirá para vermos em “Lastest data” (dados recentes), como está a atualização dos novos itens. Este protótipo só cadastrará um IP de Servidor MX. Caso possua mais de um, será necessário criar tantos itens de protótipo quanto o número de IPs a consultar.

Verificação dos resultados

Para ter certeza de que tudo correu bem, depois dos cadastros acima, aguarde de 5 a 10 minutos e verifique em “Dados Recentes” (Lastest data) se os novos itens estão sendo processados:

Lastest-data01

Veja que, para cada lista (identificada pelo Nome), existe um valor de retorno em “Lastest value” de acordo com o “Value mapping” configurado anteriormente.

Outro local para verificar é nos itens do próprio Host:

Host-itens01

Considerações finais

Este tutorial não tem a intenção de esgotar o assunto, ou seja, não mostra todas as formas de fazer algo e sim a que me pareceu mais simples e sistemática. Todos os passos aqui descritos, foram feitos e testados no momento em que eram executados. Se algo não der certo, verifique os passos e repita-os novamente. Apesar disso, erros podem ocorrer por uma digitação errada no momento da criação do material. Isso é super-comum.

Ademais, aqui só está sendo mostrado como fazer o principal: criar a lista, montar o LLD e o item de verificação (único ou múltiplo). A seguir, indicações de itens importantes.

A fazer:

  1. É importante aprender a lidar com o portal MuitlRBL. Nele, algumas listas são do Tipo Blacklist outras Whitelist dentre outros Tipos. Estes scripts apresentados aqui, só levam em consideração o Tipo Blacklist, mas é preciso ficar de olho em listas informacionais e tira-las das verificações, caso necessário (evitando falsos-positivos);
  2. Algumas listas podem informar falsos-positivos quanto a listar o IP pesquisado. Caso queira remover certa lista das próximas verificações, adicionar a URL dela no arquivo “/usr/local/zabbix/temp/ignorar-blacklists.txt”;
  3. Criar um item (direto no Host e não como protótipo) para atualização da lista diariamente com o item “up.dnsbl.ml”(com valor de retorno do tipo Texto). Cuidado no tempo de atualização, não é necessário atualizar a lista mais de uma vez por dia;
  4. Criar um item (direto no Host e não como protótipo) para contar a quantidade de entradas na lista: “up.dnsbl.co”;
  5. Criar “Triggers prototypes” para gera alertas caso o IP caia em uma das listas;
  6. Criar novos UserParameters (por sua conta) que informem a quantidade de Blacklists em que o IP está listado (item com retorno numérico para geração de Gráficos);
  7. Criar novos LLDs (por sua conta) que, ao invés de informar um IP do MX, informemos o domínio e automaticamente o Zabbix pegue todos os MX deste.

Outras dicas:

Como saber meus MX?

Simples: caso não tenha familiaridade com os comandos “nslookup” ou “dig”, sites como o Kloth permitem descobrir quaiquer registros DNS.

Como testar com IPs de SPAMMERS?

Para testar o script “dnsbl.sh” com um IP que é realmente um SPAMMER, acesso o site do Projeto Honeypot, na lista de “Spam Servers“copie um dos IPs e execute o script com os parâmetros necessários:

./dnsbl.sh ct IP-SPAMMER

Conclusão:

Agradeço pelo interesse em meu trabalho e peço desculpas caso não tenha encontrado aqui o que deseja. Apesar de tudo, o que me levou a publicar este material foi a necessidade que tive de resolver problemas como os citados nele. Espero que sirva igualmente aos colegas de profissão e que os que desejarem melhorar isto tudo, estejam à vontade.

Mais informações: Homepage da Comunidade Brasileira e lista de discussão oficial da mesma.

Abraço!

Zabbix: Quantas CPUs eu tenho? (sockets, cores, threads…)

Há pouco tempo, me deparei com uma situação estranha relacionada a consumo de recursos. Um de nossos servidores de aplicação reclamava de desempenho (quanto à CPU), quando na verdade sobravam núcleos ociosos (segundo o gráfico gerado pelo Zabbix):

Antes

O servidor em questão roda um Debian 7 e parece possuir 32 núcleos (inclusive confirmado pelo $cat /proc/cpuinfo). Aqui é que está a questão: em alguns momentos do dia as reclamações de lentidão vinham e a resposta era dada pelo gráfico, ou seja, o servidor está “rodando folgado”.

Verificando a configuração da máquina, veio a surpresa: na verdade a soma de núcleos é 16 (2 sockets x 8 núcleos). Mas e de onde veio esse 32?

Explicação: cada núcleo suporta duas Threads. (2 x 8) x 2 = 32

Mas, e como saber qual a real quantidade de núcleos físicos eu tenho? Bem, vamos deixar o Zabbix responder isso.

Script e UserParameter

Para que a informação venha correta, foi preciso desenvolver um script que checa e trabalha algumas informações provenientes do /proc/cpuinfo.

Script: http://1drv.ms/1Ypsxfz

Dados:

./cpu.sh info [cores|threads]
cores: multi / single
threads: on / off
./cpu.sh count [sockets|cores|threads]
sockets, cores, threads = x (número correspondente ao item)

Para complementar, criei um arquivo com o  UserParameter: http://1drv.ms/1YpsArU

UserParameter=up.system.cpu[*],/usr/local/zabbix/scripts/cpu.sh "$1" "$2"

Como visto acima é um parâmetro simples (o “up” é de UserParameter, para diferenciar dos itens originais do Zabbix). O script só precisa estar no local certo (ou no local de escolha) e os itens criados, complementando os que já são utilizados para CPU.

Com isso tudo resolvido, o gráfico gerado será algo assim:

Depois

O item padrão “system.cpu.num” está no gráfico como “CPU – Quantidade de núcleos Virtuais (sockets x threads)”. O Item “CPU – Quantidade total de Núcleos físicos (sockets x cores)” vem do novo UserParameter “up.system.cpu[count,cores]”.

Abraço!

Monitoramento de syslog-ng Server (Linux) com Zabbix

Da mesma forma que visto no Post sobre Monitoramento de Pools DHCP em servidores Linux, é comum que certas vezes esbarremos em necessidades que a ferramenta não oferece monitoramento de forma Nativa. Mas, como estamos falando do Zabbix, isto é só uma questão de vontade e pequenas adaptações. 😀

Primeiro: O que é Syslog?

O crescimento das redes de computadores (como se diz em todas as introduções de Monografias de T.I) se dá devido à adição de mais e mais componentes de Hardware. Estes componentes estão vindo cada vez mais inteligentes, inclusive gerando informações sobre seu estado (impressoras=tonner acabando, quantidade de páginas impressas, interrupções na impressão/papel preso. Switch=acesso às configurações, comandos executados em seu terminal, alteração no estado das portas e etc).

Estas informações geralmente ficam no equipamento em um armazenamento pequeno e temporário (geralmente entre 10 e 50 MegaBytes). Devido a essa baixa capacidade de armazenamento, os registros gerados são descartados em pouco tempo, fazendo com que dados históricos sejam perdidos, junto com a capacidade de acompanhar ou entender certos problemas.

Os sistemas operacionais (proprietários ou livres) também armazenam este tipo de informação em seus sistemas de arquivos. O Linux (em suas várias Distros), geralmente os coloca em /var/log.

Estes equipamentos e sistemas vão se multiplicando (junto com os problemas e famosos ‘causos do além’). Então, como recolher estas informações de maneira centralizada e persistente? Resposta: Servidor Syslog remoto.

Existem alguns servidores Syslog com esta finalidade. Este tutorial se foca no Syslog-NG.

Syslog-NG

O que é?

Servidor Syslog remoto com suporte ao padrão descrito na RFC 5424 que carrega o padrão Syslog de trabalhar os registros, sendo interoperável entre dispositivos e diferentes Sistemas. No servidor que o Hospeda, utiliza as Portas 514 (tanto TCP quanto UDP), gravando os arquivos no diretório configurado no arquivo /etc/syslog-ng/syslog-ng.conf (diretivas destination).

Considerações

  • Este tutorial não pretende cobrir a instalação ou manutenção do Syslog-NG, mas sim oferecer aos Administradores, uma ideia de como monitora-los com o auxílio do Zabbix;
  • Não são dadas garantias de funcionamento ou exata adaptação ao(s) cenário(s) do Leitor. São passos executados em uma instalação ‘do mundo real’, que funcionaram nas configurações descritas ao longo do Tutorial;
  • Sempre faça Backups dos arquivos de configuração, mesmo que em pequenas.

Cenário

  • Servidor Zabbix na versão 2.2.0;
  • Servidor a ser monitorado: Ubuntu 12.04.3 LTS com o Agente Zabbix versão 2.0.9 (a ser atualizado);
    • Os arquivos de configuração do zabbix_agentd estão em /etc/zabbix;
  • Aplicação alvo do monitoramento: Syslog-NG Versão 3.3.4 (apt-get install syslog-ng);
    • O servidor Syslog-NG recebe registros de Switchs, routers e diversos Servidores Linux;
    • Foi criada uma partição com um arranjo de discos utilizando LVM, totalizando 400GB montada em /data
    • Para cada host, o servidor Syslog cria automaticamente um conjunto de diretórios no padrão /data/log/$host/$ano/$mes/$dia/$arquivos_de_log
  • O usuário que roda o zabbix_agent tem que ter um shell válido (/bin/bash neste caso).

O que é importante monitorar em um Servidor deste tipo?

Bem, na verdade seus requisitos podem ser diferentes dos meus. Estes foram os mais importantes pra mim:

  1. portas UDP/TCP 514 e informações de um Template Linux padrão: memória, rede, discos, processos e etc (que não serão abordadas aqui);
  2. partição ou ponto de montagem do armazenamento de Logs;
  3. quantidade de hosts que estão utilizando o servidor para Logs;
  4. lista de hosts que estão utilizando o servidor para Logs;
  5. consumo de disco por host.

Passo a passo para o monitoramento

O monitoramento de dados “não padrão” geralmente é feito via UserParameter. Aqui, para o Syslog, utilizaremos essa técnica novamente.

Primeiro: configurar o sudoers, adicionando as seguinte linhas no fim do arquivo:

zabbix ALL=NOPASSWD:/bin/ls
zabbix ALL=NOPASSWD:/usr/bin/du

Elas “liberam” o usuário zabbix a executar os comandos ls e du como super-usuário, sem precisar informa a senha.

Segundo: editar o arquivo de configuração do Zabbix Agentd (zabbix_agentd.conf), adicionando (ou alterando/descomentando) a seguinte linha:

Include=/etc/zabbix/zabbix_agentd.d/

Isto fará com que o agente Zabbix considere o diretório zabbix_agentd.d como possível fonte de configuração adicional, lendo-o a cada inicialização.

Terceiro: criar um arquivo userparameter_SysLog.conf no diretório /etc/zabbix/zabbix_agentd.d com o seguinte conteúdo:

UserParameter=logged.hosts.list,sudo ls /data/log|sed 's/\t/\n/g'
UserParameter=logged.hosts.count,sudo ls /data/log|wc -w
UserParameter=logged.hosts.space.total,sudo du -s /data/log|sed 's/\t/;/g'|cut -d ";" -f1
UserParameter=logged.hosts.space.host[*],sudo du -s /data/log/$1|sed 's/\t/;/g'|cut -d ";" -f1

Quarto: reiniciar o processo Zabbix_agentd.

OBS: caso o processo não suba, verifique os arquivos de configuração alterados e veja se alguma linha está incorreta inclusive com o arquivo dos “UserParameter”.

Explicando os parâmetros criados

  • logged.hosts.list: traz a lista dos hosts (separados por “new lines”) que estão utilizando este servidor de syslog;
  • logged.hosts.count: quantidade (em número inteiro) de hosts utilizando estes servidor;
  • logged.hosts.space.total: total de dados em uso, do diretório principal na partição utilizada para guardar os logs;
  • logged.hosts.space.host[*]: espaço total ocupado por cada host que utiliza este servidor Syslog;
    • o parâmetro esperado neste item ( [*] ), é o nome/ip do host que se deseja saber o quando ocupa de espaço no Servidor Syslog.

Para o último item, cabe uma ressalva: quando um host ou ativo de rede é apontado para este servidor Syslog, é criada uma pequena árvore (como comentado à cima, em Cenário). Esta árvore tem como Base o Nome ou IP do host:

  • Nome: caso o Servidor Syslog consiga recuperar no servidor DNS, o registro PTR (ponteiro) para o IP que acaba de chegar;
  • IP: Caso o item anterior não funcione.

Criando os itens

Lista de hosts logados:

Item lista de hosts

Item resultante (Lastest data):

Lastest Data - lista hosts

Contador de hosts Logados:

Item qtd de hosts_

Resultado:

Resultado qtd de hosts

Espaço total utilizado pelos hosts:

Item espaço total

Resultado:

Item espaço total - Resultado

Espaço utilizado por um host específico:

Item Espaço do host

Resultado:

Item Espaço do host - Resultado

Implementando a auto-busca para novos hosts adicionados

O servidor Syslog-NG irá receber vários novos hosts ao longo de seu funcionamento na rede. Configura um novo item (logged.hosts.space.host[]) para cada host certamente não é nada prático.

Para resolver isto, iremos utilizar o LLD (Low Level Discovery).

Em resumo, ele fará uma busca, de tempos em tempos, para verificar se existem novos hosts utilizando o servidor Syslog e caso existam, criará automaticamente um item logged.hosts.space.host para cada um deles.

Aviso: O LLD apesar de super útil, pode não ser compreendido no primeiro momento. Para compreender dê uma olhada aquiaqui.

Utilizando LLD para verificar espaço em novos hosts

A continuação deste tutorial vem em breve.

Abraço a todos e feliz ano novo!

Monitoramento de pools ISC-DHCP com Zabbix

O Zabbix não possui nativamente uma forma de monitoramento para Servidores DHCP, então qual a solução? Resposta: fazer com que o Zabbix leia as informações de algum lugar no sistema operacional.

Obs: este tutorial cobre o monitoramento utilizando o Linux como servidor DHCP. Para monitoramento com Windows, veja esta postagem do Zilmar.

Cenário:

  • Servidor Zabbix Versão 2.0.7;
  • Servidor a ser monitorado: Ubuntu 10.04 com o Agente Zabbix versão 2.0.7;
  • Aplicação alvo do monitoramento: ISC-DHCP (apt-get install dhcp3-server);
  • O usuário que roda o zabbix_agent precisa ter um shell válido (/bin/bash).

No meu caso, além da funcionalidade padrão (servir configurações de rede de forma automática), meu DHCP server possui a função de servir múltiplas faixas diferentes que chegam nele através de DHCP-Relay feitos em alguns Switchs.

Mas, o que é importante monitorar em um Servidor deste tipo?

  1. Capacidade de IPs por pool DHCP;
  2. Quantidade de IPs sendo utilizados em cada pool;
  3. Quantidade de IPs “Tocados” em cada pool.

Estes IPs  “Tocados” representa a quantidade máxima de Máquinas diferentes que já foram endereçadas em cada pool. Servem, em linhas gerais, para ver o quão suficiente é este pool (ou seja, agora você tem como planejar!).

Agora, como fazer pra que o Zabbix leia estas informações no servidor DHCP?

Pesquisando uma forma de extrair os dados do DHCP Server, me deparei com esta alternativa.  O problema desta abordagem é que, para cada novo pool configurado, seria necessário, manualmente, fazer uma nova configuração individual no SNMP… Ou seja, nada prático. Continuando a pesquisa, achei a seguinte alternativa: http://dhcpd-pools.sourceforge.net/ A promessa era de ser mais rápido que os “concorrentes” (inclusive do que minha primeira alternativa), pois o arquivo de Leases é bem grande e qualquer “cat + grep + cut” levaria um bom tempo e consumiria recursos da máquina. Bem, só dá pra saber, testando:

Passos:

Instalação das dependências:

apt-get install -y -b  xz-utils gnulib uthash-dev

Criação de um diretório para os fontes:

mkdir /usr/src/dhcpd-pools

Download e descompactação dos fonte do dhcpd-pools:

cd /usr/src/dhcpd-pools

wget http://sourceforge.net/projects/dhcpd-pools/files/dhcpd-pools-2.23.tar.xz/download -O dhcpd-pools-2.23.tar.xz

tar xJf dhcpd-pools-2.23.tar.xz

Compilação e instalação:

./configure && make && make install

Depois de instalado, um teste básico pode ser feito com o seguinte comando:

dhcpd-pools -c local/do/dhcpd.conf -l local/do/dhcpd.leases

No caso do setup utilizado nesta instalação, o comando completo ficaria (procure os arquivos, conforme sua instalação):

dhcpd-pools -c /etc/dhcp3/dhcpd.conf -l /var/lib/dhcp3/dhcpd.leases

A saída do comando, provavelmente será parecida com esta:

Ranges:
shared net name first ip last ip max cur percent touch t+c t+c perc
All networks 172.16.101.1 - 172.16.101.254 254 6 2.362 179 185 72.835

Shared networks:
name max cur percent touch t+c t+c perc

Sum of all ranges:
name max cur percent touch t+c t+c perc
All networks 254 6 2.362 179 185 72.835

Para cada instalação e configuração, a saída poderá ser diferente. Mas é possível ter uma noção através deste arquivo. Lendo o retorno do comando, temos o seguinte:

shared net name first ip last ip max cur percent touch t+c t+c perc
All networks 172.16.101.1 - 172.16.101.254 254 6 2.362 179 185 72.835

Dá pra tirar daí, que minha rede possui uma capacidade máxima de 254 endereços (da forma que foi configurada), está com 6 endereços em uso atualmente, o que representa 2.362% e que dela já foram utilizados 179 endereços diferentes (além dos outros campos que não comentarei). Porém se eu tiver várias redes preciso que, ao invés de ser mostrado “All networks”, seja mostrado o nome da rede. Para isso, será necessário executar alterações nos arquivos de configuração do Serviço DHCP. As alterações são pra “envolver” cada pool com um nome específico, através do uso da diretiva “shared-network”. Em minha instalação, editei o arquivo /etc/dhcp3/dhcpd.conf que estava assim:

subnet 172.16.100.0 netmask 255.255.253.0 {
 default-lease-time 7200;
 max-lease-time 10800;
 range 172.16.101.1 172.16.101.254;
 option routers 172.16.100.15;
 option domain-name-servers 172.16.100.15;
 option broadcast-address 172.16.101.255;
 option domain-name "dominio.local";
}

Deixando-o asim:

shared-network Minha-rede {
subnet 172.16.100.0 netmask 255.255.253.0 {
 default-lease-time 7200;
 max-lease-time 10800;
 range 172.16.101.1 172.16.101.254;
 option routers 172.16.100.15;
 option domain-name-servers 172.16.100.15;
 option broadcast-address 172.16.101.255;
 option domain-name "dominio.local";
}
}

Depois de salvar e reiniciar o serviço DHCPD, execute novamente o seguinte comando:

dhcpd-pools -c /etc/dhcp3/dhcpd.conf -l /var/lib/dhcp3/dhcpd.leases

Veja que em “Shared networks”, agora o retorno é diferente:

Ranges:
shared net name first ip last ip max cur percent touch t+c t+c perc
All networks 172.16.101.1 - 172.16.101.254 254 6 2.362 179 185 72.835

Shared networks:
name max cur percent touch t+c t+c perc
Minha-rede 254 11 4.331 178 189 74.409

Sum of all ranges:
name max cur percent touch t+c t+c perc
All networks 254 6 2.362 179 185 72.835

O dhcpd-pools oferece um help, no estilo man page do Linux, e nele é importante observar o seguinte (man dhcpd-pools):

-L, --limit=NR
The NR will limit what will be printed. Syntax is similar to chmod(1) permission string. The NR limit string uses two digits which vary between
0 to 7. The first digit determines which headers to display, and the second digit determines which numeric analysis tables to include in the output.
The following values are "OR'd" together to create the desired output. The default is 77.

01 Print ranges
02 Print shared networks
04 Print total summary
10 Print range header
20 Print shared network header
40 Print total summary header

Aqui é possível ver que a utilização do parâmetro “-L”, limita a exibição conforme a tabela à cima, de acordo com a combinação escolhida. Então, se executarmos o comando incluindo o “-L 22”, ele retornará somente os dados das “Shared networks”:

dhcpd-pools -c /etc/dhcp3/dhcpd.conf -l /var/lib/dhcp3/dhcpd.leases -L22

Resultado:

Shared networks:
name max cur percent touch t+c t+c perc
Minha-rede 254 11 4.331 178 189 74.409

Você também poderia fazer algum malabarismo para separar o texto, pegar certa linha e etc mas, se o comando já fornece isto, para que reinventar a roda?

Fazendo o zabbix capturar os dados

Sabemos que para obter dados que o Zabbix não consegue nativamente, uma das possibilidades é a utilização de “UserParameters”. Estes, em resumo, são itens criados livremente pelo Administrador para que, quando consultados via Zabbix_agent, retornem algo útil, como o resultado de um comando, por exemplo. Para que isto funcione, é necessário editar o arquivo de configuração do agente. Nele, procure a diretiva “Include” que, provavelmente estará assim:

# Include=/usr/local/etc/zabbix_agentd.userparams.conf

Esta diretiva diz que, além do arquivo .conf padrão, o zabbix (quando iniciar) irá procurar outros arquivos. Nesta caso é possível indicar um arquivo direto (como à cima), ou uma pasta que conterá vários outros arquivos. Para nosso tutorial, ficou da seguinte forma (Claro que este diretório precisa existir e estar acessível para leitura.):

Include=/usr/local/etc/zabbix_agentd.conf.d/

Neste diretório será necessário criar o arquivo “UserParameters_dhcpd.conf”, contendo os itens customizados e seus respectivos comandos. Copie e cole o conteúdo à baixo no arquivo “UserParameters_dhcpd.conf” (antes de copiar, verifique a configuração dos parâmetros “-c” e “-l“):

UserParameter=dhcp.pool.all,dhcpd-pools -c /etc/dhcp3/dhcpd.conf -l /var/lib/dhcp3/dhcpd.leases -L22

UserParameter=dhcp.pool.max[*],dhcpd-pools -c /etc/dhcp3/dhcpd.conf -l /var/lib/dhcp3/dhcpd.leases -L22|grep -i $1|sed 's/ \+/;/g'|cut -d';' -f2

UserParameter=dhcp.pool.use[*],dhcpd-pools -c /etc/dhcp3/dhcpd.conf -l /var/lib/dhcp3/dhcpd.leases -L22|grep -i $1|sed 's/ \+/;/g'|cut -d';' -f3

UserParameter=dhcp.pool.percent[*],dhcpd-pools -c /etc/dhcp3/dhcpd.conf -l /var/lib/dhcp3/dhcpd.leases -L22|grep -i $1|sed 's/ \+/;/g'|cut -d';' -f4

UserParameter=dhcp.pool.touch[*],dhcpd-pools -c /etc/dhcp3/dhcpd.conf -l /var/lib/dhcp3/dhcpd.leases -L22|grep -i $1|sed 's/ \+/;/g'|cut -d';' -f5

Depois de criar o arquivo (sem os espaço entre as linhas), salve e reinicie o zabbix_agent. Cada linha de UserParameter possui dois elementos: o item e o comando. Exemplo:

Item

dhcp.pool.all

Comando

dhcpd-pools -c /etc/dhcp3/dhcpd.conf -l /var/lib/dhcp3/dhcpd.leases -L22

O item é o que será configurado na interface do Servidor Zabbix. Quando o agente receber a solicitação do item (por exemplo, dhcp.pool.all), ele retornará os dados resultantes do comando. Depois disso, no servidor zabbix execute o seguinte comando:

zabbix_get -s ip.do.servidor.dhcp -k dhcp.pool.all

Se tudo estiver correto, um retorno como este será exibido (caso exista mais de um pool configurado):

Shared networks:
name max cur percent touch t+c t+c perc
Minha-rede01 356 260 73.034 87 347 97.472
Minha-rede02 422 0 0.000 0 0 0.000
Minha-rede03 782 539 68.926 232 771 98.593
...
Minha-redeN 250 43 17.200 206 249 99.600

Lembre-se: Para cada pool (Minha-rede01, Minha-rede02, Minha-rede03), serão cadastrados todos os parâmetros (max, use, percent e touch).

Outros testes pode ser feitos, utilizando os outros itens no UserParameter:

dhcp.pool.max[Minha-rede01]
Retorno (exemplo): 200

dhcp.pool.use[Minha-rede01]
Retorno (exemplo): 20
dhcp.pool.percent[Minha-rede01]
Retorno (exemplo): 12.4
dhcp.pool.touch[Minha-rede01]
Retorno (exemplo): 23

Pronto, parâmetros configurados! Agora é hora de ir ao zabbix server (via interface web) e cadastrar os itens para o Servidor DHCP, como no exemplo à baixo:

Conf_itens_DHCP01

No exemplo dos pools dado anteriormente, é possível ver o tipo de dado retornado por cada item. Cadastre um por um, e vá vendo em “Lastest data” se o resultado aparece. Depois, configure os gráficos a seu gosto e pronto, você tem os dados que queria! 😀

Até este ponto, é possível monitorar os pools DHCP tranquilamente. Agora, se você já trabalhou no zabbix com LLD (Low Level Discovery) e sabe que seria mais interessante pegar os pools automaticamente, siga pro próximo parágrafo.

Utilizando LLD para buscar os pools DHCP:

Este LLD precisa de um Script rodando localmente para trazer os nomes dos pools e popular os 4 itens. Para isso, escolhi o diretório /usr/local/etc/zabbix/scripts/ para adicionar o script que retornará os dados no formato JSON. Lá, criei o script dhcppolls.sh com o seguinte conteúdo:

#!/bin/bash
pools_all=`dhcpd-pools -c /etc/dhcp3/dhcpd.conf -l /var/lib/dhcp3/dhcpd.leases -L02|egrep -io "^[a-z]*(\-|\_)?[a-z]*"`
pools_qtd=`echo $pools_all|wc -w`
retorno=`echo -e "{\n\t\t"\"data\"":["`
for p in $pools_all
do
 if [ "$pools_qtd" -le "1" ]
 then
 retorno=$retorno`echo -e "\n\t\t{\"{#DHCPPOOL}\":\"$p\"}"`
 else
 retorno=$retorno`echo -e "\n\t\t{\"{#DHCPPOOL}\":\"$p\"},"`
 fi
 pools_qtd=$(($pools_qtd - 1))
done
retorno=$retorno`echo -e "]}"`
echo -e $retorno

Salve e saia do arquivo. No arquivo UserParameters_dhcpd.conf adicione o seguinte “UserParameter”:

UserParameter=dhcp.pool.discovery,/usr/local/etc/zabbix/scripts/dhcppolls.sh

Reinicie o agente zabbix no servidor DHCP.

Para teste, execute o seguinte no servidor Zabbix:

zabbix_get -s ip.do.servidor.dhcp -k dhcp.pool.discovery

Os dados serão parecidos com estes:

{ "data":[ {"{#DHCPPOOL}":"Minha-rede01"}, {"{#DHCPPOOL}":"Minha-rede02"}, {"{#DHCPPOOL}":"Minha-rede03"}]}

Se tudo correr como descrito, estaremos a um passo de concluir a configuração. Se não, volte ao começo do tutorial e revise as configurações feitas.

Agora, na interface web, vá ao Host Servidor DHCP e cadastre um novo item do Tipo “Discovery rules”, da seguinte forma:

LLD_DHCP

Veja que o parâmetro em “Macro” é o mesmo retornado na execução de “dhcp.pool.discovery”. Agora, será preciso criar os itens a serem populados com o dado trazido pelo LLD. Para isso, depois de criar a “Discovery Rule”, clique em “Item prototype” e crie o item como segue:

LLD_DHCP_item

Crie os 4 itens, conforme vimos anteriormente e, se desejar Triggers, gráficos e o que mais for necessário.

Pronto, fim do tutorial! 😀

Se precisar de algum suporte, é possível me encontrar (e vários outros membros) na lista Brasileira de discussão sobre Zabbix, através deste link.

Abraço!

Alcatel OT-255D

Adquiri recentemente um telefone Alcatel OT-255D.

Como ainda estou avaliando, minhas primeiras impressões são as seguintes:
### Funções em destaque:
1 – Acesso web simples e lento (WAP), somente para as mínimas necessidades como atualização do tempo;
2 – Chamada falsa (bom aplicativo);
3 – Tempo (previsão do tempo) para várias cidades do mundo (com a vizualização de hj + 2 dias pra frente);
4 – Dois SIM Cards online;
5 – Antena com Ótima recepçao de sinal (no subsolo do meu prédio, conversação perfeita – Outros modelos sofriam e não conseguiam);
6 – Preço em conta (208,00 depois de colocar a garantia extendida) dividido em até 10x;
7 – Já dei várias quedas com o aparelho em conversação, e em nenhuma delas tive problemas, nem na ligação (tipo cair ou travar) e nem depois dela (algum reflexo dessa queda). Não digo que seja indestrutível, no mínimo resistente! 😀 ;

### Contras:
1 – Segundo a loja que comprei (Laser Eletro – Natal/Rn) o aparelho só possui 3 meses de garantia por ser importado. Eu adquiri + um ano pela loja (para troca e não consertos);
2 – Não possui Bluetooth;
3 – Sem expansão de memória (cartão de memória). Memória interna de 1.3MB somente;
4 – Não possui nenhum tipo de programa para trocar dados entre ele o computador (como o Mobile Phone Tools, iTunes ou coisa parecida);
5 – Não suportaria uma música em MP3;

Não é um celular de grife, ou mesmo para mídia (fotos, vídeos, músicas ou internet rápida – Não é um SmartPhone), más se comparado aos valores dos “ChingLings” por ai a fora, sairá em vantagem. Alcatel é uma fabricante com muita experiência em telefonia, logo o produto tem boa qualidade.

Mais conteúdo:

Manual original:Download
Página Oficial do produto;

Boa sorte a quem adquiri-lo.

Feliz ano novo a todos!