A necessidade de replicar bases de dados OpenLDAP surge a partir do momento que apenas uma máquina não está dando conta da carga ou simplesmente quando necessitamos de redundância no serviço. Se considerarmos que o serviço de diretórios está centralizando toda a informação em um único lugar, concluímos logo que se esse único ponto falhar, todos os serviços que dele dependem também sairão do ar.

Junto com a replicação da informação surge o problema de manter todas as bases de dados sincronizadas, o que pode ser uma tarefa bastante complicada.

O OpenLDAP opera em um ambiente com um “Servidor Mestre” e vários outros secundários (tantos quantos forem necessários). Nesse ambiente, as consultas são efetuadas nas máquinas “Secundárias” e as atualizações na máquina “Mestre”. Quando uma atualização é efetuada na máquina “Mestre” a replicação é feita automaticamente, propagando essa informação para as máquinas “Secundárias”.

No caso do OpenLDAP existem duas técnicas diferentes de replicação: Slurpd e Syncrepl

Esta técnica é mais antiga, inclusive foi descontinuada na séria 2.4, e mantém a responsabilidade da replicação no Servidor Mestre. Utilizando um servidor de replicação chamado “slurpd”, ou seja, se esse serviço falhar, todas as replicações param.

No caso de ocorrer algum problema de comunicação entra a máquina “Mestre” e a “Secundária”, ou mesmo a máquina “Secundária” estar fora do ar durante a replicação da informação será gerado um arquivo de rejeição, cuja a extensão será “.rej” e que contém a informação que deveria ter sido propagada.

Nesse ponto ressalta-se que a sincronização das bases, utilizando este método, NÃO É RETROATIVA, ou seja, no momento em que o processo de replicação é iniciado, as bases de dados do “Servidor Mestre” e dos “Servidres Secundários” devem ser equivalentes. Além disso, se um arquivo de rejeição for gerado, o “slurpd” não irá tentar novamente, essa tarefa cabe ao administrador do sistema fazer manualmente.

As principais razões da descontinuidade são:

• Não é confiável;

• É extremamente sensível a ordem na qual os registros são gravados;

• A replicação deixa de funcionar facilmente, o que exige intervenção manual contínua para mantê-la.

• Não tolera longos períodos sem comunicação. Se o Servidor Mestre fica fora do ar por muito tempo o arquivo de rejeição cresce tanto que o “slurpd” não é capaz de processá-lo.

Este é o método atualmente utilizado e único disponível a partir da série 2.4 do OpenLDAP. Trata-se de um módulo do próprio “slapd” e não há necessidade de ativar mais um serviço a parte.

O Syncrepl é basicamente um sistema de replicação que é ativado e controlado pelo “Servidor Secundário”, ou seja, a responsabilidade de manter a replicação fica no cliente e não no servidor. A vantagem imediata deste método é não ter que reiniciar o “Servidor Mestre” sempre que se vai adicionar uma réplica ao ambiente. Outro aspecto importante é o fato de que se a conexão entre o “Servidor Master” e o “Servidor Secundário” for interrompida por algum tempo e depois restaurada, a sincronização será feita automaticamente, sem a necessidade de intervenção manual.

Dois métodos de replicação estão disponíveis no “syncrepl”:

push-based - Neste método o “Servidor Secundário”, após a primeira sincronização, monitora o “Servidor Mestre” de tempos em tempos, comparando as duas bases e atualizando às informações que foram modificadas. Este tempo é configurável. Este método é ativado definindo a opção “type” da configuração como “refreshOnly”.

pull-based - Neste método o “Servidor Secundário”, após a primeira sincronização, mantém uma conexão persistente com o “Servidor Mestre”. Assim qualquer alteração é sincronizada imediatamente. Este método é ativado definindo a opção “type” da configuração como “refreshAndPersist”.

Os dois métodos são extremamente eficientes porque utilizam um sistema de controle que informa apenas os campos que foram alterados, não sendo necessário trafegar a base completa do “Servidor Mestre” para o “Servidor Secundário”.

Todas as alterações feitas, sejam no “Servidor Master”, seja no “Servidor Secundário” são armazenados, originalmente em memória, usando para isso um “log”. Este log é volátil e não pode ser acessado diretamente.

1. Configure o “/etc/hosts” para que seja possível resolver o nome de todos os “Servidores Secundários”

2. Pare o OpenLDAP no “Servidor Master”

