Projeto da Disciplina

A disciplina está orientada à resolução de um "grande" problema: projeto e implementação de duas redes de computadores interligadas via Internet - atendendo matriz e filial de uma mesma empresa. Estas duas redes deverão prover serviços internos a cada uma das unidades, bem como serviços de uso externo (outra unidade e/ou funcionários em trânsito).

A ideia é permitir que os funcionários possam trabalhar de qualquer ponto da Internet com o mínimo de perda de acesso aos dados. Ou seja, o acesso virtual à rede (serviços, ferramentas e dados) deverá ser equivalente ao acesso físico - dentro da matriz ou da filial.

Para fins didáticos, serão usados apenas 4 computadores para criar o ambiente interno da empresa:

graph Empresa {

Internet [shape=diamond]

subgraph clusterMatriz {
 label=Matriz
 cliente_Matriz [label=Cliente]
 servidor_Matriz [label=Servidor, shape=Mrecord]

 servidor_Matriz -- cliente_Matriz
}

subgraph clusterFilial {
 label=Filial
 cliente_Filial [label=Cliente]
 servidor_Filial [label=Servidor, shape=Mrecord]

 servidor_Filial -- cliente_Filial
}

Internet -- servidor_Matriz
Internet -- servidor_Filial

}

</graphviz>

Serviços

Cada unidade deverá ter serviços que provejam o ambiente de trabalho aos seus usuários:

Transparentes ao usuário final:
- Facilitadores: serviços de automatização dos processos de configuração dos componentes da rede, bem como localização de serviços voltados aos usuários.
- Diretórios e Bancos de Dados: organização de dados para acesso fácil, rápido e controlado.
- Acesso remoto: o controle central das duas redes, em particular dos servidores, será realizado pelo administrador de redes da matriz.
- Gerência: garantia de qualidade dos serviços prestados.
De uso direto do usuário final:
- Compartilhamento: troca de arquivos entre os usuários.
- Serviços específicos: se possível, encapsulados em ferramentas mais genéricas para veiculação através da rede. Exemplo: aplicativos para ERP, CRM e BI via ambiente Web ou através de túneis seguros.
- Comunicação: texto, voz e vídeo - de forma síncrona ou não.

Observações

Tráfego não controlado (via Internet) deverá, sempre que possível, ser protegido de terceiros utilizando criptografia.
Informação útil a toda a empresa deverá estar armazenada no servidor da matriz. Ao servidor da filial, somente deverão residir informações desta unidade.
O acesso aos dados deverá ser o mais transparente possível ao usuário final. Cabe apenas ao administrador de rede e/ou de sistemas conhecer todos as vias de tráfego da informação.

Tabela de Serviços

Assumindo o S.O. Ubuntu Linux:

Serviço	Porta/Protocolo	Programa principal	Arquivo de configuração principal	Arquivo de Registro
NTP	123/UDP	`/usr/sbin/ntpd`	`/etc/ntp.conf`	`/var/log/syslog`
Cron	(serviço local)	`/usr/sbin/cron`	`/etc/crontab`	`/var/log/syslog`
Syslog	514/UDP	`/usr/sbin/rsyslogd`	`/etc/rsyslog.conf`	`/var/log/messages`
DHCP	67/UDP	`/usr/sbin/dhcpd`	`/etc/dhcp3/dhcpd.conf`	`/var/log/syslog`
DNS	53/UDP	`/usr/sbin/named`	`/etc/bind/named.conf`	`/var/log/daemon.log`
SMB	137/UDP, 138/UDP, 139/TCP, 445/TCP	`/usr/sbin/smbd`, `/usr/sbin/nmbd`	`/etc/samba/smb.conf`	`/var/log/samba/log.smbd`, `/var/log/samba/log.nmbd`
HTTP	80/TCP, 443/TCP	`/usr/sbin/apache2`	`/etc/apache2/apache2.conf`	`/var/log/apache2/access.log`

Arquivos úteis:

* /etc/protocols: lista os protocolos utilizados pelo sistema.
* /etc/services: lista os serviços conhecidos (well-known services).

Comandos úteis para listar portas e serviços (com o usuário root):

Portas em modo escuta (abertas):

netstat -lnut

Associação entre processos e portas (arquivos do tipo socket):

lsof -n | grep TCP
lsof -n | grep UDP
fuser -v -n tcp <número da porta>

Visão Geral de Administração de Sistemas e de Rede

09/02: História dos S.O.s e Linguagens de Programação

Tópicos: história e evolução dos sistemas operacionais e das redes de computadores.
Páginas da apostila: 11-15
Para consulta: dicionário de comandos *nix.
Referências externas:

10/02: Instalação de S.O.s Linux

Sistemas instalados: Ubuntu Linux 9.10 como servidor.
- Instalação mínima.
- Recomendações de particionamento para servidores - em particular o uso de LVM.

12/02: Intepretador de Comandos

Tópicos: interpretador de comandos bash, criação de um script shell:

#!/bin/bash
...

Atividade 1

