Mudanças entre as edições de "Gerência de Redes de Computadores (técnico) (diário 2010-1)"
(353 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) | |||
Linha 1: | Linha 1: | ||
+ | * Endereço encurtado: http://bit.ly/gar20101 | ||
+ | * Diário de acordo com o [http://docs.google.com/Doc?docid=0AfKQkavuEKVtZGhnOG5qZ3NfNTE2NTl2cjR2ZnI&hl=pt_BR plano de ensino]. | ||
+ | |||
=Projeto da Disciplina= | =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 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 | + | 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: | + | Para fins didáticos, serão usados apenas 4 computadores para criar o ambiente interno da empresa: |
− | <graphviz> | + | <center><graphviz> |
graph Empresa { | graph Empresa { | ||
Linha 29: | Linha 32: | ||
Internet -- servidor_Filial | Internet -- servidor_Filial | ||
} | } | ||
− | </graphviz> | + | </graphviz></center> |
+ | |||
+ | ==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 [http://pt.wikipedia.org/wiki/ERP ERP], [http://pt.wikipedia.org/wiki/Customer_relationship_management CRM] e [http://pt.wikipedia.org/wiki/Business_intelligence 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: | ||
+ | <center> | ||
+ | {| border=1 | ||
+ | |- | ||
+ | | '''Serviço''' || '''Porta/Protocolo''' || '''Programa principal''' || '''Arquivo de configuração principal''' || '''Arquivo de Registro''' | ||
+ | |- | ||
+ | | [[#NTP|NTP]] || 123/UDP || <tt>/usr/sbin/ntpd</tt> || <tt>/etc/ntp.conf</tt> || <tt>/var/log/syslog</tt> | ||
+ | |- | ||
+ | | [[#Cron|Cron]] || (serviço local) || <tt>/usr/sbin/cron</tt> || <tt>/etc/crontab</tt> || <tt>/var/log/syslog</tt> | ||
+ | |- | ||
+ | | [[#Syslog|Syslog]] || 514/UDP || <tt>/usr/sbin/rsyslogd</tt> || <tt>/etc/rsyslog.conf</tt> || <tt>/var/log/messages</tt> | ||
+ | |- | ||
+ | | [[#24/03: DHCP|DHCP]] || 67/UDP || <tt>/usr/sbin/dhcpd</tt> || <tt>/etc/dhcp3/dhcpd.conf</tt> || <tt>/var/log/syslog</tt> | ||
+ | |- | ||
+ | | [[#DNS|DNS]] || 53/UDP || <tt>/usr/sbin/named</tt> || <tt>/etc/bind/named.conf</tt> || <tt>/var/log/daemon.log</tt> | ||
+ | |- | ||
+ | | [[#12/04: SMB|SMB]] || 137/UDP, 138/UDP, 139/TCP, 445/TCP || <tt>/usr/sbin/smbd</tt>, <tt>/usr/sbin/nmbd</tt> || <tt>/etc/samba/smb.conf</tt> || <tt>/var/log/samba/log.smbd</tt>, <tt>/var/log/samba/log.nmbd</tt> | ||
+ | |- | ||
+ | | [[#14/04: HTTP|HTTP]] || 80/TCP, 443/TCP || <tt>/usr/sbin/apache2</tt> || <tt>/etc/apache2/apache2.conf</tt> || <tt>/var/log/apache2/access.log</tt> | ||
+ | |- | ||
+ | | [[#SMTP|SMTP]] || 25/TCP || <tt>/usr/lib/postfix/master</tt> || <tt>/etc/postfix/main.cf</tt> || <tt>/var/log/mail.log</tt> | ||
+ | |- | ||
+ | | [[#IMAP|IMAP]] || 143/TCP || <tt>/usr/lib/dovecot/imap</tt> || || <tt>/var/log/auth.log</tt> | ||
+ | |} | ||
+ | </center> | ||
− | + | Arquivos úteis: | |
+ | * <tt>/etc/protocols</tt>: lista os protocolos utilizados pelo sistema. | ||
+ | * <tt>/etc/services</tt>: lista os serviços conhecidos (''well-known services''). | ||
+ | |||
+ | Comandos úteis para listar portas e serviços (com o usuário <tt>root</tt>): | ||
+ | * Portas em modo escuta (abertas): | ||
+ | <syntaxhighlight lang=bash> | ||
+ | netstat -lnut | ||
+ | </syntaxhighlight> | ||
+ | * Associação entre processos e portas (arquivos do tipo ''socket''): | ||
+ | <syntaxhighlight lang=bash> | ||
+ | lsof -n | grep TCP | ||
+ | lsof -n | grep UDP | ||
+ | fuser -v -n tcp <número da porta> | ||
+ | </syntaxhighlight> | ||
=Visão Geral de Administração de Sistemas e de Rede= | =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 [[Gerência de Redes de Computadores (técnico)#Referências Bibliográficas|apostila]]: 11-15 | ||
+ | * Para consulta: dicionário de [[Comandos de Sistemas Operacionais variantes do UNIX|comandos *nix]]. | ||
+ | * Referências externas: | ||
+ | ** [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.33.1204&rep=rep1&type=pdf The UNIX Time-Sharing System] (arquivo PDF) | ||
+ | ** [http://www.levenez.com Linha cronológica das linguagens de programação e sistemas operacionais baseados no UNIX]. | ||
+ | ** [http://focalinux.cipsga.org.br/guia/inic_interm/index.html Guia Foca Linux - versão intermediário] | ||
− | == | + | ==10/02: Instalação de S.O.s Linux== |
+ | * Sistemas instalados: [http://www.ubuntu.com/getubuntu/download Ubuntu Linux 9.10] como servidor. | ||
+ | ** Instalação mínima. | ||
+ | ** Recomendações de particionamento para servidores - em particular o uso de [http://en.wikipedia.org/wiki/Logical_volume_management LVM]. | ||
+ | |||
+ | ==12/02: Intepretador de Comandos== | ||
+ | * Tópicos: interpretador de comandos <tt>bash</tt>, criação de um ''script shell'': | ||
+ | <syntaxhighlight lang=bash> | ||
+ | #!/bin/bash | ||
+ | ... | ||
+ | </syntaxhighlight> | ||
+ | ===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 <tt>/etc/passwd</tt>. | ||
+ | # 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 <tt>usuariosAdm</tt>: | ||
+ | vi usuariosAdm | ||
+ | cujo conteúdo é: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | #!/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." | ||
+ | </syntaxhighlight> | ||
+ | Para executar o ''script'', é preciso liberar a execução para, em seguida, rodar o ''script'' como um programa regular: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | chmod 755 usuariosAdm | ||
+ | ./usuariosAdm | ||
+ | </syntaxhighlight> | ||
==19/02: Intepretador de Comandos== | ==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: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | #!/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 | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | * Variante: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | #!/bin/bash | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ===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: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | #!/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 | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | * Variante: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | #!/bin/bash | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ===Atividade 3=== | ||
+ | Criar um ''script'' que salvaguarda (''backup'') os dados pessoais de um usuário, compactando-os e deixando apenas acessíveis ao administrador <tt>root</tt>, e o remove do sistema. Variante: remover os grupos vazios - que originalmente eram "povoados" apenas pelo usuário removido. | ||
+ | |||
+ | ====Proposta de solução==== | ||
+ | * Original: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | #!/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." | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | * Variante: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | #!/bin/bash | ||
+ | |||
+ | </syntaxhighlight> | ||
+ | |||
+ | ==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. | ||
+ | <center><graphviz> | ||
+ | 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></center> | ||
=Revisão dos Conceitos de Redes de Computadores= | =Revisão dos Conceitos de Redes de Computadores= | ||
− | == | + | ==26/02: Redes Locais== |
* Tópicos: Arquiteturas de rede, protocolo IP, cálculo de máscara de rede. | * Tópicos: Arquiteturas de rede, protocolo IP, cálculo de máscara de rede. | ||
− | |||
− | ==05/03: Redes Remotas | + | ==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. | ||
+ | |||
+ | <center><graphviz> | ||
+ | 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></center> | ||
+ | * 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: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | sysctl -w net.ipv4.ip_forward=1 | ||
+ | </syntaxhighlight> | ||
+ | informação que pode ser gravada no arquivo <tt>/etc/sysctl.conf</tt>. | ||
+ | |||
+ | ==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 de Sistemas Operacionais variantes do UNIX#Rede|comandos]] para rede. | ||
+ | |||
+ | * Arquivos de configuração (assumindo o [[#10/02: Instalação de S.O.s Linux|sistema escolhido para a disciplina]]): | ||
+ | ** <tt>/etc/network/interfaces</tt>: IP, máscara de rede, ''broadcast'' para cada uma das interfaces, e rotas para o sistema. | ||
+ | ** <tt>/etc/resolv.conf</tt>: servidor(es) DNS para o sistema. | ||
+ | ** <tt>/etc/sysctl.conf</tt>: funcionalidades adicionais do sistema, como roteamento ou ponte. | ||
==10/03: Redes Remotas== | ==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, <tt>eth0</tt> e <tt>eth1</tt> no arquivo <tt>/etc/network/interfaces</tt>. O exemplo abaixo se aplicou à máquina M1 do laboratório (do professor): | ||
+ | <syntaxhighlight lang=bash> | ||
+ | # 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 | ||
+ | </syntaxhighlight> | ||
+ | Após a configuração do arquivo, pode-se aplicar os valores utilizando o comando (o símbolo <tt>#</tt> inicial simboliza um comando digitado pelo superusuário <tt>root</tt>): | ||
+ | <syntaxhighlight lang=bash> | ||
+ | /etc/init.d/networking restart | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | * Ativação do roteamento no ''kernel''. | ||
+ | O arquivo <tt>/etc/sysctl.conf</tt> 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: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | sysctl -p /etc/sysctl.conf | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | * 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 <tt>/etc/init.d/nat</tt>: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | #!/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 | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | Passo 2: mudança das permissões, uma vez que se trata de um arquivo executável: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | chmod 700 /etc/init.d/nat | ||
+ | <code> | ||
+ | |||
+ | Passo 3: referência do ''script'' modelo para um nível de execução. Por predefinição (arquivos do diretório <tt>/etc/init</tt>), 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: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | cd /etc/rc2.d | ||
+ | ln -s ../init.d/nat S01nat | ||
+ | </syntaxhighlight> | ||
+ | O arquivo será executado junto com o sistema (<tt>S</tt>), sendo o primeiro ''script'' deste nível 2 (<tt>01</tt>). | ||
=Serviços em Rede: Facilitadores= | =Serviços em Rede: Facilitadores= | ||
==12/03: Relógio e Agendamento de Tarefas== | ==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 [http://www.rnp.br/ntp/ NTP] é hierárquico, em níveis de ''stratum''. Um servidor ''stratum'' 1 conhecido é do Observatório Nacional, <tt>ntp.on.br</tt>, 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 <tt>ntp</tt>: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | apt-get install ntp | ||
+ | </syntaxhighlight> | ||
+ | E caso queira-se escolher o servidor do nível acima, basta editar o seu arquivo de configuração, <tt>/etc/ntp.conf</tt>. Foi escolhido o servidor do [http://www.rnp.br/cais/ 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 <tt>ntpdate</tt> e, na linha de comando, digitar: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | ntpdate <IP do servidor> | ||
+ | </syntaxhighlight> | ||
+ | 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 (<tt>cron</tt>). | ||
+ | |||
+ | ===Cron=== | ||
+ | O serviço <tt>cron</tt> 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 é <tt>/etc/crontab</tt>, porém cada usuário pode ter agendar tarefas particulares, através do comando: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | crontab -e | ||
+ | </syntaxhighlight> | ||
+ | para criar/modificar tarefas, ou mesmo listar as atuais: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | crontab -l | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | As agendas particulares ficam armazenadas no diretório <tt>/var/spool/cron</tt>. | ||
+ | |||
+ | Obs.: esses serviços já estão listados na [[#Tabela de Serviços|Tabela de Serviços]]. | ||
==17/03: Registros do Sistema e Prova Prática== | ==17/03: Registros do Sistema e Prova Prática== | ||
+ | ===Syslog=== | ||
+ | O <tt>syslog</tt> é, 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 <tt>syslog</tt> identificar as várias origens e prioridades e separá-las em vários arquivos, dispostos no diretório <tt>/var/log</tt>. | ||
− | ==19/03: DHCP e | + | Alguns arquivos importantes de ''log'': |
+ | * <tt>/var/log/messages</tt> | ||
+ | * <tt>/var/logl/syslog</tt> | ||
+ | |||
+ | Atualizada a [[#Tabela de Serviços|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 = <tt>172.31.240.0</tt> | ||
+ | ** Máscara de sub-rede = <tt>255.255.240.0</tt> | ||
+ | ** Roteador (padrão) da sub-rede = primeiro IP válido | ||
+ | ** Servidor DNS = <tt>200.135.37.65</tt> | ||
+ | # 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 <tt>root</tt> (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 <tt>/var/log/syslog</tt>. | ||
+ | |||
+ | |||
+ | |||
+ | ==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 | ||
+ | <syntaxhighlight lang=bash> | ||
+ | # 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; | ||
+ | } | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ===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: | ||
+ | <center><graphviz> | ||
+ | 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></center> | ||
+ | |||
+ | Atualizada a [[#Tabela de Serviços|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= | =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 [http://www.root-servers.org/ 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 <tt>/var/log/daemon.log</tt>. | ||
+ | |||
+ | Como o arquivo principal <tt>/etc/bind/named.conf</tt> faz apenas referências a outros 3 arquivos, o primeiro arquivo de fato a ser modificado é <tt>/etc/bind/named.conf.options</tt>: | ||
+ | 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|DHCP]]), que a rede local é <tt>10.0.0.16/30</tt>. | ||
+ | |||
+ | Enquanto que o arquivo anterior tratava do serviço em linhas gerais, no arquivo <tt>/etc/bind/named.conf.local</tt> será criado o domínio <tt>redes.sj.ifsc.edu.br</tt> 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 <tt>/etc/bind/redes.sj.ifsc.edu.br</tt>: | ||
+ | $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 <tt>/etc/bind/10.in-addr.arpa</tt>: | ||
+ | $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: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | tail -f /var/log/daemon.log | ||
+ | </syntaxhighlight> | ||
+ | em uma janela, enquanto que na outra: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | /etc/init.d/bind9 restart | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | Além disso, ferramentas como <tt>dig</tt> 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 <tt>/etc/resolv.conf</tt>: | ||
+ | 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|DHCP]]. | ||
+ | |||
+ | <center><graphviz> | ||
+ | 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></center> | ||
+ | |||
+ | Atualizada a [[#Tabela de Serviços|Tabela de Serviços]]. | ||
+ | |||
+ | ===LDAP=== | ||
+ | Veja a [http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol#RFCs lista de RFCs sobre LDAP na Wikipédia] (em inglês). | ||
+ | |||
+ | ==07/04: DNS== | ||
+ | Revisão de [[Gerência de Redes de Computadores (técnico) (diário 2010-1)#DNS|DNS]]. | ||
=Serviços em Rede: Compartilhamento= | =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 [http://www.samba.org Samba]. Do seu principal arquivo de configuração, cabe destacar da seção <tt>[global]</tt>: | ||
+ | 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 [http://oreilly.com/catalog/9780596007690/ Using Samba]. A versão anterior (2a.) está [http://samba.org/samba/docs/using_samba/toc.html disponível para leitura]. | ||
+ | |||
+ | Atualizada a [[#Tabela de Serviços|Tabela de Serviços]]. | ||
==14/04: HTTP== | ==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 <tt>/home/documentos</tt>, 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, <tt>documentos</tt> está no diretório <tt>/etc/apache2/conf.d</tt>, onde definem-se os arquivos de extensão do arquivo principal (<tt>/etc/apache2/apache2.conf</tt>): | ||
+ | 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== | ==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: | ||
+ | <center><graphviz> | ||
+ | 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></center> | ||
+ | |||
+ | ====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: | ||
+ | <center><graphviz> | ||
+ | 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></center> | ||
+ | |||
+ | Segue a configuração abaixo: | ||
+ | * Criação do diretório <tt>/home/orcamentos</tt>: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | mkdir -p /home/orcamentos | ||
+ | chown www-data /home/orcamentos | ||
+ | chmod 700 /home/orcamentos | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | * Pacotes a instalar: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | apt-get install samba apache2 | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | * Ativação de módulo [http://www.webdav.org/ DAV] no Apache2: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | a2enmod dav_fs | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | * Servidor Matriz, arquivo <tt>/etc/samba/smb.conf</tt>: | ||
+ | [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 <tt>/etc/apache2/conf.d/orcamentos</tt>: | ||
+ | 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 <tt>/etc/htpasswd</tt>: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | touch /etc/htpasswd | ||
+ | chmod 600 /etc/htpasswd | ||
+ | chown www-data:www-data /etc/htpasswd | ||
+ | htpasswd -m /etc/htpasswd jose | ||
+ | htpasswd -m /etc/htpasswd maria | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | * Aplicação das configurações: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | /etc/init.d/samba restart | ||
+ | /etc/init.d/apache2 restart | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ==23/04: Prova Prática== | ||
=Serviços em Rede: Comunicação= | =Serviços em Rede: Comunicação= | ||
==28/04: Correio Eletrônico== | ==28/04: Correio Eletrônico== | ||
+ | Antes de iniciar o serviço de correio eletrônico, é preciso adicionar um registro ao domínio [[#DNS|DNS]] - o arquivo <tt>redes.sj.ifsc.edu.br</tt>: | ||
+ | ... | ||
+ | @ 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: | ||
+ | * [http://www.sendmail.org Sendmail] | ||
+ | * [http://www.postfix.org Postfix] | ||
+ | * [http://www.exim.org Exim] | ||
+ | * [http://www.qmail.org Qmail] | ||
+ | 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: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | apt-get install postfix | ||
+ | </syntaxhighlight> | ||
+ | o arquivo <tt>/etc/postfix/main.cf</tt> 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 [http://www.kernel.org/pub/linux/libs/pam/index.html PAM]): | ||
+ | <syntaxhighlight lang=bash> | ||
+ | apt-get install dovecot-imapd | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | Atualizada a [[#Tabela de Serviços|Tabela de Serviços]]. | ||
+ | |||
+ | ==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: <tt>com.br</tt>. Assim, servidores e clientes passaram a usar esse servidor (arquivo <tt>/etc/resolv.conf</tt>), 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 [http://roundcube.net Roundcube], de boa usabilidade e fácil instalação. | ||
+ | |||
+ | Após descarregar o [http://roundcube.net/download pacote de instalação], pode-se descompactá-lo no diretório <tt>/var/www/roundcube</tt>, uma vez que o diretório <tt>/var/www</tt> (em Debian e Ubunu) é utilizado para depositar arquivos voltados à Web. Aqui, será usada a última versão estável (0.3.1): | ||
+ | <syntaxhighlight lang=bash> | ||
+ | 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 | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | Algumas funções PHP são interessantes para associar ao ''webmail'': | ||
+ | <syntaxhighlight lang=bash> | ||
+ | apt-get install php5-mysql php5-gd php5-mcrypt | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ====Instalação da Base de Dados==== | ||
+ | <syntaxhighlight lang=bash> | ||
+ | apt-get install mysql-server | ||
+ | mysql -uroot -p | ||
+ | </syntaxhighlight> | ||
+ | Uma vez conectado ao banco de dados, será criada uma base de dados (<tt>roundcube</tt>) e associado à essa um usuário (<tt>rcadmin</tt> e senha <tt>s3nh4</tt>) com plenos poderes (<tt>all privileges</tt>): | ||
+ | > 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: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | vi /etc/apache2/conf.d/webmail | ||
+ | </syntaxhighlight> | ||
+ | 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: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | /etc/init.d/apache2 restart | ||
+ | </syntaxhighlight> | ||
− | + | A instalação continuará via Web, através da página <tt><nowiki>http://<servidor>/webmail/installer</nowiki></tt>. | |
==05/05: VoIP== | ==05/05: VoIP== | ||
+ | * Leitura do [[Guia básico de VoIP com Asterisk]]. | ||
+ | * Implementação de dois ramais em cada PBX: | ||
+ | ** [http://ekiga.net Ekiga] softphone | ||
+ | ** Telefone IP ou ATA | ||
==07/05: VoIP== | ==07/05: VoIP== | ||
+ | * Interligação dos ''soft'' PBXs via prefixos: arquivo <tt>/etc/asterisk/extensions.conf</tt>. | ||
+ | |||
+ | =Projeto Final da Disciplina= | ||
+ | O projeto final da disciplina contemplará os estudos realacionados ao sistema operacional GNU/Linux e seus serviços em rede. | ||
− | = | + | ==12/05: Apresentação== |
+ | O projeto final consiste em desenvolver a solução para uma empresa chamada '''Q Soluções'''. Essa empresa possui matriz e 5 filiais, todas em capitais do Estado. | ||
− | == | + | ===Necessidades=== |
+ | O "cliente" apresentou aos "prestadores de serviço" as seguintes necessidades: | ||
+ | * Cada unidade tem autonomia em termos de administração de redes e serviços. | ||
+ | * Cada unidade terá um subdomínio: <tt>fln.qsolucoes.com.br</tt>, <tt>ctb.qsolucoes.com.br</tt> e assim por diante. | ||
+ | * Há, em cada unidade, arquivos de foro interno e de foro externo. Os arquivos de foro externo precisam estar acessíveis a partir de qualquer IP válido. | ||
+ | * Deve haver a comunicação entre todas as pessoas da empresa. | ||
+ | * O monitoramento deve ser cruzado e de malha fechada entre todas as unidades. | ||
+ | * Deve haver backup diário incremental e backup completo semanal a ser enviado à matriz. | ||
− | == | + | ===Dinâmica das próximas aulas: Líder da Semana=== |
+ | A cada semana, 1 membro da equipe atuará como líder. Ele será responsável por: | ||
+ | * Intermediar a comunicação entre professor (cliente do "produto") e equipe (prestadores de serviço). | ||
+ | * Apresentar resultados semanais de evolução do "produto". | ||
+ | * Organizar-se junto aos outros líderes da semana para deliberar sobre as aulas: | ||
+ | ** Assunto de cada aula. | ||
+ | ** Tempo destinado à aula expositiva (professor) e desenvolvimento do projeto final (alunos). | ||
− | = | + | {|width="100%" style="background-color: #F0FFF0; font-family:Verdana, Arial, Helvetica, sans-serif; font-size: 100%; border: 1px solid #B1CDEB; text-align: left; padding-left: 7px" |
+ | | '''Equipe''' || '''12-14/05''' || '''19-21/05''' || '''26-28/05''' || '''02-04/06''' || '''09-11/06''' | ||
+ | |- | ||
+ | | rowspan="5" | Matriz (FLN) || Maykon | ||
+ | |- | ||
+ | | || Francisco | ||
+ | |- | ||
+ | | || || Wolney | ||
+ | |- | ||
+ | | || || || Maykon | ||
+ | |- | ||
+ | | || || || || Francisco | ||
+ | |- | ||
+ | | rowspan="5" | Porto Alegre (POA) || Eris | ||
+ | |- | ||
+ | | || Jessé | ||
+ | |- | ||
+ | | || || Eris | ||
+ | |- | ||
+ | | || || || Jessé | ||
+ | |- | ||
+ | | || || || || Eris | ||
+ | |- | ||
+ | | rowspan="5" | Curitiba (CTB) || Rodolfo | ||
+ | |- | ||
+ | | || Roberto | ||
+ | |- | ||
+ | | || || Luan | ||
+ | |- | ||
+ | | || || || Rodolfo | ||
+ | |- | ||
+ | | || || || || Roberto | ||
+ | |- | ||
+ | | rowspan="5" | São Paulo (SPO) || Jacob | ||
+ | |- | ||
+ | | || Mailin | ||
+ | |- | ||
+ | | || || Rubia | ||
+ | |- | ||
+ | | || || || Jacob | ||
+ | |- | ||
+ | | || || || || Mailin | ||
+ | |- | ||
+ | | rowspan="5" | Rio de Janeiro (RJO) || Jean | ||
+ | |- | ||
+ | | || Mário Allan | ||
+ | |- | ||
+ | | || || Mário André | ||
+ | |- | ||
+ | | || || || Jean | ||
+ | |- | ||
+ | | || || || || Mário Allan | ||
+ | |- | ||
+ | | rowspan="5" | Vitória (VIT) || Thiago | ||
+ | |- | ||
+ | | || Carla | ||
+ | |- | ||
+ | | || || Caroline | ||
+ | |- | ||
+ | | || || || Thiago | ||
+ | |- | ||
+ | | || || || || Carla | ||
+ | |- | ||
+ | |} | ||
− | ==19/05: | + | ==14/05: Revisão de S.O.== |
− | * | + | * Reinstalação dos sistemas operacionais para os servidores e roteadores. |
+ | |||
+ | ==19/05: Revisão dos Serviços Básicos== | ||
+ | * Roteamento, NAT e redirecionamento de porta | ||
+ | * Cron | ||
+ | * DHCP | ||
+ | * NTP | ||
+ | |||
+ | Abaixo, um exemplo de ''script shell'' a ser usado para filtro de pacotes, NAT e redirecionamento de porta: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | #!/bin/sh -e | ||
+ | # | ||
+ | # Na maioria dos casos, não é preciso mexer na área do código, basta apenas alterar o conteúdo das variáveis. | ||
+ | LOCAL="192.168.2.254" | ||
+ | IFACE_EXTERNA="eth1" | ||
+ | REDE_INTERNA="192.168.2.0/29" | ||
+ | SERVIDOR_INTERNO="192.168.2.1" | ||
+ | INTERNET_TCP="80 443" | ||
+ | INTERNET_UDP="53" | ||
+ | |||
+ | limpar_regras() | ||
+ | { | ||
+ | iptables -t filter -F | ||
+ | iptables -t nat -F | ||
+ | } | ||
− | + | politica_liberar() | |
+ | { | ||
+ | iptables -t filter -P INPUT ACCEPT | ||
+ | iptables -t filter -P FORWARD ACCEPT | ||
+ | iptables -t filter -P OUTPUT ACCEPT | ||
+ | } | ||
− | + | politica_negar() | |
+ | { | ||
+ | iptables -t filter -P INPUT DROP | ||
+ | iptables -t filter -P FORWARD DROP | ||
+ | iptables -t filter -P OUTPUT ACCEPT | ||
+ | } | ||
− | + | local() | |
+ | { | ||
+ | iptables -t filter -A INPUT -i lo -j ACCEPT | ||
+ | iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT | ||
+ | } | ||
− | + | rede_interna() | |
+ | { | ||
+ | # Liberar apenas acesso via SSH e ICMP tipo echo (ping) | ||
+ | iptables -t filter -A INPUT -s ${REDE_INTERNA} -d ${LOCAL} \ | ||
+ | -p tcp --dport 22 --syn -j ACCEPT | ||
+ | iptables -t filter -A INPUT -s ${REDE_INTERNA} -d ${LOCAL} \ | ||
+ | -p icmp --icmp-type echo-request -j ACCEPT | ||
+ | } | ||
− | + | internet() | |
− | + | { | |
+ | iptables -t nat -A POSTROUTING -o ${IFACE_EXTERNA} -j MASQUERADE | ||
+ | for porta in ${INTERNET_TCP} | ||
+ | do | ||
+ | iptables -t nat -A PREROUTING -p tcp --dport ${porta} --syn \ | ||
+ | --DNAT --to-destination ${SERVIDOR_INTERNO} | ||
+ | done | ||
+ | for porta in ${INTERNET_UDP} | ||
+ | do | ||
+ | iptables -t nat -A PREROUTING -p udp --dport ${porta} \ | ||
+ | --DNAT --to-destination ${SERVIDOR_INTERNO} | ||
+ | done | ||
+ | echo "." | ||
+ | } | ||
− | + | case ${1} in | |
− | * | + | "start"|"restart") |
+ | politica_negar | ||
+ | limpar_regras | ||
+ | local | ||
+ | rede_interna | ||
+ | internet | ||
+ | ;; | ||
+ | "stop") | ||
+ | politica_liberar | ||
+ | limparRegras | ||
+ | ;; | ||
+ | "status") | ||
+ | clear | ||
+ | iptables -t nat -L -n -v | ||
+ | echo | ||
+ | echo "Pressione ENTER para continuar..." | ||
+ | read tecla | ||
+ | iptables -t filter -L -n -v | ||
+ | ;; | ||
+ | *) | ||
+ | echo "Use: ${0} (start|stop|restart|status)" | ||
+ | esac | ||
+ | exit 0 | ||
+ | </syntaxhighlight> | ||
− | == | + | =Conceitos= |
+ | <center> | ||
+ | {| border=1 | ||
+ | | '''Aluno''' || '''Prova 1''' || '''Prova 2''' || '''Projeto final''' | ||
+ | |- | ||
+ | | Carla || D || C || D | ||
+ | |- | ||
+ | | Caroline || D || C || D | ||
+ | |- | ||
+ | | Eris || C || B ||A | ||
+ | |- | ||
+ | | Fabio || C || B || D | ||
+ | |- | ||
+ | | Francisco || C || A || C | ||
+ | |- | ||
+ | | Jacob || B || B ||A | ||
+ | |- | ||
+ | | Jean || C || B ||C | ||
+ | |- | ||
+ | | Jessé || C || B ||A | ||
+ | |- | ||
+ | | Luan || D || B ||D | ||
+ | |- | ||
+ | | Mailin || D || B ||B | ||
+ | |- | ||
+ | | Mário Allan || C || B ||D | ||
+ | |- | ||
+ | | Mário André || D || B ||D | ||
+ | |- | ||
+ | | Maykon || C || B ||B | ||
+ | |- | ||
+ | | Patrick || D || D ||D | ||
+ | |- | ||
+ | | Roberto || C || B ||D | ||
+ | |- | ||
+ | | Rodolfo || C || B ||B | ||
+ | |- | ||
+ | | Rubia || B || B ||B | ||
+ | |- | ||
+ | | Thiago || A || B ||D | ||
+ | |- | ||
+ | | Wolney || A || A ||C | ||
+ | |- | ||
+ | |} | ||
+ | </center> | ||
= Projeto Integrador= | = Projeto Integrador= | ||
− | == | + | ==07/06 até 09/07: Projeto Integrador== |
− | * [[Projeto Integrador - | + | * Para [[Projeto Integrador - 2010.1|este semestre]]. |
− | * [[Projeto Integrador - | + | * Veja também o projeto do [[Projeto Integrador - 2009.2|semestre anterior]]. |
{{Voltar|Gerência de Redes de Computadores (técnico) (página)|página principal da disciplina}} | {{Voltar|Gerência de Redes de Computadores (técnico) (página)|página principal da disciplina}} |
Edição atual tal como às 16h48min de 9 de julho de 2010
- Endereço encurtado: http://bit.ly/gar20101
- Diário de acordo com o plano de ensino.
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 |
SMTP | 25/TCP | /usr/lib/postfix/master | /etc/postfix/main.cf | /var/log/mail.log |
IMAP | 143/TCP | /usr/lib/dovecot/imap | /var/log/auth.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/02: 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.
- Para redes locais:
- 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
<code>
Passo 3: referência do ''script'' modelo para um nível de execução. Por predefinição (arquivos do diretório <tt>/etc/init</tt>), 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:
<syntaxhighlight lang=bash>
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.
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
Atualizada a Tabela de Serviços.
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
- Leitura do Guia básico de VoIP com Asterisk.
- Implementação de dois ramais em cada PBX:
- Ekiga softphone
- Telefone IP ou ATA
07/05: VoIP
- Interligação dos soft PBXs via prefixos: arquivo /etc/asterisk/extensions.conf.
Projeto Final da Disciplina
O projeto final da disciplina contemplará os estudos realacionados ao sistema operacional GNU/Linux e seus serviços em rede.
12/05: Apresentação
O projeto final consiste em desenvolver a solução para uma empresa chamada Q Soluções. Essa empresa possui matriz e 5 filiais, todas em capitais do Estado.
Necessidades
O "cliente" apresentou aos "prestadores de serviço" as seguintes necessidades:
- Cada unidade tem autonomia em termos de administração de redes e serviços.
- Cada unidade terá um subdomínio: fln.qsolucoes.com.br, ctb.qsolucoes.com.br e assim por diante.
- Há, em cada unidade, arquivos de foro interno e de foro externo. Os arquivos de foro externo precisam estar acessíveis a partir de qualquer IP válido.
- Deve haver a comunicação entre todas as pessoas da empresa.
- O monitoramento deve ser cruzado e de malha fechada entre todas as unidades.
- Deve haver backup diário incremental e backup completo semanal a ser enviado à matriz.
Dinâmica das próximas aulas: Líder da Semana
A cada semana, 1 membro da equipe atuará como líder. Ele será responsável por:
- Intermediar a comunicação entre professor (cliente do "produto") e equipe (prestadores de serviço).
- Apresentar resultados semanais de evolução do "produto".
- Organizar-se junto aos outros líderes da semana para deliberar sobre as aulas:
- Assunto de cada aula.
- Tempo destinado à aula expositiva (professor) e desenvolvimento do projeto final (alunos).
Equipe | 12-14/05 | 19-21/05 | 26-28/05 | 02-04/06 | 09-11/06 |
Matriz (FLN) | Maykon | ||||
Francisco | |||||
Wolney | |||||
Maykon | |||||
Francisco | |||||
Porto Alegre (POA) | Eris | ||||
Jessé | |||||
Eris | |||||
Jessé | |||||
Eris | |||||
Curitiba (CTB) | Rodolfo | ||||
Roberto | |||||
Luan | |||||
Rodolfo | |||||
Roberto | |||||
São Paulo (SPO) | Jacob | ||||
Mailin | |||||
Rubia | |||||
Jacob | |||||
Mailin | |||||
Rio de Janeiro (RJO) | Jean | ||||
Mário Allan | |||||
Mário André | |||||
Jean | |||||
Mário Allan | |||||
Vitória (VIT) | Thiago | ||||
Carla | |||||
Caroline | |||||
Thiago | |||||
Carla |
14/05: Revisão de S.O.
- Reinstalação dos sistemas operacionais para os servidores e roteadores.
19/05: Revisão dos Serviços Básicos
- Roteamento, NAT e redirecionamento de porta
- Cron
- DHCP
- NTP
Abaixo, um exemplo de script shell a ser usado para filtro de pacotes, NAT e redirecionamento de porta:
#!/bin/sh -e
#
# Na maioria dos casos, não é preciso mexer na área do código, basta apenas alterar o conteúdo das variáveis.
LOCAL="192.168.2.254"
IFACE_EXTERNA="eth1"
REDE_INTERNA="192.168.2.0/29"
SERVIDOR_INTERNO="192.168.2.1"
INTERNET_TCP="80 443"
INTERNET_UDP="53"
limpar_regras()
{
iptables -t filter -F
iptables -t nat -F
}
politica_liberar()
{
iptables -t filter -P INPUT ACCEPT
iptables -t filter -P FORWARD ACCEPT
iptables -t filter -P OUTPUT ACCEPT
}
politica_negar()
{
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT
}
local()
{
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
}
rede_interna()
{
# Liberar apenas acesso via SSH e ICMP tipo echo (ping)
iptables -t filter -A INPUT -s ${REDE_INTERNA} -d ${LOCAL} \
-p tcp --dport 22 --syn -j ACCEPT
iptables -t filter -A INPUT -s ${REDE_INTERNA} -d ${LOCAL} \
-p icmp --icmp-type echo-request -j ACCEPT
}
internet()
{
iptables -t nat -A POSTROUTING -o ${IFACE_EXTERNA} -j MASQUERADE
for porta in ${INTERNET_TCP}
do
iptables -t nat -A PREROUTING -p tcp --dport ${porta} --syn \
--DNAT --to-destination ${SERVIDOR_INTERNO}
done
for porta in ${INTERNET_UDP}
do
iptables -t nat -A PREROUTING -p udp --dport ${porta} \
--DNAT --to-destination ${SERVIDOR_INTERNO}
done
echo "."
}
case ${1} in
"start"|"restart")
politica_negar
limpar_regras
local
rede_interna
internet
;;
"stop")
politica_liberar
limparRegras
;;
"status")
clear
iptables -t nat -L -n -v
echo
echo "Pressione ENTER para continuar..."
read tecla
iptables -t filter -L -n -v
;;
*)
echo "Use: ${0} (start|stop|restart|status)"
esac
exit 0
Conceitos
Aluno | Prova 1 | Prova 2 | Projeto final |
Carla | D | C | D |
Caroline | D | C | D |
Eris | C | B | A |
Fabio | C | B | D |
Francisco | C | A | C |
Jacob | B | B | A |
Jean | C | B | C |
Jessé | C | B | A |
Luan | D | B | D |
Mailin | D | B | B |
Mário Allan | C | B | D |
Mário André | D | B | D |
Maykon | C | B | B |
Patrick | D | D | D |
Roberto | C | B | D |
Rodolfo | C | B | B |
Rubia | B | B | B |
Thiago | A | B | D |
Wolney | A | A | C |
Projeto Integrador
07/06 até 09/07: Projeto Integrador
- Para este semestre.
- Veja também o projeto do semestre anterior.