Mudanças entre as edições de "Gerência de Redes (diário 2012-1)"
(31 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) | |||
Linha 1: | Linha 1: | ||
− | O formato da apostila é [http://idpf.org/epub EPUB], publicado semanalmente | + | Calendário pós-greve: http://tele.sj.ifsc.edu.br/arquivos/publicos/Horarios2012-1_PosGreve/ |
+ | |||
+ | O formato da apostila é [http://idpf.org/epub EPUB], que fora publicado semanalmente até a metade da disciplina. Ele foi produzido usando o aplicativo [http://code.google.com/p/sigil/ Sigil]. | ||
Há diversos dispositivos para leitura desse formato. No Linux, o aplicativo <tt>calibre</tt> (para Ubuntu está disponível pelo seu [http://packages.ubuntu.com/search?keywords=calibre&searchon=names§ion=all repositório oficial]) lê e converte para esse formato. | Há diversos dispositivos para leitura desse formato. No Linux, o aplicativo <tt>calibre</tt> (para Ubuntu está disponível pelo seu [http://packages.ubuntu.com/search?keywords=calibre&searchon=names§ion=all repositório oficial]) lê e converte para esse formato. | ||
Linha 101: | Linha 103: | ||
** Maio | ** Maio | ||
** Junho | ** Junho | ||
− | ** | + | ** [[Gerência de Redes (diário 2012-1) - prova 4|Setembro]] |
onde serão avaliados, de forma prática, todos os conteúdos até a aula anterior. | onde serão avaliados, de forma prática, todos os conteúdos até a aula anterior. | ||
Linha 108: | Linha 110: | ||
** No máximo 1 C e nenhum D: B; | ** No máximo 1 C e nenhum D: B; | ||
** No máximo 1 D: C; | ** No máximo 1 D: C; | ||
− | ** Demais casos: D. | + | ** Demais casos: D[https://docs.google.com/spreadsheet/ccc?key=0AvKQkavuEKVtdDRTaTJ0bFBZb2lVLWFqSkJ3VEw2a1E .] |
=Ambiente de Trabalho= | =Ambiente de Trabalho= | ||
Linha 489: | Linha 491: | ||
mv roundcube webmail | mv roundcube webmail | ||
chown -R www-data:www-data webmail | chown -R www-data:www-data webmail | ||
− | find | + | find webmail -type d -exec chmod 700 {} \; |
− | find | + | find webmail -type f -exec chmod 400 {} \; |
</syntaxhighlight> | </syntaxhighlight> | ||
Embora as permissões não sejam as ideais (ainda é possível valores mais agressivos), isso permite a [http://trac.roundcube.net/wiki/Howto_Install continuação da aplicação via interface Web]: | Embora as permissões não sejam as ideais (ainda é possível valores mais agressivos), isso permite a [http://trac.roundcube.net/wiki/Howto_Install continuação da aplicação via interface Web]: | ||
− | http://www.rtfm.com.br/webmail/ | + | http://www.rtfm.com.br/webmail/installer |
+ | Segundo o guia oficial de instalação, é importante adicionar algumas permissões à aplicação (<tt>AllowOverride</tt>), uma vez que a mesma utiliza arquivos <tt>.htaccess</tt> para reduzir o acesso em alguns diretórios. Portanto, deve ser criado um arquivo de configuração para o Apache: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | 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 | ||
+ | </syntaxhighlight> | ||
+ | E, por fim, adicionar as linhas referentes ao serviço de email no serviço DNS, mas especificamente no final do arquivo <tt>/etc/bind/rtfm.com.br</tt>: | ||
+ | @ 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: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | service bind9 restart | ||
+ | </syntaxhighlight> | ||
+ | Ou, para aqueles que já conhecem o [http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.pdf rndc]: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | rndc reload | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ==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 [http://en.wikipedia.org/wiki/FCAPS 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''? | ||
+ | |||
+ | Desses itens acima listados, por questões de tempo e didática, serão abordados Monitoramento e Contabilização. Havendo tempo hábil, os demais também serão abordados. | ||
+ | |||
+ | ===Monitoramento=== | ||
+ | O termo recurso pode se aplicar, em termos de monitoramento, a um equipamento de rede ou serviço oferecido em rede. Isso implica a sua disponibilidade e um sistema monitor, que testa regularmente para saber do estado daquele. Havendo alguma falha no teste, será disparada uma ação específica e pré-programada, que pode ser desde um alerta ou mesmo uma ação corretiva sem a intervenção do admnistrador. | ||
+ | |||
+ | O monitoramento pode ser realizado a partir de ferramentas próprias do administrador (''scripts'' sob rotina), porém há aplicações desenvolvidas para tal, como por exemplo [http://nagios.org Nagios], [http://zenoss.com Zenoss] e outros. | ||
+ | |||
+ | Um ''script'': | ||
+ | <syntaxhighlight lang=bash> | ||
+ | #!/bin/bash | ||
+ | |||
+ | # Tem um endereço para testar? | ||
+ | if [ "${1}" = "" ] | ||
+ | then | ||
+ | echo "Use: ${0} <IP>" | ||
+ | exit | ||
+ | fi | ||
+ | |||
+ | # Coleta dos dados: quantidade de pings respondidos | ||
+ | RESPOSTA=$(ping -c 3 ${1} | grep received | cut -d , -f 2 | cut -d r -f 1) | ||
+ | |||
+ | # Teste: pelo menos um ping retornou? | ||
+ | if [ "${RESPOSTA}" -gt "0" ] | ||
+ | then | ||
+ | echo "No ar." | ||
+ | else | ||
+ | echo "Fora do ar." | ||
+ | fi | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ===Contabilização=== | ||
+ | Uma vez o recurso disponível em rede, pode-se contabilizar o seu uso; ou seja, ''quanto'' do recurso é utilizado. Na arquitetura TCP/IP, o protocolo mais usado para tal é o Simple Network Management Protocol (SNMP), documentado ao longo de [http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol#RFC_references várias RFCs]. Nesse protocolo, há as entidades principais: o ''dispositivo a ser monitorado'', deve possuir um ''agente'', uma aplicação simples que responde a requisições de consulta (<tt>GET</tt>) e de escrita (<tt>SET</tt>), e o ''gerente'' que realiza tais operações remotas (''network management system'' - NMS). | ||
+ | |||
+ | Cabe, portanto, ao gerente SNMP realizar, periodicamente, consultas aos vários agentes rodando nos dispositivos sob monitoramento. Esse processo regular se chama ''polling''. Porém, como cada agente possui informações específicas, como a tabela de roteamento de um roteador ou a quantidade de usuários conectados em um sistema UNIX-''like'', não há um modelo rígido de quais dados serão fornecidos. Ao invés disso, há um conjunto de documentos que definem quais informações estão disponíveis e como acessá-las: as ''Management Information Bases'' (MIBs). As MIBs organizam os dados de forma hierárquica, em árvore, onde cada um desses objetos (''object identifier'' - OID) possui: | ||
+ | * Uma localização numérica. | ||
+ | * Uma descrição textual. | ||
+ | * O tipo de dado a ser armazenado: número, data, texto, etc. | ||
+ | * O valor do dado. | ||
+ | Pelo fato de ser uma árvore, uma MIB pode, assim, estender a árvore global a partir de um ramo de outra MIB (lembrando: a árvore é uma estrutura de dados recursiva...). O subconjunto de MIBs utilizadas para um dispositivo (e seu agente) definem que informações podem ser coletadas pelo gerente. A título de exemplo, na [http://docs.oracle.com/cd/B16240_01/doc/em.102/b16244/chap1.htm#insertedID6 documentação de uma aplicação da Oracle] nota-se a extensão da árvore (nó .1.3.6.1.4.1) para atender a detalhes específicos do programa em questão. | ||
+ | |||
+ | Para visualizar as informações, pode-se instalar alguns comandos de consulta e escrita SNMP: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | aptitude install snmp | ||
+ | </syntaxhighlight> | ||
+ | Contudo, os comandos se aplicam apenas a operações básicas e acessando diretamente os dados. Para fazer pleno uso, i.e., utilizando as MIBs como referência, deve-se instalar também a lista atualizada das mesmas (e atualizar o arquivo de configuração <tt>snmp.conf</tt>): | ||
+ | <syntaxhighlight lang=bash> | ||
+ | aptitude install snmp-mibs-downloader | ||
+ | download-mibs | ||
+ | sed -i 's/^mibs\ :/#mibs\ :/g' /etc/snmp/snmp.conf | ||
+ | </syntaxhighlight> | ||
+ | Agora, pode-se realizar consultas aos agentes. | ||
+ | |||
+ | Um último conceito: a troca de dados entre agente e gerente se dá quando ambos pertencem a um mesmo agrupamento, ou '''comunidade'''. Na versão 3 do SNMP, é possível adicionar ainda autenticação ao processo. Geralmente, utilizam-se as versões 1 (equipamentos antigos ou de poucas funcionalidades) ou 2c. Os comandos a seguir perfazem toda a árvore do dispositivo (sequências de consultas: <tt>GETNEXT</tt>) alvo de forma sequencial do equipamento 192.168.1.1 e que pertence à comunidade <tt>ifsc</tt>: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | snmpwalk -v 2c -c ifsc 192.168.1.1 | ||
+ | snmpwalk -Of -v 2c -c ifsc 192.168.1.1 | ||
+ | snmpwalk -On -v 2c -c ifsc 192.168.1.1 | ||
+ | </syntaxhighlight> | ||
+ | O primeiro é o comando convencional. O segundo apresenta o nó da árvore de acordo com a descrição da MIB correspondente. O terceiro, por fim, apresenta todos os elementos com seu "endereço" numérico. Para saber mais sobre a correspondência entre número e descrição, há o comando <tt>translate</tt>: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | snmptranslate -Of .1.3.6.1.4.1 | ||
+ | snmptranslate -Oa .1.3.6.1.4.1 | ||
+ | </syntaxhighlight> | ||
+ | O primeiro comando "traduz" o seu valor, enquanto que o segundo identifica qual a MIB que o documenta. | ||
+ | |||
+ | ====Cenário==== | ||
+ | No nosso cenário, é interessante que todos os equipamentos importantes na rede estejam conm seus agentes operando e respondendo, regularmente, ao gerente central. Para fins didáticos, será utilizado o [http://cacti.net Cacti] como gerente, o qual é implementado em plataforma AMP; logo, pode-se aproveitar toda a infraestrutura de serviço Web e MySQL dos servidores da DMZ (Matriz). Embora sua documentação seja suficiente no auxílio de uma [http://www.cacti.net/downloads/docs/html/install_unix.html instalação manual], a instalação automatizada também o é: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | aptitude install cacti | ||
+ | </syntaxhighlight> | ||
+ | A configuração não será o foco deste tópico, uma vez que há [http://www.cacti.net/downloads/docs/html/basics.html documentação disponível para tal]. Ao invés, haverá a ênfase no SNMP em si. | ||
+ | |||
+ | No caso dos agentes, em sistemas variantes do UNIX, pode-se utilizar a implementação mais comum: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | aptitude install snmpd | ||
+ | </syntaxhighlight> | ||
+ | Inicialmente, pode ser utilizada uma configuração bastante simples: um agente que define uma única comunidade somente-leitura para gerente remoto - no caso, a comunidade <tt>ifsc</tt>. Além disso, é bastante recomendado informar '''onde está''' e '''quem é o responsável''' pelo dispositivo monitorado, de forma que seja possível, em termos de tempo hábil, corrigir ou prevenir uma falha. Esses são os objetos <tt>SNMPv2-MIB::sysLocation.0</tt> (<tt>.1.3.6.1.2.1.1.6.0</tt>) e <tt>SNMPv2-MIB::sysContact.0</tt> (<tt>.1.3.6.1.2.1.1.4.0</tt>), respectivamente. | ||
+ | <syntaxhighlight lang=bash> | ||
+ | cat > /etc/snmp/snmpd.conf << EOF | ||
+ | rocommunity ifsc | ||
+ | sysLocation IFSC Sao Jose - Laboratorio de Redes I | ||
+ | sysContact etorresini@ifsc.edu.br | ||
+ | EOF | ||
+ | sed -i 's/\ 127.0.0.1//g' /etc/default/snmpd | ||
+ | service snmpd restart | ||
+ | </syntaxhighlight> | ||
+ | O primeiro comando aplica toda a configuração do agente SNMP. O segundo comando permite conexões remotas (além de ''loopback''). O último, por fim, reinicia o serviço agente. | ||
+ | |||
+ | Para testar, pode-se realizar os comandos no mesmo servidor onde está instalado o gerente (Web), consultando desde o tempo no ar do agente (''uptime''), bem como os parâmetros definidos manualmente no arquivo acima. Assumindo que o agente está no computador com o IP 192.168.1.1: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | snmpget -v 2c -c ifsc 192.168.1.1 sysUpTimeInstance | ||
+ | snmpget -v 2c -c ifsc 192.168.1.1 sysLocation.0 | ||
+ | snmpget -v 2c -c ifsc 192.168.1.1 sysContact.0 | ||
+ | </syntaxhighlight> | ||
+ | Ou, com o ''endereço'' na árvore de objetos: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | snmpget -On -v 2c -c ifsc 192.168.1.1 sysUpTimeInstance | ||
+ | snmpget -On -v 2c -c ifsc 192.168.1.1 sysLocation.0 | ||
+ | snmpget -On -v 2c -c ifsc 192.168.1.1 sysContact.0 | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | O que se percebe, com os resultados acima, é que tais objetos está próximos na árvore: | ||
+ | * Tempo: <tt>.1.3.6.1.2.1.1.3.0</tt> | ||
+ | * Local: <tt>.1.3.6.1.2.1.1.4.0</tt> | ||
+ | * Responsável: <tt>.1.3.6.1.2.1.1.6.0</tt> | ||
+ | Logo, pode-se varrer (''walk'') um ramo superior da árvore comum a todos (<tt>.1.3.6.1.2.1.1<tt>), mostrando esses objetos próximos: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1.3.6.1.2.1.1 | ||
+ | </syntaxhighlight> | ||
+ | E, como uma árvore é um conceito recursivo, esse efeito se prolonga até o ramo principal, a raiz, mostrando mais e mais objetos: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1.3.6.1.2.1.1 | ||
+ | snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1.3.6.1.2.1 | ||
+ | snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1.3.6.1.2 | ||
+ | snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1.3.6.1 | ||
+ | snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1.3.6 | ||
+ | snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1.3 | ||
+ | snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1 | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | Dito isso, pode-se agora dizer que os objetos são indexados; ou seja, cada ramo da árvore possui um conjunto de informações relativamente próximas. Isso significa que os nomes de interface de rede estarão reunidos em um ramo: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | snmpwalk -v 2c -c ifsc 192.168.1.1 IF-MIB::ifDescr | ||
+ | snmpwalk -v 2c -c ifsc 192.168.1.1 .1.3.6.1.2.1.2.2.1.2 | ||
+ | </syntaxhighlight> | ||
+ | Enquanto que estatísticas de uso em outro, como quantidade de pacotes ''unicast'' transmitidos em outro, conferindo escalabilidade da árvore global: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | snmpwalk -v 2c -c ifsc 192.168.1.1 IF-MIB::ifOutUcastPkts | ||
+ | snmpwalk -v 2c -c ifsc 192.168.1.1 .1.3.6.1.2.1.2.2.1.17 | ||
+ | </syntaxhighlight> | ||
+ | Porém, como já dito, esses objetivos estão próximos, mais especificamente visíveis todos um nível acima: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | snmpwalk -v 2c -c ifsc 192.168.1.1 .1.3.6.1.2.1.2.2.1 | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | Nota-se, em todos os casos, o índice designando cada interface: geralmente a interface ''loopback'' é a primeira (sufixo <tt>1</tt>), seguida pelas demais - e seus sufixos ou terminações na sequência: eth0 (<tt>2</tt>), eth1 (<tt>3</tt>), eth2 (<tt>4</tt>) e assim por diante. | ||
+ | |||
+ | A ferramenta [http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&substep=2&translate=Translate&tree=NO Cisco SNMP Object Navigator] pode ser útil para navegar pela árvore e sua definição através das MIBs. | ||
+ | |||
+ | Por fim, uma tarefa a ser realizada: instalar e configurar o agente em todos os servidores da matriz e adicioná-las à contabilização do gerente Cacti no servidor Web. |
Edição atual tal como às 19h33min de 5 de novembro de 2016
Calendário pós-greve: http://tele.sj.ifsc.edu.br/arquivos/publicos/Horarios2012-1_PosGreve/
O formato da apostila é EPUB, que fora publicado semanalmente até a metade da disciplina. Ele foi produzido 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
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?
Desses itens acima listados, por questões de tempo e didática, serão abordados Monitoramento e Contabilização. Havendo tempo hábil, os demais também serão abordados.
Monitoramento
O termo recurso pode se aplicar, em termos de monitoramento, a um equipamento de rede ou serviço oferecido em rede. Isso implica a sua disponibilidade e um sistema monitor, que testa regularmente para saber do estado daquele. Havendo alguma falha no teste, será disparada uma ação específica e pré-programada, que pode ser desde um alerta ou mesmo uma ação corretiva sem a intervenção do admnistrador.
O monitoramento pode ser realizado a partir de ferramentas próprias do administrador (scripts sob rotina), porém há aplicações desenvolvidas para tal, como por exemplo Nagios, Zenoss e outros.
Um script:
#!/bin/bash
# Tem um endereço para testar?
if [ "${1}" = "" ]
then
echo "Use: ${0} <IP>"
exit
fi
# Coleta dos dados: quantidade de pings respondidos
RESPOSTA=$(ping -c 3 ${1} | grep received | cut -d , -f 2 | cut -d r -f 1)
# Teste: pelo menos um ping retornou?
if [ "${RESPOSTA}" -gt "0" ]
then
echo "No ar."
else
echo "Fora do ar."
fi
Contabilização
Uma vez o recurso disponível em rede, pode-se contabilizar o seu uso; ou seja, quanto do recurso é utilizado. Na arquitetura TCP/IP, o protocolo mais usado para tal é o Simple Network Management Protocol (SNMP), documentado ao longo de várias RFCs. Nesse protocolo, há as entidades principais: o dispositivo a ser monitorado, deve possuir um agente, uma aplicação simples que responde a requisições de consulta (GET) e de escrita (SET), e o gerente que realiza tais operações remotas (network management system - NMS).
Cabe, portanto, ao gerente SNMP realizar, periodicamente, consultas aos vários agentes rodando nos dispositivos sob monitoramento. Esse processo regular se chama polling. Porém, como cada agente possui informações específicas, como a tabela de roteamento de um roteador ou a quantidade de usuários conectados em um sistema UNIX-like, não há um modelo rígido de quais dados serão fornecidos. Ao invés disso, há um conjunto de documentos que definem quais informações estão disponíveis e como acessá-las: as Management Information Bases (MIBs). As MIBs organizam os dados de forma hierárquica, em árvore, onde cada um desses objetos (object identifier - OID) possui:
- Uma localização numérica.
- Uma descrição textual.
- O tipo de dado a ser armazenado: número, data, texto, etc.
- O valor do dado.
Pelo fato de ser uma árvore, uma MIB pode, assim, estender a árvore global a partir de um ramo de outra MIB (lembrando: a árvore é uma estrutura de dados recursiva...). O subconjunto de MIBs utilizadas para um dispositivo (e seu agente) definem que informações podem ser coletadas pelo gerente. A título de exemplo, na documentação de uma aplicação da Oracle nota-se a extensão da árvore (nó .1.3.6.1.4.1) para atender a detalhes específicos do programa em questão.
Para visualizar as informações, pode-se instalar alguns comandos de consulta e escrita SNMP:
aptitude install snmp
Contudo, os comandos se aplicam apenas a operações básicas e acessando diretamente os dados. Para fazer pleno uso, i.e., utilizando as MIBs como referência, deve-se instalar também a lista atualizada das mesmas (e atualizar o arquivo de configuração snmp.conf):
aptitude install snmp-mibs-downloader
download-mibs
sed -i 's/^mibs\ :/#mibs\ :/g' /etc/snmp/snmp.conf
Agora, pode-se realizar consultas aos agentes.
Um último conceito: a troca de dados entre agente e gerente se dá quando ambos pertencem a um mesmo agrupamento, ou comunidade. Na versão 3 do SNMP, é possível adicionar ainda autenticação ao processo. Geralmente, utilizam-se as versões 1 (equipamentos antigos ou de poucas funcionalidades) ou 2c. Os comandos a seguir perfazem toda a árvore do dispositivo (sequências de consultas: GETNEXT) alvo de forma sequencial do equipamento 192.168.1.1 e que pertence à comunidade ifsc:
snmpwalk -v 2c -c ifsc 192.168.1.1
snmpwalk -Of -v 2c -c ifsc 192.168.1.1
snmpwalk -On -v 2c -c ifsc 192.168.1.1
O primeiro é o comando convencional. O segundo apresenta o nó da árvore de acordo com a descrição da MIB correspondente. O terceiro, por fim, apresenta todos os elementos com seu "endereço" numérico. Para saber mais sobre a correspondência entre número e descrição, há o comando translate:
snmptranslate -Of .1.3.6.1.4.1
snmptranslate -Oa .1.3.6.1.4.1
O primeiro comando "traduz" o seu valor, enquanto que o segundo identifica qual a MIB que o documenta.
Cenário
No nosso cenário, é interessante que todos os equipamentos importantes na rede estejam conm seus agentes operando e respondendo, regularmente, ao gerente central. Para fins didáticos, será utilizado o Cacti como gerente, o qual é implementado em plataforma AMP; logo, pode-se aproveitar toda a infraestrutura de serviço Web e MySQL dos servidores da DMZ (Matriz). Embora sua documentação seja suficiente no auxílio de uma instalação manual, a instalação automatizada também o é:
aptitude install cacti
A configuração não será o foco deste tópico, uma vez que há documentação disponível para tal. Ao invés, haverá a ênfase no SNMP em si.
No caso dos agentes, em sistemas variantes do UNIX, pode-se utilizar a implementação mais comum:
aptitude install snmpd
Inicialmente, pode ser utilizada uma configuração bastante simples: um agente que define uma única comunidade somente-leitura para gerente remoto - no caso, a comunidade ifsc. Além disso, é bastante recomendado informar onde está e quem é o responsável pelo dispositivo monitorado, de forma que seja possível, em termos de tempo hábil, corrigir ou prevenir uma falha. Esses são os objetos SNMPv2-MIB::sysLocation.0 (.1.3.6.1.2.1.1.6.0) e SNMPv2-MIB::sysContact.0 (.1.3.6.1.2.1.1.4.0), respectivamente.
cat > /etc/snmp/snmpd.conf << EOF
rocommunity ifsc
sysLocation IFSC Sao Jose - Laboratorio de Redes I
sysContact etorresini@ifsc.edu.br
EOF
sed -i 's/\ 127.0.0.1//g' /etc/default/snmpd
service snmpd restart
O primeiro comando aplica toda a configuração do agente SNMP. O segundo comando permite conexões remotas (além de loopback). O último, por fim, reinicia o serviço agente.
Para testar, pode-se realizar os comandos no mesmo servidor onde está instalado o gerente (Web), consultando desde o tempo no ar do agente (uptime), bem como os parâmetros definidos manualmente no arquivo acima. Assumindo que o agente está no computador com o IP 192.168.1.1:
snmpget -v 2c -c ifsc 192.168.1.1 sysUpTimeInstance
snmpget -v 2c -c ifsc 192.168.1.1 sysLocation.0
snmpget -v 2c -c ifsc 192.168.1.1 sysContact.0
Ou, com o endereço na árvore de objetos:
snmpget -On -v 2c -c ifsc 192.168.1.1 sysUpTimeInstance
snmpget -On -v 2c -c ifsc 192.168.1.1 sysLocation.0
snmpget -On -v 2c -c ifsc 192.168.1.1 sysContact.0
O que se percebe, com os resultados acima, é que tais objetos está próximos na árvore:
- Tempo: .1.3.6.1.2.1.1.3.0
- Local: .1.3.6.1.2.1.1.4.0
- Responsável: .1.3.6.1.2.1.1.6.0
Logo, pode-se varrer (walk) um ramo superior da árvore comum a todos (.1.3.6.1.2.1.1), mostrando esses objetos próximos:
snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1.3.6.1.2.1.1
E, como uma árvore é um conceito recursivo, esse efeito se prolonga até o ramo principal, a raiz, mostrando mais e mais objetos:
snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1.3.6.1.2.1.1
snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1.3.6.1.2.1
snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1.3.6.1.2
snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1.3.6.1
snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1.3.6
snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1.3
snmpwalk -On -v 2c -c ifsc 192.168.1.1 .1
Dito isso, pode-se agora dizer que os objetos são indexados; ou seja, cada ramo da árvore possui um conjunto de informações relativamente próximas. Isso significa que os nomes de interface de rede estarão reunidos em um ramo:
snmpwalk -v 2c -c ifsc 192.168.1.1 IF-MIB::ifDescr
snmpwalk -v 2c -c ifsc 192.168.1.1 .1.3.6.1.2.1.2.2.1.2
Enquanto que estatísticas de uso em outro, como quantidade de pacotes unicast transmitidos em outro, conferindo escalabilidade da árvore global:
snmpwalk -v 2c -c ifsc 192.168.1.1 IF-MIB::ifOutUcastPkts
snmpwalk -v 2c -c ifsc 192.168.1.1 .1.3.6.1.2.1.2.2.1.17
Porém, como já dito, esses objetivos estão próximos, mais especificamente visíveis todos um nível acima:
snmpwalk -v 2c -c ifsc 192.168.1.1 .1.3.6.1.2.1.2.2.1
Nota-se, em todos os casos, o índice designando cada interface: geralmente a interface loopback é a primeira (sufixo 1), seguida pelas demais - e seus sufixos ou terminações na sequência: eth0 (2), eth1 (3), eth2 (4) e assim por diante.
A ferramenta Cisco SNMP Object Navigator pode ser útil para navegar pela árvore e sua definição através das MIBs.
Por fim, uma tarefa a ser realizada: instalar e configurar o agente em todos os servidores da matriz e adicioná-las à contabilização do gerente Cacti no servidor Web.