pontifícia universidade católica do paraná – pucpr curso ... › ~jamhour › rss › tccrss08b...
TRANSCRIPT
Pontifícia Universidade Católica do Paraná – PUCPR
Curso de Especialização - Redes e Segurança de Sistemas
Replicação de dados usando o Rsync
Sidnei Baron
Contribuído com a montagem do ambiente para a elaboração e teste, no
desenvolvimento do shell script e na escrita do artigo.
Curitiba, abril de 2010
Replicação de dados usando o Rsync
Rodrigo Dresch, Sidnei Baron
Curso de Redes e Segurança de Sistemas
Pontifícia Universidade Católica do Paraná
Curitiba, abril de 2010
Resumo
Uma indisponibilidade nos sistemas pode afetar diretamente os lucros de uma empresa, além de
comprometer a credibilidade, ou seja, a confiabilidade dos dados empresariais passaria a ficar
exposta a riscos altos. Manter servidores de backup em localidades diferentes, por exemplo: em
prédios, cidades ou até mesmo em países diferentes, para replicar os arquivos alterados
constantemente, é uma das técnicas utilizadas para minimizar a indisponibilidade aqui citada.
Atualmente o Rsync é uma das ferramentas mais utilizadas para a réplica de dados e se combinada
com a utilização do programa Stunnel para a implementação de um túnel criptografado, torna
possível a replicação de dados entre servidores de forma segura e eficiente.
1. Introdução
As atualizações de dados obrigatoriamente ocorrem de uma forma constante. O
conglomerado de informações que trafegam por uma rede, durante 24 horas por dia, tornaram
fundamental o desenvolvimento de técnicas para agilizar o processo de recuperação de dados
automaticamente.
A replicação de dados surge como uma das alternativas para suprir essa necessidade, além
de permitir que a recuperação das informações (muitas vezes vitais) possa ser feita quase que
imediatamente.
Os sites backups, já utilizados por algumas organizações, possuem sem dúvidas enormes
vantagens, no que diz respeito a custo benefício: “Os custos de criação de uma solução baseada em um site backup são compensados pela
retenção de grandes clientes que buscam muita segurança de seus dados e prezam pelo conceito de
Business Continuity, ou seja, o tempo de indisponibilidade para recuperação dos dados em caso de
acidentes é praticamente zero", afirma Guido Peters, gerente da área de Business Development da
Siemens.[1]
Este tipo de atividade vem ganhando mais espaço no mercado corporativo, principalmente
por, de certo modo, garantir a total disponibilidade sem perdas. Há casos presenciados, por
organizações em que as estimativas dos prejuízos foram incalculáveis: Muitas empresas localizadas no World Trade Center, em Nova York, tiveram suas
informações perdidas porque seus sistemas backup de armazenamento encontravam-se na outra
torre, também destruída. Os prejuízos foram letais para algumas companhias, que não sobreviveram
à perda de seu "patrimônio de dados", irrecuperável em tempo hábil para a retomada das
operações.[1]
A partir desta informação é possível analisar que uma indisponibilidade nos sistemas pode
afetar diretamente os lucros, além de comprometer a credibilidade, ou seja, a confiabilidade dos
dados empresariais passaria a ficar exposta a riscos altos.
Vale salientar ao ter e eventualmente utilizar um site backup, que este obtenha os dados o
mais próximo possível do site original, de modo a comparar as duas informações (original e cópia)
e a identificação das mesmas seja até imperceptível, do ponto de vista usual, tornando a replicação
de dados fidedigna.
Uma das ferramentas open source mais utilizadas e conhecidas para a réplica de dados entre
servidores Unix é o Rsync. O que é o Rsync e principalmente, o seu funcionamento e as suas
respectivas implementações necessárias, são algumas das informações que serão abordadas neste
documento.
O objetivo é mostrar como ele poderá ser implementado resultando na replicação de dados
assíncrona com segurança, contando com a utilização do Stunnel, programa que funciona como
uma capa de criptografia que irá assegurar a confiabilidade desta solução.
2. Descrição da necessidade
A proposta inicial aqui é representar a replicação assíncrona de arquivos entre dois
servidores Linux. O objetivo principal é restabelecer todos os serviços, considerando um caso de
contingência, no menor tempo possível, aplicando a replicação de dados como uma solução estável
e atrativa.
Com o intuito de exemplificar a solução, o cenário proposto neste artigo possui dois
servidores com o Apache (serviço de hospedagem de sites), representado pela Figura 1. Eles estão
hospedados em locais diferentes e diretamente conectados à internet.
Figura 1 - Cenário proposto para a replicação de dados.
Fonte: Os Autores, 2010.
No servidor principal, os serviços ficam disponíveis para o acesso pela internet. A interação
que os clientes estabelecem ao acessarem e atualizarem o conteúdo pela internet é visível. Pode se
observar também que no servidor backup, os serviços ficam inativos e sua utilização ocorre apenas
sincronizando os dados com o servidor principal, o que ocorre temporariamente e pré-configurado
conforme a necessidade e banda disponível.
Todo o tipo de informação que trafegar entre os servidores deve ser considerado
confidencial, principalmente por lidar com dados sigilosos, cita-se, por exemplo, arquivos com
fonte de páginas de conteúdo dinâmico, ou ainda, os arquivos de que contenham usuários e senhas
de acesso ao banco de dados. Levando em consideração que o próprio diretório (/var/www/html) já
possui um nível mínimo de segurança, onde somente o superusuário (root) e o usuário apache (que
executa o serviço) possuem permissão de acesso, deve-se denotar atenção especial aos dados
replicados que obrigatoriamente acabam expondo-se pela rede ou pela internet, exigindo um nível
ainda maior de segurança.
Portanto a segurança é o fator fundamental desta solução, e sem sua devida configuração
corretamente realizada, as informações poderiam ser facilmente capturadas com um Sniffer1 na
rede. Há vários programas disponíveis para tal análise, aqui foi utilizada a ferramenta Wireshark,
para demostrar a captura das informações.
O artigo postado por Fabiano Candido (INFO, 2009) [4], descreve o funcionamento do
Wireshark: O Wireshark é um programa que analisa os dados que os protocolos de rede trocam quando estão
ativos. […] Desenvolvido em código aberto, o programa serve para o usuário verificar o
desempenho da rede e executar testes de pacotes.[...]. O Wireshark também conta com filtros de
protocolos, permitindo ao usuário receber apenas as informações que deseja. Além disso, o
programa está preparado para salvar log das operações de análise, um bom recurso para quem
precisa implementar sistemas novos na rede.
Para comprovar sua funcionalidade o programa foi alocado estrategicamente entre os
servidores, sendo possível coletar os dados trafegados durante a replicação com o Rsync. Em uma
situação real, um cracker2 poderia utilizar a técnica de Man-in-the-midle
3 para interceptar a conexão
e ter acesso aos dados trafegados.
Observa-se na Figura 2 a captura realizada pela ferramenta Wireshark. A identificação dos
dados coletados durante determinado tráfego é fácil de obter, ou seja, o conteúdo é claramente
visível, nomes de usuários, senhas e demais informações ficam expostas. Conclui-se que este
arquivo, se transferido durante a replicação desta forma, sem criptografia, por exemplo, pode vir a
comprometer toda a estrutura de segurança em uma rede corporativa.
Figura 2 - Wireshark: captura do tráfego gerado pelo Rsync sem criptografia.
Fonte: Os Autores, 2010.
1 Sniffer (também conhecido como Packet Sniffer, Analisador de Rede, Analisador de Protocolo, Ehernet Sniffer em redes do padrão Ethernet ou ainda Wireless Sniffer em redes wireless). Ferramenta, constituída de um software ou hardware, é capaz de interceptar e registrar o tráfego de dados em uma rede de computadores. Captura cada pacote e eventualmente decodifica e analisa o seu conteúdo de acordo com o protocolo. [2] 2 Cracker é o termo usado para designar quem pratica a quebra (ou cracking) de um sistema de segurança, de forma ilegal ou sem ética. [14] 3 Man-in-the-midle, também chamado de MITM, é um ataque em que a conexão entre as máquinas das vítimas é interceptada e entregue ao seu destino original. A máquina vitima acredita que a comunicação esta ocorrendo diretamente para a outra vítima, porém a comunicação esta passando através do atacante. O resultado do ataque não é somente interceptar algum dado sensível, mas poder injetar e manipular os dados para ganhar um controle futuro na vítima. [3]
3. Solução apresentada
A solução proposta se baseia no artigo Rsync + Stunnel 4.x disponível no site do projeto
Rsync [13]. Nele é descrito a utilização da ferramenta Rsync para replicação dos dados, e o Stunnel
para criar a comunicação criptografada.
3.1 Ferramentas utilizadas 3.1.1 Rsync Rsync é um software open source que permite fazer transferência incremental de arquivos.
Rsync é atualmente mantido por Wayne Davison pela licença GNU General Public License (GPL)
[5].
O artigo publicado por Duda Grass, corrobora quando cita o funcionamento do Rsync na
publicação intitulada Backups de Redes com Fedora + Rsync [6]: O Rsync funciona como uma ferramenta de backup integral quando é executado pela primeira vez,
ao fazer o backup do mesmo diretório outras vezes, Rsync comporta-se como sistema de backup
incremental. Ele copia apenas o que mudou na árvore de diretórios, antes de transferir os dados, faz
uma comparação do arquivo na origem e no destino e de um arquivo modificado ele irá transferir
apenas o blocos novos ou alterados do arquivo.
Para minimizar os custos de latência na transferência dos arquivos o Rsync divide o arquivo
de origem em vários pedaços e gera uma pequena assinatura de cada pedaço, então envia pela rede
estas assinaturas, e efetuando o mesmo procedimento no lado oposto, descobre quais pedaços
faltam no arquivo de destino para torná-lo igual ao de origem. [7]
O backup dos arquivos entre os servidores, aqui também chamado de replicação, ocorre de
forma assíncrona, ou seja, os dados são sincronizados de tempos em tempos entre os servidores, por
exemplo, a cada hora. Diferente de uma replicação síncrona, que ocorre quando uma réplica dos
dados é mantida exatamente sincronizada e consistente. [9]
O próprio Rsync não possui criptografia, mas pode utilizar o SSH4 para fazer a
comunicação e transporte entre os servidores de forma criptografada [11]. Porém utilizar o SSH
para a replicação pode trazer outros problemas de segurança.
Para fazer a comunicação via SSH é necessário acessar o servidor com uma conta válida. No
cenário de replicação, essa mesma conta deve possuir privilégios de acesso aos arquivos e diretórios
que se deseja replicar, por esse motivo muitos administradores utilizam a própria conta de
superusuário (root) para este fim. Como o processo de replicação deve ocorrer de forma automática
e transparente, a autenticação por senha usada no SSH é removida deixando somente a troca de
chaves públicas e privadas entre os servidores envolvidos. Desta maneira, fica claro que se algum
invasor conseguir acesso ao Servidor Backup ele também terá acesso a outro servidor facilmente.
A instalação do Rsync é bem simples e a maioria das distribuições Linux já possui uma
versão empacotada disponível com a mídia de instalação ou no repositório da distribuição Linux
disponível na internet. Em uma distribuição Debian e originados (exemplo: Ubuntu) a instalação via
internet do Rsync pode ser feita com o seguinte comando:
apt-get install rsync
Em uma distribuição RedHat ou originados (exemplo: Fedora, CentOS), o comando para a
instalação via internet pode ser:
yum install rsync
4 SSH (Secure Shell) é um programa e um protocolo de rede que permite a conexão com a outro
computador na rede criptografada, de forma a executar comandos de uma unidade remota.[10]
3.1.2 Stunnel Stunnel é um programa projetado para funcionar como uma capa de criptografia SSL
(Secure Sockets Layer) entre o servidor local e o servidor remoto. Ele pode ser empregado para
adicionar funcionalidade SSL, comumente usado para serviços como POP3 e IMAP sem qualquer
alteração no código dos programas. Ele irá negociar uma conexão SSL usando as bibliotecas
OpenSSL ou SSLeay. [12]
Como no Rsync, a instalação do Stunnel também é bem simples e a maioria das
distribuições Linux já possui. Em uma distribuição Debian ou originada a instalação via internet do
Stunnel pode ser feita com o seguinte comando:
apt-get install stunnel
Em uma distribuição RedHat ou originadas, o comando para a instalação via internet pode
ser:
yum install stunnel
3.2 Descrição da solução
Em uma replicação de dados usando somente o Rsync, o cliente do Rsync, neste caso o
Servidor de Backup, se conecta diretamente na porta do Servidor Principal. Deste modo todo o
tráfego entre os servidores pode ser “escutado” e entendido. A Figura 3 representa esta replicação.
Figura 3 - Replicação dos dados com o rsync sem criptografia.
Fonte: Os Autores, 2010.
Para evitar que os dados fiquem expostos na rede, a solução é implementar o Stunnel para
estabelecer um tunelamento criptografado entre os servidores envolvidos e utilizar o Rsync para
replicar os dados por dentro deste túnel.
No Servidor Backup, os comandos de replicação sempre irao se conectar na porta local, mas
todo o tráfego será redirecionado para a porta do Rsync (873) no outro servidor, passando pelo túnel
criptografado. A Figura 4 ilustra este tunelamento e a conexão utilizada pelo Rsync.
Figura 4 - Replicação dos dados com o rsync com criptografia.
Fonte: Os Autores, 2010.
Para que o ambiente proposto assegure o devido funcionamento são considerados alguns
diretórios fundamentais para a disponibilidade do serviço:
• /var/ww – Diretório com o conteúdo dos sites;
• /var/log/httpd – Diretório com os arquivos de log;
• /etc/httpd - Diretório com arquivos de configuração do serviço.
4. Implementação 4.1 Servidor principal As portas utilizadas no Servidor Principal são: 873 - aberta pelo Rsync; e 273 - aberta pelo
Stunnel.
4.1.1 Stunnel
A configuração do Stunnel é feita pelo arquivo /etc/stunnel/stunnel.conf. A listagem a seguir
é mostrada a configuração utilizada para o cenário proposto:
cert = /etc/stunnel/stunnel.pem
client = no
pid = /var/run/stunnel.pid
[rsync]
accept = 273
connect = 873
As opções utilizadas são:
• cert: Na opção devera ser informada o certificado digital. O comando apresentado gera o
certificado no arquivo /etc/stunnel/stunnel.pem.
openssl req -new -nodes -x509 -out /etc/stunnel/stunnel.pem \
-keyout /etc/stunnel/stunnel.pem chmod 600 /etc/stunnel/stunnel.pem
• client: O valor "no" informa ao daemon do stunnel para que ele atue como servidor.
• pid: Arquivo onde ficara o pid do daemon durante a sua execução.
Na sessão chamada “[rsync]” possui duas opções: accept e connect. Na opção accept é
configurada a porta em que será utilizada para estabelecer o túnel criptografado e a opção connect é
a porta para qual será redirecionado o trafego ao sair pelo túnel.
Com a configuração pronta e o certificado criado, o Stunnel pode ser iniciado pelo seguinte
comando:
stunnel
4.1.2 Rsync
A configuração do Rsync é bem extensa, executando os comandos “rsync --help” e “man
rsync” é possível listar a grande quantidade de suas opções. Para atender as necessidades deste
cenário o arquivo de configuração no servidor principal foi criado em /etc/rsync.conf com o
seguinte conteúdo:
uid = root
gid = root
max connections = 1
log file = /var/log/rsyncd.log
hosts allow = 127.0.0.1
read only = yes
port = 873
[htdocs]
path = /var/www
comment = Arquivos web
[config]
path = /etc/httpd
comment = Arquivos de configuracao
[logs]
path = /var/log/httpd
comment = Arquivos de logs
As opções utilizadas são:
• uid: Usuário utilizado para rodar o daemon do rsync.
• guid: Grupo utilizado para rodar o daemon do rsync.
• max connection: Esta opção proíbe que mais do que uma replicação ocorra
simultaneamente.
• log file: Os logs do daemon e das replicações serão salvos em /var/log/rsyncd.log
• hosts allow: Somente os hosts informados possui permissão para fazer a conexão. Como
toda conexão será redirecionada para um túnel criptografado, a conexão sempre será feita
pelo endereço de loopback (127.0.0.1).
• ready only: Todos os compartilhamentos serão de somente leitura.
• port: Porta utilizada pelo daemon do rysnc.
As sessões “[htdocs]”, “[config]” e “[logs]” estão configuradas para compartilhar cada um
dos diretórios com a opção path. A opção “comment“ é opcional, porém de grande auxilio para
documentação em sistemas mais complexos.
O daemon do rsync deve ser inciado pelo seguinte comando:
rsync --config /etc/rsync.conf --daemon
4.2 Servidor de backup
No lado do servidor de backup somente o Stunnel fica rodando. Para a replicação, um shell
script com comandos Rsync são executado por agendamentos pré-determinados.
As portas utilizadas no Servidor Backup são a porta 873 para o Stunnel e uma porta alta
aleatória usada pelo Rsync no shell script.
4.2.1 Stunnel
As configurações do Stunnel no Sevidor Backup são semelhantes ao do servidor principal,
porém algumas opções devem ser ajustadas. A configuração é exibida a seguir:
cert = /etc/stunnel/stunnel.pem
client = yes
pid = /var/run/stunnel.pid
[rsync]
accept = 873
connect = www.empresa.com.br:273
As opções utilizadas são:
• cert: Para que seja estabelecida a comunicação criptografada entre o servidor e o cliente, o
mesmo certificado digital devera ser utilizado. Depois de gerado no servidor principal, uma
cópia do mesmo deve ser feita para o Servidor Backup. Se houver acesso via SSH é possível
fazer a cópia com o seguinte comando:
scp [email protected]:/etc/stunnel/stunnel.pem /etc/stunnel/
• client: Neste servidor o daemon do stunnel será o cliente de acesso;
Na sessão “[rsync]” as opções são:
• accept: O daemon do Stunnel ira simular a porta do Rsync (873).
• connect: Deverá ser informado o endereço do servidor principal e a porta do Stunnel
(www.empresa.com.br:273).
Com a configuração pronta e o certificado criado, o Stunnel pode ser iniciado pelo seguinte
comando:
stunnel
4.2.2 Rsync
No Servidor Backup um shell script executará os comandos para a replicação dos dados. A
sintaxe do comando Rsync é:
rsync [OPTIONS] rsync://[USER@]HOST[:PORT]/SRC [DEST]
As linhas de comandos listadas a seguir exemplificam a replicação dos diretórios
compartilhados no servidor principal.
rsync -avz --delete rsync://localhost/htdocs /var/www
rsync -avz --delete rsync://localhost/config /etc/httpd
rsync -avz --delete rsync://localhost/logs /var/log/httpd
As opções utilizadas estão descritas na Tabela 1.
Opção Descrição
-a Irá garantir que permissões e proprietários dos arquivos
transferidos sejam preservados no servidor destino.
-v Faz com que seja detalhamento a execução do comando rsync e
seja exibida na tela.
-z Faz com que os dados sejam compactados antes de serem
transferidos, sendo que no destino eles são automaticamente
descompactados.
--delete Deleta os arquivos que não existem no servidor de destino.
Tabela 1 – Opções do comando Rsync utilizada no cenário proposto.
Nestes comandos é possível visualizar que o Rsync conecta na porta local
(rsync://localhost), aberta pelo Stunnel. Isso permite que o Stunnel encaminhe a conexão pelo túnel
criptografado até a porta do Rsync no servidor principal.
O diretório de destino da replicação é o mesmo que o do compartilhado pelo servidor
principal, agilizando assim o processo de ativação do ambiente de contingência, já que os dados já
estão no seu devido lugar.
No Anexo A encontra-se o shell script desenvolvido pelo autores para a execução dos
comandos de replicação. Este shell script devera estar localizado no diretório ”/usr/local/bin” com o
nome de ”replicacao.sh”.
4.3 Executando a replicação
Com o Stunnel rodando em ambos servidores e com o Rsync rodando no Servidor Principal,
já é possível fazer as replicações. O script deverá ser executado como o usuário root pelo comando:
/usr/local/bin/replicacao.sh
Após as configurações devidamente estabelecidas. Um novo teste de análise de rede foi
efetuado, para testar a veracidade da solução. Pode-se observar na Figura 5, onde mostra partes da
replicação capturadas pelo Wireshark, porém desta vez não é possível entender o conteúdo
replicado, já que o mesmo está criptografado.
Figura 5 – Captura da replicação entre dois servidores usando o rsync e stunnel.
Fonte: Os Autores, 2010.
Esta replicação deverá ocorrer periodicamente, por isso é necessário adicioná-lo ao
agendados de tarefas do Linux, o Crontab5. Para editar ou incluir na Crontab digite o seguinte
comando com o usuário root.
crontab -e
A seguir é mostrada a entrada na Crontab para que, a cada hora, o script de replicação
execute.
# Replicacao dos dados
00 */1 * * * /usr/local/bin/replicacao.sh >> /var/log/replicacao-cron.log 2>&1
5. Considerações finais
Manter servidores com o conteúdo replicado é uma das melhores estratégias para minimizar
a indisponibilidade dos serviços em uma corporação. Alguns cuidados devem ser tomados para que
os dados não fiquem desprotegidos durante a replicação, conforme demonstrado.
O objetivo inicial foi alcançado já que a ferramenta Rsync mostrou-se eficiente e confiável
para a replicação dos dados, mesmo que os dados são transportados sem nenhuma criptografia.
Deficiência esta corrigida com a implementação do Stunnel, obtendo como resultado um túnel
criptografado entre os servidores envolvidos.
Este artigo exemplificou a replicação de dados em um ambiente de hospedagem de sites,
mas a solução demonstrou também flexibilidade para que a mesma possa ser estendida para outros
serviços, bastando alterar a configuração no compartilhamento do Rsync e o shell script
desenvolvido.
5 A Cron (ou Crontab) é um recurso dos sistemas Unix que permite o agendamento da execução de determinados
comandos. Após uma checagem, caso exista uma instrução para execução de comando, a Cron o fará.[15]
6. Bibliografia [1] Storage sobre redes ópticas: mais segurança às informações críticas. Disponível em: <
http://www.siemens.com.br/templates/coluna1.aspx?channel=4850>. Acessado em: 15 mar. 2010.
[2] Sniffing. Disponível em: <http://pt.wikipedia.org/wiki/Sniffing>. Acessado em: 15 mar. 2010.
[3] Sanders, C. Understanding Man-in-the-Middle Attacks - ARP Cache Poisoning. Disponível
em: <http://www.windowsecurity.com/articles/Understanding-Man-in-the-Middle-Attacks-ARP-
Part1.html>. Acessado em: 15 mar. 2010.
[4] Wireshark. Disponível em: <http://info.abril.com.br/downloads/wireshark>. Acessado em: 15
mar. 2010.
[5] Welcome to the rsync web pages. Disponível em: <http://samba.anu.edu.au/rsync/>. Acessado
em: 15 mar. 2010.
[6] Grass, D.. Backups de Redes com Fedora + Rsync. Disponível em:
<http://dudagrass.livejournal.com/1159.html>. Acessado em: 15 mar. 2010.
[7] Rsync. Disponível em: <http://pt.wikipedia.org/wiki/Rsync>. Acessado em: 15 mar. 2010.
[8] How Rsync Works. A Practical Overview. Disponível em:
<http://samba.anu.edu.au/rsync/how-rsync-works.html>. Acessado em: 15 mar. 2010.
[9] Hopkins, M.; Thomas, D.. Replicação de Dados com InterBase/Firebird. Disponível em:
<http://www.comunidade-firebird.org/cflp/downloads/CFLP_T022.PDF>. Acessado em: 15 mar.
2010.
[10] SSH. Disponível em: <http://pt.wikipedia.org/wiki/SSH>. Acessado em: 15 mar. 2010.
[11] Rsync features. Disponível em: <http://samba.anu.edu.au/rsync/features.html>. Acessado em:
15 mar. 2010.
[12] Stunnel -- Universal SSL Wrapper. Disponível em: <http://www.stunnel.org/>. Acessado
em: 15 mar. 2010.
[13] Rsync + Stunnel 4.x. Disponível em: <http://www.netbits.us/docs/stunnel_rsync.html>.
Acessado em: 15 mar. 2010.
[14] Cracker. Disponível em: <http://pt.wikipedia.org/wiki/Cracker>. Acessado em: 15 mar. 2010.
[15] O que é Cron (ou Crontab)? Disponível em:
<http://ajuda.uolhost.com.br/index.php?p=resposta&res=589>. Acessado em: 15 mar. 2010.
Anexo A – Shell Scrip /usr/local/bin/replicacao.sh #!/bin/bash
##################################################################
###
# Script para replicacao de dados usando o rsync + stunnel
#
# Autores: Rodrigo Dresch
# Sidnei Baron
# Data: 20/03/2010
#
##################################################################
###
##
# Variaveis Globais
##
LOGDIR="/var/log/rsync"
LOG="$LOGDIR/rsync.log"
RUNID=`date +%s`
DEBUG=0
RSYNC="/usr/bin/rsync"
SERVIDOR="localhost"
PORTA="873"
DRYRUN=1
####
# Funcao para gravar logs
#
# Sintaxe:
# gera_log "texto a ser gravado no log"
####
gera_log(){
echo "[$RUNID] $1" >> $LOG 2>&1
[ $DEBUG -eq 1 ] && echo "[$RUNID] $1"
}
####
# Funcao que executa a replicacao
#
# Sintaxe:
# replica "parametros" "compartilhamento" "diretorio de
destino"
####
replica(){
[ $DRYRUN -eq 0 ] && PARAM=$1 || PARAM="$1 -n"
SHARED=$2
DESTINO=$3
gera_log "[$SHARED] Iniciando replicacao do compartilhamento"
gera_log "[$SHARED] Comando: $RSYNC $PARAM
rsync://$SERVIDOR:$PORTA/$SHARED $DESTINO"
$RSYNC $PARAM rsync://$SERVIDOR:$PORTA/$SHARED $DESTINO >
$LOGDIR/$SHARED.log 2>&1
RETVAL=$?
if [ $RETVAL -eq 0 ]; then
gera_log "[$SHARED] Fim da replicacao do compartilhamento
com Sucesso (Code: $RETVAL)"
else
gera_log "[$SHARED] Fim da replicacao do compartilhamento
com Erro (Code: $RETVAL)"
fi
return $RETVAL
}
##
# Se nao existe o diretorio de logs, cria
[ ! -d "$LOGDIR" ] && mkdir -p "$LOGDIR"
####
# Chamada para as Replicacoes
####
ERRO=0
# Opcoes basicas
#
# -v = Mostra mais detalhes durante a replicacao
# -p = Preserve permissions
# -a = This is equivalent to -rlptgoD. It is a quick way of
saying you want recursion and want to preserve almost
# everything (with -H being a notable omission). The
only exception to the above equivalence is when --files-from
# is specified, in which case -r is not implied.
#
OPCOES="-apv --delete"
gera_log "--> Inicio da replicacao (`date +"%Y/%m/%d %H:%M"`)"
#
# Incluir aqui as replicacoes
#
# replica opcoes compartilhamento diretorio_destino
replica $OPCOES htdocs /var/www/ || ERRO=1
replica $OPCOES config /etc/httpd || ERRO=1
replica $OPCOES logs /var/log/httpd || ERRO=1
if [ $ERRO -eq 0 ]; then
gera_log "<-- Fim da replicacao com Sucesso (`date +"%Y/%m/%d
%H:%M"`)"
else
gera_log "<-- Fim da replicacao com Erro (`date +"%Y/%m/%d
%H:%M"`)"
fi
exit $ERRO