Gerência de Redes (diário 2012-1)
O formato da apostila é EPUB, publicado semanalmente no repositório do professor. Ele está em produção usando o aplicativo Sigil.
Há diversos dispositivos para leitura desse formato. No Linux, o aplicativo calibre (para Ubuntu está disponível pelo seu repositório oficial) lê e converte para esse formato.
Diretamente na rede há as seguintes opções:
- Addon EPUBReader para Firefox.
- O sítio MagicScroll, isolado ou como aplicativo para Google Chrome.
- O Aldiko Book Reader para celulares com Android.
| Script para facilitar o uso do GIT: |
|---|
|
|
Método de Avaliação
- Serão 4 provas, uma por mês:
- Abril
- Maio
- Junho
- Julho
onde serão avaliados, de forma prática, todos os conteúdos até a aula anterior.
- [A composição final do conceito se dará da seguinte forma:
- 4 A: A;
- No máximo 1 C e nenhum D: B;
- No máximo 1 D: C;
- Demais casos: D.
Ambiente de Trabalho
Link para cadastro no github: https://github.com/signup/free
NetKit
Eduardo Guse, João Carlos Warmling e Thiago Cunha
Foi usada a versão do netkit do professor Marcelo Sobral(gnome-netkit) disponível aqui.
- Repositório Git do projeto no github
Anderson Rosa e Ricardo Martins
Nós também utilizamos a versão gnome-netkit do Professor Marcelo Sobral
Marcelo,Gilberto,Paulo Alves e Liamari
Usamos tambem o gnome-netkit do professor Marcelo Sobral
- Lab.conf, dhcp.conf e interfaces : Repositorio do GitHub
Bruna Amante
Helton Luiz Porto, Emerson Gomes, Fernando
Utilizado gnome-netkit do professor Marcelo Sobral
Renato, Carlos Alberto, Rafael Pereira
Anderson Felisbino, Bolivar Lagos e Renan Hames
Michel Fernandes, Guilherme Bilbao, Jean Cesar
Rafael Luchi Luz
Carlos Moisés Araldi Maciel
Anderson Pereira, Paulo Vitor, Rafael Togo
Scripts e Arquivos de Configuração
Capítulo 1
- Item "Juntando as Peças..":
#!/bin/bash
#
# 20120320 Ederson Torresini: uma proposta de solução do item "Juntando as Peças..."
# Variáveis globais
TMP="/tmp/.saida"
enter()
{
echo ""
echo -n "Tecle [ENTER] para avançar..."
read enter
}
arquivosLocais()
{
echo ""
echo "Arquivos do tipo 'named pipe'. Por favor, aguarde..."
find / -type p -ls 2> /dev/null
enter
echo ""
echo "Arquivos do tipo UNIX 'socket'. Por favor, aguarde..."
find / -type s -ls 2> /dev/null
enter
}
sockets()
{
case ${1} in
"1")
lsof -n -P | grep TCP | grep LISTEN > ${TMP}
lsof -n -P | grep UDP | grep LISTEN >> ${TMP}
cat ${TMP} | sort
enter
;;
"2"|"3")
lsof -n -P | grep TCP | grep LISTEN > ${TMP}
lsof -n -P | grep UDP | grep LISTEN >> ${TMP}
cat ${TMP} | grep ${2} |sort
enter
;;
esac
}
cat /dev/null > ${TMP}
chmod 600 ${TMP}
if [ "$(id -u)" != "0" ]
then
echo "Rodando como usuário não privilegiado."
echo "Os resultados poderão estar incompletos."
enter
fi
while true
do
clear
echo "Por favor, escolha uma opção:"
echo "1) Arquivos locais (IPC)."
echo "2) 'Sockets'."
echo "n) Encerrar programa."
echo -n "Digite a sua opção: "
read opcao
case ${opcao} in
"1")
arquivosLocais
;;
"2")
echo ""
echo "Listar serviços por nome de processo, dono ou porta?"
echo "1) Processo."
echo "2) Dono."
echo "3) Porta."
echo -n "Digite a sua opção: "
read opcao
case ${opcao} in
"2")
echo ""
echo -n "Digite o nome do usuário: "
read subopcao
;;
"3")
echo ""
echo -n "Digite o número da porta: "
read subopcao
;;
esac
sockets ${opcao} ${subopcao}
;;
"n")
rm -f ${TMP}
exit
;;
*)
echo "Escolha opção válida."
esac
done
LAMP
O termo LAMP se refere a Linux + Apache + MySQL + PHP. Vamos aos passos para a instalação e configuração das aplicações de acordo com as necessidades.
Sempre será considerado o cenário visto em sala:
- Servidor DMZ 0: bora-bora
- IP: 192.168.3.1
- Serviço: MySQL
- Servidor DMZ 1: tuvalu
- IP: 192.168.3.2
- Serviço: HTTP
Blog
O CMS escolhido para o blog foi o Wordpress, um dos mais utilizados. De acordo com o cenário, o banco de dados será instalado no primeiro servidor, bora-bora, enquanto que o servidor Web será no segundo, Tuvalu.
Servidor 0: Bora-bora
Primeiro, a instalação do servidor MySQL:
aptitude install mysql-server
Depois, a configuração de um banco de dados para o blog. É criado um usuário webmaster, com a senha 'secret4', cujo acesso se dará a partir do servidor Web (informado pelo seu IP):
mysql -uroot -p mysql
Uma vez dentro do CLI do banco, através dos comandos SQL são criados tanto o usuário quanto o banco - incluindo seus relacionamentos:
CREATE DATABASE wordpress; GRANT ALL PRIVILEGES ON wordpress.* TO 'webmaster'@'192.168.3.2' IDENTIFIED BY 'secret4'; FLUSH PRIVILEGES;
Servidor 1: Tuvalu
No servidor Web, é instalado o servidor Web e o interpretador PHP - já com suporte a MySQL:
aptitude install apache2 php5 php5-mysql
Em seguida, é descarregado o código do Wordpress (última versão = 3.3.2) no diretório de publicação, /var/www, para compor a URL /blog:
cd /var/www
wget http://br.wordpress.org/wordpress-3.3.2-pt_BR.tar.gz
tar xzf wordpress-3.3.2-pt_BR.tar.gz
rm -f wordpress-3.3.2-pt_BR.tar.gz
mv wordpress blog
Depois, são aplicadas as permissões e propriedades para o total controle da aplicação:
chown -R www-data:www-data blog
find blog -type d -exec chmod 700 {} \;
find blog -type f -exec chmod 600 {} \;
Após a configuração do blog, pode-se facilitar o acesso ao código para o webmaster utilizando o WebDAV, que expande os métodos HTTP. Primeiro, é ativado o módulo do Apache e reiniciado o serviço:
a2enmod dav dav_fs dav_lock
service apache2 restart
O diretório do blog deve, pois, ter permissões especiais. É criado um arquivo de configuração para tal:
vi /etc/apache2/conf.d/blog
com o conteúdo:
<Directory /var/www/blog> Dav On </Directory>
Porém, por questões de segurança, deve-se restringir ao máximo tal diretório, permitindo que apenas o código PHP seja executado sem problemas. O arquivo fica assim:
<Directory /var/www/blog> Options None AllowOverride None Dav On </Directory>
Ainda assim, não haverá acesso externo. Isso acontece porque nas novas versões o Apache bloqueia por padrão (ou omissão). Deve-se liberar o acesso para qualquer IP:
<Directory /var/www/blog> Options None AllowOverride None Dav On Order allow,deny Allow from all </Directory>
E se o blog pudesse estar visível apenas via HTTPS? Bom, ativa-se o módulo SSL e redireciona todo o tráfego HTTP para HTTPS:
a2enmod ssl
a2ensite default-ssl
vi /etc/apache2/sites-enabled/000-default
onde adiciona-se a seguinte linha após a definição do VirtualHost:
RedirectMatch ^/(.*) https://www.rtfm.com.br/blog/
Cria-se um certificado auto-assinado para confirmar a identidade do sítio:
openssl req -new -x509 -nodes -days 365 -out /etc/ssl/certs/apache2.pem -keyout /etc/ssl/certs/apache2.pem
Na configuração do servidor Web via HTTPS, altera-se o certificado antigo por esse. No arquivo /etc/apache2/sites-enabled/default-ssl deve-se trocar as linhas:
SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
por
SSLCertificateFile /etc/ssl/certs/apache2.pem SSLCertificateKeyFile /etc/ssl/certs/apache2.pem
Até o presente momento, o blog está publicado na Web, com tráfego HTTPS disponível. Contudo, qualquer pessoa, inclusive o webmaster pode alterar o código PHP. Para controlar esse acesso, é adicionado um esquema de autenticação para limitar os métodos HTTP. Exceto os métodos básicos GET e POST, todos os outros métodos irão requerer autenticação:
<Directory /var/www/blog>
Options None
AllowOverride None
Dav On
Order allow,deny
Allow from all
<LimitExcept GET POST>
AuthType Basic
AuthName "Acesso Restrito."
AuthUserFile /etc/apache2/blog-senhas
Require valid-user
</LimitExcept
</Directory>
E, por fim, é criado o arquivo de senhas, /etc/apache2/blog-senhas com o comando htpasswd, e um primeiro chamado webmaster:
htpasswd -c -s /etc/apache2/blog-senhas webmaster
Embora se pergunte se ainda será possível ver o código PHP do Wordpress, ou mesmo os arquivos de usuário enviados via upload, usando WebDAV, a resposta é sim. Mas como o código já é software livre, e as imagens já estão disponíveis, qual a diferença?
Se quiser, pode-se utilizar outros métodos mais sofisticados, como WebDAV via HTTPS e acesso regular ao blog via HTTP. Assim, para todo o tráfego HTTPS é preciso autenticação do webmaster, tornando a solução mais segura.
O blog de Tele tem um cenário semelhante:
- HTTP sem WebDAV e sem senha:
- Blog: http://tele.sj.ifsc.edu.br/blog.
- Leitura de arquivo públicos: http://tele.sj.ifsc.edu.br/arquivos/alunos e http://tele.sj.ifsc.edu.br/arquivos/publicos/.
- HTTPS com WebDAV e com senha:
- Leitura e Escrita de arquivos públicos e restritos: todos os arquivos públicos, https://tele.sj.ifsc.edu.br/arquivos/cotel e https://tele.sj.ifsc.edu.br/arquivos/tele/.
digraph HTTP {
subgraph clusterHTTP
{
label="HTTP"
Blog [shape=Mrecord]
"Leitura de arquivos" [shape=Mrecord]
}
subgraph clusterHTTPS
{
label="HTTPS" [shape=Mrecord]
"Escrita de arquivos" [shape=Mrecord]
}
Blog -> "Leitura de arquivos"
Blog -> "Escrita de arquivos" [label="Redir"]
"Leitura de arquivos" -> "Escrita de arquivos" [label="Redir"]
"Escrita de arquivos" -> "Leitura de arquivos" [label="Redir"]
}
</graphviz>Resumo
Servidor 0: Bora-bora:
- Pacotes instalados:
mysql-server
- Comandos executados:
mysql -u root-p
Servidor 1: Tuvalu
- Pacotes instalados:
apache2 php5 php5-mysql
- Comandos executados:
a2enmod dav dav_fs dav_lock a2enmod ssl a2ensite ssl service apache2 restart
- Arquivos/diretórios modificados:
/var/www/blog/ /etc/apache2/sites-enable/000-default /etc/apache2/sites-enable/default-ssl /etc/apache2/conf.d/blog /etc/apache2/blog-senhas
digraph DHTML {
rankdir=LR
Cliente [shape=plaintext]
subgraph clusterBoraBora
{
label="Bora-Bora"
MySQL [shape=Mrecord]
}
subgraph clusterTuvalu
{
label="Tuvalu"
Apache [shape=Mrecord]
PHP [shape=Mrecord]
}
Cliente -> Apache [color=blue,label="HTTP"]
Apache -> PHP [color=green,label="Aplicação"]
PHP -> MySQL [color=red,label="SQL"]
}
</graphviz>Webmail
A aplicação Web escolhida foi RoundCube, que implementa uma interface amigável ao usuário final, como arrastar e soltar mensagens de uma caixa a outra (embora isso soe antigo, é bom lembrar que ainda há usuários com navegador sem suporte a tais funcionalidades). De acordo com o cenário, assim como o blog, o banco de dados será criado no servidor bora-bora e a aplicação Web em tuvalu.
Servidor 0: Bora-bora
Com o servidor MySQL já instalado, é preciso apenas cria a base:
mysql -uroot -p
E dentro da CLI do serviço:
CREATE DATABASE roundcube; GRANT ALL PRIVILEGES ON roundcube.* TO 'webmaster'@'192.168.3.2'; FLUSH PRIVILEGES;
Não é necessário associar, dessa vez, a senha ao usuário, uma vez que a tupla máquina-usuário-senha já existe. O que faltava, nesse caso, era relacionar o par máquina-usuário à base.
Servidor 1: Tuvalu
O servidor Web também será de SMTP e de IMAP, permitindo que, futuramente, seja permitido apenas o webmail em detrimento das aplicações locais (desktop).
Assim, para instalar o servidor SMTP, optou-se pelo Postfix por questões didáticas: documentação e facilidade de configuração e integração com outras aplicações. Dica: atenção especial aos parâmetros que iniciam por my.
aptitude install postfix
Uma vez instalado, o principal arquivo de configuração, /etc/postfix/main.cf, fica assim:
# Geral myhostname = mail.rtfm.com.br mydomain = rtfm.com.br # # MTA* -> MTA myorigin = @myhostname mynetworks = 127.0.0.0/8 [::1]/128 192.168.0.0/24 192.168.3.0/24 # # MTA -> MTA* inet_interfaces = all mydestination = rtfm.com.br, mail.rtfm.com.br, smtp.rtfm.com.br, localhost, localhost.localdomain relayhost = alias_maps = /etc/aliases
Como a ênfase está no webmail, ao invés da aplicação de desktop, será utilizado um servidor simples de IMAP, com a intenção de acesso exclusivo via Web:
aptitude install dovecot-imapd
E pronto! Não é necessário qualquer configuração. Lembrando que a configuração apresentada para ambos os serviços prevê usuários locais do sistema instalado; ou seja, todos aqueles listados nas fontes de busca (/etc/nsswitch.conf).
Agora sim, os pré-requisitos do RoundCube foram atendidos: LAMP + SMTP + IMAP. Próximo passo: descarregar o código PHP da aplicação. A última versão disponível é 0.7.2
cd /var/www/
wget http://downloads.sourceforge.net/project/roundcubemail/roundcubemail/0.7.2/roundcubemail-0.7.2.tar.gz
tar xzf roundcubemail-0.7.2.tar.gz
rm -f roundcubemail-0.7.2.tar.gz
mv roundcube webmail
chown -R www-data:www-data webmail
find webmail -type d -exec chmod 700 {} \;
find webmail -type f -exec chmod 400 {} \;
Embora as permissões não sejam as ideais (ainda é possível valores mais agressivos), isso permite a continuação da aplicação via interface Web:
http://www.rtfm.com.br/webmail/installer
Segundo o guia oficial de instalação, é importante adicionar algumas permissões à aplicação (AllowOverride), uma vez que a mesma utiliza arquivos .htaccess para reduzir o acesso em alguns diretórios. Portanto, deve ser criado um arquivo de configuração para o Apache:
cat > /etc/apache2/conf.d/webmail << EOF
<Directory /var/www/webmail/>
Options None
AllowOverride All
Order allow,deny
Allow from all
</Directory>
EOF
service apache2 restart
E, por fim, adicionar as linhas referentes ao serviço de email no serviço DNS, mas especificamente no final do arquivo /etc/bind/rtfm.com.br:
@ IN MX 0 mail.rtfm.com.br. mail IN A 192.168.3.2 smtp IN CNAME mail.rtfm.com.br. imap IN CNAME mail.rtmf.com.br.
E, claro, reiniciar o serviço:
service bind9 restart
Ou, para aqueles que já conhecem o rndc:
rndc reload
Gerência de Rede
A gerência de rede, embora vista oficialmente apenas no último mês de aula, é vista ao longo de toda a disciplina - por isso o seu nome. No modelo OSI, é utilizado o padrão FCAPS:
- Monitoramento (fault): o recurso está disponível?
- Configuração (configuration): o recurso está bem configurado?
- Contabilização (accounting): quanto do recurso está sendo utilizado?
- Desempenho (performance): o recurso está sendo bem usado?
- Segurança (security): o recurso está protegido?