3. Edite o arquivo de configuração “slapd.conf” adicione, abaixo da opção “index”, o seguinte conteúdo:

replica uri=ldap://ldap__.kyapanel.com.br/
        binddn="cn=Replicator,dc=kyapanel,dc=com,dc=br"
        bindmethod=simple
        credentials=123456
        tls=yes

Explicando:

linha 1 – Define o “Servidor Secundário”
linha 2 – “binddn” é o DN do usuário que deve efetuar a alteração na base de dados do “Servidor Secundário”. Esse usuário deve ser diferente do usuário administrador da base do “ Servidor Master”
linha 3 – “bindmethod” especifica o método de autenticação e “simple” significa, sem SASL.
linha 4 – “credentials” define a senha do usuário especificado na opção “binddn”
linha 5 – “tls” especifica se a conexão entre o “Servidor Master” e o “Servidor Secundário” deve usar criptografia; sempre uma boa idéia!

Deve-se fazer uma configuração como esta para cada “Servidor Secundário” no qual se deseja ter uma réplica.

4. Procure pela opção “replogfile” e descomente essa linha.

5. Adicione à base de dados o usuário “Replicator” que é do tipo SimpleSecurityObject. Para fazer isso, edite um arquivo chamado replicator.ldif e insira o seguinte conteúdo:

dn: cn=Replicator,dc=kyapanel,dc=com,dc=br
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: Replicator
description: LDAP Replicator
userPassword: 123456

6. Pare o OpenLDAP e dicione o usuário com o comando:

slapadd -l replicator.ldif

7. Inicie o OpenLDAP em modo debug, só para ter certeza de que não há nenhum erro:

slapd -d 64

8. Se não ocorreu nenhum erro pode-se ativar o servidor OpenLDAP.

A configuração do(s) “Servidore(s) Secundário(s)” são ligeiramente diferentes do “Servidor Master”. Sendo assim vamos usar como ponto de partida o arquivo de configuração da “Servidor Master”.

1. Configure o “/etc/hosts” para que seja possível resolver os nomes dos servidores “Master” e “Secundários”

2. Copie, o arquivo de configuração “slapd.conf” do “Servidor Master” para a o “Servidor Secundário” em questão. Lembre-se de fazer uma cópia de segurança do arquivo atual, antes de sobrescrevê-lo.

3. Edite o arquivo “slapd.conf” e apague as linhas de configuração de replica que foram definidas no “Servidor Master”, ou seja, remova as linhas com as opções:

replica
replogfile

4. Adicione, após a opção “index” o seguinte conteúdo:

updatedn cn=Replicator,dc=kyapanel,dc=com,dc=br
updateref ldap://ldap__.kyapanel.com.br/

Explicando:

linha 1 – define o usuário que será utilizado para fazer a réplica. Em nosso exemplo é cn=Replicator,dc=kyapanel,dc=com,dc=br.
linha 2 – define o “host” do “Servidor Master”

5. Altere as “ACL’s” para que o usuário “Replicator” tenha permissões totais de escrita na base e o usuário “admin” não tenha mais permissão. Para isso basta substituir o usuário “admin” por “Replicator” em todas as ACL‘s. Deve ficar assim:

access to attrs=userPassword,shadowLastChange
    by dn="cn=Replicator,dc=kyapanel,dc=com,dc=br" write
    by anonymous auth
    by self write
    by * none

access to dn.base="" by * read

access to *
    by dn="cn=Replicator,dc=kyapanel,dc=com,dc=br"
    write
    by * read

6. Uma vez que o “Servidor Secundário” está configurado, é necessário trazer a base física do “Servidor Master”. Lembre-se que para fazer replicação utilizando “slurpd” é necessário que o estado das bases, nos dois lados, seja idêntico. Portanto:

