Estabelecendo um Esquema de Espelhamento de Diretórios

Ari Frazão Jr. <ari@na-rc.rnp.br>

Rede Nacional de Ensino e Pesquisa (RNP)

Introdução
Criando um esquema simples
Configuração do Mirror
Exemplo de utilização
Instalação do pacote
Conclusão
Referências bibliográficas
Sites relacionados

Este artigo apresenta uma proposta de espelhamento a ser implementada pela RNP em relação aos seus PoPs, usando o software mirror.

Embora tratemos de um caso específico - a distribuição de informações (software, base de dados) através dos servidores FTP presentes nos PoPs -, a solução por nós adotada pode ser estendida a qualquer instituição que possua máquinas distribuídas geograficamente, que estejam conectadas através de uma rede TCP/IP, como a Internet, e que apresentem necessidades similares às nossas.

Introdução

Nos últimos dois anos, a RNP tem auxiliado diversos órgãos da administração federal através da distribuição de informações de interesse destes nos diversos servidores que encontram-se espalhados pelo seu backbone.

Os pedidos dão-se, basicamente, devido ao fato destas instituições não possuírem um link com a Internet com largura suficiente para atender a demanda causada pelas pessoas interessadas em obter as informações por elas disponibilizadas. Com a distribuição pela rede, tem-se o cuidado de criar uma estrutura que guia o usuário ao site da RNP mais conveniente para a captura da informação, que se dá de forma rápida e eficiente.

Dentre as distribuições feitas até agora, constam: os resultados das eleições junto com o TSE, os programas para declaração do imposto de renda (atendendo à solicitação da Receita Federal), os programas para pedido de bolsa de doutorado do CNPq, dentre outros.

A principal motivação para a proposta de um esquema de espelhamento automático dá-se, primeiramente, por razões de eficiência. Na forma como vem sendo feita, a cada nova demanda, os técnicos dos PoPs são acionados, e estes têm que criar a estrutura no seu repositório de FTP anônimo, tal e qual a especificação dada pela instituição interessada, e, ainda, fazer a transferência manual dos arquivos que devem nela constar.

O grande problema deste esquema acontece quando há a necessidade de transferências freqüentes para a atualização de versão causadas, na maioria das vezes, por terem sido encontrados erros (bugs) nos softwares disponibilizados. Assim, os técnicos passam a ser instados, com freqüência, para desempenharem ações repetitivas e que tendem a aborrecer.

Apresenta-se neste artigo, uma estratégia de utilização de um software (no caso, o mirror) que, a partir de uma máquina que contém uma base de dados, esta passa a ser replicada em diversas outras que encontram-se distribuídas geograficamente.

Criando um esquema simples

A simplicidade, em relação ao esquema aqui proposto, dá-se pelo fato de que as informações a serem replicadas, por sua própria natureza, encontram-se em áreas de FTP anônimo, ou seja, áreas públicas. Assim, é possível fazer uso do software mirror, cujo propósito é, exatamente, facilitar o espelhamento de pacotes entre repositórios públicos.

O esquema, portanto, é composto pelos seguintes tópicos:

O órgão interessado entra em contato com qualquer unidade administrativa da RNP (Coordenação Geral ou Núcleos de Apoio) e justifica o seu pedido de espelhamento;
A solicitação deve ser encaminhada à Coordenação Adjunta, atualmente responsável pela interação com os PoPs, que estuda o mérito da questão;
Após um parecer favorável desta coordenação, as informações que devem ser espelhadas são colocadas numa máquina central, a ftp.rnp.br, a partir do diretório /pub/RNP;
A partir deste ponto, as máquinas dos PoPs, que já devem ter sido configuradas a contento, passarão a transferir as informações recém instaladas em ftp://ftp.rnp.br/pub/RNP para o diretório /pub/RNP do seu próprio repositório público.

A Figura 1 ajuda a ilustrar o esquema acima detalhado.

Figura 1: Esquema de Disseminação de Informações via RNP

Configuração do Mirror

Segundo a própria página do manual que o acompanha, o mirror é um pacote escrito em Perl que faz uso do protocolo FTP para duplicar uma hierarquia de diretórios entre a máquina onde ele é executado e uma máquina remota.

Ele possui uma série de características (features) úteis que acabam influindo na eficiência, tais como:

A possibilidade de compressão dos arquivos no momento da transferência, de forma a trafegar um maior volume de dados em menos tempo;
A comparação das datas de criação dos arquivos (time-stamps) e de seus tamanhos de forma a evitar a tranferência desnecessária dos mesmos.

O mirror funciona de uma forma bastante simples: ele conecta-se à máquina remota, constrói internamente uma lista de diretórios de ambas as máquinas envolvidas na operação, compara-os, cria os subdiretórios necessários, transfere os arquivos indicados (mantendo a data da criação dos originais), cria links simbólicos e remove arquivos ou diretórios não mais existentes na origem.

Embora o mirror possa ser ativado na linha de comandos, na forma como o utilizaremos, ele será ativado através do crontab, tomando como base um arquivo de configuração apropriado.

O ARQUIVO DE CONFIGURAÇÃO

