Protocolo de Gerenciamento RMON

O padrão RMON para monitoramento remoto oferece uma arquitetura de gerenciamento distribuída para análise de tráfego, resolução de problemas, demonstração de tendências e gerenciamento proativo de redes de modo geral.

Criado pelos mesmos grupos que desenvolveram o TCP/IP e o SNMP, o RMON é um padrão IETF (Internet Engineering Task Force) de gerenciamento de redes cuja sigla significa Remote Network Monitoring MIB. Primeiramente, desenvolveu-se o padrão SNMP, somente depois pensou-se no RMON.

O Simple Network Management Protocol, ou SNMP, é um protocolo de gerenciamento realmente simples: a única informação que se tem através de um alerta SNMP é que existe um problema em um ponto da rede. Os alertas do SNMP padrão notificam um problema somente quando ele já atingiu uma condição extrema suficiente a ponto de comprometer a comunicação na rede como um todo.

Ao contrário do que se pode imaginar, o SNMP não é capaz de definir o problema, nem sua gravidade, não fornece, tampouco, recursos para uma investigação das causas desse problema. O diagnóstico do problema é uma tarefa do administrador da rede. Assim, o SNMP é simplesmente um alerta para uma condição extrema da rede.

O comitê do IETF decidiu que, para promover uma maior e melhor expansão das tecnologias de rede, era necessário um padrão de gerenciamento de redes mais sofisticado. As principais características do novo padrão, o RMON, seriam:

• Interoperabilidade independentemente de fabricante;
• Capacidade de fornecer informações precisas a respeito das causas de falha no funcionamento normal da rede, assim como da severidade dessa falha;
• Oferecer ferramentas adequadas para diagnóstico da rede.

Além destas características, o padrão deveria oferecer um mecanismo proativo para alertar o administrador dos eventuais problemas da rede, além de métodos automáticos capazes de coletar dados a respeito desses problemas.

Assim, o RMON tornou-se um padrão por volta de 1990. O RMON II foi publicado para entender as capacidades do RMON.

Algumas RFCs tratam do protocolo RMON:

• RMON1: RFC 1757 - Remote Network Monitoring Management Information Base (Draft)
• RMON1: RFC 2819 - Remote Network Monitoring Management Information Base
• RFC 1513 - Token Ring Extensions to the Remote Network Monitoring MIB
• RMON2: RFC 2021 - Remote Network Monitoring Management Information Base Version 2 using SMIv2 (Obsolete) *
• RFC 3273 - Remote Network Monitoring Management Information Base for High Capacity Networks **
• RMON2: RFC 4502 - Remote Network Monitoring Management Information Base Version 2 using SMIv2
  * Substituiu
  ** Atualizou
• SMON: RFC 2613 - Remote Network Monitoring MIB Extensions for Switched Networks (Proposto)
• Overview: RFC 3577 - Introduction to the RMON Family of MIB Modules

Características do Protocolo
O protocolo RMON é uma MIB SNMP, portanto o dispositivo deve possuir um agente SNMP;

É específico para tecnologias Ethernet e Token Ring, apesar de existir uma implementação para ATM;

O dispositivo que implementa o suporte para RMON se chama probe RMON: Um probe pode ser implementado em um dispositivo dedicado ou em um elemento de rede, como um hub, switch ou roteador;

Visa monitorar tráfego de um segmento da rede. O probe deve ficar em um ponto da rede por onde passa todo o tráfego do segmento, deve haver um probe RMON por segmento de rede a ser monitorado;

Em redes comutados, RMON é implementado normalmente nos equipamentos ativos ou através de espelhamento do tráfego de suas portas para uma porta de monitoração (port mirroring).

Objetivos do RMON
Realizar análise e levantar informações estatísticas sobre os dados coletados em uma sub-rede, liberando a estação gerente desta tarefa;

Reduzir tráfego entre rede local gerenciada e a estação gerente remota;

Detectar, registrar e informar à estação gerente sobre situações de erro e eventos significativos da rede;

Permitir o gerenciamento pró-ativo da rede, diagnosticando e registrando eventos que possibilitem detectar o mal funcionamento e prever falhas que interrompam a sua operação;

Enviar informações de gerenciamento para múltiplas estações gerentes.

Abrangência das versões

Exemplo de funcionamento

MIB RMON1

Aquisição de Estatísticas de Tráfego:

• Estatístico (Statistics)
• Histórico (History)
• Hosts
• Classificação de n Hosts (Host Top N)
• Matriz (Matrix)
• Token Ring

Detecção e Resolução de Situações Críticas e de Erro:

• Alarme (Alarm)
• Filtro (Filter)
• Captura de pacote (Packet Capture)
• Evento (Event)

RMON1 – Statistics
Estatísticas básicas do tráfego em cada segmento de rede Ethernet.

Exemplos de estatísticas Ethernet:

• Bytes trafegados;
• Pacotes trafegados (<uni/broad/multi>cast);
• Pacotes < 64 bytes;
• Pacotes > 1518 bytes;
• Pacotes com erro de CRC;
• Número de colisões.

RMON1 – History
Armazena n últimas estatísticas da rede.

Configuração:

• Intervalos de amostragem;
• Quantidade de amostras armazenadas.

Análise da tendência de comportamento de uma rede:

• Cria subsídios para um gerenciamento pró-ativo.

RMON1 – Hosts
Estatísticas para cada host do segmento de rede.

Exemplos:

• Número de bytes transmitidos e recebidos;
• Número de pacotes transmitidos e recebidos;
• Número de pacotes com erro transmitidos;
• Número de pacotes broadcast transmitidos;
• Número de pacotes multicast transmitidos.

RMON1 – Hosts Top N
Classifica os hosts de acordo com valores de variáveis do grupo hosts.

Permite definir:

• Variável para ordenação;
• Duração da amostragem;
• Quantidade de hosts na lista.

Exemplo:

• As 10 máquinas que mais transmitiram pacotes na rede hoje;
• As 5 máquinas que mais transmitiram pacotes com erros nas últimas 2 horas;
• As 20 máquinas que mais geraram tráfego de broadcast na semana.

RMON1 – Matrix
Associa estatísticas de tráfego entre pares de máquinas.

Exemplos:

• Pacotes transmitidos;
• Octetos transmitidos;
• Pacotes com erros transmitidos.

Facilita a obtenção de informações em relação à comunicação entre um par qualquer de estações.

  
RMON1 – Token Ring
O suporte a Token Ring pode ser feito de 2 formas:

• Extensão dos grupos Statistics e History para redes Token Ring: Grupos Statistics e History originais eram dependentes de Ethernet.
• Novo grupo Token Ring.

RMON1 – Alarm
Estabelece limites de operação para variáveis de MIB.

Se limites forem ultrapassados, gera alarmes.

Exemplos:

• Mais de 20 pacotes com erro nos últimos 5 minutos;
• Bytes enviados for menor que 100.000.000/5s.

RMON1 – Filter
Define condições associadas a pacotes trafegados pela rede.

Se pacote atende às condições estabelecidas:

• Captura o pacote ou Registra estatísticas baseadas no mesmo.

Exemplos:

• Captura todos os pacotes vindos do servidor S1;
• Conta quantos pacotes estão indo para o roteador e não são originários dos servidores: Tráfego entre segmentos de redes das estações.

RMON1 – Packet Capture
Troubleshooting em segmentos de redes remotos.

Como capturar tráfego em um segmento de rede?

