Mudanças entre as edições de "Gerência de Redes (diário 2011-2)"

De MediaWiki do Campus São José
Ir para navegação Ir para pesquisar
 
(199 revisões intermediárias por 3 usuários não estão sendo mostradas)
Linha 1: Linha 1:
−
Endereço encurtadi: http://bit.ly/ger20112
+
Endereço encurtado: http://bit.ly/ger20112
 +
 
 
=Planejamento=
 
=Planejamento=
 
====01/08====
 
====01/08====
Linha 7: Linha 8:
 
Visão histórica dos sistemas operacionais, linguagens de programação e redes de computadores.
 
Visão histórica dos sistemas operacionais, linguagens de programação e redes de computadores.
  
−
=Revisão e Integração das Disciplinas=
+
=Projeto da Disciplina=
 +
A proposta de implementação de rede e seus serviços, até o final do semestre, é esta:
 +
<center>
 +
<graphviz>
 +
graph Projeto
 +
{
 +
  rankdir=LR
 +
  Internet [shape=circle]
 +
  Servidor_F [label=Servidor,shape=Mrecord]
 +
  Firewall_M [label=Firewall,shape=Mrecord]
 +
  Servidor_DMZ [label=Servidor,shape=Mrecord]
 +
  Servidor_LAN [label=Servidor,shape=Mrecord]
 +
  Switch_F [label=Switch,shape=record]
 +
  Switch_LAN [label=Switch,shape=record]
 +
  Cliente1_F [label="Cliente 1",shape=plaintext]
 +
  Cliente2_F [label="Cliente 2",shape=plaintext]
 +
  Cliente1_LAN [label="Cliente 1",shape=plaintext]
 +
  Cliente2_LAN [label="Cliente 2",shape=plaintext]
 +
  Cliente3_LAN [label="Cliente 3",shape=plaintext]
 +
  Internet -- Servidor_F
 +
  Internet -- Firewall_M
 +
  subgraph clusterFilial
 +
  {
 +
    label=Filial
 +
    Servidor_F -- Switch_F
 +
    Switch_F -- Cliente1_F
 +
    Switch_F -- Cliente2_F
 +
  }
 +
  subgraph clusterMatriz
 +
  {
 +
    label=Matriz
 +
    subgraph clusterDMZ
 +
    {
 +
      label=DMZ
 +
      Firewall_M -- Servidor_DMZ
 +
    }
 +
    subgraph clusterLAN
 +
    {
 +
      label=LAN
 +
      Firewall_M -- Switch_LAN
 +
      Switch_LAN -- Servidor_LAN
 +
      Switch_LAN -- Cliente1_LAN
 +
      Switch_LAN -- Cliente2_LAN
 +
      Switch_LAN -- Cliente3_LAN
 +
    }
 +
  }
 +
}
 +
</graphviz>
 +
</center>
 +
 
 +
==Método de trabalho==
 +
Este wiki será utilizado como diário de bordo das aulas ministradas, com referências a diversos documentos (livros e publicados na Internet, dando preferência a esse último).
 +
 
 +
