This project is read-only.
Sincronização de diretórios OpenLDAP

A principal ferramenta que mantém sincronizados os diretórios OpenLDAP é o serviço (daemon) slurpd, que também pertence ao projeto OpenLDAP.

A função do slurpd é observar todas as modificações que ocorrem no diretório mestre (master), buscando replicá-las no diretório escravo (slave), de forma que os dados estejam sempre sincronizados.

Para isto, necessita-se de, ao menos, dois diretórios: um que será o mestre (onde também estará o serviço slurpd) e o escravo (que pode estar em uma máquina remota).

A forma que o slurpd usa para replicar os dados do diretório mestre ao escravo é fazendo um bind a um usuário do diretório escravo, da mesma maneira que se faz um bind ao usuário administrador do diretório quando se quer modificar alguma informação da árvore.

Assim como o slapd, o slurpd também obtém seus parâmetros de configuração através do arquivo slapd.conf.

Os parâmetros a serem observados e configurados para que a replicação funcione corretamente são os seguintes:

replogfile /var/lib/ldap/replog
replica uri=ldap://192.168.1.2
binddn="cn=Replica,dc=codeplex,dc=ndos"
bindmethod=simple
credentials=foobar


O parâmetro replogfile indica o caminho (path) onde encontra-se o arquivo de registros (logs) da replicação. Neste arquivo estão registradas todas as modificações, em formato ldif, feitas no diretório mestre. O serviço slurpd monitora constantemente este arquivo e, a todo o momento em que há uma mudança no mesmo, o slurpd executa a modificação equivalente no diretório escravo e aguarda um código de sucesso. Se este for positivo, o serviço slurpd elimina do arquivo replogfile as modificações, deixando-o novamente vazio.

O parâmetro replica uri, como o nome indica, refere-se ao servidor e a porta na qual se encontra o diretório escravo onde se replicarão as modificações que ocorrem no mestre.

Como já foi comentado previamente neste handbook, binddn é o usuário do diretório que o slurpd utilizará para fazer as modificações que necessitem de replicação no diretório escravo. Já que é necessário um usuário para isto, também será necessária sua respectiva senha, que será indicada no parâmetro credentials.

O valor de bindmethod indica o tipo de autenticação que se realizará no processo de sincronização. Neste exemplo, o método simples (simple) é utilizado.

Com estes valores, o servidor mestre está configurado de forma suficiente para que o serviço slurpd trate de realizar a sincronização com o diretório escravo.

Para que isto funcione, o servidor escravo deve ter o arquivo slapd.conf também configurado propriamente, de forma que aceite e finalize corretamente a solicitação de sincronismo com o servidor mestre.

Em primeiro lugar, no servidor escravo, devem se definir cuidadosamente as permissões ou acls (access control lists, listas de controle de acesso) que correspondem ao usuário que o slurpd irá utilizar para fazer as modificações no diretório escravo. Este usuário, como já foi dito, está definido pelo parâmetro binddn no slapd.conf do servidor mestre.

A seguir, é necessário definir dois parâmetros próprios da replicação, conforme abaixo:

updatedn "cn=Replica,dc=codeplex,dc=ndos"
updateref "ldap://172.16.161.1"


O parâmetro updateref indica o endereço do servidor que serve como mestre, através do qual todas as modificações serão replicadas no servidor escravo.

O parâmetro updatedn faz, mais uma vez, referência ao usuário através do qual as modificações serão realizadas, provenientes do servidor mestre. Para qualquer tentativa de modificação do diretório escravo que não ocorra através do usuário indicado em updatedn, o servidor devolverá uma resposta ao cliente dizendo que a modificação deverá ser feita através do servidor constante no parâmetro updateref. Com isto, mantém-se a consistência na replicação, forçando que qualquer tentativa de escrita no servidor escravo apenas venha do servidor mestre e que seja feita por meio do usuário da replicação. O único usuário que terá permissão para realizar uma modificação diretamente no servidor escravo é o usuário root do mesmo, por isto é conveniente separar o usuário root do usuário encarregado pela replicação.

Qualquer tentativa de escrita por parte do usuário de replicação, indicado em updatedn que não seja solicitada pelo slurpd do servidor mestre também resultará em erro, que será enviado ao cliente que está tentando fazer esta escrita no servidor escravo.

O esquema do funcionamento de um processo de replicaçao é o seguinte:

slurpd_schema_pt.png
Diagrama do processo de replicação de informações.


Com os servidores mestre e escravo corretamente configurados, o passo seguinte é fazer com que os diretórios partam de uma mesma base de informação. Para isto, deve ser feita uma cópia de segurança da árvore mestre que será carregada no servidor escravo. Aqui pode-se antever um problema: durante o processo de cópia e carga do diretório no escravo, pode acontecer que um cliente realize uma alteração no servidor mestre (que não está na cópia de segurança) resultando em versões diferentes. O ideal é parar o servidor mestre, uma situação que não é possível normalmente para um administrador. Uma alternativa menos traumática é reiniciar o servidor mestre em modo de apenas leitura. Para isto, basta adicionar no parâmetro readonly o valor on no arquivo de configuração slapd.conf do servidor mestre.

Chegou o momento de fazer a cópia. Há muitas formas de fazer isto. A mais rápida e simples é através do comando slapcat que está incluído no pacote openldap.

# /usr/local/sbin/slapcat -b dc=codeplex,dc=ndos -l backup.ldif


O arquivo backup.ldif contém a informação íntegra do diretório mestre. Copia-se o mesmo ao diretório escravo para que seja carregado. Assume-se que o diretório escravo está totalmente vazio no momento de carregar os dados a partir do mestre.

/usr/local/sbin/slapadd -l backup.ldif


Agora, nos dois diretórios, há exatamente a mesma informação. Uma vez iniciados, a partir deste momento, todos os dados modificados no servidor mestre serão replicados no escravo.


Capítulo anterior | Índice | Próximo capítulo

Last edited Sep 14, 2007 at 8:28 PM by joicekafer, version 6

Comments

No comments yet.