• Colocar no segmento um sniffer;
• Utilizar o probe RMON.

Captura pacotes para análise na rede.

Parâmetros da captura:

• Quantos bytes de cada pacotes serão armazenados? Default são os 100 primeiros bytes.
• Qual filtro determina os pacotes a serem capturados?
• Qual o tamanho do buffer a ser utilizado?

RMON1 – Event
Algumas ações do probe provocam eventos, por exemplo:

• Alarme disparado;
• Pacote que atende condições de um filtro.

Grupo event determina o que fazer nestes casos:
Log interno;
snmp-trap;
Log-and-trap.

RMON2
O RMON1 trabalha na camada de enlace de dados. Mas e as demandadas de Estatísticas de IP, IPX, etc? Estatísticas de HTTP, FTP, etc?

O RMON2 visa atender essas necessidades.

MIB RMON2
A MIB do RMON2 é um subconjunto da árvore MIB: 9 novos grupos básicos de variáveis.

RMON2 – Protocol Directory
Diretório de Protocolo.

Lista dos protocolos que o probe RMON2 consegue monitorar;

Visa à interoperabilidade.

RMON2 – Protocol Distribution
Estatísticas sobre todos os protocolos suportados pelo probe.

Número de bytes e de pacotes referentes cada protocolo trafegando naquele segmento da rede.

RMON2 – Network Layer Host/Matrix e Application Layer Host/Matrix

RMON2 – User History
Histórico de Coleta do Usuário.

Equivalente ao grupo de history do RMON1. Permite, porém configurar quais variáveis serão mantidas no histórico, além do intervalo e quantidade da amostragem.

RMON2 – Probe Configuration
Configuração do Probe.

Padroniza a configuração do probe RMON, visando interoperabilidade entre probes e softwares gerentes de diferentes fabricantes.

Exemplos:

• Reboot do probe;
• Atualização de Software.

RMON2 – Address Map
Mapeamento de Endereços.

Relaciona endereços MAC e endereços de Rede (IP, IPX).

RMON – Considerações Finais
RMON pode exigir bastante processamento: Nem sempre um determinado recurso tem recursos de processamento e armazenamento para suportar todos os grupos de variáveis da RMON-MIB.

É suficiente que sejam implementados um único desses grupos, para o elemento ser considerado em conformidade com o RMON. Na especificação dos dispositivos são definidos quais grupos de RMON ele suporta.

No caso de existirem múltiplos gerentes, o elemento RMON deve determinar quais informações de gerenciamento devem ser encaminhadas para cada gerente.

Referências:
•    Gabos, Denis.; Melo, Tereza C. Apostila de Gerenciamento de Redes, EPUSP, 2003.
•    Stallings, W. SNMP, SNMPv2, SNMPv3 and RMON1 and 2. 3rd ed. 7th printing, 2003.
•    Kurose; Ross. Redes de Computadores e a Internet. Uma nova Abordagem. Pearson Education, 2003.
•    http://www.simpleweb.org
•    http://www.rnp.br/newsgen/9901/rmon.html
•    http://www.dsc.ufcg.edu.br/~jacques/cursos/gr/html/aplic/aplic5.htm
Pessoal o material usado como base para a criação destes textos, veio de amigos, listas de distribuição e pesquisas na internet, portanto não possuo referências sobre os mesmos, mas se você identificar algum material de sua autoria, por favor entre em contato que os devidos créditos serão atribuídos. 

A MIB

A MIB (Management Information Base - Base de Informações de Gerenciamento) é um conjunto dos objetos gerenciados, com o objetivo de abranger informações necessárias para a gerência da rede, é importante salientar que a MIB não contém objetos reais, somente os organiza.

Objetos Gerenciados
São “estruturas de dados” resultantes da modelagem dos recursos da rede a serem gerenciados, podem ter permissões para serem lidos ou alterados sendo que cada leitura representará o estado real do recurso e cada alteração será refletida no próprio recurso, isso permite automatização de grande parte das tarefas de gerência.

Modelos de Gerenciamento
O padrão OSI define três modelos para gerenciamento de redes:

• Modelo Organizacional
• Modelo Informacional
• Modelo Funcional

Modelo organizacional
Descreve a forma pela qual a gerência pode ser distribuída entre domínios e sistemas dentro de um domínio.

Modelo funcional
Descreve as áreas funcionais e seus relacionamentos.

Modelo informacional
Provê a base para a definição de objetos gerenciados e suas relações, classes atributos, ações e nomes.

Características do Modelo OSI
Na definição de objetos gerenciados é utilizada a orientação a objetos. Objetos com características semelhantes são agrupados em classes de objetos, uma classe pode ser uma subclasse de outra, e a primeira herda todas as propriedades da segunda.

Classe, Subclasse e Superclasse
Uma classe é definida por:

• Atributos da classe
• Ações que podem ser invocadas
• Eventos que podem ser relatados
• Subclasse a qual ela deriva
• Superclasse na qual ela está contida

Hierarquias dos Objetos Gerenciados:
Para a definição dos objetos gerenciados deve-se considerar três hierarquias:

• Hierarquia de herança
• Hierarquia de nomeação
• Hierarquia de registros usados na caracterização e identificação de objetos gerenciados

Hierarquia de Herança
Conhecida também como hierarquia de classe, tem como objetivo facilitar a modelagem dos objetos, através da utilização do paradigma da orientação a objetos. Ferramenta que facilita a definição de classes, superclasses, subclasses.

Hierarquia de Nomeação
Hierarquia usada para identificar uma instância de um objeto. Conhecida como Hierarquia de containment, descreve a relação de "estar contido em" aplicado aos objetos.

Um objeto gerenciado está contido dentro de um (e somente um) objeto gerenciado, um objeto gerenciado existe somente se o objeto que o contém existir.

Hierarquia de Registro
Hierarquia usada para identificar os objetos, independentemente das hierarquias de heranças e nomeação. É especificada segundo regras estabelecidas pela notação ASN.1 (Abstract Syntax Notation. One).
Cada objeto é identificado por uma sequência de números, correspondente aos nós percorridos desde a raiz, até o objeto em questão.

MIB da Internet
O RFC (Request for Comments) 1066 apresentou a primeira versão da MIB, a MIB-1, o IAB (Internet Activities Board) aceita MIB como padrão no RFC 1156.

O RFC 1158 propôs uma segunda MIB, a MIB-II, aceita e formalizada como padrão no RFC 1213.

A árvore da MIB II
Usa arquitetura de árvore de registro, cada parte da informação da árvore é um nó rotulado formado por:
Identificador de objetos (OID): 1.3.6.1.1

Descrição textual: directory(1)

O nó raiz da árvore (MIB) possui três sub-árvores:

• ccitt(0): Administração CCITT (Comite Consultatif Internationale de Telegraphie et Telephonie)
• iso(1): Administração ISO
• joint-iso-ccitt(2): Administração ISO e CCITT

 Sob o nó iso(1) temos as subárvores:

• org(3)
• dod(6)
• Internet(1)

O nó Internet(1) possui quatro subárvores:

• directory(1): Contém informações sobre o serviço de diretórios OSI
• mgmt(2): Informações de gerenciamento
• experimental(3): Objetos em pesquisa pela IAB
• private(4): Objetos definidos por outras organizações

Abaixo do nó mgmt(2) estão os objetos usados para se obter informações específicas de rede.

A árvore da MIB II

Objeto System (1.3.6.1.2.1.1)