Arquivos de configuração são compostos por uma série de comandos. Linhas em branco e aquelas que começam com o caractere jogo-da-velha ("#") são ignoradas. Este último caso é muito usado para inserir comentários no arquivo.

Cada declaração pode assumir a forma:

palavra-chave=valor

palavra-chave+valor

No primeiro caso, à palavra-chave é atribuído valor. No segundo, valor é concatenado ao final de palavra-chave.

Embora exista um grande número de palavras-chaves que podem ser definidas, os valores default podem tratar da maioria dos casos. Neste artigo, serão vistas aquelas necessárias à resolução do problema apresentado, que são elas:

package - Deve ser um nome único para cada pacote a ser espelhado.
site - Nome ou endereço IP da máquina remota.
local_dir - Nome completo do diretório para onde se quer copiar os arquivos espelhados.
remote_dir - Diretório da máquina remota que deve ser espelhado.
remote_user - Nome do usuário (login) na máquina remota.
remote_password - Senha do remote_user a ser usada na máquina remota.
user - Nome do usuário (login) ou UID que deve ser usado na máquina local, ou seja, é o dono dos arquivos transferidos.
group - Nome do grupo ou GID que deve ser usado na máquina local.
dir_mode - Permissões que devem ser dadas aos diretórios criados localmente.
file_mode - Permissões que os arquivos criados localmente devem possuir.
do_deletes - Pode assumir os valores true ou false e diz se os arquivos locais devem ser removidos se já não são encontrados na fonte.
exclude_patt - Expressão regular dos nomes de arquivos remotos que devem ser ignorados.
compress_prog - Programa (comando) que deve ser usado na compressão dos arquivos para a transmissão.
compress_excl - Expressão regular de arquivos que não devem ser comprimidos para a transferência.
update_log - Nome do arquivo onde são armazenados os logs das transferências feitas.
mail_to - Para quem enviar uma mensagem de log das transferências feitas.

A maioria das palavras-chaves acima já vêm definidas no arquivo mirror.defaults, que acompanha o próprio pacote. Este arquivo, que é lido sempre que o mirror é executado, deve conter as definições que são comuns (defaults) na transferência de qualquer pacote para a máquina em questão.

Exemplo de utilização

Para ilustrar a utilização do pacote mirror, toma-se como exemplo a configuração a ser utilizada pelo PoP-AC (homenagem a inauguração deste PoP, ocorrida no dia 12/03), que pretende espelhar o conteúdo do diretório /pub/RNP, presente na máquina ftp.rnp.br nas terças e sextas-feiras.

O ARQUIVO MIRROR.DEFAULTS

Se o nome do pacote (palavra-chave package) é defaults, então nenhuma máquina remota é contactada ou pacote é transferido, mas os valores defaults das palavras-chaves especificadas são modificados. Encontra-se, abaixo, um exemplo de configuração para o arquivo mirror.defaults a ser utilizado na máquina server1.pop-ac.rnp.br.

package=defaults
# Nome da maquina local
hostname=server1.pop-ac.rnp.br
# Diretorio para onde os arquivos serao espelhados
local_dir=/is/ftp/pub/
# Nome do usuario remoto e sua senha
remote_user=anonymous
remote_password=root@pop-ac.rnp.br
# Log do mirror
update_log=/usr/local/lib/mirror/logs/mirror.log
mail_to=root
# As permissoes dos arquivos transferidos nao devem ser mantidas
dir_mode=0755
file_mode=0444
# Usuario dono dos arquivos e diretorios da area de FTP
# (user=root e group=nobody)
user=0
group=4294967294

# Nao recupera arquivos temporarios, com espaco ou .FSP
exclude_patt=(^|/)(\.mirror$|core$|\.cap|\.in\..*\.$|MIRROR\.LOG|#.*#|\.FSP|\.cache|\.zipped|\.notar|
\.message|lost\+found/|Network Trash Folder)
compress_prog=compress

# Nao comprime os arquivos especificados
compress_excl+|-z(\d+)?$|\.tgz|_tgz|\.tar\.Z|\.tar\.gz|\.taz$|\.arc$|\.zip$|\.lzh$|\.zoo$|\.exe$|\.lha$|
\.zom$|\.gif$|\.jpeg$|\.jpg$|\.mpeg$|\.au$|\.shk$|read.*me|index|info|faq|gzip|compress|(^|/)\.\.?$
# Remove os arquivos nao mais presentes na maquina sendo espelhada
do_deletes=true
max_delete_files=100%
max_delete_dirs=100%

O valor atribuído a local_dir diz respeito ao diretório, na hierarquia da máquina server1.pop-ac.rnp.br, que foi configurado como o repositório de FTP anônimo deste servidor. Uma vez tendo configurado este serviço numa máquina UNIX qualquer, ele pode ser determinado através do comando (cd ~ftp/pub ; pwd) .

Na forma como foi definida acima, não importam as permissões do arquivo na máquina de origem, ele será sempre gravado com permissão apenas de leitura (file_mode=0444). O mesmo acontece em relação aos diretórios, onde é garantido que só o dono do mesmo tem permissão de escrita (dir_mode=0755). Tais medidas são importantantes para garantir a segurança do repositório da máquina local.