O problema: contar quantos usuários do sistema possuem a expressão adm em seu nome de login?

Proposta de solução

Há várias formas de resolver o problema. Uma delas consiste em:

Listar todos os usuários do sistema. Para fins didáticos, serão considerados apenas os usuários do arquivo /etc/passwd.
Filtrar, deste arquivo, apenas os nomes de login.
Filtrar apenas os usuários com a expressão adm.
Contar as ocorrências.

Como o processo é sequencial, esse problema pode ser resolvido via script shell, aqui denominado usuariosAdm:

vi usuariosAdm

cujo conteúdo é:

#!/bin/bash
echo "Há:"
cat /etc/passwd | cut -d : -f 1 | grep adm | wc -l
echo "usuários com a expressão adm em seu nome de login."

Para executar o script, é preciso liberar a execução para, em seguida, rodar o script como um programa regular:

chmod 755 usuariosAdm
./usuariosAdm

19/02: Intepretador de Comandos

Atividade 1

Montar um shell script que apresenta, sequencialmente, os estados do processador, memória e espaço em disco em todas as partições montadas. Variante: criar um menu para que o usuário possa escolher entre apenas um destes itens.

Proposta de solução

Original:

#!/bin/bash

echo "Estado do processador:"
top -n 1 -b | head -n 3

echo ""
echo "Estado da memória:"
free

echo ""
echo "Espaço em disco:"
df -h

Variante:

#!/bin/bash

Atividade 2

Montar um shell script para apresentar a quantidade de bytes enviados e recebidos em todas as interfaces de rede Ethernet. O interessante é que sejam coletados estes dados de 10 em 10s cinco vezes antes de encerrar o programa. Variante: apresentar, a cada 10s, apenas os bytes enviados e recebidos neste período de tempo - ao invés do acumulado apresentado originalmente pelo sistema.

Proposta de solução

Original:

#!/bin/bash

date
echo "Situação da interface de rede eth0:"
ifconfig eth0 | head -n 8 | tail -n 1

sleep 10

echo ""
date
echo "Situação da interface de rede eth0:"
ifconfig eth0 | head -n 8 | tail -n 1

sleep 10

echo ""
date
echo "Situação da interface de rede eth0:"
ifconfig eth0 | head -n 8 | tail -n 1

sleep 10

echo ""
date
echo "Situação da interface de rede eth0:"
ifconfig eth0 | head -n 8 | tail -n 1

sleep 10

echo ""
date
echo "Situação da interface de rede eth0:"
ifconfig eth0 | head -n 8 | tail -n 1

Variante:

#!/bin/bash

Atividade 3

Criar um script que salvaguarda (backup) os dados pessoais de um usuário, compactando-os e deixando apenas acessíveis ao administrador root, e o remove do sistema. Variante: remover os grupos vazios - que originalmente eram "povoados" apenas pelo usuário removido.

Proposta de solução

Original:

#!/bin/bash

# Descobrir qual o usuário a ser removido.
echo -n "Por favor, digite o nome do usuário: "
read USUARIO

# Descobrir qual é o dir. pessoal deste usuário.
DIR=`cat /etc/passwd | grep $USUARIO | cut -d : -f 6`

# Dirigir-se até o diretório pessoal do usuário.
echo "Avançando até o diretório $DIR..."
sleep 2
cd $DIR

# Escolher um diretório para "backups" de usuários.
echo "Criando um diretório de backups..."
sleep 2
mkdir /var/backups/usuariosAntigos
chmod 700 /var/backups/usuariosAntigos
chown root /var/backups/usuariosAntigos

# Fazer um "backup" deste diretório em um único arquivo.
# Compactar o "backup".
echo "Criando o backup e compactando-o..."
sleep 2
tar czf /var/backups/usuariosAntigos/$USUARIO.tar.gz .

# Proteger o acesso ao "backup".
echo "Protegendo o backup..."
sleep 2
chmod 400 /var/backups/usuariosAntigos/$USUARIO.tar.gz

# Apagar o diretório original.
cd ..
echo "Prestes a apagar o diretório $DIR em 5 segundos..."
echo "Problemas? Ctrl+C para cancelar a operação..."
sleep 5
rm -rf $DIR

# Apagar o usuário original.
echo "Apagando o usuário $USUARIO..."
sleep 2
userdel $USUARIO
echo "Usuário apagado com sucesso."

Variante:

#!/bin/bash

24/02: Início do Sistema e Scripts

Descrição do início do sistema para o sistema instalado: Ubuntu Linux versão 9.10.

digraph Inicio {

Kernel -> "/" Kernel -> "/sbin/init" "/" -> "/sbin/init" "/sbin/init" -> "/etc/init/*" "/etc/init/*" -> "/etc/init.d/rcS" -> "/etc/rcS.d/S*" -> "/etc/init.d/rc <runlevel>" "/etc/init/*" -> "/etc/init.d/rc <runlevel>" -> "/etc/rc<runlevel>.d/S*" }

</graphviz>