Exemplos de Grupos
Grupo System - Sistema de operação dos dispositivos da rede
Descrição textual: iso.org.dod.internet.mgmt.mib-2.system
OID: 1.3.6.1.2.1.1

Componentes:
sysDesc(1): Descrição do sistema, nome completo e versão do tipo de hardware, sistema operacional e software de rede.

sysObjectId(2): OID de registro (fabricante do sistema).

sysUpTime(3): Tempo de atividade do sistema (1/100 s).

sysContact (4): Pessoa ou grupo responsável pelo nó.

sysName(5): Nome do nó na rede.

sysLocation(6): Localização física do nó.

sysServices(7): Flags indicando serviços suportados.

Grupo Interfaces - Interface da rede com o meio físico
Descrição textual: iso.org.dod.internet.mgmt.mib-2.interface
OID: 1.3.6.1.2.1.2

Componentes:
ifNumber(1): Número de interfaces de rede (independentemente do seu estado atual) presentes no sistema.

ifTable(2): A tabela de informações sobre cada interface de rede, o número de interfaces é dado pelo valor do ifNumber.

ifEntry(ifTable 1):  Entradas de valores sobre cada uma das interfaces

ifIndex(ifEntry 1): Um valor único para cada interface, permite identificar a interface.

ifDescr(ifEntry 2): Identificação da interface, deve incluir o nome do fabricante, o nome do produto e a versão da interface.

ifType(ifEntry 3): Tipo de interface.

ifMtu(ifEntry 4): Tamanho máximo do datagrama suportado pela  interface, especificado em octetos.

ifSpeed(ifEntry 5): Uma estimativa da largura de banda atual da interface em bits por segundo. Para interfaces que não variam em largura de banda ou para aqueles onde não precisa estimativa pode ser feita, este objeto deve conter a largura de banda nominal.

ifPhysAddress(ifEntry 6): Endereço físico da interface, Para interfaces que não têm tal endereço (por exemplo, uma linha serial), este objeto deve conter um octeto string de comprimento zero.

ifAdminStatus(ifEntry 7): Indica o estado desejado da interface.

ifOperStatus(ifEntry 8): Indica o estado atual de funcionamento do interface.

up(1), -- pronto para passar pacotes
down(2), -- interface desabilitada
testing(3) -- indica que nenhum pacote em estado operacional podem ser passados.

ifLastChange(ifEntry 9): O tempo de funcionamento desde que a interface entrou em estado operacional.

ifInOctets(ifEntry 10): O número total de octetos recebidos na interface, incluindo caracteres de enquadramento (framing characters).

ifInUcastPkts(ifEntry 11):  O número de pacotes unicast entregues a um protocolo de camada superior.

ifInNUcastPkts(ifEntry 12): O número de pacotes não unicast (ou seja, broadcast ou multicast) entregues a um protocolo de camada superior. "

ifInDiscards(ifEntry 13):  O número de pacotes de entrada que foram escolhidos para serem descartados, mesmo que nenhum erro tenha sido detectado, impede a entrega dos pacotes a um protocolo de camada superior. Uma razão possível para descartar tais pacotes poderia ser para liberar espaço de buffer.

ifInErrors(ifEntry 14):  O número de pacotes de entrada que continham erros que impedem seu fornecimento a um protocolo de camada superior.

ifInUnknownProtos(ifEntry 15): O número de pacotes recebidos através da interface que foram descartados por causa de um protocolo desconhecido ou não suportado.

ifOutOctets(ifEntry 16):  O número total de octetos transmitidos na interface, incluindo caracteres de enquadramento (framing characters).

ifOutUcastPkts(ifEntry 17):  O número total de pacotes que o protocolo de camada superior solicitou que fossem transmitidos, incluindo aqueles que foram descartados ou não enviados.

ifOutNUcastPkts(ifEntry 18):  O número total de pacotes não unicast (ou seja, broadcast ou multicast)  que o protocolo de camada superior solicitou que fossem transmitidos, incluindo aqueles que foram descartados ou não enviados.

ifOutDiscards(ifEntry 19):  O número de pacotes de saída que foram escolhidos para serem descartados, mesmo que nenhum erro tenha sido detectado, impede a transmissão dos pacotes. Uma razão possível para descartar tais pacotes poderia ser para liberar espaço de buffer.

ifOutErrors(ifEntry 20):  O número de pacotes de saída que não puderam ser transmitidos devido a erros.

ifOutQLen(ifEntry 21):  O comprimento da fila de saída de pacotes (em pacotes).

ifSpecific(ifEntry 22):  Uma referência a definições MIB específicos para uma mídia em particular, sendo usado para realizar a interface com o objeto. Por exemplo, se a interface é realizado por uma ethernet, então o valor deste objeto refere-se a um documento que define objectos específicos para ethernet. Se esta informação não é presente, seu valor deve ser definido como OBJECT IDENTIFIER { 0 0 }, que é uma sintaxe válida para identificador de objeto, e estará em conformidade com qualquer implementação de ASN.1 e BER que devera ser capaz de gerar e reconhecer esse valor.

Grupo at (Address Translation) - Mapeamento de endereços IP em endereços físicos.
Descrição textual: iso.org.dod.internet.mgmt.mib-2.at
OID: 1.3.6.1.2.1.3

Componentes:
atTable(1): As tabelas de tradução de endereços, devem conter o endereço de rede para seu endereço físico equivalente.

Algumas interfaces não usam tabelas de conversão para determinar equivalências endereço (por exemplo, DDN-X.25 tem um método algorítmico), se todas as interfaces são deste tipo, então a tabela Address Translation está vazia, ou seja, tem zero entradas.

atEntry(atTable 1): Cada entrada contém um endereço de rede para seu endereço físico equivalente.

atIfIndex(atEntry 1): A interface identificada por um determinado valor deste índice é a mesma interface identificada pelo mesmo valor de ifIndex.

atPhysAddress(atEntry 2):  Endereço físico da interface.

atNetAddress(atEntry 3): O endereço da rede (por exemplo, o endereço IP).

Grupo ip - Protocolo IP
Descrição textual: iso.org.dod.internet.mgmt.mib-2.ip
OID: 1.3.6.1.2.1.4

Componentes (Apenas Alguns):
ipForwarding(1): (forwarding(1), not-forwarding(2)): Se o IP Forward está ou não habilitado no dispositivo.

ipInReceives(3):  O número total de datagramas de entrada recebidos pela interface,incluindo aqueles recebidos com erro.

ipInAddrErrors(5): O número de datagramas de entrada descartados porque o endereço IP de destino em seu campo de cabeçalho IP não era um endereço válido. Essa contagem inclui endereços inválidos (por exemplo, 0.0.0.0) e os endereços de Classes não suportsadas (por exemplo, Classe E).

ipInUnknownProtos(7): O número de datagramas recebido com sucesso, mas descartados por causa de um protocolo desconhecido ou não suportado.

ipOutDiscards(11): O número de datagramas IP de saída para os quais não foram encontrados problemas para impedir a sua transmissão ao seu destino, mas que foram descartados (por exemplo, por falta de espaço de buffer).

ipOutNoRoutes(12): O número de datagramas IP descartados, porque nenhuma rota podia ser encontrada para transmiti-los aos seus destinos.

ipAddrTable(20): Tabela de endereçamento IP.

ipAdEntReasmMaxSize(ipAddrEntry 5): O tamanho do maior datagrama IP que esta entidade pode re-montar a partir dos datagramas IP fragmentados recebidos por esta interface.

