Mudanças entre as edições de "Gerência de Redes (diário 2011-2)"
(171 revisões intermediárias por 3 usuários não estão sendo mostradas) | |||
Linha 1: | Linha 1: | ||
− | Endereço | + | 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 | + | =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. | ||
− | + | 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: | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | Em relação ao NetKit, trabalharemos com uma | ||
* Configuração da rede: o arquivo <tt>lab.conf</tt> define os componentes da rede. Baixa taxa de modificação. | * 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. | * 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. | ||
Linha 129: | Linha 142: | ||
** Matriz | ** Matriz | ||
*** lab.conf | *** lab.conf | ||
− | *** | + | *** Firewall0 |
**** Arquivo 1 | **** Arquivo 1 | ||
**** Arquivo 2 | **** Arquivo 2 | ||
**** Arquivo 3 | **** Arquivo 3 | ||
**** ... | **** ... | ||
− | *** | + | *** DMZ_Servidor0 |
**** Arquivo 1 | **** Arquivo 1 | ||
**** Arquivo 2 | **** Arquivo 2 | ||
**** Arquivo 3 | **** Arquivo 3 | ||
**** ... | **** ... | ||
− | *** | + | *** LAN_Servidor0 |
**** Arquivo 1 | **** Arquivo 1 | ||
**** Arquivo 2 | **** Arquivo 2 | ||
Linha 146: | Linha 159: | ||
** Filial | ** Filial | ||
*** lab.conf | *** lab.conf | ||
− | *** | + | *** Servidor0 |
**** Arquivo 1 | **** Arquivo 1 | ||
**** Arquivo 2 | **** Arquivo 2 | ||
Linha 184: | Linha 197: | ||
</syntaxhighlight> | </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>. | 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= | =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== | ==Facilitadores== | ||
===07/10=== | ===07/10=== | ||
Vistos os serviços locais de sistema operacional cron e syslog, que tratam do agendamento de tarefas e registro de eventos respectivamente. | 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]) | + | 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> | ||
+ | <graphviz> | ||
+ | digraph Serviços | ||
+ | { | ||
+ | Cron [shape=Mrecord] | ||
+ | Syslog [shape=Mrecord] | ||
+ | |||
+ | Syslog -> Cron | ||
+ | } | ||
+ | </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. | ||
+ | |||
+ | E lembre-se: [http://www.syslog.org/wiki/Main/LogAnalyzers ler ''log'' é uma arte]... | ||
===10/10=== | ===10/10=== | ||
− | ntp e dhcp | + | ====NTP==== |
+ | 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]. | ||
+ | |||
+ | <center> | ||
+ | <graphviz> | ||
+ | digraph Serviços | ||
+ | { | ||
+ | Cron [shape=Mrecord] | ||
+ | Syslog [shape=Mrecord] | ||
+ | NTP [shape=Mrecord] | ||
+ | |||
+ | Syslog -> Cron | ||
+ | Cron -> NTP | ||
+ | Syslog -> NTP | ||
+ | } | ||
+ | </graphviz> | ||
+ | </center> | ||
+ | |||
+ | 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]): | ||
+ | <syntaxhighlight lang=bash> | ||
+ | apt-get install ntp | ||
+ | </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; | ||
+ | } | ||
+ | |||
+ | A nova rede de dependências de serviços fica assim: | ||
+ | <center> | ||
+ | <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> | ||
+ | </center> | ||
==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== | ||
− | == | + | ===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}) | |
− | |||
− | |||
− | + | # 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 | ||
+ | </syntaxhighlight> | ||
=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].
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
- ...
- Matriz
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:
- Espaço de nomes (Namespace)
- Zona (Zone)
- Delegação de autoridade
- 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 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:
- Criação do diretório /var/www no servidor da DMZ, DMZ_Servidor0.
- http://br.wordpress.org/ Download da última versão em português do Brasil do CMS.
- 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.
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:
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
- ↑ RITCHIE, D. M. e THOMPSON, K. The UNIX Time-Sharing System. The Bell System Technical Journal. no. 57 parte 2. 1978.
- ↑ NEMETH, E. et al. UNIX and Linux System Administration Handbook. 4 ed. 2010. ISBN 0131480057.
- ↑ CHACO, S. Pro Git. Apress. 2009.