As palavras-chaves user e group devem refletir o dono do diretório ~ftp/pub, bem como o grupo ao qual ele pertence.

Alerta-se para o fato de que o conteúdo referente as palavras-chaves exclude_patt e compress_exclude devem estar numa mesma linha, ou seja, não deve existir nenhum a não ser no final.

O ARQUIVO RNP.CONF

Para que o espelhamento seja realmente feito, um arquivo de configuração adequado tem que ser criado. Para que a máquina server1.pop-ac.rnp.br consiga transferir o conteúdo do diretório /pub/RNP de ftp.rnp.br, basta apenas criar um arquivo com as seguintes entradas:

package=RNP
# Diretorio da maquina local onde os arquivos transferidos sao
# armazenados (/is/ftp/pub/RNP)
local_dir+RNP/
# Nome da maquina remota
site=ftp.rnp.br
# Diretorio da maquina remota que possui os arquivos a serem
# transferidos
remote_dir=/pub/RNP/

Este arquivo será referenciado, daqui em diante, com o nome de RNP.conf.

Da forma como foram configurados os arquivos acima, se o operador decide fazer um outro espelhamento, basta adicionar uma nova palavra-chave package e fazer as configurações adequadas. Assim, se ele também decide espelhar o diretório de patches presente no FTP anônimo da máquina ftp.na-rc.rnp.br, o arquivo RNP.conf ficaria da forma:

Embora já esteja tudo configurado, uma vez que esta será uma tarefa com execução periódica, torna-se necessário configurar o crontab para que este ative a execução do mirror de forma automática nos dias indicados.

A ATIVAÇÃO DO CRONTAB

Para configurar o crontab, deve-se utilizar o comando crontab -e. Estando com a variável de ambiente EDITOR configurada para o seu editor de texto preferido, o mesmo será acionado e a seguinte linha deverá ser inserida:

05 02 * * 2-6 /usr/local/lib/mirror/mirror /usr/local/lib/mirror/RNP.conf

A entrada acima configura o serviço de crontab da máquina para executar o mirror a 2h5 da madrugada de terça a sexta-feira. No caso desta máquina, o pacote foi instalado no diretório /usr/local/lib/mirror e o arquivo de configuração utilizado (RNP.conf) também encontra-se no mesmo diretório mencionado.

Estando com o pacote do mirror instalado (a ser visto na próxima seção), os três passos acima descritos são suficientes para ativar um esquema de espelhamento em qualquer máquina UNIX.

Instalação do pacote

Por se tratar de um conjunto de scripts, o mirror possui um processo de instalação bastante simples. O único incoveniente se dá pela necessidade de já existir o pacote Perl instalado na máquina, o que já é assumido como uma verdade neste artigo.

A última versão do mirror pode ser obtida no site do nettols , bem como a do Perl .

Os PoPs da RNP poderão obter uma versão já configurada segundo as particularidades do exemplo dado neste artigo na Intranet da RNP.

Com relação à instalação do pacote mirror sugerimos a seguinte configuração:

Diretório de instalação: /usr/local/lib/mirror
Arquivo de log do mirror: /usr/local/lib/mirror/logs/mirror.log
A alteração dos seguintes parâmetros presentes no arquivo mirror.defaults, de forma a contemplar as particularidades de cada unidade:
- hostname
- local_dir
- remote_password
Se necessário, a alteração dos seguintes parâmetros ainda do arquivo mirror.defaults:
- update_log
- mail_to
- user
- group

Com relação ao Perl, a única exigência do mirror para trabalhar com ele é a existência de um link de /usr/bin/perl para o diretório onde o binário se encontra (ex.: /usr/local/bin/perl).

No que diz respeito à ativação do mirror, basta configurar o crontab na forma que foi explicada na seção anterior. No entanto, se uma única máquina vai servir como fonte para muitas outras, como no caso do problema que motivou a escrita deste artigo, então é importante definir um esquema de horários de acesso de forma a garantir que o servidor não vai ser saturado com pedidos concorrentes. Assim, é sugerida a adoção de uma política que distribua os horários de acesso.

Conclusão

Apresentamos, neste artigo, uma proposta de espelhamento de informações entre máquinas geograficamente distribuídas, utilizando o software mirror.

Embora trate-se de uma proposta a ser implementada pela RNP em relação aos seus PoPs, qualquer outra instituição que tenha a mesma características poderá adotá-la.

O artigo não considera os casos em que há a utilização de servidores proxy de FTP. Se este for o caso, o leitor interessado deve estar mais atento às opções proxy, proxy-server e proxy-gateway.

Referências bibliográficas

UNIX System Administration Handbook
Evi Nemeth et al., 2^a Edição, 1995, Prentice Hall

Essential System Administration
AEleen Frisch, 2^a Edição, 1995, O'Reilly & Associates, Inc.

Páginas do manual (man pages) do mirror.

Sites relacionados

Mirror: http://sunsite.doc.ic.ac.uk/public/packages/mirror
Perl: http://www.perl.com