Replicação da base LDAP

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:

Configuração inicial 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=cooperati,dc=local”
        bindmethod=simple
        binddn=”cn=admin,dc=cooperati,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=cooperati,dc=local”
       bindmethod=simple
       binddn=”cn=admin,dc=cooperati,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=cooperati,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.

  • Tarcisio Cavalcanti

    Olá Ricardo, excelente matéria, me ajudou bastante na implementação da replicação que preciso configurar aqui nos LDAP na empresa.
    Pode tirar uma duvida, após efetuar esta configuração, tanto na maquina master, como na slave 001 e 002, esta gerando a seguinte mensagem:

    No master 001:

    Aug 2 17:39:31 sldap slapd[1075]: do_syncrep2: rid=002 got search entry without Sync State control
    Aug 2 17:39:31 sldap slapd[1075]: do_syncrepl: rid=002 rc -1 retrying (2 retries left)

    E no Master002 :

    Aug 2 17:38:31 sldap-client slapd[1262]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.1.9.1.1
    Aug 2 17:38:31 sldap-client slapd[1262]: connection_read(16): no connection!

    Ja viu essa mensagem ?

    Se puder dar uma dica agradeço. Muito Obrigado.

  • Jackson

    Estou com problemas: não esta replicando para o slaver da esse erro
    slap_client_connect: URI=ldap://172.28.2.92:389 DN=”cn=admin,dc=teste,dc=local” ldap_sasl_bind_s failed (-1)

    • Jackson,

      Use a replicação sem SASL que deve funcionar.

      • Jackson

        Como eu desabilito esse item já que na instalação dos pacotes só instalei o slapd e slapd-utils

        • A replicação é configurada no arquivo slapd.conf, é nele que você deve usar dentro das configurações de replicação(no master e no slave):

          bindmethod=simple

          Isso deve bastar.

  • Jackson

    Bom dia Vagner,
    Eu parei meu servidor principal do ldap ficando o Slaver e não consigo logar no Squid3 na ultima informação que você me passou “bindmethod=simple” já estava habilitada eu não sei o que precisa pra sincronizar se puder me ajudar eu agradeço.

    • É pra sincronizar entre master e slave ou pra usar um programa para logar no ldap?

  • Jackson

    Boa tarde Vagner,
    As duas coisas, quero ter vários slave e usar a base Ldap para vários serviços samba, squid, e-mail e etc.

  • Beleza,

    Estou tendo problemas para criar a replicação, veja a mensagem abaixo.

    syncrepl rid=123 searchbase=”dc=empresa,dc=mg,dc=gov,dc=br”: no retry defined, using default

    Sabe como resolver ?

    syncrepl rid=123
    provider=ldap://10.26.7.45:389
    type=refreshOnly
    interval=00:00:05:00
    searchbase=”dc=defensoria,dc=mg,dc=gov,dc=br”
    filter=”(objectClass=organizationalPerson)”
    scope=sub
    attrs=”*,+”
    schemachecking=off
    bindmethod=simple
    binddn=”cn=admin,dc=defensoria,dc=mg,dc=gov,dc=br”
    credentials=secret

  • Iago

    Pessoal fiz conforme explica no artigo mais sem sucesso, alguem poderia me auxiliar???