ipRouteTable(21): Tabela de roteamento IP.

ipRouteDest(ipRouteEntry 1): Endereço IP do destino da rota. Uma entrada com valor 0.0.0.0 é considerada uma rota padrão.

ipRouteMetric1(ipRouteEntry 3): A métrica de roteamento primário para esta rota. A semântica desta métrica é determinada pelo protocolo de roteamento especificado na rota do valor ipRouteProto. Se essa métrica não é utilizada, seu valor deve ser definido como -1.

ipRouteNextHop(ipRouteEntry 7): O endereço IP do próximo salto da rota. (No caso de uma rota ligada a uma interface que se realiza através de uma mídia de broadcast, o valor deste campo é o endereço IP do agente daquela interface.)

Grupo icmp – Protocolo ICMP
Descrição textual: iso.org.dod.internet.mgmt.mib-2.icmp
OID: 1.3.6.1.2.1.5

Componentes (Apenas Alguns):
icmpInMsgs(icmp 1): O número total de mensagens ICMP que a entidade recebeu. Note que a contagem inclui todos os contadores de icmpInErrors.

icmpInErrors(icmp 2): O número de mensagens ICMP que a entidade recebeu, mas determinada por erros ICMP específicos (ICMP checksums com erro, erro no tamanho, etc.)

icmpInDestUnreachs(icmp 3): O número de mensagens ICMP recebidas com destino inacessível.

icmpInTimeExcds(icmp 4): O número de mensagens ICMP recebidas com tempo excedido.

Grupo TCP – Protocolos TCP
Descrição textual: iso.org.dod.internet.mgmt.mib-2.tcp
OID: 1.3.6.1.2.1.6

Componentes (Apenas Alguns):
tcpConnTable(13): Uma tabela contendo informações de conexão TCP específicas.

tcpConnState(tcpConnEntry 1): O estado da conexão TCP.

tcpConnLocalAddress(tcpConnEntry 2): O endereço IP local para esta conexão TCP. No caso de uma conexão no estado ouvindo disposta a aceitar conexões para qualquer interface IP associado ao nó, o valor 0.0.0.0 é usado.

tcpConnRemAddress(tcpConnEntry 4): O endereço IP remoto para essa conexão TCP.

tcpConnRemPort(tcpConnEntry 5): O número da porta remota para esta conexão TCP.

Grupo UDP – Protocolos UDP
Descrição textual: iso.org.dod.internet.mgmt.mib-2.udp
OID: 1.3.6.1.2.1.7

Componentes:
udpInDatagrams(1): O número total de datagramas UDP entregues aos usuários UDP.

udpNoPorts(2): O número total de datagramas UDP recebidos para os quais não houve aplicação na porta de destino.

udpInErrors(3): O número de datagramas UDP recebidos que não puderam ser entregues por outras razões que a falta de uma aplicação na porta de destino.

udpOutDatagrams(4): O número total de datagramas UDP enviados a partir desta entidade.

udpTable(5): Uma tabela contendo informações sobre os ouvintes UDP.

udpEntry(udpTable 1): Informações sobre um determinado ouvinte UDP.

udpLocalAddress(udpEntry 1): O endereço IP local para este ouvinte UDP. No caso de um ouvinte UDP que está disposto a aceitar datagramas para qualquer interface IP associado com o nó, o valor 0.0.0.0 é usado.

udpLocalPort(udpEntry 2): O número da porta local para este ouvinte UDP.

Grupo EGP – Protocolo EGP
Descrição textual: iso.org.dod.internet.mgmt.mib-2.egp
OID: 1.3.6.1.2.1.8

Componentes (Apenas Alguns):
egpInMsgs(1): O número de mensagens EGP recebidas sem erro.

egpInErrors(2): O número de mensagens EGP recebidas com erro.

egpOutMsgs(3): O número total de mensagens EGP gerados localmente.

egpOutErros(4): O número de mensagens EGP gerados localmente não enviadas devido a limitações de recursos dentro de uma entidade EGP.

egpNeighTable(5): A tabela de vizinhos EGP.

Grupo cmot – Protocolo CMOT
Descrição textual: iso.org.dod.internet.mgmt.mib-2.cmot
OID: 1.3.6.1.2.1.9

Histórico (alguns dizem histérico)

Grupo Transmission – Meios de Transmissões
Descrição textual: iso.org.dod.internet.mgmt.mib-2.transmission
OID: 1.3.6.1.2.1.10

Histórico (alguns dizem histérico)

Grupo SNMP – Protocolo SNMP
Descrição textual: iso.org.dod.internet.mgmt.mib-2.snmp
OID: 1.3.6.1.2.1.11

Componentes:
snmpInPkts(1): O número total de mensagens entregues à entidade SNMP pelo serviço de transporte.

snmpOutPkts(2): O número total de mensagens SNMP que foram passados da entidade protocolo SNMP para o serviço de transporte.

snmpInBadVersions(3): O número total de mensagens SNMP que foram entregues à entidade protocolo SNMP, mas eram de uma versão SNMP não suportada.

snmpInBadCommunityNames(4): O número total de mensagens SNMP entregues à entidade protocolo SNMP, mas que usaram um nome da comunidade SNMP desconhecida pela entidade.

snmpInBadCommunityUses(5): O número total de mensagens SNMP entregues à entidade protocolo SNMP que representaram uma operação SNMP que não era permitido pela comunidade SNMP nomeada na mensagem.

snmpInASNParseErrs(6): O número total de erros ASN.1 ou BER encontrados pela entidade protocolo SNMP quando decodificou as Mensagens SNMP recebidas.

-- (7): Não é usado

snmpInTooBigs(8): O número total de PDUs SNMP que foram entregues à entidade protocolo SNMP e para os quais o valor do campo status de erro é `tooBig '.

SnmpInNoSuchNames(9): O número total de PDUs SNMP que foram entregues à entidade protocolo SNMP e para os quais o valor do campo status de erro é `noSuchName '.

SnmpInBadValues(10): O número total de PDUs SNMP que foram entregues à entidade protocolo SNMP e para os quais o valor do campo status de erro é `badValue '.

snmpInReadOnlys(11): O número total válido de PDUs SNMP que foram entregues à entidade protocolo SNMP e para os quais o valor do campo status de erro é 'readOnly'. Note-se que é um erro de protocolo para gerar um PDU SNMP que contém o valor `readOnly ' no campo erro de status, como tal este objeto é fornecido como um meio de detectar implementações incorretas do SNMP.

snmpInGenErrs(12): O número total de PDUs SNMP que foram entregues à entidade protocolo SNMP e para os quais o valor do campo status de erro é `genErr'.

snmpInTotalReqVars(13): O número total de objetos MIB que foram recuperados com sucesso pela entidade protocolo SNMP como o resultado de receber PDUs SNMP Get-Request e Get-Next válidos.

snmpInTotalSetVars(14): O número total de objetos MIB que foram alterados com sucesso pela entidade protocolo SNMP como o resultado de receber PDUs SNMP Set-Request válidos.

snmpInGetRequests(15): O número total de PDUs SNMP Get-Request que foram aceitas e processadas pela entidade protocolo SNMP.

snmpInGetNexts(16): O número total de PDUs SNMP Get-Next que foram aceitas e processadas pela entidade protocolo SNMP.

snmpInSetRequests(17): O número total de PDUs SNMP Set-Request que foram aceitas e processadas pela entidade protocolo SNMP.

snmpInGetResponses(18): O número total de PDUs SNMP Get-Response que foram aceitas e processadas pela entidade protocolo SNMP.

snmpInTraps(19): O número total de PDUs SNMP Trap que foram aceitas e processadas pela entidade protocolo SNMP.

snmpOutTooBigs(20): O número total de PDUs SNMP que foram gerados pela entidade protocolo SNMP e para os quais o valor do campo status de erro é `tooBig '.