Revisão dos Conceitos de Redes de Computadores

26/03: Redes Locais

Tópicos: Arquiteturas de rede, protocolo IP, cálculo de máscara de rede.

03/03: Segmentação de Redes usando Máscara de Rede

A máscara de rede, na prática, define os limites da sub-rede a ela aplicada; ou seja, a faixa de IPs associados à sub-rede. Um cenário interessante para o estudo está descrito abaixo, onde a sub-rede 10.0.0.0/24 foi segmentada para comportar todas as sub-redes expostas no exemplo.

Na sub-rede em vermelho, como há 14 computadores, a máscara de rede /28 (255.255.255.240) é suficiente para comportar todos os IPs, que podem ser os primeiros da sub-rede original: 10.0.0.0/28.
As demais sub-redes têm seus endereços definidos na própria figura. Como há apenas dois computadores por sub-rede, a máscara /30 (255.255.255.252) garante dois, e apenas dois, IPs válidos.

graph rede10 { rankdir="LR"

C01 -- S01 [color="blue",label="10.0.0.16/30"] S02 -- C02 [color="blue", label="10.0.0.20/30"] S03 -- C03 [color="blue", label="10.0.0.24/30"] S04 -- C04 [color="blue", label="10.0.0.28/30"] S05 -- C05 [color="blue", label="10.0.0.32/30"] S06 -- C06 [color="blue", label="10.0.0.36/30"] S07 -- C07 [color="blue", label="10.0.0.40/30"] S08 -- C08 [color="blue", label="10.0.0.44/30"] S09 -- C09 [color="blue", label="10.0.0.48/30"] S10 -- C10 [color="blue", label="10.0.0.52/30"] S11 -- C11 [color="blue", label="10.0.0.56/30"] S12 -- C12 [color="blue", label="10.0.0.60/30"] S13 -- C13 [color="blue", label="10.0.0.64/30"] S14 -- C14 [color="blue", label="10.0.0.68/30"]

S01 -- S02 [color="red"] S01 -- S03 [color="red"] S01 -- S04 [color="red"] S01 -- S05 [color="red"] S01 -- S06 [color="red"] S01 -- S07 [color="red"] S01 -- S08 [color="red"] S01 -- S09 [color="red"] S01 -- S10 [color="red"] S01 -- S11 [color="red"] S01 -- S12 [color="red"] S01 -- S13 [color="red"] S01 -- S14 [color="red"] }

</graphviz>

Legenda:
- S: servidor
- C: cliente

Todos os servidores, no caso, podem atuar como roteadores entre as sub-redes. No Linux, o seguinte comando ativa a função de repasse de pacotes IP:

sysctl -w net.ipv4.ip_forward=1

informação que pode ser gravada no arquivo /etc/sysctl.conf.

05/03: Configuração de Rede

Tópicos: configuração via linha de comando e por arquivo de configuração. Endereços de rede para redes locais e acesso a redes remotas.

Endereços de rede:
- Para redes locais:
  - IP
  - Máscara de rede
  - Broadcast (difusão)
- Redes Remotas
  - Uma ou mais rotas de saída, onde uma delas pode ser a rota padrão do sistema.
  - Para o acesso pleno à Internet, é interessante (mas não obrigatório) um ou mais servidores DNS.

Configuração via linha de comando: veja a lista de comandos para rede.

Arquivos de configuração (assumindo o sistema escolhido para a disciplina):
- /etc/network/interfaces: IP, máscara de rede, broadcast para cada uma das interfaces, e rotas para o sistema.
- /etc/resolv.conf: servidor(es) DNS para o sistema.
- /etc/sysctl.conf: funcionalidades adicionais do sistema, como roteamento ou ponte.

10/03: Redes Remotas

Releitura do projeto da disciplina.

A pedido dos alunos, foi refeita a instalação do sistema operacional do servidor.

Reconfiguração das duas interfaces de rede.

Foram configuradas as duas interfaces virtuais do sistema, eth0 e eth1 no arquivo /etc/network/interfaces. O exemplo abaixo se aplicou à máquina M1 do laboratório (do professor):

# Interface de 'loopback'
auto lo
iface lo inet loopback
 
# Interface "interna", ponto a ponto entre servidor e cliente (2 computadores)
auto eth0
iface eth0 inet static
   address 10.0.0.17
   netmask 255.255.255.252

# Interface "externa", da rede dos servidores (14 computadores)
auto eth1
iface eth1 inet static
   address 10.0.0.1
   netmask 255.255.255.240