cd /var/lib/ldap
rm /var/lib/ldap/*
scp root@ldap__.kyapanel.com.br:/var/lib/ldap/* /var/lib/ldap/

7. Não esqueça de verificar o permissionamento dos arquivos. Na dúvida execute:

chown openldap: /var/lib/ldap/*

8. Inicie o “Servidor Secundário” em modo debug 64 para verificar se está tudo correto:

slapd -d 64

1. Esteja seguro de que o OpenLDAP está sendo executado nos dois servidores. Pode se usar diversos comandos para isso. Os mais comuns são:

netstat -putan | grep 389
nmap localhost
fuser -v 389/tcp

2. No “Servidor Master”, ative o “slurpd” em modo debug para ter certeza de que as configurações estão funcionando:

pkill -INT slurpd
slurpd -d 64

3. Com o cliente “ldapvi” simule uma alteração na base do “Servidor Secundário” e verifique com “slapcat” se as alterações foram feitas nos dois servidores.

Neste servidor as configurações são mínimas e perenes, ou seja, só precisam ser feitas uma única vez, independente de quantos “Servidores Secundários” forem ser utilizados.

1. Pare o OpenLDAP

2. Edite o arquivo de configuração “slapd.conf” e procure pela opção “modulepath”. Logo abaixo de qualquer opção “moduleload”, insira o seguinte conteúdo:

moduleload syncprov

Esta linha faz com que o OpenLDAP utilize o módulo “syncprov” que é o responsável por ativar o recurso de sincronização.

3. Logo abaixo da opção “index” adicione o seguinte conteúdo:

overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100

Explicando

linha 1 – ativa a camada de sincronização
linha 2 – configura os “pontos de checagem”. Nesta linha são passados dois argumentos: o primeiro é o número de transações e o segundo é o tempo em minutos. Quando qualquer um dos dois for atingido o “Syncrepl” fará mais uma checagem.
linha 3 – Número máximo de registros que serão mantidos no “log” de alterações que serão replicadas.

4. A Replicação dos atributos userPassword e shadowLastChange somente será possível, utilizando o usuário Replicator se lhe for concedido o devido permissionamento.

Por padrão esses dois atributos só podem ser lidos/modificados pelo usuário “admin” e/ou por usuários autenticados.

Para permitir que o usuário “Replicator” possa ler esses atributos e assim replicá-los, altere a ACL que controla esses atributos, adicionando a linha abaixo:

by dn="cn=Replicator,dc=kyapanel,dc=com,dc=br" read

5. Inicie o “Servidor Master” em modo debug para verificar se está tudo certo:

slapd -d 64

6. Se estiver tudo certo, então inicie o OpenLDAP da forma convencional.

Estas configurações devem ser feitas em todas as replicas.

1. Pare o OpenLDAP

2. Edite o arquivo de configuração “slapd.conf” e logo abaixo da opção “index” adicione o seguinte conteúdo:

syncrepl rid=123
     provider=ldap://ldap__.kyapanel.com.br:389
     type=refreshOnly
     interval=00:00:00:10
     searchbase="dc=kyapanel,dc=com,dc=br"
     filter="(objectClass=*)"
     scope=sub
     attrs="*"
     schemachecking=off
     bindmethod=simple
     binddn="cn=Replicator,dc=kyapanel,dc=com,dc=br"
     credentials=123456

Explicando:

linha 1 – “rid” é o “replicator id” e é um número que não deve passar de três dígitos
linha 2 – “provider” define o host e a porta de conexão do “Servidor Master”
linha 3 – “type” define a técnica de replicação: “refreshOnly” ou “refreshAndPersist”
linha 4 – “interval” define o intervalo de verificação para a técnica de replicação “refreshOnly”, no formato “dias:horas:minutos:segundos”
linha 5 – “searchbase” define a parte da árvore a partir da qual a pesquisa para replicação será feita. Aconselhamos deixar a raiz da base definida nesta opção.
linha 6 – “filter” define o filtro de pesquisa que será feita em busca de alterações. Isso significa que pode-se definir o que se deseja replicar. Se não declarado, seu valor padrão é “(objectClass=*)”
linha 7 – “scope” define se a pesquisa será recursiva ou não. Se não declarada, seu valor padrão é “sub”, ou seja, recursiva
linha 8 – “attrs” define quais atributos serão pesquisados. Pode-se definir uma lista de atributos separados por vírgula. Se não declarada, seu valor padrão é “*”, ou seja, todos.
linha 9 – “schemachecking” ativa a checagem dos schemas, ou seja, será feita uma verificação para saber se os schemas existem, antes de fazer a sincronização. Se não declarada, seu valor padrão é “off”, ou seja, desativada
linha 10 – “bindmethod” é o método pelo qual a autenticação será realizada. As opções são “simple” ou “sasl”. A opção “simple” somente deve ser usada se houver um ambiente seguro de comunicação ou se a comunicação estiver sob “TLS”. A opção “sasl” exigirá a adição da opção “saslmech” para definir o mecanismo sasl que deve ser usado.
linha 11 – “binddn” define o usuário que será usado para a replicação.
linha 12 – “credentials” - define a senha do usuário que será usado para a replicação.

3. Descomente e configure corretamente a opção “rootdn”. Ela tem que estar explicitada.

rootdn          "cn=admin,dc=kyapanel,dc=com,dc=br"

4. Remova a base física, ou seja, apague o conteúdo de /var/lib/ldap para garantir uma primeira replicação fiel.:w

rm /var/lib/ldap/*

5. Inicialize o OpenLDAP

Se for necessário ou desejável, altere a opção “type” para “refreshAndPersist” e comente a opção “interval” para que a replicação seja feita em tempo de execução.

A replicação é ativada no momento em que o OpenLDAP é ativado no “Servidor Secundário”.

Antes de iniciarmos as configurações e integrações com outros serviços será importante popular a nossa base LDAP com alguns usuários e grupos. Assim os testes podem ser realizados de forma mais verídica.

Para popular a base LDAP utilizaremos o script abaixo.

1. Crie um arquivo chamado popula.sh e insira o conteúdo abaixo:

#! /bin/bash

LDAP_HOST="localhost"
LDAP_PORT="389"
LDAP_DN="cn=admin,dc=kyapanel,dc=com,dc=br"
LDAP_PWD="senha"

USERS_FILE="/tmp/users.ldif"
UID_NUMBER="2000"

>$USERS_FILE

I=1
while [ "$I" -le "30" ] ; do

# Criando arquivo ldif
  echo "dn: cn="Fulano$I da Silva",ou=Usuarios,dc=kyapanel,dc=com,dc=br"
>> $USERS_FILE
  echo "uid: fulano$I" >> $USERS_FILE
  echo "cn: Fulano$I da Silva" >> $USERS_FILE
  echo "sn: fulano$I" >> $USERS_FILE
  echo "givenName: fulano$I" >> $USERS_FILE
  echo "objectclass: inetOrgPerson" >> $USERS_FILE
  echo "objectclass: posixAccount" >> $USERS_FILE
  echo "objectclass: shadowAccount" >> $USERS_FILE
  echo "homeDirectory: /home/fulano$I" >> $USERS_FILE
  echo "loginShell: /bin/bash" >> $USERS_FILE
  echo "uidNumber: $UID_NUMBER" >> $USERS_FILE
  echo "gidNumber: $UID_NUMBER" >> $USERS_FILE
  USER_PWD=`slappasswd -s fulano$I`
  echo "userPassword: $USER_PWD" >> $USERS_FILE
  echo "gecos: Super $UID_NUMBER" >> $USERS_FILE
  echo "" >> $USERS_FILE
  echo "dn: cn="fulano$I",ou=Grupos,dc=kyapanel,dc=com,dc=br" >> $USERS_FILE
  echo "cn: fulano$I" >> $USERS_FILE
  echo "objectclass: top" >> $USERS_FILE
  echo "objectclass: posixGroup" >> $USERS_FILE
  echo "gidNumber: $UID_NUMBER" >> $USERS_FILE
  echo "memberUid: fulano$I" >> $USERS_FILE
  echo "" >> $USERS_FILE
 I=`expr $I + 1`
 UID_NUMBER=`expr $UID_NUMBER + 1`
done

ldapadd -h $LDAP_HOST -p $LDAP_PORT -x -D $LDAP_DN -w $LDAP_PWD 
-f $USERS_FILE

rm $USERS_FILE

2. Execute o script popula.sh com o comando:

sh popula.sh

3. Verifique se os usuários foram criados usando o comando slapcat ou algum cliente LDAP de sua preferência.

Serão criados trinta usuários com estas informações:

cn=”FulanoX da Silva”
uid=fulanoX
userPassword=fulanoX

Onde X é um número variando de 1 a 30.

Copyright 2007 Anahuac de Paula Gil e Francisco Kem Iti Saito

Permite-se distribuição, publicação e cópia literal da íntegra deste documento, sem pagamento de royalties, desde que sejam preservadas a nota de copyright, a URL oficial do documento e esta nota de permissão.

Permite-se também distribuição, publicação e cópia literal de seções individuais deste documento, sem pagamento de royalties, desde que sejam preservadas a nota de copyright e a nota de permissão acima, e que a URL oficial do documento seja preservada ou substituída pela URL oficial da seção individual.