snmpOutNoSuchNames(21): O número total de PDUs SNMP que foram gerados pela entidade protocolo SNMP e para os quais o valor do campo status de erro é ` noSuchName '.

snmpOutBadValues(22): O número total de PDUs SNMP que foram gerados pela entidade protocolo SNMP e para os quais o valor do campo status de erro é ` badValue '.

-- (23): Não é usado

snmpOutGenErrs(24): O número total de PDUs SNMP que foram gerados pela entidade protocolo SNMP e para os quais o valor do campo status de erro é ` genErr '.

snmpOutGetRequests(25): O número total de PDUs SNMP Get-Request que foram gerados pela entidade protocolo SNMP.

snmpOutGetNexts(26): O número total de PDUs SNMP Get-Next que foram gerados pela entidade protocolo SNMP.

snmpOutSetRequests(27): O número total de PDUs SNMP Set-Request que foram gerados pela entidade protocolo SNMP.

snmpOutGetResponses(28): O número total de PDUs SNMP Get-Response que foram gerados pela entidade protocolo SNMP.

snmpOutTraps(29): O número total de PDUs SNMP Trap que foram gerados pela entidade protocolo SNMP.

snmpEnableAuthenTraps(30): (enabled(1), disabled(2)): Indica se o processo do agente SNMP esta configurado para gerar traps de falha de autenticação. O valor deste objeto substitui qualquer informação de configuração, como tal, fornece um meio pelo qual todos os traps de falha de autenticação possam ser desabilitados.

Note que é altamente recomendável que esse objeto seja armazenados em memória não-volátil para que ele permaneça constante entre as reinicializações do sistema de gerencia de rede.

Referências:
RFC1213
Pessoal o material usado como base para a criação destes textos, veio de amigos, listas de distribuição e pesquisas na internet, portanto não possuo referências sobre os mesmos, mas se você identificar algum material de sua autoria, por favor entre em contato que os devidos créditos serão atribuídos.

Procedimento Horário de Verão: GNU/Linux, FreeBSD e Windows

Horário de Verão 2011/2012:

Início: 16/10/11 - 3º Domingo

Término: 26/02/2012 - 4 Domingo

Sistemas GNU/Linux:

1. Verificar a existência do arquivo '/etc/localtime' e se este arquivo é um link simbólico ou não.

Não é recomendado possuir o arquivo /etc/localtime como link simbólico, pois em sistemas em que o diretório /usr nao estiver acessivel (nao tiver sido montado, por exemplo) no momento da inicialização da máquina, as informações contidas no arquivo localtime não serão carregadas.

# ls -las /etc/localtime

2. Verificar se existe no diretório /usr/share/zoneinfo/Brazil algum arquivo que contenha informações relativas a outros horários de verão (DICA: geralmente um arquivo com extensão .zic).

    a) Se não existir nenhum arquivo com tais informações então crie um novo, de nome 'verao.zic' por exemplo, no diretório /usr/share/zoneinfo/Brazil/. Este arquivo deverá conter as seguintes linhas:

    Rule Brazil  2011    only     -       Oct    16   00:00   1       S

    Rule Brazil  2012    only     -       Feb    26   00:00   0       -

    Zone    Brazil/East             -3:00   Brazil          BR%sT

# ls -las /usr/share/zoneinfo/Brazil/*.zic

3. Uma vez feitos os devidos ajustes no arquivo 'verao.zic' execute o comando 'zic':

# cd /usr/share/zoneinfo/Brazil/

# zic verao.zic

4. Neste caso em particular o comando atualizará o arquivo East.

Para verificar se as configurações corretas foram feitas, execute o comando 'zdump', conforme segue abaixo:

# zdump -v /usr/share/zoneinfo/Brazil/East |grep 201[12]

Você deverá obter uma resposta como a que segue abaixo:

/usr/share/zoneinfo/Brazil/East  Sun Oct 16 02:59:59 2011 UTC = Sat Oct 15 23:59:59 2011 BRT isdst=0 gmtoff=-10800

/usr/share/zoneinfo/Brazil/East  Sun Oct 16 03:00:00 2011 UTC = Sun Oct 16 01:00:00 2011 BRST isdst=1 gmtoff=-7200

/usr/share/zoneinfo/Brazil/East  Sun Feb 26 01:59:59 2012 UTC = Sat Feb 25 23:59:59 2012 BRST isdst=1 gmtoff=-7200

/usr/share/zoneinfo/Brazil/East  Sun Feb 26 02:00:00 2012 UTC = Sat Feb 25 23:00:00 2012 BRT isdst=0 gmtoff=-10800

Note que em "Sat Oct 15 23:59:59 2011" o sistema ainda não está no Horário de Verão (indicação 'BRT'). No segundo seguinte as modificações do Horário de Verão entram em vigor, adiantando o localtime em uma hora: "Sun Oct 16 01:00:00 2011 BRST" (O horário mostrado ao usuário passará para 1 da manhã, e não para meia-noite, mostrando o adiantamento do horário).

Em "Sat Feb 25 23:59:59 2012 BRST", o Horário de Verão terminará no segundo seguinte, com o localtime sendo então atrasado em 1 hora: "Sat Feb 25 23:00:00 2012 BRT" (o horário mostrado ao usuário voltará para às 23:00).

5. Por último, se o arquivo /etc/localtime NÃO for um link para o arquivo /usr/share/zoneinfo/Brazil/East, deve-se copiar o arquivo East para /etc/localtime

# cp East /etc/localtime

Caso o arquivo /etc/localtime seja um link, sugerimos que o link seja removido e a cópia descrita acima seja executada. Lembre-se sempre de fazer cópias de segurança antes de modificar seu sistema.

Sistemas FreeBSD:

1. Verificar a existência do arquivo '/etc/localtime' e se este arquivo é um link simbólico ou não.

Não é recomendado possuir o arquivo /etc/localtime como link simbólico, pois em sistemas em que o diretório /usr nao estiver acessivel (nao tiver sido montado, por exemplo) no momento da inicialização da máquina, as informações contidas no arquivo localtime não serão carregadas.

# ls -las /etc/localtime

2. Verificar se existe no diretório /usr/share/zoneinfo algum arquivo que contenha informações relativas a outros horários de verão (DICA: geralmente um arquivo com extensão .zic).

    a) Se não existir nenhum arquivo com tais informações então crie um novo, de nome 'verao.zic' por exemplo, no diretório /usr/share/zoneinfo. Este arquivo deverá conter as seguintes linhas:

    Rule Brazil  2011    only     -       Oct    16   00:00   1       S

    Rule Brazil  2012    only     -       Feb    26   00:00   0       -

    Zone hv2011 -3:00 Brazil BR%sT

No exemplo acima, o nome 'hv2011' representa o arquivo que será criado ao executar o comando 'zic verao.zic', o qual conterá as informações do Horário de Verão. Este novo arquivo deverá ser copiado sobre /etc/localtime, lembrando que será preciso fazer uma cópia de segurança do arquivo /etc/localtime antes de sobrescrevê-lo.

# ls -las /usr/share/zoneinfo/ *.zic

3. Uma vez feitos os devidos ajustes no arquivo 'verao.zic' execute o comando 'zic':

# cd /usr/share/zoneinfo/Brazil/

# zic verao.zic

4. Neste caso em particular o comando gerará o arquivo 'hv2011'.

Para verificar se as configurações corretas foram feitas, execute o comando 'zdump', conforme segue abaixo:

# zdump -v /usr/share/zoneinfo/hv2011

Você deverá obter uma resposta como a que segue abaixo:

/usr/share/zoneinfo/hv2011  Sun Oct 16 02:59:59 2011 UTC = Sat Oct 15 23:59:59 2011 BRT isdst=0 gmtoff=-10800

/usr/share/zoneinfo/hv2011  Sun Oct 16 03:00:00 2011 UTC = Sun Oct 16 01:00:00 2011 BRST isdst=1 gmtoff=-7200

/usr/share/zoneinfo/hv2011  Sun Feb 26 01:59:59 2012 UTC = Sat Feb 25 23:59:59 2012 BRST isdst=1 gmtoff=-7200

/usr/share/zoneinfo/hv2011  Sun Feb 26 02:00:00 2012 UTC = Sat Feb 25 23:00:00 2012 BRT isdst=0 gmtoff=-10800

Note que em "Sat Oct 15 23:59:59 2011" o sistema ainda não está no Horário de Verão (indicação 'BRT'). No segundo seguinte as modificações do Horário de Verão entram em vigor, adiantando o localtime em uma hora: "Sun Oct 16 01:00:00 2011 BRST" (O horário mostrado ao usuário passará para 1 da manhã, e não para meia-noite, mostrando o adiantamento do horário).

Em "Sat Feb 25 23:59:59 2012 BRST", o Horário de Verão terminará no segundo seguinte, com o localtime sendo então atrasado em 1 hora: "Sat Feb 25 23:00:00 2012 BRT" (o horário mostrado ao usuário voltará para às 23:00).

5. Por último, se o arquivo /etc/localtime NÃO for um link, deve-se copiar o arquivo 'hv2011' para /etc/localtime

# cp /usr/share/zoneinfo/hv2011 /etc/localtime

Caso o arquivo /etc/localtime seja um link, sugerimos que o link seja removido e a cópia descrita acima seja executada. Lembre-se sempre de fazer cópias de segurança antes de modificar seu sistema.

Sistemas Windows:

1. Faça o download do TZEdit.

2. Ao executar o arquivo baixado ele vai descompactar os arquivos em:

C:\Program Files\TZEdit

3. Entre na pasta e execute o TZEDIT.EXE

4. Configure-o conforme imagem abaixo:

Referências:

http://www.rnp.br/cais/alertas/2007/cais-alr-20071005.html#FREE

http://support.microsoft.com/kb/927229/pt-br

Duplicando Discos Virtuais no VirtualBox

Introdução:
Muitas vezes criamos máquinas virtuais e depois desejamos criar uma nova máquina idêntica a primeira, como se fossemos clonar a máquina virtual, a primeira idéia que nos vem a cabeça é copiar o arquivo do disco virtual, criar uma nova máquina e apontar para o disco recém copiado.

O problema:
Os discos possuem uma identificação única e ao realizarmos o procedimento acima, vamos receber uma mensagem dizendo que o disco já está em uso.

Observe que eu renomeie a cópia de CentOS 6.0 para CentOS 6.0 - Cópia, mas o VirtualBox diz que os dois discos tem o mesmo UUID.

Como resolver:
Pesquisando na net (vide referências) descobri que poderia usar um comando para gerar a cópia dos discos, o comando VBoxManage clonehd <disco original> <cópia do disco>, mas eu já tinha feito uma cópia do disco, e acho mais fácil fazer dessa maneira.
Pesquisando mais um pouco descobri que eu poderia pegar a cópia do disco e gerar um novo UUID para o mesmo usando o comando VBoxManage internalcommands sethduuid <copia do disco>.

Usando a cópia do disco:
Agora já podemos usar a cópia que fizemos do disco em uma nova máquina virtual, na mesma máquina física.

Simples não?
 
Referências:
Blog do Athanazio
Blog Networks & Security

Gerenciamento de Redes - O Protocolo SNMP

O SNMP (Simple Network Management Protocol) é um protocolo da camada de aplicação que tem como objetivo principal coletar informações de dispositivos gerenciáveis. É o responsável por veícular informações de gerência (valores das MIBs).

Suas interações são sem conexão, trabalha com Mensagens no protocolo UDP/IP, utiliza as portas 161 e 162 e seus pacotes tem tamanho variável.

Este protocolo se tornou padrão para gerência na Internet, por ser simples de implementar e amplamente difundido.

É composto de um Protocolo para troca de mensagens e padrões para estruturar a informação.

As Informações de Gerenciamento são armazenadas em MIBs que são definidas através da SMI (Structure of Management Information) e transportadas através do protocolo SNMP.

SMI
Podemos entender a SMI como uma descrição lógica das informações. É composta dos seguintes elementos:
Nomes dos objetos gerenciados, referenciados através dos OIDs (Object IDentifiers);
Sintaxe dos dados, seguindo os padrões da ASN.1 (Abstract Syntax Notation 1);
Sintaxe de transferência, seguindo as regras da BER (Basic Encoding Rules).

ASN.1
É uma linguagem de descrição de dados da ISO, definida em formato texto não ambíguo, que permite definir modelo de dados com formato independente de máquina. A implementação de dados não é considerada.

Sintaxe básica em ANS.1
Tipos de dados:
Primitivos: INTEGER, OCTET STRING, OBJECT IDENTIFIER, NULL, Subtipos;
Construtores: Lista e Tabelas;
Definidos: Nomes alternativos para tipos ASN.1.

Notações em ASN.1, seguem algumas convenções:

Exemplos de Definição ASN.1:
sysContact OBJECT-TYPE
SYNTAX DisplayString (SIZE (0...255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
    “Texto xxxxxxxxxxxxxxxxxxxxxxxx”

parDhcpStartTime OBJECT-TYPE
SYNTAX  DisplayString (SIZE (1..30))
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
    “Dhcp Server start time”


Campo SYNTAX:
Define o conteúdo do objeto.
INTEGER: Inteiros de 32 bits.
INTEGER (1...100) Sub-tipo inteiro).
OCTET STRING: String de bytes.
OBJECT IDENTIFIER: Localização de outro objeto na MIB.

Aceita alguns tipos específicos de aplicação:
IpAddress: OCTET STRING com 4 bytes.
Counter: Inteiro 32 bits.
Gauge: Inteiro 32 bits.
TimeTicks: Inteiro 32 bits (1/100 de segundo).

Campo ACCESS:
Define a acessibilidade do objeto.

read only: Somente leitura.
read-write: Leitura e escrita.

write-only: Somente escrita, senha do equipamento, por exemplo.
not-accessible: Não acessível, campo para operações internas, por exemplo.

Campo STATUS
Situação do objeto na MIB.
Mandatory: Devem ser implementados por todos os agentes, os valores contidos devem ser válidos.
Optional: Pode ou não ser implementado.
Deprecated: Foi substituido por novo objeto, mas ainda é válido, se tornará obsoleto mais tarde.
Obsolete: Não deve ser considerado.

Mensagem SNMP
Limitada a 484 bytes

As PDUs SNMP
Protocol Data Unit – Unidade de Dados de Protocolo 

Toda operação gera uma resposta, com excessão do Trap. Os dados das operações são transportados na porta 161 UDP/IP, enquanto os traps são transportados na porta 162 UDP/IP.


Estrutura das PDUs SNMP

Preâmbulo e Cabeçalho
Versão:
0: SNMPv1
1: SNMPv2c
2: SNMPv2u/SNMPv2p
3: SNMPv3

Tipo de PDU:
0: getRequest
1: getNextRequest
2: getResponse
3: setRequest
4: trap

Request ID:
Valor númerico usado para fazer referência a pedidos e respostas.

Códigos de erro (Error Status):
0: noError: Sucesso na operação.
1: tooBig: Resposta muito grande.
2: noSuchName: OID não suportado pelo agente.
3: badvalue: Valor incorreto para operação set.
4: readOnly: Tentativa de escrita inválida.
5: genErr: Erro não relacionado ao protocolo.

Error index:
Indica qual variável listada na PDU causou o erro.

A Arquitetura SNMP

Operações/Mensagens SNMP
Get-Request: Recupera o valor de informações de gerenciamento.

Get-Next-Request: Recupera o valor de informações de gerenciamento existentes após um determinado identificador; pega o valor da próxima variável.

Get-Bulk-Request: Estende a funcionalidade da função Get-Next. Traz um bloco de informações (Tabela) de cada vez.

Set-Request: Modifica o valor de informações de gerenciamento.

TRAP: Informa um evento ocorrido no sistema gerenciado.

Inform-Request: Fornece uma informação de gerenciamento não solicitada, usado entre gerentes, porém diferentemente do Trap no caso do Inform-Request existe a confirmação do recebimento da mensagem.

Exemplo de Operação:

Limitações de SNMP
Falta de segurança:
Esquema de autenticação trivial.
Limitações no uso do método SET.

Ineficiência:
Esquema de eventos limitado e fixo.
Operação baseada em pooling.
Comandos transportam poucos dados.

Falta de funções específicas:
MIB com estrutura fixa.
Falta de comandos de controle.
Falta de comunicação entre gerenciadores.

Não confiável:
Baseado em UDP/IP.
Traps sem reconhecimento.

Vulnerabilidade SNMP - Proteção:
Aplicar patchs fornecidos pelo fabricante;
Utilizar aplicações SNMP somente onde seja necessário;
Filtrar o acesso aos dispositivos gerenciados, permitindo somente o tráfego a partir de seus próprios servidores de gerenciamento;
Alterar o nome padrão das comunidades;
Isolar o tráfrego de gerência em uma rede específica, uma VLAN por exemplo, etc...

Versões SNMP:

• SNMP v1
• SNMP v2
• SNMP v3

SNMP V1
Características e Operações Básicas:
Get: Usado pelo NMS (Network Management System – Sistema de Gerenciamento de Redes) para adquirir o valor de uma ou mais instâncias de um objeto de um agente;
GetNext: Usado pelo NMS para adquirir o valor do próximo objeto em uma tabela ou lista;
Set: Usado pelo NMS para atribuir um valor a um objeto no agente.

SNMP V2
Durante a “divergência” SNMPv2, foram definidos quatro variações:
O SNMPv2 original: SNMPv2p; Com o "p" referindo-se a "party-based“ security;
SNMPv2 baseado na comunidade: SNMPv2c;
SNMPv2 baseada no usuário: SNMPv2u;
“SNMPv2 Estrela”: SNMPv2*; Combina elementos de SNMPv2p e SNMPv2u. Isso nunca foi formalmente padronizado. Sim, isso é um asterisco no nome.

Destes, os três primeiros foram documentados em conjuntos de padrões SNMP RFC Standard, o quarto não foi.
A estrutura do formato de mensagem global para cada variante é discutido em um padrão administrativo ou de segurança para a variação em questão, que faz referência à norma SNMPv2 compartilhada para o formato de PDU (RFC 1905).

SNMP V2 (v2c)
Características e Operações adicionais:
Trap: Mensagem não solicitada, enviada por um agente para informar ao NMS sobre um evento significante;
GetBulk: Usado pelo NMS para adquirir eficientemente grandes blocos de dados;
Inform: Permite que um NMS envie traps para outro NMS e receba respostas desses traps.

SNMP V3
Melhorias de Segurança:
USM: User-based Security Model (Modelo de Segurança Baseada em Usuários);
VACM: View-based Access Control Model (Modelo de controle de acesso baseado em visões);
Configuração dinâmica de agentes SNMP utilizando comandos SNMP.

Modelo de Segurança SNMP
Modelo mais comum: SNMP V2c.
Baseado no conceito de “comunidade”.
Cada dispositivo implementa uma ou mais comunidades.
Comunidade default: “public” para leitura e “private” para gravação.


Uma comunidade define:
Método para autenticar o acesso (senha), a visibilidade da MIB e o privilégios de acesso à MIB.

Serviço de autenticação:
Todas as mensagens SNMP são autenticadas, o nome da comunidade serve como senha, porém esse é um sistema de segurança frágil e limitado; Não permite a operação SET em alguns casos.

Alguns dispositivos controlam o acesso usando o nome da comunidade e o número IP do(s) gerente(s) o que eleva um pouco a segurança, mas não resolve o problema.

Traps em SNMP
São mensagens enviadas pelo agente ao gerente, não são respostas a pedidos, ou seja são mensagens não solicitadas, representam eventos anormais.

Classificam-se em:
Genéricos: presentes na MIB padrão.
Específicos: definidos na MIB “enterprises”.

Traps genéricos
ColdStart:
Dispositivo foi ligado;
Configuração local pode ter sido alterada;
Informa ao gerente sobre sua existência.

WarmStart:
Dispositivo foi reinicializado;
Configuração local não foi alterada.

LinkDown:
Link ou porta de comunicação ligado ao nó falhou.

LinkUp:
Link ou porta local foi (re)ativada.

AuthenticationFailure:
O dispositivo recebeu mensagem SNMP não autorizada;
Comunidade não reconhecida;
Número IP de gerente inválido.

EgpNeighborLoss:
Exterior Gateway Protocol falhou no nó;
Normalmente usado em roteadores.

Referências:
Pessoal o material usado como base para a criação destes textos, veio de amigos, listas de distribuição e pesquisas na internet, portanto não possuo referências sobre os mesmos, mas se você identificar algum material de sua autoria, por favor entre em contato que os devidos créditos serão atribuídos.

Instalando o Homebrew Channel no System Menu 4.3 sem precisar de jogos originais

Introdução:
Pessoal saiu um novo método de destravamento para Wii 4.3, que não necessita de jogos originais, e é extremamente simples de executar.
Ele se chama Letterbomb!

Links:
Letterbomb: Instalando o Homebrew Channel no System Menu 4.3 sem precisar de jogos originais.
LetterBomb – Dê nova vida à sua Wii com firmware 4.3

Abraços,
Déo

Formação Zabbix na ICANS

Fonte: ICANS # public DevBlog



Estamos usando o software Zabbix para monitorar a disponibilidade e funcionalidade da nossa infra-estrutura de TI e, especificamente, o bom funcionamento do site PokerStrategy.com. 
Na semana passada, organizamos uma sessão de treinamento em Zabbix com Rihards Olups da Zabbix SIA - a empresa que desenvolve o software e fornece suporte e treinamento. Nós fornecemos a sala de conferências com novos laptops Lenovo T420 e o habitual catering[1] de guloseimas deliciosas da Marie. Ambos, participantes externos e colegas ICANS participaram do workshop, que consistiu de sessões de “Zabbix Certified Specialist” e “Zabbix for Large Environments”. Foi uma semana difícil com muita informação, magia hands-on e exercícios complicados. Mas estávamos todos felizes de estar lá e temos aprendido muito. Mesmo depois de dois anos usando o Zabbix ainda há maneiras de melhorar a nossa configuração.

Eu aproveitei a oportunidade para uma pequena entrevista com Rihards.

Rihards, por favor, apresente-se e ao Zabbix em algumas frases.
Zabbix é uma solução de monitoramento muito flexível e totalmente opensource. Ou melhor, uma ferramenta que traz paz de espírito. Zabbix SIA é uma empresa que está trabalhando no Zabbix, adicionando recursos e melhorando-o de muitas maneiras. SIA não faz parte do nome - é mais ou menos o mesmo que GmbH[2]  na Alemanha. Eu, pessoalmente, juntei-me há dois anos porque eu gosto da abordagem opensource - e eu gosto de trabalhar em coisas que eu gosto. Embora o meu uso do Zabbix remeta a 2001, ano em que foi lançado, eu tenho mais experiência do lado de usuário do que internamente.

Como o Zabbix é diferente de outros softwares de monitoramento?
Comparado com as soluções comerciais, Zabbix não é terrivelmente caro (incluindo o não pagamento para cada dispositivo monitorado). Também é muito mais flexível, em grande parte devido ao acesso fácil e irrestrito a todo o código fonte. Que resulta em uma solução flexível, que muitos ambientes corporativos necessitam desesperadamente. Com todas as fontes disponíveis, não existe o risco de ficar preso a um fornecedor, e não estar preso a um fornecedor oferece uma grande versatilidade e capacidade de monitorar vários ambientes diferentes.

Em geral, Zabbix oferece um pacote completo bastante singular de solução opensource - não há versões “professional” ou “enterprise” ou módulos proprietários que você tem que comprar para realmente usá-lo eficientemente. Há um monte vantagens técnicas, incluindo agentes nativos, módulo de escalonamento flexível, coletor de dados remoto (Zabbix proxy) ... mas para descobrir essas coisas seria melhor uma entrevista mais longa.

Quais são as principais vantagens e desvantagens do Zabbix na sua opinião?
Para mim, pessoalmente ao procurar uma solução de monitoramento as principais vantagens são:

• Pacote de frontend e visualização
• Solução verdadeiramente opensource
• Grande conjunto de recursos que não tem que ser colocados juntos a partir de milhões de peças.[3]

Eu poderia ser um pouco tendencioso quando se fala de grandes desvantagens, embora atualmente eu provavelmente aponte dois pontos:

• Configuração inicial pode ser não-trivial, e aprender os conceitos pode levar algum tempo (embora como um membro da comunidade Zabbix disse, "é uma curva de aprendizagem, mas a vista de cima é excelente")
• Interface de usuário em algumas partes poderiam se beneficiar de melhorias.

Como é que o Zabbix é menos conhecido por administradores de rede do que softwares como o Nagios ou Cacti? Administradores que experimentaram o Zabbix parecem que quase nunca voltam para qualquer outra coisa.
Zabbix nunca foi realmente muito anunciado - foi discretamente desenvolvido e melhorado tecnicamente. Mas, na verdade, ultimamente usuários que escolheram o Zabbix ficaram com ele. Eles também estão sugerindo para os outros, o que o torna mais popular. Um exemplo é o LinuxJournal, onde Zabbix é realmente líder atualmente.
Outra área em que o Zabbix tem crescido com pouca exposição é no segmento empresarial. Há um monte de instalações Zabbix acontecendo silenciosamente.

Você está publicando o Zabbix inteiramente sob uma licença opensource e está vendendo suporte e treinamento. Zabbix é uma outra história de sucesso provando que é possível ganhar dinheiro com software opensource?
Quando Alexei publicou o Zabbix pela primeira vez em 7 de abril em 2001, foi uma verdadeira solução opensource, mas sem quaisquer serviços comerciais disponíveis. Agora há uma empresa saudável e em crescimento, de modo que, provavelmente, se qualifica como uma história de sucesso:)

Você é o autor do livro Zabbix da Packt Publishing. Por que você decidiu escrever um livro sobre Zabbix?
Para ser justo, foi um pouco meio que acidentalmente. Eu tinha uma oferta da Packt, que disse algo ao longo das linhas como "você gostaria de fazer parte do nosso coletivo". Que soou como se haveriam muitos autores e eu só iria escrever um capítulo ou dois, o que parecia sensato - por isso eu aceitei. Depois, eu recebi um pedido para fornecer conteúdo e cronograma para todos os capítulos. Que foi um pouco chocante, mas naquele momento parecia indelicado recusar...

No que mais você está gastando seu tempo, exceto Zabbix?
Ultimamente o Zabbix toma grande parte do meu tempo, às vezes todo ele. Ainda assim, tento dedicar alguns momentos ao OpenStreetMap, um mapa livre e aberto que todos podem editar. É um projeto muito viciante e útil ao mesmo tempo, o que também me deixa mais tempo ao ar livre para coletar dados. Se alguém vê alguma coisa errada ou faltando em www.osm.org, eu gostaria de convidá-los para melhorá-lo:)

Você gosta de sua estadia em Hamburgo?
Certamente. É uma cidade agradável, com uma longa história. Meu hotel também está situado próximo ao Reeperbahn[4]. Ambos Hamburgo e Riga estavam na Liga Hanseática[5], por isso há também um pouco de história comum.

Gostaria de convidar todos os usuários Zabbix a se juntarem a nós na Zabbix Conference e 10 anos de celebração (lembre-se, foi inicialmente lançado em 2001?) Em Riga, Letônia. Isso é muito próximo à Alemanha, e além dos temas centrados em Zabbix há uma chance de visitar Riga e a região vizinha. É claro, aqueles que não estão usando o Zabbix ainda são bem-vindos para descobrir por que ele tem ganhado popularidade e descobrir como o Zabbix poderá ajudá-los a gerenciar seus ambientes. Mais detalhes estão disponíveis nas páginas da Conferência Zabbix.

Obrigado pela entrevista e uma grande, divertida e interessante semana.
 
Christoph Haas
Team Lead System & Network Services
(Inventor do QR code rickrolling)

Notas do Tradutor:
[1] Buffet
[2] Na Alemanha, existem dois tipos de empresas: de capital aberto e fechado.
A sigla "GmbH", o que está escrito após o nome da empresa, designa uma empresa privada como na Alemanha. As letras correspondem às Gesellschaft mit beschränkter Haftung que, traduzido literalmente, significa uma "sociedade de responsabilidade limitada". Empresas GmbH são incorporadas e, como tal, são pessoas jurídicas em si mesmas. Estas empresas devem ter um mínimo de dois sócios e podem ser, mas não tem que ser, de propriedade de uma empresa pública.
Fonte: Investopedia
[3] Não sei por que, mas lembrei do Nagios ;)
[4] A avenida mais famosa de Hamburgo é o centro da vida noturna do bairro boêmio de Sankt Pauli, conhecido no mundo todo pelas vitrines com prostitutas e baladas para todos os estilos musicais.
[5] Liga Hanseática
Tradução Livre