Exibir código-fonte para Gerência de Redes (diário 2011-1)

Endereço encurtado: http://bit.ly/ger20111
=Planejamento=
Planejamento realizado coletivamente e em sala.

==Cenário==
Infraestrutura de rede do IFSC campus São José:
* Espaço dividido entre público e privado para os diversos usuários:
** Técnicos administrativos.
**  Professores.
** Alunos.
** Visitantes.
* Comunicação assíncrona e síncrona (tempo real).
* Espaço para troca de dados em forma de arquivos.
* '''Disponibilidade'''.
* '''Segurança'''.

==Objetivo Geral==
Análise de cenário como objeto de estudo com proposta de melhoria em Telecomunicações como veículo mais eficiente de comunicação.

==Proposta de Trabalho==
Abordagem em camadas, conforme RM-OSI, resgatando conceitos vistos em outras disciplinas do curso:

<center>
{| border="1"
|-
| align="center" colspan="2" | '''Camada''' || align="center" | '''O que analisar''' || align="center" | '''Disciplinas de base''' || align="center" | '''Tecnologias e Padrões envolvidos''' || align="center" | '''Produto final'''
|-
| colspan="2" | Física || Espaço físico;<br>Climatização;<br>Energia elétrica;<br>Conectividade. || [[Projeto de Redes Metálicas e Ópticas]] || [http://www.abntcatalogo.com.br/norma.aspx?ID=993 NBR14565]. || [[#Resultado: plano de ação|Plano de ação]].
|-
| colspan="2" | Enlace || Segmentação da rede física em ''n'' lógicas;<br>Redundância lógica e prevenção em ''software'' de ''loops'';<br>Prioridade para mídias. || [[Redes de Computadores II (página)|Redes de Computadores II]] || Ethernet;<br>802.11;<br>802.1p;<br>802.1q;<br>802.1X;<br>LACP;<br>STP. || [[#Resultado: plano de ação 2|Plano de ação]].
|-
| colspan="2" | Rede || Atual endereçamento e roteamento da rede e transição para IPv6.  || [[Redes de Computadores I (página)|Redes de Computadores I]]<br>[[Redes de Computadores III (página)|Redes de Computadores III]] || IPv4;<br>IPv6. ||[[#Resultado: plano de ação 3|Plano de ação]].
|-
| rowspan="6" | Aplicação || Facilitadores || Automatização nas rotinas e atribuição em rede de endereços e nomes de computadores.|| [[Redes de Computadores I (página)|Redes de Computadores I]] || Syslog;<br>NTP;<br>DHCP. || [[#Resultado: implementação|Implementação em servidor virtualizado]].
|-
| Diretórios || Sistemas em rede para armazenamento de informações organizadas em diretórios.|| [[Redes de Computadores I (página)|Redes de Computadores I]] || DNS;<br>LDAP. ||
|-
| Bancos de Dados || || || ||
|-
| Compartilhamento || || || ||
|-
| Comunicação || || || ||
|-
| Gerência de Rede || || || ||
|}
</center>

==Desenvolvimento das Atividades==

===Ambiente de Teste===
* Máquinas virtuais do Lab. de Redes II.

===Ambiente de Produção===
* [http://ger20111.sj.ifsc.edu.br/arquivos-modelo/etc/ Modelos dos arquivos de configuração] (<tt>/etc</tt>).
* [http://ger20111.sj.ifsc.edu.br/modelo.img Modelo do sistema de arquivos].
* Serviços com redirecionamento de porta: servidor <tt>ger20111.sj.ifsc.edu.br</tt>.
<center>
{| border=1
|-
| align=center rowspan=2 | '''VM''' || align=center rowspan=2 | '''Aluno''' || align=center rowspan=2 | '''No ar?''' || align=center colspan=5 | '''Redirecionamento de Porta'''
|-
| align=center | '''SSH ''' || align=center | '''SMTP ''' || align=center | '''DNS ''' || align=center | '''HTTP ''' || align=center | '''HTTPS'''
|-
| 01 || Anderson Felisbino || align=center | X || 122 || 125 || 153 || [http://ger20111.sj.ifsc.edu.br:180 180] || [https://ger20111.sj.ifsc.edu.br:1443 1443]
|-
| 02 || Eduardo de Mello Garcia ||  align=center | X || 222 || 225 || 253 || [http://ger20111.sj.ifsc.edu.br:280 280] || [https://ger20111.sj.ifsc.edu.br:2443 2443]
|-
| 03 || Christiane Fernandes Dias e Silva ||  align=center | X || 322 || 325 || 353 || [http://ger20111.sj.ifsc.edu.br:380 380] || [https://ger20111.sj.ifsc.edu.br:3443 3443]
|-
| 04 || Felipe Artur Mariano ||  align=center | X || 422 || 425 || 453 || [http://ger20111.sj.ifsc.edu.br:480 480] || [https://ger20111.sj.ifsc.edu.br:4443 4443]
|-
| 05 || Glaucio Bertelli Peres || align=center |  X || 522 || 525 || 553 || [http://ger20111.sj.ifsc.edu.br:580 580] || [https://ger20111.sj.ifsc.edu.br:5443 5443]
|-
| 06 || Guilherme Bilbao Soares da Silva || align=center |  X || 622 || 625 || 653 || [http://ger20111.sj.ifsc.edu.br:680 680] || [https://ger20111.sj.ifsc.edu.br:6443 6443]
|-
| 07 || Jean Cesar Beltrame ||  align=center | X || 722 || 725 || 753 || [http://ger20111.sj.ifsc.edu.br:780 780] || [https://ger20111.sj.ifsc.edu.br:7443 7443]
|-
| 08 || Michel Fernandes de Lucena || align=center |  X || 822 || 825 || 853 || [http://ger20111.sj.ifsc.edu.br:880 880] || [https://ger20111.sj.ifsc.edu.br:8443 8443]
|-
| 09 || Paulo Sergio Alves || || 922 || 925 || 953 || [http://ger20111.sj.ifsc.edu.br:980 980] || [https://ger20111.sj.ifsc.edu.br:9443 9443]
|-
| 10 || Paulo Vitor de Almeida || align=center |  X || 1022 || 1025 || 1053 || [http://ger20111.sj.ifsc.edu.br:1080 1080] || [https://ger20111.sj.ifsc.edu.br:10443 10443]
|-
| 11 || Roicenir Girardi Rostirolla || align=center |  X || 1122 || 1125 || 1153 || [http://ger20111.sj.ifsc.edu.br:1180 1180] || [https://ger20111.sj.ifsc.edu.br:11443 11443]
|-
| 12 || Zilmar de Souza Junior || align=center |  X || 1222 || 1225 || 1253 || [http://ger20111.sj.ifsc.edu.br:1280 1280] || [https://ger20111.sj.ifsc.edu.br:12443 12443]
|-
| 13 || Liamari de Araujo || align=center |  X || 1322 || 1325 || 1353 || [http://ger20111.sj.ifsc.edu.br:1380 1380] || [https://ger20111.sj.ifsc.edu.br:13443 13443]
|-
| 14 || Regiane Paiter || align=center |  X || 1422 || 1425 || 1453 || [http://ger20111.sj.ifsc.edu.br:1480 1480] || [https://ger20111.sj.ifsc.edu.br:14443 14443]
|-
|}
</center>

==Método de Avaliação==
([[#Resultado: implementação|Facilitadores]]) * 1 +<br>
([[#Resultado: implementação|Facilitadores]] + Diretórios + Bancos de Dados) * 2 +<br>
([[#Resultado: implementação|Facilitadores]] + Diretórios + Bancos de Dados + Compartilhamento + Comunicação) * 3 +<br>
[[#Projeto Final|Projeto final]] * 4 =<br>
Somatório / 10 =<br>
Conceito Final (CF):
* Se CF < 6 então D.
* Se CF >= 6 e CF < 7,5 então C.
* Se CF >= 7,5 e CF < 9 então B.
* Se CF >= 9 então A.

==Ver Também==
* [http://wiki.softwarelivre.org/TWikiBar/WebHome Papos de Botequim]: livro do Júlio Neves sobre ''shell script'', com destaque ao bash.
* [http://www.shellscript.com.br/ Livro ''Shell Script'' Profissional]: livro do Aurélio Marinho Vargas, segundo ele "complementar ao livro (...) do Júlio".
* [http://www.guiafoca.org/ Guia Foca Linux]: material de referência do Gleydson baseado em Debian GNU/Linux.

=Aulas=

==24/02 - 03/03: Camada Física==
* 24/02: Discussão do tema, destacando as seções do cabeamento estruturado no cenário de estudo:
** Entrada de facilidades, cabeamento vertical e cabeamento horizontal: apenas passivos de rede e cabeamento rígido. Não requer climatização ou energização dos componentes.
** Armário principal e armário de telecom: passivos e ativos de rede, requendo obrigatoriamente climatização, energização e controle de acesso físico ao espaço.

* 01/03: Divisão do trabalho em pequenas equipes, para entrega parcial na próxima aula.
<center>
{| border="1"
|-
| align=center| '''Atividade''' || align=center|'''Responsável''' || align=center|'''Facilidades'''
|- 
| Verificar documentação dos pontos de rede. || Christiane e Eduardo || Identificação já realizada pelo Rafael (COINF).
|-
| Identificar pontos de rede sem fio e qualidade do sinal. || Michael e Liamari ||
|- 
| Identificar os ativos de rede para centralizá-los. || Anderson e Paulo Sérgio || 
|-
| Dimensionar demanda de pontos de rede. || Zilmar e Glaucio || Consultar Humberto (COINF).
|-
| Analisar a infraestrutura dos espaços que irão receber os armários. || Paulo Vitor e Roicenir || 
|-
| Lançamento de novos cabos: cálculo aproximado de material necessário. || Felipe,  Guilherme e Jean || 
|-
| Elaboração do documento final do plano de ação. || Regiane || 
|-
|}
</center>
Foi demandado ao professor a planta baixa do prédio, laboratório para confecção de material, acesso físico aos armários e levantamentos já realizados pela equipe da [[Portal da Coordenadoria de Informática|COINF]].
* 03/03: Apresentação do produto parcialmente realizado, resgatando a discussão da rede sem fio e localização dos ativos de rede nos espaços adequados.

===Resultado: plano de ação===
Documento sob [https://tele.sj.ifsc.edu.br/arquivos/tele/GER-2011.1/Fisica.doc análise dos professores] (acesso restrito), o qual contém:
# Análise de planta baixa do projeto original e expansões.
## Projeto elétrico, de preferência circuitos redundantes.  '''[Disponibilidade]'''
## Cabeamento estruturado e seções.
### Entrada de facilidades: passivos de rede.
### Armário principal: passivos e ativos de rede. Requer cuidados quanto a energização e climatização dos ativos. '''[Segurança]'''
### Cabeamento vertical: passivos de rede.
### Armário de telecom: passivos e, no caso particular do IFSC, ativos de rede. Requer cuidados quanto a energização e climatização dos ativos. '''[Segurança]'''
### Cabeamento horizontal: passivos de rede.
### Área de trabalho: passivos e ativos de rede (terminais).  Pode requerer cuidados quanto a energização e climatização dos ativos.
# Manutenção
## Bandejas e dispositivos de suporte do cabeamento.
## Organização física dos cabeamentos rígido (não visível) e flexível (visível).
## Padrão global de identificação de cabos e de pontos.
### Identificação de cabos.
### Identificação de pontos.
#### Áreas de cobertura das redes sem fio.
##### Sobreposição das áreas com canais/frequências distintas. '''[Disponibilidade]'''
## Posicionamentos dos ativos nos armários.
### Conexões cruzadas aos pares, viabilizando canais físicos alternativos. '''[Disponibilidade]'''
## Mapeamento da demanda reprimida de pontos.
### Cálculo de material para lançamento de novos cabos e instalação de novos pontos.
### Verificação de espaços vagos nos armários e possível remanejamento de pontos.

==10/03 - 15/03: Camada de Enlace==
* 10/03: discussão sobre as tecnologias envolvidas na Camada de Enlace, com foco na identificação dos usuários e isolamento das redes lógicas, sejam essas com ou sem fio. Já aparecem as primeiras relações entre as camadas. Além disso, as tecnologias definiram sub-redes lógicas com características próprias:
** Espaços privados:
*** Armários e sala de servidores: sub-rede lógica própria. Todos os servidores devem implementar LACP para aumento de banda com balanceamento de carga e redundância. Entre os ativos de rede, em particular ''switches'', deve-se implementar LACP e STP para prevenção e recuperação automatizada de falhas.
*** Salas administrativas: identificação do usuário por porta no ''switch'' para associá-lo a uma das sub-redes: técnico e professor.
** Espaços públicos:
*** De ensino: identificação do usuário por porta no ''switch'' para associá-lo a uma das sub-redes: professor e aluno.
*** De uso comum: identificação do usuário por autenticação (802.1x) para uma das sub-redes: técnico, professor, aluno e visitante.

<center><graphviz>
digraph Rede
{

subgraph clusterFísica
{
label="Física"

"Entrada de facilidades" [shape=Mrecord]
"Armário principal" [shape=Mrecord]
"Cabeamento vertical" [shape=Mrecord]
"Armário de telecom" [shape=Mrecord]
"Cabeamento horizontal" [shape=Mrecord]
"Área de trabalho" [shape=Mrecord]

"Entrada de facilidades" -> "Armário principal"
"Armário principal" -> "Cabeamento vertical"
"Cabeamento vertical" -> "Armário de telecom"
"Armário de telecom" -> "Cabeamento horizontal"
"Cabeamento horizontal" -> "Área de trabalho"
}

subgraph clusterEnlace
{
label="Enlace"
"Ethernet" [shape=Mrecord]
"802.11" [shape=Mrecord]
"802.1p" [shape=Mrecord]
"802.1q" [shape=Mrecord]
LACP [shape=Mrecord]
"802.1D" [shape=Mrecord]
"802.1x" [shape=Mrecord]

"802.1q" -> "802.1p"
"802.1x" -> "802.1q" [label="por usuário"]
"802.11" -> "802.1x"
"Ethernet" -> LACP
LACP -> "802.1q"
"Ethernet" -> "802.1x"
"802.1q" -> "802.1D" [label="MSTP"]
}

"Pares de cabos + canais distintos" [shape=plaintext,fontcolor=red]
"Cabeamento vertical" -> "Pares de cabos + canais distintos" [color=red]
"Cabeamento horizontal" -> "Pares de cabos + canais distintos" [color=red]
"Pares de cabos + canais distintos" -> "LACP" [color=red]
"Pares de cabos + canais distintos" -> "802.1D" [color=red]

"Identificação dos cabos e pontos" [shape=plaintext,fontcolor=red]
"Armário principal" -> "Identificação dos cabos e pontos" [color=red]
"Armário de telecom" -> "Identificação dos cabos e pontos"  [color=red]
"Área de trabalho" -> "Identificação dos cabos e pontos"  [color=red]
"Identificação dos cabos e pontos" -> "802.1q" [color=red,fontcolor=red,label="por porta"]

"Ativos de rede" [shape=plaintext,fontcolor=blue]
"Armário principal" -> "Ativos de rede" [color=blue]
"Armário de telecom" -> "Ativos de rede" [color=blue]
"Ativos de rede" -> "802.1D" [color=blue]
"Ativos de rede" -> LACP [color=blue]
"Ativos de rede" -> "802.1x" [color=blue]
"Ativos de rede" -> "802.1q" [color=blue]
"Ativos de rede" -> "802.1p" [color=blue]

"Armário principal" -> LACP [color=green,fontcolor=green,label="Servidores"]
}
</graphviz></center>


===Resultado: plano de ação===
# 802.1q: segmentação da rede.
## VLAN administrativa: 1.
## ''Guest VLAN'': uso temporário, durante o processo de autenticação.
## Padrões de numeração de acordo com o usuário.
# 802.1p: marcação de pacote para qualidade de serviço.
## Altíssima prioridade: VLAN de mídia (VoIP/vídeo).
## Prioridade regular: demais VLANs.
# 802.11: implementação de rede sem fio única (mesmo SSID).
## Em áreas de sobreposição de sinal, adotar alternância dos canais limítrofes(1-6-11).
## Criptografia WPA2-AES.
# AAA: Radius.
## Autenticação centralizada em base de usuários única.
### 802.1x: EAP-TTLS.
## Autorização baseada na VLAN.
## Auditoria de tráfego externo.
# LACP: balanceamento de carga com redundância de enlace.
# MSTP: Prevenção de ''loops''.
## Definição da hirarquia dos ''switches''.

==17/03 - 22/03: Camada de Rede==
* 17/03: rápida discussão sobre o uso de IPv4 e IPv6 na instituição - devido a apresentação dos pré-projetos do atual TCC II.
* 22/03: proposto o modelo de [http://en.wikipedia.org/wiki/DMZ_(computing)#Dual_firewalls dois firewalls] para criar duas categorias de rede.
===Resultado: plano de ação===
** Lan interna com apenas os serviços locais para clientes exclusivamente internos. Trabalhará apenas com IPs internos: faixa <tt>172.16.0.0/12</tt>.
** DMZ com os serviços de clientes internos e externos. Usará IPs externos da faixa da RNP: <tt>200.135.37.64/26</tt>.
** BDs e Diretórios: rede de acesso controlado, onde apenas os servidores terão acesso aos serviços de diretório e de bancos de dados, ambos utilizados por máquinas da LAN interna e da DMZ.

<center><graphviz>
graph Rede
{
splines=true
rankdir=LR

Internet [shape=plaintext]
FW1 [shape=Mrecord,label="1o. Firewall",style=filled, fillcolor="#FFFF66"]
DMZ [shape=record,label="<0>DMZ|<1>HTTP|<2>DNS|<3>SIP"]
FW2 [shape=Mrecord,label="2o. Firewall",style=filled, fillcolor="#FF6666"]
BD [shape=record,label="<0>BDs e Diretórios|<1>LDAP|<2>SQL"]
LAN [shape=record,label="<0>LAN interna|<1>DHCP|<2>SMB|<3>CUPS|<4>RADIUS"]

Internet -- FW1 [color=blue]
FW1 -- DMZ:0 [color=blue]
FW1 -- FW2 [color=blue]
FW2 -- BD:0 [color=blue]
FW2 -- LAN:0 [color=blue]
}
</graphviz></center>

==24/03 - 31/03: Camada de Aplicação: Facilitadores==
* 24/03: antes de começar a falar sobre serviços propriamente, foram revistos alguns conceitos de '''sistemas operacionais''' - alguns com [http://cm.bell-labs.com/cm/cs/who/dmr/cacm.pdf mais de 30 anos] e ainda em uso. Depois, focou-se em processos especiais, os ''daemons'', e sua aplicação nos serviços locais e de rede. Particularmente, três tipos serviços foram comentados (e serão vistos em detalhes na próxima aula):
** Rotinas: várias ações podem e devem ser automatizadas em ambientes complexos como sistemas operacionais (multiusuário, multiprocesso e multidados). Portanto, uma condição essencial para o funcionamento desses sistemas modernos são as tarefas periódicas automatizadas: manutenção, atualização, reciclagem, etc.. Uma implementação nos sistemas UNIX é o [http://en.wikipedia.org/wiki/Cron cron].
** Auditoria: embora ainda seja prematuro usar o termo auditoria em sua plenitude, podemos já entender o sistema multiusuário como um ambiente em que é preciso monitorar o ambiente para evitar sobrecarga e abusos. Uma das soluções para essa demanda é o [http://tools.ietf.org/rfc/rfc5424.txt Syslog].
** Hora certa: agendar tarefas e auditar um sistema são dois exemplos em que a hora certa é condição essencial para o seu bom funcionamento. Historicamente, o protocolo [http://ntp.br/ NTP] tem sido largamente utilizado para sicronizar relógios em rede. Tem-se, portanto, a primeira relação de dependência entre os serviços:


<center><graphviz>
digraph Serviços
{
subgraph clusterRede
{
label="Rede"
NTP [shape=Mrecord]

subgraph clusterSO
{
label="Sistema Operacional"
Cron [shape=Mrecord]
Syslog [shape=Mrecord]
}
}
NTP -> Cron
NTP -> Syslog
}
</graphviz></center>* 29/03: visão mais detalhada dos 3 serviços mencionados na aula anterior, associando pela primeira vez sistemas operacionais e redes de computadores.
* 31/03: visto o protocolo [http://tools.ietf.org/rfc/rfc2131.txt DHCP] e suas [http://www.bind9.net/rfc-dhcp interrelações com outros protocolos]. Atualizada a dependência entre os serviços:

<center><graphviz>
digraph Serviços
{
subgraph clusterRede
{
label="Rede"
DHCP [shape=Mrecord]
NTP [shape=Mrecord]

subgraph clusterSO
{
label="Sistema Operacional"
Cron [shape=Mrecord]
Syslog [shape=Mrecord]
}
}
DHCP -> NTP
NTP -> Cron
NTP -> Syslog
}
</graphviz></center>

===Resultado: implementação===
A primeira tarefa prática da disciplina consiste em implementar, na [[#Ambiente de Produção|máquina virtualizada particular]]:
* Configuração da segunda interface de rede Ethernet para operar no modo ''trunking'', habilitando desde já as VLANs 1 (administrativa) e 100 (''Guest'' VLAN), as quais serão usadas em (futuras) aplicações nesta disciplina.
** Para a VLAN 1, deve-se utilizar a sub-rede <tt>10.0.0.0/28</tt>, seguindo a [[#Ambiente de Produção|mesma ordem de endereçamento]] da primeira interface: primeiro IP para a primeira máquina virtualizada e assim por diante.
* Manter sincronizada a hora certa com o servidor <tt>ger20111.sj.ifsc.edu.br</tt> em regime integral.
* Verificar, periodicamente, se o serviço NTP está rodando. Caso não esteja, deve-se (re)iniciá-lo, gerando em seguida um registro no sistema (''log'') notificando a ação automatizada. Por fim, deve estar disponível, na linha de comandos, um ''script shell'' denominado '''<tt>hora</tt>''' que listará:
** Quantas vezes o relógio foi ajustado no dia corrente;
** Quantas vezes o serviço apresentou problemas e foi (re)iniciado no mês corrente.
Essa tarefa será avaliada '''durante todo o perído entre os dias 10/04/2011 e 20/04/2011'''. Poderão ser realizadas várias inspeções, a fim de comprovar a sua disponibilidade. [[#Método de Avaliação|Saiba qual é o peso dessa tarefa no conceito final]].

==05/04 - 28/04: Camada de Aplicação: Diretórios==
* 05/04: vistos os conceitos básicos de diretórios e aplicados em [http://tools.ietf.org/rfc/rfc1034.txt DNS] como exemplo de serviço de nomes:
** Estrutura de árvore.
** Domínios e zonas.
** Servidores de nomes.
*** Autoridade e delegação de autoridade.
*** Registros.

<center><graphviz>
digraph Serviços
{
subgraph clusterRede
{
label="Rede"
DHCP [shape=Mrecord]
DNS [shape=Mrecord]
NTP [shape=Mrecord]

subgraph clusterSO
{
label="Sistema Operacional"
Cron [shape=Mrecord]
Syslog [shape=Mrecord]
}
}
DHCP -> DNS
DHCP -> NTP
DNS -> NTP
NTP -> Cron
NTP -> Syslog
}
</graphviz></center>

* 07/04: continuação dos trabalhos sobre DNS, destacando os tempos de vida útil dos registros publicados nos domínios e sua replicação/''cache'' nos outros servidores.

* 12/04: devido a [http://www.ifsc.edu.br/index.php?option=com_content&view=article&id=1590:1204--campus-sao-jose-cancela-atividades-da-manha-desta-terca-feira&catid=2:ultimas falha elétrica no campus], não houve aula de laboratório.

* 14/04: introdução a [http://tools.ietf.org/rfc/rfc4511.txt LDAP]: conceitos de árvore e estrutura de diretório, história do X.500, a tríade esquema, árvore de diretórios e acesso (de controle de acesso usando ACLs a consultas).


<center><graphviz>
digraph Serviços
{
subgraph clusterRede
{
label="Rede"
DHCP [shape=Mrecord]
DNS [shape=Mrecord]
NTP [shape=Mrecord]
LDAP [shape=Mrecord]

subgraph clusterSO
{
label="Sistema Operacional"
Cron [shape=Mrecord]
Syslog [shape=Mrecord]
}
}
DHCP -> DNS
DHCP -> NTP
DNS -> NTP
DNS -> LDAP
NTP -> Cron
NTP -> Syslog
}
</graphviz></center>

* 19/04: conversa com [http://buscatextual.cnpq.br/buscatextual/visualizacv.jsp?id=K4751516E2 André Luís Gobbi Sanches] sobre plano de carreira.

* 26/04: visita ao Seminário de Pesquisa, Ensino e Extensão no campus Florianópolis.
* 28/04: vista a árvore de diretórios do IF-SC São José como estudo de caso.

===Atividades Práticas===
* Utilizando a ferramena <tt>dig</tt> ou equivalente, procure pelos valores dos registros <tt>SOA</tt> e <tt>NS</tt> dos seguintes domínios:
** sj.ifsc.edu.br.
** ifsc.edu.br.
** mec.gov.br.
* Realize as mesmas consultas de forma iterativa, iniciando nos servidores raiz (''root servers'').
* Qual é o nome completo dos professores de Tele. Dica: eles pertencem ao grupo (posixGroup) <tt>sj-tele</tt>.
* É possível utilizar o serviço LDAP ao invés de DNS para associar nomes de computadores a endereços IP? Como isso é possível?

==03/05: Camada de Aplicação: Bancos de Dados==
Assim como foi visto que nos serviços de diretórios o conceito de organização dos dados em árvore é muito importante, aqui a organização se dá da seguinte maneira:
# Tem-se as base de dados, grandes coleções de dados;
# Em uma base de dados, há tabelas;
# Em uma tabela, há registros de dados;
# Um registro de dados pode conter uma referência para outro registro em outra tabela.
Tem-se, portanto, [http://en.wikipedia.org/wiki/Relational_model relações entre os dados] armazenados.
<center>
<graphviz>
digraph BD
{
rankdir="LR"

subgraph clusterBD
{
label="Base de Dados"
t1 [shape=Mrecord,label="<0>Tabela 1|<1>registro 1|<2>registro 2|<3>...|<4>registro 3"]
t2 [shape=Mrecord,label="<0>Tabela 2|<1>registro 1|<2>registro 2|<3>...|<4>registro 3"]
t3 [shape=Mrecord,label="<0>Tabela 3|<1>registro 1|<2>registro 2|<3>...|<4>registro 3"]
}

t1:2 -> t2:1 [color=red]
t2:1 -> t3:4 [color=red]
}
</graphviz>
</center>
Além dos dados e suas relações, é importante também outras funcionalidades agregadas, como controle de acesso, registro de ações críticas e outros elementos que formam, ao final, um [http://en.wikipedia.org/wiki/Database_management_system SGBD].

<center><graphviz>
digraph Serviços
{
subgraph clusterRede
{
label="Rede"
DHCP [shape=Mrecord]
DNS [shape=Mrecord]
NTP [shape=Mrecord]
LDAP [shape=Mrecord]
SGBD [shape=Mrecord]

subgraph clusterSO
{
label="Sistema Operacional"
Cron [shape=Mrecord]
Syslog [shape=Mrecord]
}
}
DHCP -> DNS
DHCP -> NTP
DNS -> NTP
DNS -> LDAP
DNS -> SGBD
NTP -> Cron
NTP -> Syslog
}
</graphviz></center>

===Estudo de Caso: MySQL===
A facilidade de implementação e de configuração tornam o [http://www.mysql.org MySQL] bastante atrativo para aplicações de pequeno porte. No nosso [#Ambiente de Produção|ambiente de produção], Debian GNU/Linux 6.0, a instalação do servidor é bastante facilitada:
<syntaxhighlight lang=bash>
aptitude install mysql-server
</syntaxhighlight>
Há vários [http://dev.mysql.com/downloads/gui-tools/ clientes disponíveis], inclusive para CLI:
<syntaxhighlight lang=bash>
aptitude install mysql-client
</syntaxhighlight>
Antes do primeiro acesso, é preciso entender que no MySQL o processo de autenticação se dá pela combinação de três valores:
# Usuário;
# Senha;
# Endereço de máquina ou IP de origem.
Na configuração ''de fábrica'', o super-usuário <tt>root</tt> possui acesso local (<tt>localhost</tt>) com uma senha definida no ato da instalação (comando <tt>aptitude install mysql-server</tt>):
<syntaxhighlight lang=bash>
mysql -h localhost -u root -p
</syntaxhighlight>
Cabe destacar que esse usuário <tt>root</tt> é um usuário interno da aplicação, não havendo qualquer relação ou privilégio compartilhado com o administrador do sistema Linux.

Uma vez autenticado, passa-se à fase de autorização, que verifica e valida quais ações são permitidas para o usuário com a sessão em curso. Como o usuário <tt>root</tt> possui amplos privilégios, esse pode listar todas as base de dados:
<syntaxhighlight lang=mysql>
SHOW DATABASES;
</syntaxhighlight>
ou mesmo as tabelas de uma base em particular. Abaixo, são listadas as tabelas da base <tt>mysql</tt>:
<syntaxhighlight lang=mysql>
USE mysql;
SHOW TABLES;
</syntaxhighlight>
Essa base é de extrema importância, pois ela é utilizada, entre outras coisas, para armazenar os dados de autenticação e autorização ao próprio serviço - atenção às tabelas <tt>mysql.user</tt> e <tt>mysql.db</tt>!
<syntaxhighlight lang=mysql>
USE mysql;
SELECT * FROM user;
SELECT * from db;
</syntaxhighlight>
Para quem já está familizarizado com [http://en.wikipedia.org/wiki/SQL SQL], acima foram apresentados os registros completos das tabelas <tt>mysql.user</tt> e <tt>mysql.db</tt>, respectivamente.

Assim, conclui-se que para criar um usuário ou autorizar um para acesso a banco(s) de dados, basta utilizar comandos SQL para manipular tais tabelas. Também é possível, alternativamente, utilizar comandos específicos para autenticação e autorização:
<syntaxhighlight lang=mysql>
CREATE DATABASE banco;
GRANT ALL PRIVILEGES ON banco.* TO 'joao'@'localhost' IDENTIFIED BY 'codigoSecreto';
FLUSH PRIVILEGES;
</syntaxhighlight>
Acima, em ordem:
# Criação de um banco de dados denominado <tt>banco</tt>.
# Criação de um usuário denominado <tt>joao</tt>, associação a uma senha <tt>codigoSecreto</tt> e autorizado o acesso à base <tt>banco</tt> através do endereço <tt>localhost</tt>.
# Remoção da ''cache'' do banco de dados, acelerando a aplicação de autenticação e autorização mencionados anteriormente.
Essas são, portanto, as funções que competem ao administrador de sistema em relação a um SGBD. A gestão do conteúdo fica a cargo do [http://en.wikipedia.org/wiki/Database_administrator DBA].

==05/05 - 26/05: Camada de Aplicação: Compartilhamento==
* 05/05: instalação e configuração básica de servidor Web. Como estudo de caso foi utilizado o Apache, com [http://news.netcraft.com/archives/2011/05/02/may-2011-web-server-survey.html fatia de mercado global superior a 60%]. É importante compreender o funcionamento e cabeçalho do [http://www.ietf.org/rfc/rfc2616.txt HTTP versão 1.1] para [http://httpd.apache.org/docs/2.2/configuring.html configurar devidamente o serviço]:
** Endereços virtuais (''[http://httpd.apache.org/docs/2.2/vhosts/ virtual hosts]''): uma vez que o cabeçalho HTTP contém o endereço de destino, pode-se criar vários endereços virtuais no Apache, os <tt>VirtualHosts</tt>. Eles operam de forma independente. Além disso, o Apache também pode discriminar o acesso por IP ou mesmo porta de destino, criando espaços distintos.
** Mapeamentos entre sistema de arquivos e URL (''[http://httpd.apache.org/docs/2.2/urlmapping.html URL mapping]''): assim como cada endereço virtual tem seu diretório raiz ([http://httpd.apache.org/docs/2.2/urlmapping.html#documentroot DocumentRoot]), é possível mapear um diretório específico ([http://httpd.apache.org/docs/2.2/urlmapping.html#outside alias]) ou mesmo a diretório pessoal de um usuário ([http://httpd.apache.org/docs/2.2/urlmapping.html#user user]).
** Expansões com módulos ([http://httpd.apache.org/docs/2.2/dso.html DSO]): além das funções internas do servidor Apache, há as expansões para os mais diversos fins: autenticação, SSL, CGI e integração com aplicações em várias linguagens (C, PHP, Python, Java e outras).
* 10/05: Prova-relâmpago
** Duração: 1h
** Tarefa: instalação de blog no [[#Ambiente de Produção|ambiente de produção]].
** Requisitos de serviço (blog):
*** 1 post novo publicado.
*** 1 página nova publicada.
*** 1 arquivo carregado (upload) via ferramenta interna (do blog).
** Requisitos de sistema (S.O.):
*** O banco de dados pode prover acesso somente a um usuário com senha através de rede interna (''loopback'').
*** Controle de acesso: o código PHP deve ter apenas acesso de leitura ao usuário do servidor Web. Quanto aos diretórios onde é permitida a escrita, somente o usuário do servidor Web pode ler e modificá-los.
*** ''Backups'' periódicos (mínimo 2 e máximo 7):
**** Semanal: código PHP.
**** Diário, de: base de dados e arquivos carregados (''uploads'').
* 12/05: instalação de aplicação Web 2.0.
* 17/05: configuração de uma autenticação básica em HTTP.
* 19/05: configuração de transmissão segura com SSL/TLS, a qual foi posteriormente combinada com a autenticação básica.

<center><graphviz>
digraph Serviços
{
subgraph clusterRede
{
label="Rede"
DHCP [shape=Mrecord]
DNS [shape=Mrecord]
NTP [shape=Mrecord]
LDAP [shape=Mrecord]
SGBD [shape=Mrecord]
HTTP [shape=Mrecord,style=filled, fillcolor="#FFFF66"]

subgraph clusterSO
{
label="Sistema Operacional"
Cron [shape=Mrecord]
Syslog [shape=Mrecord]
}
}
DHCP -> DNS
DHCP -> NTP
DNS -> NTP
DNS -> LDAP
DNS -> SGBD
DNS -> HTTP
LDAP -> HTTP
SGBD -> HTTP
NTP -> Cron
NTP -> Syslog
}
</graphviz></center>

* 24/05: apresentação do serviço Samba no modo grupo de trabalho. Uma experiência interessante já foi [[Gerência de Redes de Computadores (técnico) (diário 2010-1)#Atividade-problema|documentada neste wiki]], tratando na integração entre HTTP (Internet) e SMB (LAN).
* 26/05: adequação do serviço Samba para operar no modo domínio.
<center><graphviz>
digraph Serviços
{
subgraph clusterRede
{
label="Rede"
DHCP [shape=Mrecord]
DNS [shape=Mrecord]
NTP [shape=Mrecord]
LDAP [shape=Mrecord]
SGBD [shape=Mrecord]
HTTP [shape=Mrecord,style=filled, fillcolor="#FFFF66"]
SMB [shape=Mrecord,style=filled, fillcolor="#FFFF66"]

subgraph clusterSO
{
label="Sistema Operacional"
Cron [shape=Mrecord]
Syslog [shape=Mrecord]
}
}
DHCP -> DNS
DHCP -> NTP
DNS -> NTP
DNS -> LDAP
DNS -> SGBD
DNS -> HTTP
DNS -> SMB
LDAP -> HTTP
LDAP -> SMB
SGBD -> HTTP
NTP -> Cron
NTP -> Syslog
}
</graphviz></center>

===Estudo de Caso: Joomla===
O [http://www.joomla.org Joomla] é um exemplo de [http://en.wikipedia.org/wiki/Content_Management_System CMS] bastante popular, sendo utilizado inclusive no [http://www.ifsc.edu.br portal do Instituto]. Sua estrutura é bastante semelhante à maioria dos CMSs mais populares: linguagem de programação interpretada e armazenamento das informações em banco de dados.

<center><graphviz>
graph ArqWeb
{
subgraph clusterCliente
{
label=Cliente
Usuário [shape=plaintext]
Navegador [shape=Mrecord]

Usuário -- Navegador
}

subgraph clusterServidor
{
label=Servidor
"Servidor Web" [shape=Mrecord,style=filled, fillcolor="#FFFF66"]
"Interpretador" [shape=Mrecord]
"Banco de Dados" [shape=Mrecord]

"Servidor Web" -- "Interpretador" [label="DHTML",color=red,fontcolor=red]
"Interpretador" -- "Banco de Dados" [label="Conteúdo",color=red,fontcolor=red]
}

Navegador -- "Servidor Web" [label="Conexão HTTP",color=blue,fontcolor=blue]
}
</graphviz></center>

A instalação é realizada em duas etapas: sistema e ambiente Web. No sistema, é preciso criar um banco de dados específico, instalar o suporte à linguagem interpretada [http://php.net PHP] e integrá-los ao servidor Web, no caso o Apache.

Como já há um [[#Estudo de Caso: MySQL|banco de dados instalado]], basta acessá-lo para criar um novo banco com acesso restrito à aplicação Web local:
<syntaxhighlight lang=bash>
mysql -u root -p mysql
</syntaxhighlight>
usando os comandos SQL:
<syntaxhighlight lang=mysql>
CREATE DATABASE joomla;
GRANT ALL PRIVILEGES ON joomla.* TO 'usuario'@localhost IDENTIFIED BY 'senha';
FLUSH PRIVILEGES;
QUIT; 
</syntaxhighlight>

Em seguida, a instalação do PHP, hoje na versão 5, e sua integração ao MySQL e Apache:
<syntaxhighlight lang=bash>
aptitude install php5 php5-mysql
service apache2 restart
</syntaxhighlight>
A própria instalação do PHP se encarrega de ativar o módulo dentro do Apache, o qual também pode ser feito da seguinte forma:
<syntaxhighlight lang=bash>
a2enmod php5
service apache2 restart
</syntaxhighlight>

Por último, a configuração de um ambiente reservado ao Joomla com algumas particularidades:
<syntaxhighlight lang=bash>
vi /etc/apache2/conf.d/joomla.conf
</syntaxhighlight>
O arquivo terá o seguinte conteúdo:
 <Directory /var/www/cms>
    # Sem configuração prévia
    Options None
    # Porém, permite que a aplicação proteja algum diretório
    # com diretivas contidas em arquivo com o nome ".htaccess".
    AllowOverride AuthConfig
    # Controle de acesso por IP: livre
    Order allow,deny
    Allow from all
 </Directory>
Sempre que modificar a configuração do Apache, é preciso no mínimo aplicar esse valores. O comando <tt>reload</tt> mantém as conexões abertas e aplica os novos valores:
<syntaxhighlight lang=bash>
service apache2 reload
</syntaxhighlight>

Por último, o código PHP. No sítio do [http://www.joomla.org/download.html Joomla], a última versão disponível é a 1.6.3. Os passos a seguir descrevem o descarregamento do código até a aplicação de permissões mínimas para operação - considerando que o Apache está rodando com o usuário de sistema <tt>www-data</tt> (comum nos sistemas baseados em [http://www.debian.org Debian]:
<syntaxhighlight lang=bash>
cd /var/www
mkdir cms
cd cms
wget http://joomlacode.org/gf/download/frsrelease/14659/64120/Joomla_1.6.3-Stable-Full_Package.zip
unzip Joomla_1.6.3-Stable-Full_Package.zip
rm Joomla_1.6.3-Stable-Full_Package.zip
chown -R www-data:www-data .
find . -type d -exec chmod 500 {} \;
find . -type f -exec chmod 400 {} \;
touch configuration.php
chmod 600 configuration.php
chmod 700 logs
chmod 700 tmp
</syntaxhighlight>
O restante da configuração segue em ambiente Web: <nowiki>http://<servidor>/cms</nowiki>.

===Cenário: Autenticação básica sobre SSL/TLS===
A RFC 2617 define a autenticação básica e ''digest'' para sessões HTTP. Contudo, como ela ocorre com texto puro, ''ipsis literis'', é preciso proteger tal tráfego. Assim, faz-se necessário utilizar outra porta com transmissão segura via SSL/TLS: HTTPS (443/TCP).

No servidor Web apache 2, a autenticação se dá por diretório mapeado (DocumentRoot, Directory) ou por URL (Location). Abaixo um exemplo do diretório <tt>/home/documentos</tt>, criado e compartilhado sob autenticação básica. Nos sistemas baseados em Debian, o dono do processo-serviço é <tt>www-data</tt> e grupo com mesmo nome.

Primeiro, a criação do diretório:
<syntaxhighlight lang=bash>
cd /home
mkdir documentos
chmod 700 documentos
chown www-data:www-data documentos
</syntaxhighlight>

Em seguida, o compartilhamento com autenticação básica. O módulo de autenticação já vem ativado - e pode ser confirmado com: <tt>apache2ctl -M</tt>.
<syntaxhighlight lang=bash>
cd /etc/apache2/conf.d/
vi documentos
</syntaxhighlight>
O arquivo conterá o seguinte conteúdo:
 <Directory /home/documentos/>
    Options Indexes
    AllowOverride None
    Order allow,deny
    Allow from all
    AuthType Basic
    AuthName "Acesso restrito"
    AuthUserFile /etc/apache2/htpasswd-senhas
    Require valid-user
 </Directory>
O arquivo de senhas informando acima, <tt>/etc/apache2/htpasswd-senhas</tt>, pode ser criado com a ferramenta <tt>htpasswd</tt>:
<syntaxhighlight lang=bash>
htpasswd -c -m /etc/apache2/htpasswd-senhas <usuário>
</syntaxhighlight>
Depois deve-se, pois, proteger esse arquivo:
<syntaxhighlight lang=bash>
chmod 640 /etc/apache2/htpasswd-senhas
chown root:www-data /etc/apache2/htpasswd-senhas
</syntaxhighlight>
Após reiniciar o serviço Apache 2, o diretório será visível via HTTP somente com o par <usuário>:<senha>.

Agora, a segunda etapa do processo: a autenticação somente com SSL/TLS. Outro facilitador, <tt>a2ensite</tt> pode ser usado para ativar o ''site'' com SSL:
<syntaxhighlight lang=bash>
a2ensite default-ssl
</syntaxhighlight>
Após, cria-se o certificado personalizado e autoassinado (validade: 4 anos) e informado na configuração do Apache 2:
<syntaxhighlight lang=bash>
openssl req -new -x509 -days 1460 -nodes -out /etc/ssl/certs/apache2.pem -keyout /etc/ssl/certs/apache2.pem
chown root:www-data /etc/ssl/certs/apache2.pem
chmod 640 /etc/ssl/certs/apache2.pem
vi /etc/apache2/sites-enabled/default-ssl
</syntaxhighlight>
e modificando somentes as linhas:
 SLCertificateFile /etc/ssl/certs/apache2.pem
 SSLCertificateKeyFile /etc/ssl/certs/apache2.pem
Por fim, ativa-se o módulo ssl:
<syntaxhighlight lang=bash>
a2enmod ssl
</syntaxhighlight>
e força o usuário, quando for utilizar HTTP para acessar tal diretório, a ser encaminhado para HTTPS:
<syntaxhighlight lang=bash>
vi /etc/apache2/sites-enabled/000-default
</syntaxhighlight>
adicionando a seguinte linha dentro do escopo <tt><nowiki><VirtualHost></nowiki></tt>:
 RedirectMatch ^/documentos(.*)$ https://<servidor>/$1
onde <tt>servidor</tt> é nome completo (FQDN) do servidor Web. Para terminar, resta apenas reiniciar o serviço:
<syntaxhighlight lang=bash>
service apache2 restart
</syntaxhighlight>

==31/05 - 09/06: Camada de Aplicação: Comunicação==
* 31/05: visto, em sala de aula, os protocolos SMTP para envio de ''emails'' e POP3 e IMAP para recebimento.
* 02/06: atividade em laboratório, envolvendo os protocolos SMTP e IMAP para envio e recebimento de ''emails'' utilizando aplicativos específicos (Outlook, Thunderbird, Evolution e outros) e ''webmail'' (adotado o aplicativo [http://roundcube.net/ Roundcube] por questões didáticas). A atividade envolverá:
** NTP: para compor a hora certa no cabeçalho SMTP, HTTP e outros;
** DNS: para comunicação interdomínio.
** SGBD: para armazenamento de dados do usuário.
** SMTP: para envio dos ''emails''.
** POP3 ou IMAP: para recebimento e leitura dos emails, seja em aplicativo específico ou ''webmail''.
** HTTP: para veiculação do ''webmail''.

<center><graphviz>
digraph Serviços
{
subgraph clusterRede
{
label="Rede"
DHCP [shape=Mrecord]
DNS [shape=Mrecord]
NTP [shape=Mrecord]
LDAP [shape=Mrecord]
SGBD [shape=Mrecord]
HTTP [shape=Mrecord,style=filled, fillcolor="#FFFF66"]
SMB [shape=Mrecord,style=filled, fillcolor="#FFFF66"]
SMTP [shape=Mrecord]
IMAP [shape=Mrecord]
Webmail [shape=Mrecord,style=filled,fillcolor="#66FF66"]

subgraph clusterSO
{
label="Sistema Operacional"
Cron [shape=Mrecord]
Syslog [shape=Mrecord]
}
}
DHCP -> DNS
DHCP -> NTP
DNS -> NTP
DNS -> LDAP
DNS -> SGBD
DNS -> HTTP
DNS -> SMB
DNS -> SMTP
DNS -> IMAP
LDAP -> HTTP
LDAP -> SMB
LDAP -> SMTP
LDAP -> IMAP
SGBD -> HTTP
SGBD -> Webmail
HTTP -> Webmail
SMTP -> Webmail
IMAP -> Webmail
NTP -> Cron
NTP -> Syslog
}
</graphviz></center>
* 09/06: Prova.
*# Genérico: Crie o domínio <sobrenome>.com.br, onde o servidor principal, além de deter a autoridade sobre o domínio, ainda deverá fazer referência (nome, A, ou apelido, CNAME) aos seus serviços disponibilizados: NTP, SMB, HTTP, SMTP e IMAP.
*# Sistema: Crie usuários de A a M.
*# SMB: Compartilhe o diretório /home/arquivos para os usuários que são vogais. Somente eles podem ter acesso de leitura ou de escrita ao conteúdo.
*# SMB: Compartilhe o diretório /var/www/sites com permissão de leitura+escrita para os usuários de F a M e apenas permissão de leitura para A e B.
*# SMB: Compartilhe o diretório /opt com permissão apenas de leitura para todos os usuários, de A a M.
*# HTTP: compartilhe o diretório /home com permissão de leitura aos usuários de B a F.
*# HTTP: compartilhe o diretório /var/www/arquivos com permissão de leitura e de escrita para todos os usuários (A a M).
*# Publique um serviço de Webmail funcional. Teste-o com o envio local. Não pode ser o serviço Roundcube.
*# Sistema: monitore periodicamente o sistema em busca de arquivos com as seguintes extensões: MP3 e AVI. Liste-os e envie por email ao usuário root e apague-os em seguida.
*# Sistema: monitore periodicamente o espaço em disco nas partições. Caso exceda o limite de 90% de ocupação, envie um email ao usuário root notificando-o.
*# Sistema: monitore periodicamente os diretórios compartilhados em SMB e HTTP por arquivos com as extensões COM e PIF, a fim de identificar algum vírus em potencial. Se achar algum arquivo, mova-os para um diretório de quarentena e avise o usuário root sobre os mesmos para análise posterior.

==14/06 - 28/06: Camada de Aplicação: Gerência da Rede==
* 14/06: apresentação das 5 gerências de rede: Monitoramento, Contabilização, Desempenho, Configuração e Segurança. Foi dada ênfase ao protocolo SNMP para Monitoramento e Contabilização - veja publicação da RNP [http://www.rnp.br/newsgen/9708/n3-2.html 1] e [http://www.rnp.br/newsgen/9712/gerencia.html 2].
* 16/06: instalação de agente e gerente SNMP para primeiras avaliações do protocolo para monitoramento e contabilização do ambiente de rede.

===Cenário: Agente e Gerente SNMP em ambiente Linux===
O sistema utilizado é o Debian GNU/Linux 6.0. Algumas modificações foram feitas por questões legais - licenciamento dos documentos, mais especificamente as MIBs (''Management Information Base'').

====Agente====
No caso do agente, como esse é bastante simples - fazendo jus ao nome do protocolo - deve-se instalar o pacote e depois configurá-lo:
<syntaxhighlight lang=bash>
apt-get install snmpd
vi /etc/snmp/snmpd.conf
</syntaxhighlight>
Uma configuração bastante sucinta deve conter:
* Comunidade: tipo de acesso (leitura ou leitura+escrita) e nome da comunidade;
* Localização do equipamento: endereço o mais descritivo possível;
* Responsável: nome e formas de contato;
* Funcionalidades: em que camadas o sistema opera.
A seguinte configuração:
 rocommunity ger
 sysLocation Laboratório de Redes de Computadores II - IFSC campus São José
 SysContact "Ederson Torresini" <etorresini@ifsc.edu.br>
 sysServices 72
indica um agente da comunidade <tt>ger</tt> com permissão única de leitura a todos os atributos (<tt>rocommunity</tt>), localizado no Lab. de Redes II (<tt>SysLocation</tt>), aos cuidados do prof. Ederson (<tt>sysContact</tt>) e que opera em todas as camadas do modelo TCP/IP (<tt>sysServices</tt>).
Feito isso, basta reiniciar o serviço:
<syntaxhighlight lang=bash>
/etc/init.d/snmpd restart
</syntaxhighlight>

====Gerente====
Para o gerente, é extremamente interessante possuir localmente as MIBs e os comandos básicos (CLI), a fim de testar os atributos (localização, tipo e faixa de valores possíveis). Nesse caso, deve-se instalar ambos os pacotes, o primeiro com os comandos e o seguindo o qual descarrega e atualiza as MIBs a partir da Internet:
<syntaxhighlight lang=bash>
apt-get install snmp
apt-get install snmp-mibs-downloader
download-mibs
</syntaxhighlight>
Em seguida, deve-se remover a referência no arquivo de configuração <tt>/etc/snmp/snmp.conf</tt> para fazer pleno uso das MIBs inclusive em linha de comando, conforme a [http://wiki.debian.org/SNMP Wiki do Debian]:
<syntaxhighlight lang=bash>
sed -i 's/^mibs ://g' /etc/snmp/snmp.conf
</syntaxhighlight>

Assim, será possível realizar ações em linha de comando, como por exemplo operações GET:
<syntaxhighlight lang=bash>
snmpget -c ger -v 2c localhost sysLocation.0
snmpget -c ger -v 2c localhost sysContact.0
snmpget -c ger -v 2c localhost sysServices.0
</syntaxhighlight>
Ou mesmo uma varredura em toda a árvore de atributos, utilizando para tal a operação GETNEXT (sequencial):
<syntaxhighlight lang=bash>
snmpwalk -c ger -v 2c localhost .1
</syntaxhighlight>

O próximo passo é escolher um gerente SNMP que atenda às necessidades. Em código aberto, há disponíveis:
* [http://cacti.net Cacti];
* [http://www.opennms.org OpenNMS];
* [http://www.nagios.org/ Nagios];
* [http://www.zabbix.com/ Zabbix];
* [http://www.zenoss.com/ Zenoss].
Por questões didáticas, e pela facilidade de administração (Web), adotaremos o Cacti, cuja [http://www.cacti.net/downloads/docs/html/unix_configure_cacti.html documentação] é bem objetiva e funcional. Uma vez o sistema no ar, é possível passar direto para o [http://www.cacti.net/downloads/docs/html/graph_howto.html cadastro dos "alvos"] e listar [http://www.cacti.net/downloads/docs/html/new_graphs.html quais informações] serão coletadas periodicamente.

Caso o erro "[NOT FOUND] RRDTool Binary Path: The path to the rrdtool binary." apareça durante a configuração do Cacti execute:
<syntaxhighlight lang=bash>
apt-get install libdbi0 librrd4
</syntaxhighlight>

===Cenário: Gerente de Monitoramento baseado em ''Shell Script''===
Para entender a primeira gerência, de monitoramento, construa um ''shell script'' que realiza sequencialmente as seguintes operações:
# Leitura, por linha de comando, de um alvo por nome ou endereço IP.
# Teste do próprio gerente:
## Camada de física/enlace: interface Ethernet ativa (''up'').
## Camada de rede: endereçamento IP e rota-padrão.
## Camada de transporte e de aplicação: ''download''.
# Uma vez garantida a conectividade do gerente, parte-se para o "alvo". Primeiramente, teste de alcançabilidade (camada de rede) com ICMP. Em seguida, parte-se para as aplicações: o programa deverá testar, além do serviço no ar (porta aberta), também a sua eficiência: o serviço deve operar normalmente:
## DNS: serviço rodando e pelo menos 3 consultas a registros com resposta válida (<tt>SOA</tt>, <tt>NS</tt> e <tt>A</tt>).
## SGBD: serviço rodando e consulta (<tt>SELECT</tt>) com pelo menos 1 registro.
## LDAP: serviço rodando e consulta (''search'') com pelo menos 1 registro.
## NTP: serviço rodando e sincronização válida de relógio.
## SMB: serviço rodando e listagem dos compartilhamentos.
## HTTP: serviço rodando e pelo menos 2 arquivos descarregados (integralmente e parcialmente via HTTP/1.1) com sucesso.
## SMTP: serviço rodando e teste de envio de email. Dica: comando <tt>mail</tt> que integra o pacote [http://packages.debian.org/squeeze/mailutils mailutils].
# Ao final, o programa deverá emitir um relatório com a lista de testes realizados com e sem sucesso.
<syntaxhighlight lang=bash>
#!/bin/bash
 

# Variáveis
ETH="eth0"
GOOGLE="74.125.234.84"
 
# Funções
local_enlace(){
	echo -n "Camada de enlace..."
	ifconfig ${1} | grep -q UP
	ENLACE=$(echo $?)
	if [ "${ENLACE}" = "0" ]
	then
		echo " OK."
	else
		echo "Falha geral: camada de enlace."
		# Programa falha no primeiro testo. Retorna "1".
		exit 1
	fi                
} 

local_rede(){
	echo "- Camada de rede:"
	echo -n "  - Endereçamento..."
	IP=""
	IP=$(ifconfig ${1} | grep inet | head -n 1 | cut -d : -f 2 | cut -d B -f 1)
	if [ "${IP}" != "" ]
	then
		echo " OK."
	else
		echo " Falha geral: interface ${ETH}."
		exit 2
	fi
	echo -n "  - Roteamento..."
	ROTA=0
	ROTA=$(route -n | grep -q ^0.0.0.0 && echo 1)
	if [ "${ROTA}" = "1" ]
	then
		echo " OK."
	else
		echo " Falha geral: rota-padrão."
		exit 3
	fi
}

generico_http(){
	echo -n "- HTTP..."
	GET=0
	GET=$(wget http://${1}/ -O - 2>&1 |grep -q "200 OK" && echo 1)
	if [ "${GET}" = "1" ]
	then
		echo " OK."
	else
		echo " Falha geral: requisição HTTP."
		exit 4
	fi
}

alvo_icmp(){
	echo -n "Testando alcançabilidade ao alvo..."
	PORCENTAGEM=$(ping -c 2 ${1} | grep received | cut -d , -f 3 | cut -d % -f 1)
	if [ "${PORCENTAGEM}" -le "50" ]
	then
		echo " OK."
	else
		echo " Falha geral: ICMP (echo request/reply)."
		exit 5
	fi
}

alvo_dns(){
	echo "- Domínio DNS ${dominio}:"
	for registro in SOA NS MX A
	do
		RESPOSTA="0"
		echo -n "  - Registro ${registro}..."
		RESPOSTA=$(dig @${1} ${registro} ${2} | grep -q "ANSWER" && echo 1)
		if [ "${RESPOSTA}" = "1" ]
		then
			echo " OK."
		else
			echo " falhou."
		fi
	done
}


# Programa Principal
#
# Validação da entrada de dados
if [ "${2}" = "" ]
then
	echo "Use: ${0} (nome ou IP do alvo) (domínio)"
	exit 255
fi


# Teste local: enlace, rede e aplicação
echo "Testes locais:"
local_enlace ${ETH}
local_rede ${ETH}
generico_http ${GOOGLE}
#
# Testes no alvo
echo
echo "Testes no alvo:"
alvo_icmp ${1}
alvo_dns ${1} ${2}
generico_http ${1}

# Sugestão: testar as aplicações com netcat :-)

# Programa rodou plenamente com sucesso. Retorna "0".
exit 0
</syntaxhighlight>

=Projeto Final=
Em acordo entre professor e alunos, foi modificado [[#Método de Avaliação|método da avaliação final]] de prova prática para projeto com defesa oral.
==Sobre o cenário==
O projeto trata da implementação de um cenário hipotético - e bastante comum no Brasil:
<center><graphviz>
graph Empresa
{
Internet [shape=plaintext]
1 [shape=circle]
2 [shape=circle]
3 [shape=circle]
subgraph clusterMatriz
{
label=Matriz
Servidor_M [label=Servidor,shape=Mrecord]
}
subgraph clusterFilial
{
label=Filial
Servidor_F [label=Servidor,shape=Mrecord]
}
Servidor_M -- Internet
Servidor_F -- Internet
Internet -- 1
Internet -- 2
Internet -- 3
}
</graphviz></center>
Na figura acima veem-se, pois, os três eixos que compõem a organização:
* Matriz;
* Filial;
* "n" funcionários em trânsito (representados 3 deles).

==Requisitos do Sistemas==
* Hora certa: o servidor da matriz deverá alinhar seu relógio com outros da Internet para, em seguida, permitir o alinhamento pelas estações de trabalho na matriz, servidor da filial e esse para as estações da sua localidade. Desejável o uso de criptografia e/ou senha de controle.
* Domínio unificado: hierarquia entre o domínio da matriz e da filial, requerendo para tal delegação de subdomínio entre as duas localidades.
* Cadastro de usuários único: seja na matriz, na filial ou em trânsito, deverá haver apenas um cadastro único de usuários e válido em qualquer localidade para todos os serviços de autenticação. Desejável o uso de serviço em rede como LDAP.
* Compartilhamento de arquivos local e global: tanto na matriz quando na filial devereá haver um repositório local de arquivos, os quais de interesse restrito a essa localidade. Além disso, deverá haver em paralelo, de forma complementar, um repositório global disponível a todos (matriz, filial e em trânsito). Obrigatório o uso de criptografia e esquemas de autenticação e de autorização.
* Sistema de comunicação por texto, voz ou vídeo entre todos os funcionários das localidades. Qualquer um destes sistemas é válido e pode compor a solução final: correio eletrônico, mensagem instantânea e VoIP. Para cada sistema, deverá estar disponível a cada funcionário uma solução utilizando aplicação dedicada e em versão Web (exemplo: aplicação cliente de correio eletrônico e ''webmail'').
* Gerência centralizada de rede: monitoramento e contabilização com interface Web disponível na Internet. Obrigatório o uso de criptografia, autenticação e autorização.
* ''Backup'' local e global, condizente com os serviços de compartilhamento de arquivos e de comunicação, armazenando toda e qualquer informação possível relacionada a esses serviços oferecidos. Além disso, deverão também ser salvaguardados os arquivos de configuração dos servidores das duas localidades.
* Segurança na matriz e na filial em pelo menos duas camadas: Rede (filtro de pacotes) e Aplicação (''proxy'').

==Implementação==
Em duplas, matriz e filial, no [[#Ambiente de Produção|ambiente de produção]].


<center><small>[[Gerência de Redes (página)|Página principal da disciplina]]</small></center>