Em relação à parte prática da disciplina, em que envolve a configuração dos sistemas operacionais e serviços agregados, será disponibilizado um [[#Controle de versão|repositório]] com os arquivos de configuração vistos em aula disponível para consulta:
 +
<syntaxhighlight lang=bash>
 +
git clone https://tele.sj.ifsc.edu.br/projetos/ger-etorresini/
 +
</syntaxhighlight>
 +
 
 +
Além disso, será também construída, ao longo da disciplina, uma [[#Serviços|tabela-resumo dos serviços de rede]] estudados.
 +
 
 +
=Revisão e Integração da Disciplina no Curso=
 
===Sistema Operacional===
 
===Sistema Operacional===
 
====08/08====
 
====08/08====
Linha 68: Linha 129:
 
Utilizado o [[Controle de versão|material publicado para a disciplina de TCC I]], uma vez que vários alunos fazem as duas matérias neste semestre.
 
Utilizado o [[Controle de versão|material publicado para a disciplina de TCC I]], uma vez que vários alunos fazem as duas matérias neste semestre.
  
 +
===NetKit===
 
====03/10====
 
====03/10====
 
Apresentação dos alunos sobre o NetKit, o qual será utilizado como ferramenta de apoio, junto ao controle de versão, para o projeto da disciplina.
 
Apresentação dos alunos sobre o NetKit, o qual será utilizado como ferramenta de apoio, junto ao controle de versão, para o projeto da disciplina.
  
−
A proposta de rede, até o final do semestre, é esta:
+
Em relação ao NetKit, trabalharemos com uma versão oficial [http://tele.sj.ifsc.edu.br/arquivos/alunos/ger/ congelada para uso] neste semestre de 2011-2, onde haverá três níveis de arquivo:
 +
* Configuração da rede: o arquivo <tt>lab.conf</tt> define os componentes da rede. Baixa taxa de modificação.
 +
* Modelo do sistema de arquivos: arquivo modelo a ser usado por toda máquina do cenário. Sem qualquer modificação ao longo do projeto.
 +
* Configuração dos computadores: cada máquina terá, além do modelo, arquivos adicionais de configuração dos serviços prestados (DHCP, DNS, HTTP e outros). Alta taxa de modificação.
 +
 
 +
Como serão duas redes distintas, unidas pela "nuvem Internet", haverá dois diretórios com os arquivos mutáveis: configuração da rede (arquivo <tt>lab.conf</tt>) e configuração das máquinas correspondentes.
 +
* Diretório raiz
 +
** Matriz
 +
*** lab.conf
 +
*** Firewall0
 +
**** Arquivo 1
 +
**** Arquivo 2
 +
**** Arquivo 3
 +
**** ...
 +
*** DMZ_Servidor0
 +
**** Arquivo 1
 +
**** Arquivo 2
 +
**** Arquivo 3
 +
**** ...
 +
*** LAN_Servidor0
 +
**** Arquivo 1
 +
**** Arquivo 2
 +
**** Arquivo 3
 +
**** ...
 +
** Filial
 +
*** lab.conf
 +
*** Servidor0
 +
**** Arquivo 1
 +
**** Arquivo 2
 +
**** Arquivo 3
 +
**** ...
 +
 
 +
Assim, poderemos controlar a versão de todos os arquivos mutáveis do projeto: configuração da rede e dos computadores. Para fazer isso, é preciso preparar o ambiente. A sequência dos passos está [http://tele.sj.ifsc.edu.br/blog/projetos/ descrita no blog de Tele], a qual explicamos abaixo para o usuário <tt>etorresini</tt>:
 +
<syntaxhighlight lang=bash>
 +
cd $HOME
 +
wget http://tele.sj.ifsc.edu.br/arquivos/publicos/.gitconfig
 +
vi .gitconfig
 +
wget http://tele.sj.ifsc.edu.br/arquivos/publicos/.netrc
 +
vi .netrc
 +
git clone https://tele.sj.ifsc.edu.br/projetos/ger-etorresini
 +
cd ger-etorresini
 +
mkdir Matriz
 +
vi Matriz/lab.conf
 +
git add Matriz/lab.conf
 +
mkdir Filial
 +
vi Filial/lab.conf
 +
git add Filial/lab.conf
 +
git commit -a -m "Arquivos de configuração do NetKit: redes Matriz e Filial."
 +
git push origin master
 +
</syntaxhighlight>
 +
 
 +
Esse processo, acima descrito, deve ser executado apenas na primeira vez. Nas demais ocasiões, é interessante sincronizar a base remota com a local (<tt>pull</tt>), editar o(s) arquivo(s), registrar a versão localmente (<tt>commit</tt>) e sincronizar a base local com a remota (<tt>push</tt>). Segue o exemplo abaixo:
 +
<syntaxhighlight lang=bash>
 +
cd $HOME/ger-etorresini
 +
git pull
 +
vi <nome do arquivo>
 +
vi <nome do outro arquivo>
 +
...
 +
git add <arquivo novo, se houver>
 +
git add <outro arquivo novo, se houver>
 +
git commit -a -m "<mensagem do commit>"
 +
git push
 +
</syntaxhighlight>
 +
O professor acompanhará as atividades pela [https://tele.sj.ifsc.edu.br/cgi-bin/gitweb.cgi interface Web comum a todos os projetos]. Os alunos poderão utilizar ferramentas CLI ou gráficas para ler os repositórios local e remoto(s), bem como material de apoio disponível na Internet <ref>CHACO, S. '''[http://progit.org/ Pro Git]'''. Apress. 2009.</ref>.
 +
 
 +
Dica do [http://www.sj.ifsc.edu.br/~msobral/netkit/ Prof. Sobral]: em cada máquina virtual, há um diretório <tt>/hostlab</tt>, que é um mapeamento do diretório do laboratório (máquina virtualizadora).
 +
 
 +
=Serviços=
 +
 
 +
A tabela abaixo se refere a sistemas baseados em Debian, como Ubuntu e NetKit.
 +
<center>
 +
{| border="1"
 +
|-
 +
| align=center | '''Tipo''' || align=center | '''Serviço''' || align=center | '''RFC''' || align=center | '''Porta''' || align=center | '''Executável''' || align=center | '''Configuração'''
 +
|-
 +
| rowspan=4 | Facilitadores || [[#Cron|Cron]] ||  ||  || /usr/sbin/cron || /etc/crontab
 +
|-
 +
| [[#Syslog|Syslog]] || [http://tools.ietf.org/html/rfc5424 5424] || 514/UDP || /usr/sbin/rsyslogd || /etc/rsyslog.conf
 +
|-
 +
| [[#NTP|NTP]] || [http://tools.ietf.org/html/rfc5905 5905] || 123/UDP || /usr/sbin/ntpd || /etc/ntp.conf
 +
|-
 +
| [[#DHCP|DHCP]] || [http://tools.ietf.org/html/rfc2131 2131] || 67/UDP || /usr/sbin/dhcpd || /etc/dhcp3/dhcpd.conf
 +
|-
 +
| Diretórios || [[#DNS|DNS]] || [http://tools.ietf.org/html/rfc1035 1035] || 53/UDP || /usr/sbin/named || /etc/bind/named.conf
 +
|-
 +
| Compartilhamento || [[#HTTP|HTTP]] || [http://tools.ietf.org/html/rfc2616 2616] || 80/TCP, 443/TCP || /usr/sbin/apache2 || /etc/apache2/apache2.conf
 +
|-
 +
|}
 +
</center>
 +
 
 +
==Facilitadores==
 +
===07/10===
 +
Vistos os serviços locais de sistema operacional cron e syslog, que tratam do agendamento de tarefas e registro de eventos respectivamente.
 +
 
 +
====Cron====
 +
Esse termo, comumente usado nos sistemas Windows, serve para abranger todos os serviços que programam a execução de aplicações em horários predefinidos, permitindo inclusive executá-los periodicamente. Nos sistemas baseados em UNIX (homenagem a [http://spectrum.ieee.org/tech-talk/computing/software/dennis-ritchie-1941-2011 Dennis Ritchie]), essa tarefa fica a cargo do serviço [http://en.wikipedia.org/wiki/Vixie_cron#Modern_versions cron].
 +
 
 +
Esse serviço não possui dependências, embora seja fortemente recomendado o uso de [[#NTP|hora certa]] para o sistema.
 +
<center>
 +
<graphviz>
 +
digraph Serviços
 +
{
 +
  Cron [shape=Mrecord]
 +
}
 +
</graphviz>
 +
</center>
 +
 
 +
 
 +
O cron possui arquivos de configuração para:
 +
* [http://livecronjobs.com/ Sistema]: <tt>/etc/crontab</tt>, que pode incluir outros arquivos.
 +
* [http://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html Usuário]: armazenado em <tt>/var/spool/cron/crontabs/<nowiki><usuário></nowiki></tt>, porém com edição facilitada pelo aplicativo <tt>crontab</tt>.
 +
 
 +
====Syslog====
 +
São os serviços responsáveis por registrar eventos importantes do sistema, como por exemplo detecção de novo ''hardware'' USB ou autenticação de usuário.
 +
 
 +
O serviço syslog, da família UNIX, organiza os registros, ou ''logs'', segundo a sua origem (''facility'') e gravidade (''priority''). Assim, todo ''log'' será identificado com a hora da ação, ''facility'' e ''priority''. De acordo com o arquivo de configuração do serviço, tal ''log'' será guardado em um ou mais arquivos - geralmente em <tt>/var/log</tt>. Contudo, não é possível guardar indefinidamente os ''logs'' por questão de espaço em disco, assim os sistemas já agendam reciclagem periódica dos ''logs'' mais antigos e rotação dos nomes dos arquivos: a aplicação <tt>logrotate</tt>.
 +
 
 
<center>
 
<center>
 
<graphviz>
 
<graphviz>
−
graph Projeto
+
digraph Serviços
 
{
 
{
−
rankdir=LR
+
  Cron [shape=Mrecord]
 +
  Syslog [shape=Mrecord]
  
−
Internet [shape=diamond]
+
  Syslog -> Cron
−
Servidor_F [shape=Mrecord]
+
}
 +
</graphviz>
 +
</center>
 +
 
 +
O serviço pode operar tanto localmente, o caso mais comum, como [http://tools.ietf.org/html/rfc5424 em rede]. Assim, é possível convergir todos os ''logs'' de uma rede, por exemplo, em um único servidor. Isso é possível porque informações como nome/IP da máquina e ''[http://www.unixtimestamp.com/ timestamp]'' fazem parte de cada registro.
  
−
Internet -- Servidor_F
+
E lembre-se: [http://www.syslog.org/wiki/Main/LogAnalyzers ler ''log'' é uma arte]...
−
Internet -- Firewall_M
 
  
−
Servidor_F -- Switch_F
+
===10/10===
−
Switch_F -- Cliente1_F
+
====NTP====
−
Switch_F -- Cliente2_F
+
Ambos os serviços mencionados na aula anterior dependem fortemente do sistema operando com a hora certa. O [http://datatracker.ietf.org/wg/ntp/charter/ histórico] protocolo [http://ntp.br/NTP/MenuNTPNtp NTP] permite a sincronização da hora dos sistemas em rede. No brasil, está disponível um ''pool'' de servidores: <tt>pool.ntp.br</tt> - parte de um [http://www.pool.ntp.org/ esforço global].
  
−
Firewall_M -- Servidor_DMZ
+
<center>
 +
<graphviz>
 +
digraph Serviços
 +
{
 +
  Cron [shape=Mrecord]
 +
  Syslog [shape=Mrecord]
 +
  NTP [shape=Mrecord]
  
−
Firewall_M -- Switch_LAN
+
  Syslog -> Cron
−
Switch_LAN -- Servidor_LAN
+
  Cron -> NTP
−
Switch_LAN -- Cliente1_LAN
+
  Syslog -> NTP
−
Switch_LAN -- Cliente2_LAN
 
−
Switch_LAN -- Cliente3_LAN
 
 
}
 
}
 
</graphviz>
 
</graphviz>
 
</center>
 
</center>
  
−
Em relação ao NetKit, trabalharemos com a sua [http://wiki.netkit.org/index.php/Download_Official versão oficial], onde haverá três níveis de arquivo:
+
A instalação e configuração do serviço é bastante simples ([http://ntp.br/NTP/MenuNTPGuia#Instala_o_para_GNU_Linux_e_outro baseado no guia do NTP.br]):
−
* Configuração da rede: arquivo do NetKit que define os componentes da rede. Baixa taxa de modificação.
+
<syntaxhighlight lang=bash>
−
* Modelo do sistema de arquivos: arquivo modelo a ser usado por toda máquina do cenário. Sem qualquer modificação ao longo do projeto.
+
apt-get install ntp
−
* Configuração dos computadores: cada máquina terá, além do modelo, arquivos adicionais de configuração dos serviços prestados (DHCP, DNS, HTTP e outros). Alta taxa de modificação.
+
</syntaxhighlight>
 +
E adicionar os servidores brasileiro, mantendo apenas essa linha (e removendo as demais):
 +
server pool.ntp.br
 +
e reiniciar o serviço:
 +
<syntaxhighlight lang=bash>
 +
/etc/init.d/ntp restart
 +
</syntaxhighlight>
 +
 
 +
Obs.: por questões de S.O., o serviço não alterará o relógio quando a diferença for maior que 128ms. Assim, nesses casos é preciso um ajuste diferenciado:
 +
<syntaxhighlight lang=bash>
 +
/etc/init.d/ntp stop
 +
ntpd -q -g
 +
/etc/init.d/ntp start
 +
</syntaxhighlight>
 +
 
 +
====DHCP====
 +
O serviço DHCP é um grande facilitador para atribuir endereço de rede às máquinas de mesma rede local. Descendente do [http://tools.ietf.org/html/rfc951 BOOTP], cuja função era iniciar sistemas operacionais completos remotamente,
 +
o DHCP é mais utilizado para automatizar a configuração de rede, em especial:
 +
* Endereço de rede
 +
* Máscara de sub-rede
 +
* Endereço de ''broadcasting''
 +
* Rota(s)-padrão
 +
* Servidor(es) DNS
 +
* Servidor(es) de hora certa na rede local
 +
Com o [http://tools.ietf.org/html/rfc4862 IPv6], esse serviço pode ser usado como opcional para configuração.
 +
 
 +
A implementação utilizada para a disciplina será a da [http://www.isc.org/software/dhcp ISC], cuja configuração é bastante facilitada. No exemplo a seguir (arquivo <tt>/etc/dhcp3/dhcpd.conf</tt>), o serviço DHCP em Servidor0 fornecerá IPs para até 100 clientes da rede local LAN no [[#Projeto da Disciplina|nosso cenário de estudo]]:
 +
# Autoridade para responder às requisições em 'broadcast'
 +
authoritative;
 +
#
 +
# Sem DDNS (http://tools.ietf.org/html/rfc2136)
 +
ddns-update-style none;
 +
#
 +
# Rede local
 +
subnet 10.0.0.0 netmask 255.0.0.0 {
 +
  #
 +
  # Endereços para a rede local
 +
  range 10.0.0.100 10.0.0.199;
 +
  option subnet-mask 255.0.0.0;
 +
  option broadcast-address 10.255.255.255;
 +
  #
 +
  # Firewall0
 +
  option routers 10.255.255.254;
 +
  #
 +
  # Servidor0 presta tanto o serviço DHCP como DNS
 +
  option domain-name-servers 10.0.0.1;
 +
  #
 +
  # Tempos de 'aluguel'
 +
  default-lease-time 3600;
 +
  max-lease-time 14400;
 +
}
  
−
Como serão duas redes distintas, unidas pela "nuvem Internet", haverá dois diretórios com configuração da rede (arquivo <tt>lab.conf</tt>) e configuração das máquinas correspondentes:
+
A nova rede de dependências de serviços fica assim:
−
* Diretório raiz
+
<center>
−
** Matriz
+
<graphviz>
−
*** <tt>lab.conf</tt>
+
digraph Serviços
−
** Filial
+
{
−
*** <tt>lab.conf</tt>
+
  Cron [shape=Mrecord]
 +
  Syslog [shape=Mrecord]
 +
  NTP [shape=Mrecord]
 +
  DHCP [shape=Mrecord]
  
−
Assim, poderemos controlar a versão de todos os arquivos mutáveis do projeto: configuração da rede e dos computadores.
+
  Syslog -> Cron
 +
  Cron -> NTP
 +
  Syslog -> NTP
 +
  DHCP -> NTP
 +
  DHCP -> Syslog
 +
}
 +
</graphviz>
 +
</center>
  
−
=Serviços=
 
−
==Facilitadores==
 
 
==Diretórios e Bancos de Dados==
 
==Diretórios e Bancos de Dados==
 +
===14/10===
 +
====DNS====
 +
O serviço DNS é provavelmente o mais crítico de Internet, uma vez que provê suporte a praticamente todos os outros. De estrutura hierárquica, inicia pelos [http://www.root-servers.org/ servidores raiz] e se ramifica em domínios e subdomínios cuja autoridade foi delegada - originalmente em [http://tools.ietf.org/html/rfc1591 pequena escala] se comparada à [http://www.iana.org/domains/root/db atual estrutura]. No Brasil, essa tarefa fica a cargo do [http://registro.br/ Registro.br].
 +
 +
Em conjunto com o DNS, o serviço WHOIS permite identificar as pessoas e organizações associadas a cada domínio.
 +
 +
Alguns [http://tools.ietf.org/html/rfc1034 conceitos básicos do sistema]:
 +
* Espaço de nomes (''Namespace'')
 +
* Zona (''Zone'')
 +
* Delegação de autoridade
 +
* [http://www.iana.org/assignments/dns-parameters Registro de recurso (''Resource Record'')]
 +
* Servidor de nomes
 +
 +
A rede de dependências dos serviços mostra-se mais complexa. A ligação entre DHCP e DNS é clara, e está explícita no [[#DHCP|arquivo de configuração daquele serviço]].
 +
<center>
 +
<graphviz>
 +
digraph Serviços
 +
{
 +
  Cron [shape=Mrecord]
 +
  Syslog [shape=Mrecord]
 +
  NTP [shape=Mrecord]
 +
  DHCP [shape=Mrecord]
 +
  DNS [shape=Mrecord]
 +
 +
  Syslog -> Cron
 +
  Cron -> NTP
 +
  Syslog -> NTP
 +
  DHCP -> NTP
 +
  DHCP -> Syslog
 +
  DNS -> DHCP
 +
  DNS -> NTP
 +
  DNS -> Syslog
 +
}
 +
</graphviz>
 +
</center>
 +
 +
===17/10===
 +
Manutenção do repositório para execução remota do ambiente.
 +
 +
A partir desse serviço, os arquivos de configuração serão publicados apenas no [[#Método de trabalho|repositório]].
 +
 +
===21/10===
 +
Primeira entrega do semestre: servidor DNS com domínio próprio funcional.
 +
 +
===24/10===
 +
Configuração do DNS reverso do domínio e integração entre DHCP e DNS.
 +
 
==Compartilhamento==
 
==Compartilhamento==
−
==Comunicação==
+
===28/10===
 +
====HTTP====
 +
Uma das vantagens da implementação Apache é a sua [http://httpd.apache.org/docs/2.2/ documentação].
 +
<center>
 +
<graphviz>
 +
digraph Serviços
 +
{
 +
  Cron [shape=Mrecord]
 +
  Syslog [shape=Mrecord]
 +
  NTP [shape=Mrecord]
 +
  DHCP [shape=Mrecord]
 +
  DNS [shape=Mrecord]
 +
  HTTP [shape=Mrecord]
 +
 
 +
  Syslog -> Cron
 +
  Cron -> NTP
 +
  Syslog -> NTP
 +
  DHCP -> NTP
 +
  DHCP -> Syslog
 +
  DNS -> DHCP
 +
  DNS -> NTP
 +
  DNS -> Syslog
 +
  HTTP -> DNS
 +
  HTTP -> NTP
 +
}
 +
</graphviz>
 +
</center>
 +
 
 +
===28/10===
 +
Atividade-relâmpago: disponibilizar uma página Web no servidor DMZ para acesso externo e interno (LAN).
 +
 
 +
===31/10===
 +
===04/11===
 +
====Aplicação Web: Blog====
 +
Aula destinada aos alunos para a realização da seguinte tarefa: publicar um blog no servidor externo do [[#Projeto da Disciplina|cenário]]. Recomendou-se o uso do Wordpress como CMS.
 +
 
 +
=====Preparação do Ambiente=====
 +
O sistema de arquivos escolhido para a disciplina não possui em sua instalação o PHP, um dos requisitos do Wordpress. Assim, foi necessário rodar uma máquina virtual em modo escrita para instalar, de forma permanente, a aplicação nas máquinas da Matriz:
 +
<syntaxhighlight lang=bash>
 +
vstart VM --append="eth0=tuntap,tapXX" -W -M 256
 +
</syntaxhighlight>
 +
onde:
 +
* <tt>VM</tt>: o nome da máquina virtual a ser executada. Recomenda-se utilizar uma já existente, em <tt>lab.conf</tt>.
 +
* <tt>tapXX</tt>: a interface virtual disponível pela máquina virtualizadora. Cada aluno já possui, pré-configurado, uma interface para a rede Matriz e outra para a Filial.
 +
* <tt>-W 256</tt>: como a instalação por pacotes nos sistemas Debian, incluindo NetKit, consome mais memória que os 32MB habituais do ambiente (opção <tt>VM_MEMORY</tt> do arquivo <tt>netkit/netkit.conf</tt>), optou-se por rodar essa VM em particular com mais recursos.
 +
 
 +
Após isto, a máquina virtual de testes será inciada, a qual por padrão utiliza como fonte de pacotes a Itália, para a alteração para o Brasil. Faça o seguinte:
 +
<syntaxhighlight lang=bash>
 +
cd /etc/apt
 +
vi sources.list
 +
</syntaxhighlight>
 +
Comente a linha com it, e desmarque o br, salve o arquivo.
 +
 
 +
Em seguida, configure a rede (com o auxílio do DHCP), baixe a chave de segurança PGP do repositório brasileiro, atualize a lista dos pacotes e instale os requisitos do Wordpress:
 +
<syntaxhighlight lang=bash>
 +
dhclient eth0
 +
gpg --keyserver pgp.mit.edu --recv-keys AED4B06F473041FA
 +
gpg --export -a |apt-key add -
 +
apt-get update
 +
apt-get install php5 php5-mysql
 +
</syntaxhighlight>
 +
 
 +
Por fim, remove todos os comandos do histórico, uma vez que essa VM está em modo escrita permanente:
 +
<syntaxhighlight lang=bash>
 +
cat /dev/null > /root/.bash_history
 +
history -c
 +
</syntaxhighlight>
 +
 
 +
Por fim, o servidor SQL. Como haveria problemas em operar o servidor dentro do ambiente NetKit, por causa da impermanência dos dados, optou-se por utilizar um servidor remoto: a máquina virtualizadora raul:
 +
* Servidor: raul, ou 172.18.19.0, ou raul.sj.ifsc.edu.br.
 +
* Base de dados: ger_<usuário>_wordpress
 +
* Usuário: <usuário, trocando . por _>
 +
* Senha: a interface TAP disponibilizada para a rede Matriz - específica por aluno.
 +
 
 +
=====Instalação da Aplicação Web=====
 +
A instalação se baseou fortemente no [http://codex.wordpress.org/pt-br:Instalando_o_WordPress guia oficial do CMS]:
 +
# Criação do diretório <tt>/var/www</tt> no servidor da DMZ, <tt>DMZ_Servidor0</tt>.
 +
# http://br.wordpress.org/ ''Download'' da [http://br.wordpress.org/ última versão em português do Brasil] do CMS.
 +
# Configuração do CMS via interface Web: <nowiki>http://<servidor>/blog</nowiki>.
 +
 
 +
<syntaxhighlight lang=bash>
 +
cd Matriz/DMZ_Servidor0
 +
mkdir -p var/www
 +
cd var/www
 +
wget http://br.wordpress.org/wordpress-3.2.1-pt_BR.tar.gz
 +
tar xzf wordpress-3.2.1-pt_BR.tar.gz
 +
rm wordpress-3.2.1-pt_BR.tar.gz
 +
mv wordpress blog
 +
find blog -type d -exec chmod 777 {} \;
 +
find blog -type f -exec chmod 666 {} \;
 +
</syntaxhighlight>
 +
Nota: como os alunos não podem modificar a propriedade dos arquivos, utilizaremos as permissões acima mencionadas; contudo, em ambientes de produção essa prática é totalmente desencorajada.
 +
 
 +
===07/11===
 +
 
 +
===11/11===
 +
Visão geral de [http://www.iti.gov.br/twiki/bin/view/Certificacao/PerguntasFrequentes certificação digital]. Na prática, a criação de um certificado auto-assinado para o servidor HTTPS (visível a partir do ''mundo externo'' do NetKit):
 +
openssl req -new -x509 -days 1460 -nodes -out /etc/ssl/certs/apache2.pem -keyout /etc/ssl/certs/apache2.pem
 +
 
 +
===18/11===
 +
O objetivo da aula foi colocar no ar o serviço [http://www.ietf.org/rfc/rfc4366.txt HTTPS]. A solução proposta em sala, vale salientar, foi para os SO GNU/Linux Debian e derivados, como Ubuntu. Para isso, foi necessário ativar o módulo SSL para que haja uma porta a "escutar" na porta 443. Com essa ativação os arquivos que estão no diretório modelo (<tt>/etc/apache2/mods-available</tt>) são direcionados para um de produção (<tt>/etc/apache2/mod-enabled</tt>). Vale lembrar que é necessário ter previamente um certificado digital - visto na aula anterior. Uma das definições desse arquivo trata das URLs, ou mais especificamente da porção servidor, vindo a ter ''virtual hosts'' específicos, os quais servem para configurar vários nomes: no cabeçalho da camada de aplicação pode ser passado o nome de máquina, dessa forma se pode ter muitos servidores web e essas páginas podem ter muitos nomes no DNS.
 +
 
 +
A sequência de passos fica portanto assim:
 +
* Criação de certificado digital, visto na [[#11/11|aula anterior]].
 +
* No caso do servidor Web Apache, hoje em sua segunda versão, a ativação do módulo SSL para processar requisições sobre SSL na porta 443/TCP. O recomendado seria utilizar ''links'' simbólicos, porém como estamos trabalhando com o ambiente NetKit, será utilizada a cópia dos arquivos (para posterior controle de versão) para evitar uma possível ligação "quebrada".
 +
<syntaxhighlight lang=bash>
 +
cd /etc/apache2/
 +
cp -p mod-enabled/ssl* mods-available/
 +
</syntaxhighlight>
 +
* Em seguida, a configuração do servidor com SSL. O arquivo <tt>/etc/apache2/sites-available/default-ssl</tt> será copiado (caso semelhante ao anterior) e modificado apenas o certificado - para se adequar ao primeiro passo:
 +
<syntaxhighlight lang=bash>
 +
cd /etc/apache2/
 +
cp -p sites-available sites-enabled/
 +
sed -i s/\tSSLCertificateFile.*/\tSSLCertificateFile /etc/ssl/certs/apache2.pem/g sites-enabled/default-ssl
 +
sed -i s/\tSSLCertificateKeyFile.*/\tSSLCertificateKeyFile /etc/ssl/certs/apache2.pem/g sites-enabled/default-ssl
 +
</syntaxhighlight>
 +
* Por último, reiniciar o serviço:
 +
<syntaxhighlight lang=bash>
 +
/etc/init.d/apache2 restart
 +
</syntaxhighlight>
 +
 
 +
Nota: sobre SSL, boa parte dos navegadores não implementa [http://en.wikipedia.org/wiki/HTTP_pipelining HTTP Pipelining]. Nas versões mais antigas do Internet Explorer (7 e inferiores), inclusive, deve-se forçar o uso do [http://www.w3.org/Protocols/HTTP/1.0/spec.html HTTP/1.0].
 +
 
 +
===21/11===
 +
====Aplicação Web: repositório de arquivos====
 +
A aplicação Web Wordpress provê a publicação de arquivos de mídia ([http://www.w3schools.com/php/php_file_upload.asp PHP]. É possível, além da própria ferramenta, utilizar outros mecanismos de transferências de arquivos em ambos os sentidos (cliente e servidor) sem as limitações das linguagens e suas aplicações - seja por razões de segurança ou implementação.
 +
 
 +
Uma dessas possibilidades é o WebDAV, que expande a gama de métodos HTTP para permitir a publicação de arquivos e manipulação de suas propriedades.
 +
 
 +
Para complementar a aplicação Wordpress, que provê um blog
 +
Tivemos nesse dia um resumo sobre a aula anterior de HTTPS, além de alguns procedimentos de como fazer com que o Apache tenha um sistema de autenticação, para isso foi criado um arquivo no diretório /etc/apache2/.htpasswd com comando htpasswd do Apache. Nesse arquivo foi definido que se tenha um usuário válido.
 +
<center><graphviz>
 +
digraph Site
 +
{
 +
  rankdir=LR
 +
  Cliente [shape=plaintext]
 +
  Blog [shape=Mrecord]
 +
  Repositório [shape=Mrecord]
 +
 
 +
  Cliente -> Blog [label=HTTP,color=blue,fontcolor=blue]
 +
  Cliente -> Repositório [label=HTTPS,color=red,fontcolor=red]
 +
  Blog -> Repositório [label=URL]
 +
}
 +
</graphviz></center>
 +
 
 +
===25/11===
 +
Atual estado do laboratório NetKit:
 +
 
 +
[[File:Labconf.jpg|Laboratório|200px]]
 +
[[File:Firewall0.jpg|200px|''Firewall'']]
 +
[[File:DMZ Servidor0.jpg|200px|DMZ: Servidor]]
 +
[[File:LAN Servidor0.jpg|200px|LAN: Servidor]]
 +
[[File:LAN micro0.jpg|200px|LAN: estação]]
 +
 
 
=Gerência=
 
=Gerência=
 +
<syntaxhighlight lang=bash>
 +
#!/bin/sh
 +
 +
# Variáveis
 +
TOTAL=$(cat /proc/meminfo |grep ^MemTotal | cut -d : -f 2 | cut -d k -f 1)
 +
LIVRE=$(cat /proc/meminfo |grep ^MemFree | cut -d : -f 2 | cut -d k -f 1)
 +
 +
# Porcentagem
 +
DIVISOR=$(expr ${LIVRE} \* 100)
 +
RESULTADO=$(expr ${DIVISOR} / ${TOTAL})
  
−
29/08 02/09
+
# Acima de 90% ocupado, ou 10% livre, para o serviço Apache.
−
05/09 09/09
+
if [ "${RESULTADO}" -le "10" ]
−
12/09 16/09
+
then
−
19/09 23/09
+
    # Para o Apache e informa via log a pouca memória disponível.
−
26/09 30/09
+
    /etc/init.d/apache2 stop > /dev/null 2> /dev/null
 +
    logger -p user.info "Serviço Apache parado, memória no limite: apenas ${RESULTADO}% livre."
 +
else
 +
    # Conta quantos processos com o nome "apache" existem
 +
    PROCESSOS=$(pidof apache2 | wc -w)
 +
    #
 +
    # Se o resultado for zero (Apache parado), inicia o serviço.
 +
    if [ "${PROCESSOS}" = "0" ]
 +
    then
 +
        /etc/init.d/apache2 start > /dev/null 2> /dev/null
 +
        logger -p user.info "(Re)Iniciando Apache - ${RESULTADO}% de memória principal disponível..."
 +
    else
 +
        logger -p user.info "Tranquilo, ainda há ${RESULTADO}% de memória principal disponível..."
 +
    fi
 +
fi
  
−
03/10 07/10
+
# Fim do programa: saída com sucesso.
−
10/10 14/10
+
exit 0
−
17/10 21/10
+
</syntaxhighlight>
−
24/10
 
−
31/10 04/11
 
−
07/11 11/11
 
−
      18/11
 
−
21/11 25/11
 
−
28/11 02/12
 
−
05/12 09/12
 
−
12/12 16/12
 
−
19/12
 
  
 
=Referências=
 
=Referências=

Edição atual tal como às 12h41min de 20 de dezembro de 2011

Endereço encurtado: http://bit.ly/ger20112

Planejamento

01/08

Discussão e montagem coletiva do plano de ensino deste semestre.

05/08

Visão histórica dos sistemas operacionais, linguagens de programação e redes de computadores.

Projeto da Disciplina

A proposta de implementação de rede e seus serviços, até o final do semestre, é esta:

<graphviz> graph Projeto { 

 rankdir=LR
 Internet [shape=circle]
 Servidor_F [label=Servidor,shape=Mrecord]
 Firewall_M [label=Firewall,shape=Mrecord]
 Servidor_DMZ [label=Servidor,shape=Mrecord]
 Servidor_LAN [label=Servidor,shape=Mrecord]
 Switch_F [label=Switch,shape=record]
 Switch_LAN [label=Switch,shape=record]
 Cliente1_F [label="Cliente 1",shape=plaintext]
 Cliente2_F [label="Cliente 2",shape=plaintext]
 Cliente1_LAN [label="Cliente 1",shape=plaintext]
 Cliente2_LAN [label="Cliente 2",shape=plaintext]
 Cliente3_LAN [label="Cliente 3",shape=plaintext]
 Internet -- Servidor_F
 Internet -- Firewall_M
 subgraph clusterFilial
 {
   label=Filial
   Servidor_F -- Switch_F
   Switch_F -- Cliente1_F
   Switch_F -- Cliente2_F
 }
 subgraph clusterMatriz
 {
   label=Matriz
   subgraph clusterDMZ
   {
     label=DMZ
     Firewall_M -- Servidor_DMZ
   }
   subgraph clusterLAN
   {
     label=LAN
     Firewall_M -- Switch_LAN
     Switch_LAN -- Servidor_LAN
     Switch_LAN -- Cliente1_LAN
     Switch_LAN -- Cliente2_LAN
     Switch_LAN -- Cliente3_LAN
   }
 }

} </graphviz>

Método de trabalho

Este wiki será utilizado como diário de bordo das aulas ministradas, com referências a diversos documentos (livros e publicados na Internet, dando preferência a esse último).

Em relação à parte prática da disciplina, em que envolve a configuração dos sistemas operacionais e serviços agregados, será disponibilizado um repositório com os arquivos de configuração vistos em aula disponível para consulta: 

git clone https://tele.sj.ifsc.edu.br/projetos/ger-etorresini/

Além disso, será também construída, ao longo da disciplina, uma tabela-resumo dos serviços de rede estudados.

Revisão e Integração da Disciplina no Curso

Sistema Operacional

08/08

Paralisação das atividades docentes.

12/08

Aula de sistemas operacionais baseados em UNIX, em particular GNU/Linux. Revisão dos conceitos originários do UNIX[1] e que podem ser utilizados na administração de sistemas até hoje, como por exemplo no Linux[2].

<graphviz>

graph SO { 

Usuário
"Memória principal"
"Dispositivo(s) de armazenamento"
subgraph clusterSO
{
 label="S.O."
 Usuários [shape=plaintext]
 Processos [shape=plaintext]
 Dados [shape=plaintext]
 Kernel [shape=circle]
}
Usuário -- Usuários [label=Interação,fontcolor=red,color=red]
"Memória principal" -- Processos [label=Processamento,fontcolor=red,color=red]
"Dispositivo(s) de armazenamento" -- Dados [label="Sistema(s) de arquivos",fontcolor=red,color=red]
Usuários -- Processos [color=lightgray]
Processos -- Dados [color=lightgray]
Kernel -- Usuários [color=blue]
Kernel -- Processos [color=blue,fontcolor=blue,label="Chamadas de sistema"]
Kernel -- Dados [color=blue]

}

</graphviz>

15/08

Visão do início do sistema (initialization) em PC, do POST à seleção do nível de execução.

Software básico

19/08

Do código-fonte, passando pela compilação e código final, ao empacotamento. Como exemplo, foi utilizado o Asterisk para compreensão do processo de compilação de software (bibliotecas, dependências, ativação de funcionalidades e outros). No Ubuntu 10.04 - já de posse do código no diretório corrente - foram necessários os comandos para uma instalação básica: 

aptitude update
aptitude install buid-essential
aptitude install libxml2-dev
aptitude install libsqlite3-dev
aptitude install libncurses-dev
./configure
make
make install
make samples
asterisk -c

Nota-se, nos comandos acima, os comandos aptitude para instalar via pacote as bibliotecas necessárias a compilação.

Rede

22/08

26/08

Não haverá aula devido a greve dos servidores públicos federais.

Controle de versão

29/09

Utilizado o material publicado para a disciplina de TCC I, uma vez que vários alunos fazem as duas matérias neste semestre.

NetKit

03/10

Apresentação dos alunos sobre o NetKit, o qual será utilizado como ferramenta de apoio, junto ao controle de versão, para o projeto da disciplina.

Em relação ao NetKit, trabalharemos com uma versão oficial congelada para uso neste semestre de 2011-2, onde haverá três níveis de arquivo:

  • Configuração da rede: o arquivo lab.conf define os componentes da rede. Baixa taxa de modificação.
  • Modelo do sistema de arquivos: arquivo modelo a ser usado por toda máquina do cenário. Sem qualquer modificação ao longo do projeto.
  • Configuração dos computadores: cada máquina terá, além do modelo, arquivos adicionais de configuração dos serviços prestados (DHCP, DNS, HTTP e outros). Alta taxa de modificação.

Como serão duas redes distintas, unidas pela "nuvem Internet", haverá dois diretórios com os arquivos mutáveis: configuração da rede (arquivo lab.conf) e configuração das máquinas correspondentes.

  • Diretório raiz
    • Matriz
      • lab.conf
      • Firewall0
        • Arquivo 1
        • Arquivo 2
        • Arquivo 3
        • ...
      • DMZ_Servidor0
        • Arquivo 1
        • Arquivo 2
        • Arquivo 3
        • ...
      • LAN_Servidor0
        • Arquivo 1
        • Arquivo 2
        • Arquivo 3
        • ...
    • Filial
      • lab.conf
      • Servidor0
        • Arquivo 1
        • Arquivo 2
        • Arquivo 3
        • ...

Assim, poderemos controlar a versão de todos os arquivos mutáveis do projeto: configuração da rede e dos computadores. Para fazer isso, é preciso preparar o ambiente. A sequência dos passos está descrita no blog de Tele, a qual explicamos abaixo para o usuário etorresini: 

cd $HOME
wget http://tele.sj.ifsc.edu.br/arquivos/publicos/.gitconfig
vi .gitconfig
wget http://tele.sj.ifsc.edu.br/arquivos/publicos/.netrc
vi .netrc
git clone https://tele.sj.ifsc.edu.br/projetos/ger-etorresini
cd ger-etorresini
mkdir Matriz
vi Matriz/lab.conf
git add Matriz/lab.conf
mkdir Filial
vi Filial/lab.conf
git add Filial/lab.conf
git commit -a -m "Arquivos de configuração do NetKit: redes Matriz e Filial."
git push origin master

Esse processo, acima descrito, deve ser executado apenas na primeira vez. Nas demais ocasiões, é interessante sincronizar a base remota com a local (pull), editar o(s) arquivo(s), registrar a versão localmente (commit) e sincronizar a base local com a remota (push). Segue o exemplo abaixo: 

cd $HOME/ger-etorresini
git pull
vi <nome do arquivo>
vi <nome do outro arquivo>
...
git add <arquivo novo, se houver>
git add <outro arquivo novo, se houver>
git commit -a -m "<mensagem do commit>"
git push

O professor acompanhará as atividades pela interface Web comum a todos os projetos. Os alunos poderão utilizar ferramentas CLI ou gráficas para ler os repositórios local e remoto(s), bem como material de apoio disponível na Internet [3].

Dica do Prof. Sobral: em cada máquina virtual, há um diretório /hostlab, que é um mapeamento do diretório do laboratório (máquina virtualizadora).

Serviços

A tabela abaixo se refere a sistemas baseados em Debian, como Ubuntu e NetKit.

Tipo Serviço RFC Porta Executável Configuração
Facilitadores Cron /usr/sbin/cron /etc/crontab
Syslog 5424 514/UDP /usr/sbin/rsyslogd /etc/rsyslog.conf
NTP 5905 123/UDP /usr/sbin/ntpd /etc/ntp.conf
DHCP 2131 67/UDP /usr/sbin/dhcpd /etc/dhcp3/dhcpd.conf
Diretórios DNS 1035 53/UDP /usr/sbin/named /etc/bind/named.conf
Compartilhamento HTTP 2616 80/TCP, 443/TCP /usr/sbin/apache2 /etc/apache2/apache2.conf

Facilitadores

07/10

Vistos os serviços locais de sistema operacional cron e syslog, que tratam do agendamento de tarefas e registro de eventos respectivamente.

Cron

Esse termo, comumente usado nos sistemas Windows, serve para abranger todos os serviços que programam a execução de aplicações em horários predefinidos, permitindo inclusive executá-los periodicamente. Nos sistemas baseados em UNIX (homenagem a Dennis Ritchie), essa tarefa fica a cargo do serviço cron.

Esse serviço não possui dependências, embora seja fortemente recomendado o uso de hora certa para o sistema.

<graphviz> digraph Serviços { 

 Cron [shape=Mrecord]

} </graphviz>


O cron possui arquivos de configuração para:

  • Sistema: /etc/crontab, que pode incluir outros arquivos.
  • Usuário: armazenado em /var/spool/cron/crontabs/<usuário>, porém com edição facilitada pelo aplicativo crontab.

Syslog

São os serviços responsáveis por registrar eventos importantes do sistema, como por exemplo detecção de novo hardware USB ou autenticação de usuário.

O serviço syslog, da família UNIX, organiza os registros, ou logs, segundo a sua origem (facility) e gravidade (priority). Assim, todo log será identificado com a hora da ação, facility e priority. De acordo com o arquivo de configuração do serviço, tal log será guardado em um ou mais arquivos - geralmente em /var/log. Contudo, não é possível guardar indefinidamente os logs por questão de espaço em disco, assim os sistemas já agendam reciclagem periódica dos logs mais antigos e rotação dos nomes dos arquivos: a aplicação logrotate.

<graphviz> digraph Serviços { 

 Cron [shape=Mrecord]
 Syslog [shape=Mrecord]

 Syslog -> Cron

} </graphviz>

O serviço pode operar tanto localmente, o caso mais comum, como em rede. Assim, é possível convergir todos os logs de uma rede, por exemplo, em um único servidor. Isso é possível porque informações como nome/IP da máquina e timestamp fazem parte de cada registro.

E lembre-se: ler log é uma arte...

10/10

NTP

Ambos os serviços mencionados na aula anterior dependem fortemente do sistema operando com a hora certa. O histórico protocolo NTP permite a sincronização da hora dos sistemas em rede. No brasil, está disponível um pool de servidores: pool.ntp.br - parte de um esforço global.

<graphviz> digraph Serviços { 

 Cron [shape=Mrecord]
 Syslog [shape=Mrecord]
 NTP [shape=Mrecord]

 Syslog -> Cron
 Cron -> NTP
 Syslog -> NTP

} </graphviz>

A instalação e configuração do serviço é bastante simples (baseado no guia do NTP.br): 

apt-get install ntp

E adicionar os servidores brasileiro, mantendo apenas essa linha (e removendo as demais): 

server pool.ntp.br

e reiniciar o serviço: 

/etc/init.d/ntp restart

Obs.: por questões de S.O., o serviço não alterará o relógio quando a diferença for maior que 128ms. Assim, nesses casos é preciso um ajuste diferenciado: 

/etc/init.d/ntp stop
ntpd -q -g 
/etc/init.d/ntp start

DHCP

O serviço DHCP é um grande facilitador para atribuir endereço de rede às máquinas de mesma rede local. Descendente do BOOTP, cuja função era iniciar sistemas operacionais completos remotamente, o DHCP é mais utilizado para automatizar a configuração de rede, em especial:

  • Endereço de rede
  • Máscara de sub-rede
  • Endereço de broadcasting
  • Rota(s)-padrão
  • Servidor(es) DNS
  • Servidor(es) de hora certa na rede local

Com o IPv6, esse serviço pode ser usado como opcional para configuração.

A implementação utilizada para a disciplina será a da ISC, cuja configuração é bastante facilitada. No exemplo a seguir (arquivo /etc/dhcp3/dhcpd.conf), o serviço DHCP em Servidor0 fornecerá IPs para até 100 clientes da rede local LAN no nosso cenário de estudo: 

# Autoridade para responder às requisições em 'broadcast'
authoritative;
#
# Sem DDNS (http://tools.ietf.org/html/rfc2136)
ddns-update-style none;
#
# Rede local
subnet 10.0.0.0 netmask 255.0.0.0 {
  #
  # Endereços para a rede local
  range 10.0.0.100 10.0.0.199;
  option subnet-mask 255.0.0.0;
  option broadcast-address 10.255.255.255;
  #
  # Firewall0
  option routers 10.255.255.254;
  #
  # Servidor0 presta tanto o serviço DHCP como DNS
  option domain-name-servers 10.0.0.1;
  #
  # Tempos de 'aluguel'
  default-lease-time 3600; 
  max-lease-time 14400; 
}

A nova rede de dependências de serviços fica assim:

<graphviz> digraph Serviços { 

 Cron [shape=Mrecord]
 Syslog [shape=Mrecord]
 NTP [shape=Mrecord]
 DHCP [shape=Mrecord]

 Syslog -> Cron
 Cron -> NTP
 Syslog -> NTP
 DHCP -> NTP
 DHCP -> Syslog

} </graphviz>

Diretórios e Bancos de Dados

14/10

DNS

O serviço DNS é provavelmente o mais crítico de Internet, uma vez que provê suporte a praticamente todos os outros. De estrutura hierárquica, inicia pelos servidores raiz e se ramifica em domínios e subdomínios cuja autoridade foi delegada - originalmente em pequena escala se comparada à atual estrutura. No Brasil, essa tarefa fica a cargo do Registro.br.

Em conjunto com o DNS, o serviço WHOIS permite identificar as pessoas e organizações associadas a cada domínio.

Alguns conceitos básicos do sistema:

A rede de dependências dos serviços mostra-se mais complexa. A ligação entre DHCP e DNS é clara, e está explícita no arquivo de configuração daquele serviço.

<graphviz> digraph Serviços { 

 Cron [shape=Mrecord]
 Syslog [shape=Mrecord]
 NTP [shape=Mrecord]
 DHCP [shape=Mrecord]
 DNS [shape=Mrecord]

 Syslog -> Cron
 Cron -> NTP
 Syslog -> NTP
 DHCP -> NTP
 DHCP -> Syslog
 DNS -> DHCP
 DNS -> NTP
 DNS -> Syslog

} </graphviz>

17/10

Manutenção do repositório para execução remota do ambiente.

A partir desse serviço, os arquivos de configuração serão publicados apenas no repositório.

21/10

Primeira entrega do semestre: servidor DNS com domínio próprio funcional.

24/10

Configuração do DNS reverso do domínio e integração entre DHCP e DNS.

Compartilhamento

28/10

HTTP

Uma das vantagens da implementação Apache é a sua documentação.

<graphviz> digraph Serviços { 

 Cron [shape=Mrecord]
 Syslog [shape=Mrecord]
 NTP [shape=Mrecord]
 DHCP [shape=Mrecord]
 DNS [shape=Mrecord]
 HTTP [shape=Mrecord]

 Syslog -> Cron
 Cron -> NTP
 Syslog -> NTP
 DHCP -> NTP
 DHCP -> Syslog
 DNS -> DHCP
 DNS -> NTP
 DNS -> Syslog
 HTTP -> DNS
 HTTP -> NTP

} </graphviz>

28/10

Atividade-relâmpago: disponibilizar uma página Web no servidor DMZ para acesso externo e interno (LAN).

31/10

04/11

Aplicação Web: Blog

Aula destinada aos alunos para a realização da seguinte tarefa: publicar um blog no servidor externo do cenário. Recomendou-se o uso do Wordpress como CMS.

Preparação do Ambiente

O sistema de arquivos escolhido para a disciplina não possui em sua instalação o PHP, um dos requisitos do Wordpress. Assim, foi necessário rodar uma máquina virtual em modo escrita para instalar, de forma permanente, a aplicação nas máquinas da Matriz: 

vstart VM --append="eth0=tuntap,tapXX" -W -M 256

onde:

  • VM: o nome da máquina virtual a ser executada. Recomenda-se utilizar uma já existente, em lab.conf.
  • tapXX: a interface virtual disponível pela máquina virtualizadora. Cada aluno já possui, pré-configurado, uma interface para a rede Matriz e outra para a Filial.
  • -W 256: como a instalação por pacotes nos sistemas Debian, incluindo NetKit, consome mais memória que os 32MB habituais do ambiente (opção VM_MEMORY do arquivo netkit/netkit.conf), optou-se por rodar essa VM em particular com mais recursos.

Após isto, a máquina virtual de testes será inciada, a qual por padrão utiliza como fonte de pacotes a Itália, para a alteração para o Brasil. Faça o seguinte: 

cd /etc/apt
vi sources.list

Comente a linha com it, e desmarque o br, salve o arquivo.

Em seguida, configure a rede (com o auxílio do DHCP), baixe a chave de segurança PGP do repositório brasileiro, atualize a lista dos pacotes e instale os requisitos do Wordpress: 

dhclient eth0
gpg --keyserver pgp.mit.edu --recv-keys AED4B06F473041FA
gpg --export -a |apt-key add -
apt-get update
apt-get install php5 php5-mysql

Por fim, remove todos os comandos do histórico, uma vez que essa VM está em modo escrita permanente: 

cat /dev/null > /root/.bash_history
history -c

Por fim, o servidor SQL. Como haveria problemas em operar o servidor dentro do ambiente NetKit, por causa da impermanência dos dados, optou-se por utilizar um servidor remoto: a máquina virtualizadora raul:

  • Servidor: raul, ou 172.18.19.0, ou raul.sj.ifsc.edu.br.
  • Base de dados: ger_<usuário>_wordpress
  • Usuário: <usuário, trocando . por _>
  • Senha: a interface TAP disponibilizada para a rede Matriz - específica por aluno.
Instalação da Aplicação Web

A instalação se baseou fortemente no guia oficial do CMS:

  1. Criação do diretório /var/www no servidor da DMZ, DMZ_Servidor0.
  2. http://br.wordpress.org/ Download da última versão em português do Brasil do CMS.
  3. Configuração do CMS via interface Web: http://<servidor>/blog.
cd Matriz/DMZ_Servidor0
mkdir -p var/www
cd var/www
wget http://br.wordpress.org/wordpress-3.2.1-pt_BR.tar.gz
tar xzf wordpress-3.2.1-pt_BR.tar.gz 
rm wordpress-3.2.1-pt_BR.tar.gz 
mv wordpress blog
find blog -type d -exec chmod 777 {} \;
find blog -type f -exec chmod 666 {} \;

Nota: como os alunos não podem modificar a propriedade dos arquivos, utilizaremos as permissões acima mencionadas; contudo, em ambientes de produção essa prática é totalmente desencorajada.

07/11

11/11

Visão geral de certificação digital. Na prática, a criação de um certificado auto-assinado para o servidor HTTPS (visível a partir do mundo externo do NetKit): 

openssl req -new -x509 -days 1460 -nodes -out /etc/ssl/certs/apache2.pem -keyout /etc/ssl/certs/apache2.pem

18/11

O objetivo da aula foi colocar no ar o serviço HTTPS. A solução proposta em sala, vale salientar, foi para os SO GNU/Linux Debian e derivados, como Ubuntu. Para isso, foi necessário ativar o módulo SSL para que haja uma porta a "escutar" na porta 443. Com essa ativação os arquivos que estão no diretório modelo (/etc/apache2/mods-available) são direcionados para um de produção (/etc/apache2/mod-enabled). Vale lembrar que é necessário ter previamente um certificado digital - visto na aula anterior. Uma das definições desse arquivo trata das URLs, ou mais especificamente da porção servidor, vindo a ter virtual hosts específicos, os quais servem para configurar vários nomes: no cabeçalho da camada de aplicação pode ser passado o nome de máquina, dessa forma se pode ter muitos servidores web e essas páginas podem ter muitos nomes no DNS.

A sequência de passos fica portanto assim:

  • Criação de certificado digital, visto na aula anterior.
  • No caso do servidor Web Apache, hoje em sua segunda versão, a ativação do módulo SSL para processar requisições sobre SSL na porta 443/TCP. O recomendado seria utilizar links simbólicos, porém como estamos trabalhando com o ambiente NetKit, será utilizada a cópia dos arquivos (para posterior controle de versão) para evitar uma possível ligação "quebrada".
cd /etc/apache2/
cp -p mod-enabled/ssl* mods-available/
  • Em seguida, a configuração do servidor com SSL. O arquivo /etc/apache2/sites-available/default-ssl será copiado (caso semelhante ao anterior) e modificado apenas o certificado - para se adequar ao primeiro passo:
cd /etc/apache2/
cp -p sites-available sites-enabled/
sed -i s/\tSSLCertificateFile.*/\tSSLCertificateFile /etc/ssl/certs/apache2.pem/g sites-enabled/default-ssl
sed -i s/\tSSLCertificateKeyFile.*/\tSSLCertificateKeyFile /etc/ssl/certs/apache2.pem/g sites-enabled/default-ssl
  • Por último, reiniciar o serviço:
/etc/init.d/apache2 restart

Nota: sobre SSL, boa parte dos navegadores não implementa HTTP Pipelining. Nas versões mais antigas do Internet Explorer (7 e inferiores), inclusive, deve-se forçar o uso do HTTP/1.0.

21/11

Aplicação Web: repositório de arquivos

A aplicação Web Wordpress provê a publicação de arquivos de mídia (PHP. É possível, além da própria ferramenta, utilizar outros mecanismos de transferências de arquivos em ambos os sentidos (cliente e servidor) sem as limitações das linguagens e suas aplicações - seja por razões de segurança ou implementação.

Uma dessas possibilidades é o WebDAV, que expande a gama de métodos HTTP para permitir a publicação de arquivos e manipulação de suas propriedades.

Para complementar a aplicação Wordpress, que provê um blog Tivemos nesse dia um resumo sobre a aula anterior de HTTPS, além de alguns procedimentos de como fazer com que o Apache tenha um sistema de autenticação, para isso foi criado um arquivo no diretório /etc/apache2/.htpasswd com comando htpasswd do Apache. Nesse arquivo foi definido que se tenha um usuário válido.

<graphviz>

digraph Site { 

 rankdir=LR
 Cliente [shape=plaintext]
 Blog [shape=Mrecord]
 Repositório [shape=Mrecord]

 Cliente -> Blog [label=HTTP,color=blue,fontcolor=blue]
 Cliente -> Repositório [label=HTTPS,color=red,fontcolor=red]
 Blog -> Repositório [label=URL]

}

</graphviz>

25/11

Atual estado do laboratório NetKit:

Laboratório Firewall DMZ: Servidor LAN: Servidor LAN: estação

Gerência

#!/bin/sh

# Variáveis
TOTAL=$(cat /proc/meminfo |grep ^MemTotal | cut -d : -f 2 | cut -d k -f 1)
LIVRE=$(cat /proc/meminfo |grep ^MemFree | cut -d : -f 2 | cut -d k -f 1)

# Porcentagem
DIVISOR=$(expr ${LIVRE} \* 100)
RESULTADO=$(expr ${DIVISOR} / ${TOTAL})

# Acima de 90% ocupado, ou 10% livre, para o serviço Apache.
if [ "${RESULTADO}" -le "10" ]
then
    # Para o Apache e informa via log a pouca memória disponível.
    /etc/init.d/apache2 stop > /dev/null 2> /dev/null
    logger -p user.info "Serviço Apache parado, memória no limite: apenas ${RESULTADO}% livre."
else
    # Conta quantos processos com o nome "apache" existem
    PROCESSOS=$(pidof apache2 | wc -w)
    #
    # Se o resultado for zero (Apache parado), inicia o serviço.
    if [ "${PROCESSOS}" = "0" ]
    then
        /etc/init.d/apache2 start > /dev/null 2> /dev/null
        logger -p user.info "(Re)Iniciando Apache - ${RESULTADO}% de memória principal disponível..."
    else
        logger -p user.info "Tranquilo, ainda há ${RESULTADO}% de memória principal disponível..."
    fi
fi

# Fim do programa: saída com sucesso.
exit 0

Referências

  1. ↑ RITCHIE, D. M. e THOMPSON, K. The UNIX Time-Sharing System. The Bell System Technical Journal. no. 57 parte 2. 1978.
  2. ↑ NEMETH, E. et al. UNIX and Linux System Administration Handbook. 4 ed. 2010. ISBN 0131480057.
  3. ↑ CHACO, S. Pro Git. Apress. 2009.


Voltar para página principal da disciplina

Disponível em “https://wiki.sj.ifsc.edu.br/index.php?title=Gerência_de_Redes_(diário_2011-2)&oldid=38670”