Após a configuração do arquivo, pode-se aplicar os valores utilizando o comando (o símbolo # inicial simboliza um comando digitado pelo superusuário root):

# /etc/init.d/networking restart

Ativação do roteamento no kernel.

O arquivo /etc/sysctl.conf possui diversas configuração relacionadas ao kernel Linux. Entre elas, o roteamento:

...
net.ipv4.ip_forward=1
...

o qual foi aplicado através do comando:

# sysctl -p /etc/sysctl.conf

Criação de um script shell para NAT.

Como na instalação padrão do Ubuntu não há um arquivo específico para configurar NAT, foi adotada a abordagem de criar um script próprio - para fins didáticos. Esse processo foi executado com a seguinte série de passos:

Passo 1: criação do script modelo, arquivo /etc/init.d/nat:

#!/bin/bash
 
# "Limpeza" das regras antigas
iptables -t nat -F
 
# Criação de uma regra genérica para NAT, considerando a interface eth1 como "externa"
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Passo 2: mudança das permissões, uma vez que se trata de um arquivo executável:

# chmod 700 /etc/init.d/nat

Passo 3: referência do script modelo para um nível de execução. Por predefinição (arquivos do diretório /etc/init), o nível comum é 2. Portanto, é recomendável uma ligação simbólica à cópia do arquivo original - para facilitar a manutenção do arquivo:

# cd /etc/rc2.d
# ln -s ../init.d/nat S01nat

O arquivo será executado junto com o sistema (S), sendo o primeiro script deste nível 2 (01).

Serviços em Rede: Facilitadores

12/03: Relógio e Agendamento de Tarefas

NTP

A sincronização do relógio do sistema é extremamente importante, não só pelo próprio S.O., mas também porque inúmeros serviços em rede dependem diretamente dessa informação.

O serviço NTP é hierárquico, em níveis de stratum. Um servidor stratum 1 conhecido é do Observatório Nacional, ntp.on.br, cujos clientes estão no nível 2, e assim por diante. Portanto, é interessante, sempre que possível, expandir a árvore para dentro da rede local

Servidor

O servidor atuará como um replicador do serviço dentro da rede local, para instalá-lo, tem-se o pacote ntp:

apt-get install ntp

E caso queira-se escolher o servidor do nível acima, basta editar o seu arquivo de configuração, /etc/ntp.conf. Foi escolhido o servidor do CAIS da RNP:

...
# Linha 16 do arquivo original: servidor CAIS da RNP como relógio-base
server ntp.cais.rnp.br
...

Cliente

Já no cliente o pacote a ser instalado é o ntpdate e, na linha de comando, digitar:

ntpdate <IP do servidor>

Diferente do servidor, que roda como um serviço (daemon), o cliente sincronizará apenas uma única vez com o servidor. Surge a necessidade de realizar periodicamente esta tarefa de outra forma: o agendamento de tarefas (cron).

Cron

O serviço cron deve rodar em todos os sistemas derivados do UNIX, uma vez que o sistema o utiliza para diversas tarefas de manutenção.

O arquivo principal de configuração é /etc/crontab, porém cada usuário pode ter agendar tarefas particulares, através do comando:

# crontab -e

para criar/modificar tarefas, ou mesmo listar as atuais:

$ crontab -l

As agendas particulares ficam armazenadas no diretório /var/spool/cron.

Obs.: esses serviços já estão listados na Tabela de Serviços.

17/03: Registros do Sistema e Prova Prática

Syslog

O syslog é, nos derivados do UNIX, o sistema de registro de eventos, ou logs. Existem vários identificadores de origem dos logs, chamados de facilities. Associado a um identificador de origem, há o seu nível de prioridade, as priorities. Assim, é possível ao syslog identificar as várias origens e prioridades e separá-las em vários arquivos, dispostos no diretório /var/log.

Alguns arquivos importantes de log:

/var/log/messages
/var/logl/syslog

Atualizada a Tabela de Serviços.

Quanto à prova, essa foi dividida em duas partes:

Teórica: cálculo de máscara de redes, individual.
Prática: configuração de rede e serviço em rede, individual ou em dupla.

Prova

Parte teórica

Assumindo a sub-rede inicial 172.31.0.0/17, segmente-a em partes iguais com a nova máscara: /19. A partir disso, identifique o 4o. IP válido da 1a. sub-rede.
- Resposta: 172.31.0.4

Assumindo a sub-rede inicial 10.0.20.0/24, segmente-a em partes iguais com a nova máscara: /29. A partir disso, identifique o penúltimo IP válido da 3a. sub-rede.
- Resposta: 10.0.20.21

Assumindo a sub-rede inicial 10.214.192.0/18, segmente-a em partes iguais com a nova máscara: /23. A partir disso, identifique o 34o. IP válido da 7a. sub-rede.
- Resposta: 10.214.204.34

Assumindo a sub-rede inicial 172.14.224.0/19, segmente-a em partes iguais com a nova máscara: /25. A partir disso, identifique o 12o. IP válido da 5a. sub-rede.
- Resposta: 172.14.226.12

Parte prática

Assuma que a sub-rede está configurada da seguinte maneira:
- Endereço de sub-rede = 172.31.240.0
- Máscara de sub-rede = 255.255.240.0
- Roteador (padrão) da sub-rede = primeiro IP válido
- Servidor DNS = 200.135.37.65

Configure a interface "externa" do servidor para pertencer à sub-rede descrita acima.
Configure o roteador e servidor DNS, acima mencionados, como padrão.
Demonstre que o servidor NTP do servidor está sincronizando o relógio do sistema com algum servidor remoto.
Demonstre que o cliente NTP da estação de trabalho está sincronizando o relógio do sistema com o servidor da rede local.
Crie um shell script que verifique, a cada 5min, se o usuário root (ou outro usuário operando como administrador do sistema) está conectado. Se estiver, apresente na sua tela/terminal o último registro de evento de sincronização de relógio - informação obtida pelo sistema de logs. Dica: arquivo /var/log/syslog.

Conceitos

Aluno	Teoria (4 itens)	Prática (3 itens)	Conceito
Carla	0	2	D
Caroline	0	2	D
Eris	0	3	C
Fabio	0	3	C
Francisco	0	3	C
Jacob	2	3	B
Jean	1	3	C
Jessé	1	3	C
Luan	0	2	D
Mailin	0	2	D
Mario Allan	1	2	C
Mario André	0	2	D
Maykon	1	3	C
Patrick	0	2	D
Roberto	2	2	C
Rodolfo	2	2	C
Rubia	3	2	B
Thiago	4	2	A
Wolvey	3	3	A

19/03: Feriado

Feriado municipal de São José, SC.

24/03: DHCP

No cenário acima exposto, pode-se ter a seguinte configuração para uma das redes locais.

Servidor

No servidor, segue a configuração:

Arquivo /etc/dhcp3/dhcpd.conf

# Integração com os outros serviços
#
# Atualizar alguma informação com origem no DNS? Nenhuma (none).
ddns-update-style none
#
# O 'log' das atividades do servidor serão registradas pela 'facility' local7 - arquivo /var/log/syslog
log-facility local7;

# Rede interna:  10.0.0.16/30 
subnet 10.0.0.16 netmask 255.255.255.252 {
   #
   # Faixa de IPs disponíveis: apenas um
   range 10.0.0.18 10.0.0.18;
   #
   # Máscara de rede    
   option subnet-mask 255.255.255.252;
   #
   #Endereço de 'broadcast'
   option broadcast-address 10.0.0.19;
   #
   # Rotas
   option routers 10.0.0.17;
   #
   # Servidores e domínios DNS
   option domain-name-servers 10.0.0.17;
   option domain-name "redes.sj.ifsc.edu.br";

   # Tempo predefinido e máximo de "aluguel" (lease): 4h e 1 dia respectivamente
   default-lease-time 14440;
   max-lease-time 86400;
}

Cliente

No cliente, basta configurá-lo como cliente DHCP - ou configuração automática.

O "diálogo" abaixo ocorre entre servidor (67/UDP) e cliente (68/UDP) para a obtenção dos valores de rede:

digraph DHCP { rankdir=LR Servidor [shape=Mrecord] Cliente

Cliente -> Servidor [label="1: Discover (broadcast)",color=red] Servidor -> Cliente [label="2: Offer (uniccast)",color=blue] Cliente -> Servidor [label="3: Request (unicast)",color=blue] Servidor -> Cliente [label="4: ACK (unicast)",color=blue] }

</graphviz>

Atualizada a Tabela de Serviços.

Pesquisa

26/03: Web

Pesquise sobre os seguintes temas:

World Wide Web, projeto iniciado no começo dos anos 1990
O protocolo HTTP
Os padrões XML, HTML, URL, RSS e Atom
Páginas estáticas e dinâmicas (DHTML/xHTML)
Aplicações Web e integração com bancos de dados:
- Ferramentas de edição online, como microblogs, blogs e wikis
- Content Management System (CMS)
Segurança na Web: SSL/TLS, HTTPS, autenticação
A Web 2.0: mashups, redes sociais, aplicativos Web como alternativa ao local (Google Docs, Microsoft Office)
Sistemas projetados para a Web: Chrome OS
Mobilidade, Ubiquidade e endereço único

Serviços em Rede: Diretórios

31/03: DNS e LDAP

DNS

Um dos serviços mais importantes da Internet, uma vez que é responsável pela tradução de nomes de computadores - e seus domínios - em IPs e vice-versa em escala global.

Servidor

Este é um dos serviços mais delicados em sua configuração, uma vez que as falhas de configuração não inviabilizam o processo de rodar; ou seja, mesmo com má configuração o servidor iniciará. É preciso, portanto, estar sempre atento aos registros do serviço - no caso, o arquivo /var/log/daemon.log.

Como o arquivo principal /etc/bind/named.conf faz apenas referências a outros 3 arquivos, o primeiro arquivo de fato a ser modificado é /etc/bind/named.conf.options:

options {
   ...
   listen-on-v6 { any; };
   listen-on { any; };
   allow-recursion { 127.0.0.0/8; 10.0.0.16/30; };
   allow-query { any; };
   allow-query-cache { any; };
};

assumindo, assim como nos outros serviços (como DHCP), que a rede local é 10.0.0.16/30.

Enquanto que o arquivo anterior tratava do serviço em linhas gerais, no arquivo /etc/bind/named.conf.local será criado o domínio redes.sj.ifsc.edu.br e seu reverso:

...
zone "redes.sj.ifsc.edu.br" {
   type master;
   file "/etc/bind/redes.sj.ifsc.edu.br";
};
zone "10.in-addr.arpa" {
   type master;
   file "/etc/bind/10.in-addr.arpa";
};

Próxima etapa: as informações específicas de domínio em /etc/bind/redes.sj.ifsc.edu.br:

$TTL 86400
@         IN   SOA   ns1.redes.sj.ifsc.edu.br.   ederson.redes.sj.ifsc.edu.br. (
    2010033101   ; serial
            1d   ; refresh
            1h   ; retry
            1w   ; expire
            1d   ; negative cache ttl
)
@        IN   NS     ns1
ns1      IN   A      10.0.0.1
www      IN   CNAME  ns1
servidor IN   CNAME  ns1

e seu reverso, arquivo /etc/bind/10.in-addr.arpa:

$TTL 86400
@      IN   SOA   ns1.redes.sj.ifsc.edu.br.   ederson.redes.sj.ifsc.edu.br. (
    2010033101   ; serial
            1d   ; refresh
            1h   ; retry
            1w   ; expire
            1d   ; negative cache ttl
)
@      IN   NS    ns1.redes.sj.ifsc.edu.br.
1.0.0 IN   PTR   ns1

Nota: como o serviço pode rodar com má configuração, é interessante (re)iniciar o serviço com um monitor dos registros:

# tail -f /var/log/daemon.log

em uma janela, enquanto que na outra:

# /etc/init.d/bind9 restart

Além disso, ferramentas como dig permitem consultas específicas aos registros criados (SOA, NS, MX, e outros).

Cliente

A configuração do cliente é feita de duas formas. Na forma manual, basta editar o arquivo /etc/resolv.conf:

domain redes.sj.ifsc.edu.br
nameserver 127.0.0.1

Na forma automática, tanto o servidor DNS quanto os domínios de busca já são atribuídos pelo serviço anterior, DHCP.

digraph DNS { rankdir=LR

subgraph clusterDireto { label="redes.sj.isfc.edu.br" ns1 [shape=circle] www [shape=record] servidor [shape=record]

www -> ns1 [label=CNAME] servidor -> ns1 [label=CNAME] }

subgraph clusterReverso { label="10.in-addr.arpa" "1.0.0" [shape=record] }

ns1 -> "1.0.0" [label=A] "1.0.0" -> ns1 [label=PTR] }

</graphviz>

Atualizada a Tabela de Serviços.

LDAP

Veja a lista de RFCs sobre LDAP na Wikipédia (em inglês).

07/04: DNS

Revisão de DNS.

Serviços em Rede: Compartilhamento

12/04: SMB

O SMB foi um serviço projetado para redes locais (faz uso de broadcasts para descoberta de computadores). Originalmente desenvolvido pela IBM na década de 1980, sofreu profundas modificações pela Microsoft, tornando-se CIFS. No Windows Vista, foi incorporada a versão 2.0 do protocolo (ou suíte de protocolos, para ser mais extato) SMB.

No começo, havia os grupos de trabalho, cujo controle de acesso aos recursos, como impressoras e diretórios, era feito em cada equipamento. Depois, vieram os domínios: hierarquização e centralização das políticas de uso dos recursos da rede.

Nos sistemas variantes do UNIX, é possível utilizar essa suíte de protocolos através do pacote Samba. Do seu principal arquivo de configuração, cabe destacar da seção [global]:

workgroup

que identifica o grupo de trabalho ou domínio a fazer parte, e:

security
os level
domain logons
domain master
local master
preferred master

para definir o "perfil" do Samba: estação de trabalho, servidor ou PDC. A configuração abaixo, por exemplo, define uma estação de trabalho do grupo REDES:

[global]
  workgroup = REDES
  ...
  security = user
  os level = 33
  domain logons = no
  domain master = no
  local master = no
  preferred master = no
  ...

enquanto que esta configuração pode definir um PDC (a escolha final do PDC, único na rede, dependerá dos outros computadores da rede):

[global]
  workgroup = REDES
  ...
  security = user
  os level = 255
  domain logons = yes
  domain master = yes
  local master = yes
  preferred master = yes
  ...

Uma ótima referência para o assunto é o livro Using Samba. A versão anterior (2a.) está disponível para leitura.

Atualizada a Tabela de Serviços.

14/04: HTTP

Apesar também publique e compartilhe arquivos em rede, histórica e conceitualmente SMB e HTTP são radicalmente diferentes; contudo, a integração entre os mesmos é bastante simples - desde que se entenda como processos/daemons atuam no S.O.

Um mesmo diretório, como por exemplo /home/documentos, pode ser compartilhado no Samba:

[Documentos]
  path = /home/documentos
  browseable = yes
  writable = yes
  valid users = joao, maria, jose
  force group = www-data
  create mask = 0600
  directory mask = 0700

e, ao mesmo tempo, no Apache (servidor HTTP). O arquivo abaixo, documentos está no diretório /etc/apache2/conf.d, onde definem-se os arquivos de extensão do arquivo principal (/etc/apache2/apache2.conf):

Alias /Documentos /home/documentos
<Directory /home/documentos>
  Options Indexes
  Order allow,deny
  Allow from all
</Directory>

Nesse segundo caso, como pode-se perceber, o acesso é anônimo e sem controle de acesso. Além disso, o navegador terá restrições em modificar os arquivos a distância - ao contrário do cliente SMB.

É possível equiparar tanto o controle de acesso por usuário, bem como os dois sentidos de operação: leitura e escrita.

16/04: HTTP

Tópicos: Autenticação, HTTPS, aplicações Web.

Atividade-problema

Compartilhe, no servidor da Matriz, um diretório chamado Orçamentos para os usuários João, Maria e José, conforme o cenário abaixo:

graph Empresa {

Internet [shape=diamond]

subgraph clusterMatriz {
 label=Matriz
 cliente_Matriz [label=Cliente]
 servidor_Matriz [label=Servidor, shape=Mrecord]

 servidor_Matriz -- cliente_Matriz
}

subgraph clusterFilial {
 label=Filial
 cliente_Filial [label=Cliente]
 servidor_Filial [label=Servidor, shape=Mrecord]

 servidor_Filial -- cliente_Filial
}

Internet -- servidor_Matriz
Internet -- servidor_Filial

João [shape=plaintext]
Maria [shape=plaintext]
José [shape=plaintext]
João -- cliente_Matriz [color=red]
Maria -- Internet [color=red]
José -- cliente_Filial [color=red]

}

</graphviz>

Proposta de solução

Uma forma de resolver o problema acima é combinar os dois serviços de compartilhamento de arquivos. Para o usuário João, que está na mesma rede local, há vantagem em utilizar SMB, enquanto que para Maria e José o serviço baseado em HTTP é o mais indicado:

digraph Integração {

João [shape=plaintext] Maria [shape=plaintext] José [shape=plaintext] Samba [shape=circle] Apache2 [shape=circle] "Sistema de Arquivos" [shape=box3d]

João -> Samba [label="joao"] Samba -> "Sistema de Arquivos" [label="www-data",color=red]

Maria -> Apache2 [label="maria"] José -> Apache2 [label="jose"] Apache2 -> "Sistema de Arquivos" [label="www-data"]

}

</graphviz>

Segue a configuração abaixo:

Criação do diretório /home/orcamentos:

mkdir -p /home/orcamentos
chown www-data /home/orcamentos
chmod 700 /home/orcamentos

Pacotes a instalar:

apt-get install samba apache2

Ativação de módulo DAV no Apache2:

a2enmod dav_fs

Servidor Matriz, arquivo /etc/samba/smb.conf:

[global]
...
[Orçamentos]
  path = /home/orcamentos
  browseable = yes
  writable = yes
  valid users = joao
  force user = www-data
  create mask = 600
  directory mask = 700

Servidor Matriz, arquivo /etc/apache2/conf.d/orcamentos:

Alias /orcamentos /home/orcamentos
<Directory /home/documentos>
  Dav On
  Options Indexes
  Order allow,deny
  Allow from all

  AuthType Basic
  AuthName "Acesso Restrito"
  AuthUserFile /etc/htpasswd
  Require user maria jose
</Directory>

Servidor Matriz, arquivo /etc/htpasswd:

touch /etc/htpasswd
chmod 600 /etc/htpasswd
chown www-data:www-data /etc/htpasswd
htpasswd -m /etc/htpasswd jose
htpasswd -m /etc/htpasswd maria

Aplicação das configurações:

/etc/init.d/samba restart
/etc/init.d/apache2 restart

23/04: Prova Prática

Serviços em Rede: Comunicação

28/04: Correio Eletrônico

Antes de iniciar o serviço de correio eletrônico, é preciso adicionar um registro ao domínio DNS - o arquivo redes.sj.ifsc.edu.br:

...
@        IN   NS     ns1
@        IN   MX     0 mail.redes.sj.ifsc.edu.br.
ns1      IN   A      10.0.0.1
mail     IN   A      10.0.0.1
...

SMTP

O serviço de envio de emails (MTA) possui diversas implementações, em especial:

cada um com duas (des)vantagens e particularidades. Para fins didáticos, foi escolhido o Postfix, o qual possui uma configuração acessível. Depois de instalado:

apt-get install postfix

o arquivo /etc/postfix/main.cf tem uma configuração bastante simples e funcional:

...
myhostname = mail.redes.sj.ifsc.edu.br
mydomain = redes.sj.ifsc.edu.br
myorigin = $mydomain
mydestination = $myhostname, $mydomain, localhost, localhost.localdomain
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 10.0.0.16/30
...

IMAP

Há dois protocolos conhecidos para a leitura de emails: POP e IMAP. Hoje, com o uso mais disseminado da banda larga, o serviço IMAP se mostra útil para essa função.

A implementação do Dovecot é extremamente funcional: integra-se facilmente ao sistema (autenticação via PAM):

apt-get install dovecot-imapd

30/04: Correio Eletrônico

Tópicos: configuração hierárquica dos servidores DNS, envio/recebimento entre domínios diferentes.
Webmail.

Teste entre Domínios

Como em sala de aula (laboratório Redes II) cada computador possui duas máquinas virtuais (servidor e cliente) e seu próprio domínio DNS, é preciso estabelecer um elo de ligação entre os vários domínios. E como o serviço DNS é hierárquico, foi criado um servidor de nível superior: com.br. Assim, servidores e clientes passaram a usar esse servidor (arquivo /etc/resolv.conf), uma vez que o mesmo faz referência a todos os domínios - um por computador.

Webmail

A implementação de webmail escolhida foi a do Roundcube, de boa usabilidade e fácil instalação.

Após descarregar o pacote de instalação, pode-se descompactá-lo no diretório /var/www/roundcube, uma vez que o diretório /var/www (em Debian e Ubunu) é utilizado para depositar arquivos voltados à Web. Aqui, será usada a última versão estável (0.3.1):

cd /usr/local/src
wget http://downloads.sourceforge.net/project/roundcubemail/roundcubemail/0.3.1/roundcubemail-0.3.1.tar.gz
tar xzvf roundcubemail-0.3.1.tar.gz
mv roundcubemail-0.3.1 /var/www/roundcube
chown -R www-data:www-data /var/www/roundcube

Algumas funções PHP são interessantes para associar ao webmail:

apt-get install php5-mysql php5-gd php5-mcrypt

Instalação da Base de Dados

apt-get install mysql-server
mysql -uroot -p

Uma vez conectado ao banco de dados, será criada uma base de dados (roundcube) e associado à essa um usuário (rcadmin e senha s3nh4) com plenos poderes (all privileges):

> create database roundcube;
> grant all privileges on roundcube.* to rcadmin@localhost identified by 's3nh4';
> flush privileges;
> quit;

Configuração do servidor Web

Provavelmente a essa altura o Apache já está instalado, então basta configurá-lo:

vi /etc/apache2/conf.d/webmail

Cujo conteúdo desse arquivo é:

Alias /webmail /var/www/roundcube
<Directory /var/www/roundcube>
   Options None
   AllowOverride Limit
   Order allow,deny
   Allow from all
</Directory>

E depois reiniciar do serviço:

/etc/init.d/apache2 restart

A instalação continuará via Web, através da página http://<servidor>/webmail/installer.

05/05: VoIP

07/05: VoIP

Serviços em Rede: Acesso Remoto

12/05: SSH, VNC, RDP

O futuro: computação em nuvem, virtualização, mobilidade.

14/05: Prova Prática

Gerência de Rede

Um exemplo de gerência nos dias de hoje: como anda o sinal 3G na sua região de interesse?

Gerência de Redes de Computadores (técnico) (diário 2010-1)

Projeto da Disciplina

Serviços

Observações

Tabela de Serviços

Visão Geral de Administração de Sistemas e de Rede

09/02: História dos S.O.s e Linguagens de Programação

10/02: Instalação de S.O.s Linux

12/02: Intepretador de Comandos

Atividade 1

Proposta de solução

19/02: Intepretador de Comandos

Atividade 1

Proposta de solução

Atividade 2

Proposta de solução

Atividade 3

Proposta de solução

24/02: Início do Sistema e Scripts

Revisão dos Conceitos de Redes de Computadores

26/03: Redes Locais

03/03: Segmentação de Redes usando Máscara de Rede

05/03: Configuração de Rede

10/03: Redes Remotas

Serviços em Rede: Facilitadores

12/03: Relógio e Agendamento de Tarefas

NTP

Servidor

Cliente

Cron

17/03: Registros do Sistema e Prova Prática

Syslog

Prova

Parte teórica

Parte prática

Conceitos

19/03: Feriado

24/03: DHCP

Servidor

Cliente

Pesquisa

26/03: Web

Serviços em Rede: Diretórios

31/03: DNS e LDAP

DNS

Servidor

Cliente

LDAP

07/04: DNS

Serviços em Rede: Compartilhamento

12/04: SMB

14/04: HTTP

16/04: HTTP

Atividade-problema

Proposta de solução

23/04: Prova Prática

Serviços em Rede: Comunicação

28/04: Correio Eletrônico

SMTP

IMAP

30/04: Correio Eletrônico

Teste entre Domínios

Webmail

Instalação da Base de Dados

Configuração do servidor Web

05/05: VoIP

07/05: VoIP

Serviços em Rede: Acesso Remoto

12/05: SSH, VNC, RDP

14/05: Prova Prática

Gerência de Rede

19/05: Conceitos

21/05: Scritps

26/05: Monitoramento

28/05: Contabilização

02/06: Contabilização

04/06: Segurança

09/06: Segurança

11/06: Prova Prática

Projeto Integrador