O OpenLDAP fornece dois programas para replicar a base de dados.
O primeiro e o mais antigo é o slurpd (obsoleto). Trabalha de acordo com os eventos gerados no arquivo de log e só trabalha com sincronização baseada em evento. Neste modelo é o servidor que inicia a réplica. Apenas as mudanças feitas depois da última sincronização serão transmitidas.
O segundo é o syncrepl, disponível apartir da versão do OpenLDAP 2.2, que é baseada no status da réplica e a sincronização acontece em períodos determinados de tempo ou baseada em eventos. Neste modelo é o cliente que inicia a réplica. Trabalha no modelo de sincronização completa, onde é feita a réplica de todas as alterações e as diferenças entre o master e o slave.
O syncrepl é um programa de réplica embutido dentro do OpenLDAP. Ele é mais flexível e tem mais opções, comparado ao slurpd (obsoleto).
Com o syncrepl, é possível replicar somente parte da base de dados do usuário ou também replicar a árvore completa. Ele oferece parâmetros que aumentam a segurança e o desempenho na hora da réplica. Por exemplo, você poderá especificar que replicará apenas usuários que tenham o parâmetro do homedir igual a /home/filial1.
As principais características do syncrepl são:
- Baseado em estado – não são necessários arquivos de log para a sincronização (um cookie representa o status atual da réplica).
- Incremental – somente atualiza depois que a última sincronização foi transmitida.
- São os clientes que iniciam as sessões de sincronização.
- Réplica baseada em evento e em tempo determinado (refreshOnly e refreshAndPersist).
- Suporta réplica parcial, dependendo dos filtros aplicados.
- Não necessita de um programa especial como o slurpd. Ele é iniciado juntamente com o processo do LDAP.
Como o syncrepl, o servidor backup não precisa ter uma base de dados inicial, adicionada manualmente para começar a réplica. Ao pedir um update da base, toda a estrutura é replicada. Isto pode ser feito em intervalos de tempo determinados, ou pelo fornecimento de uma conexão persistente. A conexão persistente foi inventada para ser o meio mais eficiente quando a largura de banda da rede permiti-la.
No slave (servidor de backup), o syncrepl necessita saber em qual modalidade trabalhará:
refreshOnly, que determina o intervalo de tempo para fazer a sincronização
O Intervalo é definido dessa forma:
interval=00:00:10:00 (DD:HH:MM:SS)
Nesse caso a sincronização será realizada a cada 10 minutos.
refreshAndPersist, que trabalha com uma conexão persistente.
Em vez de utilizar um intervalo de tempo, temos que definir o retry.
retry=30,10,300,+
No caso de erro a cada 30 segundos, ele fará dez tentativas. Em caso de erro, esperará 300 segundos para fazer novas tentativas. O “+” indica que serão feitas infinitas tentativas.
Mãos a obra, precisaremos do primeiro servidor configurado como no post da primeira configuração do LDAP:
Ok, feito isso iremos preparar nosso servidor como master – master (mirrormode)
Master001
Acrescentar e alterar as seguintes linhas no slapd.conf:
modulepath /usr/lib/ldap moduleload back_bdb moduleload syncprov [...] index objectClass,entryCSN,entryUUID eq # Opções para syncrepl overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 serverID 001 syncrepl rid=002 provider=ldap://10.1.1.MASTER002:389 type=refreshAndPersist retry=60,3,300,+ searchbase=”dc=mundotibrasil,dc=local” bindmethod=simple binddn=”cn=admin,dc=mundotibrasil,dc=local” credentials=senhadoadmin mirrormode on
Feito as devidas alterações, vamos reiniciar o slapd do MASTER001:
# /etc/init.d/slapd restart
Para o outro master iremos utilizar a mesma configuração inicial do MASTER001, mas neste caso não adicionaremos os ldifs.
Master002
Acrescentar e alterar as seguintes linhas no slapd.conf:
modulepath /usr/lib/ldap moduleload back_bdb moduleload syncprov [...] index objectClass,entryCSN,entryUUID eq # Opções para syncrepl overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 serverID 002 syncrepl rid=001 provider=ldap://10.1.1.MASTER001:389 type=refreshAndPersist retry=60,3,300,+ searchbase=”dc=mundotibrasil,dc=local” bindmethod=simple binddn=”cn=admin,dc=mundotibrasil,dc=local” credentials=senhadoadmin mirrormode on
Reiniciar o slave:
# /etc/init.d/slapd restart
Vamos realizar uma consulta e verificar se os dados do MASTER001 já foram transferidos.
# ldapsearch -x -D cn=admin,dc=mundotibrasil,dc=local -W
Se não houve nenhum erro a consulta feita retornou todos os dados registrados em MASTER001 e a partir desse ponto será possível adicionar registros em qualquer um dos servidores e o mesmo será replicado para o outro servidor.
Espero que tenham gostado do post. Comente e não deixem de assinar o nosso portal.
Ricardo Pinheiro,
Atualmente uso o OpenLDAP + DC Samba, meu ambiente é composto por três bases (Matriz e Filial), eu faço a gestão desses usuário através da console GoSa, (Criação de Usuário, Grupos, etc), porem a base de uma das filial não aparece mais nesta console, nem através da interface do phpLDAPadmin, porem quando eu executo o comando ( ldapsearch -x -W -D), apontando a respectiva base, é possivel localizar a mesma, porem quando necessito adicionar um novo usuário o processo esta muito trabalho, eu faço a criação de um usuário na base da Matriz, depois localizo as informações dele no ldap, posteriormente a criação de um arquivo e importo através do comando (ldapadd -x -D cn=admin,c=br -W -f usuario.lidf), mas dessa forma não esta nada pratico, sem contar a grande margem para cometer erros. Eu sei que esta postagem é muito antiga, porem mesmo assim optei por enviar este comentário, com alguma expectativa que você possa me dar um retorno.
Muito obrigado,
Wesley Santos