☰

Problemas com back-end LDAP no OpenLDAP

tag-icon • tag-icon replication openldap slapd
Problemas com back-end LDAP no OpenLDAP

Bom dia;

Depois de trabalhar na configuração de um servidor proxy LDAP para replicar dados LDAP, recebo a seguinte mensagem:

52a0b5ca send_ldap_result: conn=-1 op=0 p=3

52a0b5ca send_ldap_result: err=32 correspondido="" text=""

52a0b5ca ==> ldap_back_add("dc=basecorp,dc=net")

52a0b5ca =>ldap_back_getconn: conexão 0x7f40ea0 buscada refcnt=1.

/usr/libexec/slapd: erro de pesquisa de símbolo: /usr/libexec/openldap/back_ldap-2.4.so.2: símbolo indefinido: ldap_add_ext

Isso ocorre com o OpenLDAP 2.4.37 em um host Solaris 10 x86 e também em um host RedHat 5.5. Ambos são instalados a partir de fontes, incluindo a distribuição BDB mais recente. sourceserver é a máquina da qual desejo extrair dados e sincronizar com destserver (veja as configurações abaixo).

Então, a única coisa que as duas máquinas nas quais tentei executar o proxy têm em comum sou eu (ugh!). O problema é que configurei o proxy ao contrário? Talvez eu não tenha permissão para adicionar uma entrada a um back-end LDAP? Esperançosamente, um de vocês pode examinar minhas configurações abaixo e responder à minha pergunta, assim como a muitas outras por aí.

Meu slapd.conf para o proxy:

database ldap
hidden on
suffix "dc=basecorp,dc=net"
rootdn "cn=Manager"
uri    ldaps://destserver01.dest.net:636

lastmod on


acl-bind  bindmethod=simple
          binddn="cn=Manager"
          credentials=mypassword

syncrepl  rid=500
          provider=ldaps://sourceserver01.dest.net:636
          binddn="cn=Manager"
          bindmethod=simple
          credentials=mypassword
          searchbase="dc=basecorp,dc=net"
          filter="(objectClass=*)"
          scope=sub
          schemachecking=on
          type=refreshAndPersist
          retry="5 5 300 5"

overlay   syncprov

Por último, permita-me jogar lama na água:

Eu usei nm:

[root@buildtest01 ~]# nm  /usr/libexec/openldap/back_ldap-2.4.so.2 | grep ldap_add
                 U ldap_add_ext

E aí está o meu símbolo que falta. Com!?

Responder1

Como presumido @c4f4t0r, você (ainda) não está tendo problemas de configuração - você está tendoconstruir problemas relacionados.

DR:não use back-ends dinâmicos, eles estão quase sempre quebrados, a menos que você mexa no processo de construção. Pule para a atualização abaixo para ver os detalhes horríveis...

Você provavelmente possui bibliotecas LDAP antigas ou não OpenLDAP nos locais padrão do sistema. Não acredito que o configurescript seja inteligente o suficiente para testar essa condição ou que o processo de construção seja suficientemente robusto para lidar com ela. Por exemplo, se um antigo libldap.sofor encontrado em um local da biblioteca do sistema, ele será usado em preferência ao correto e instalado recentemente libldap.soem tempo de execução. Correr lddcontra back_ldap-2.4.sodeve mostrar isso.

Você pode consertar isso (sem reconstruir) adicionando o diretório relevante à variável de ambiente LD_LIBRARY_PATHpara que o diretório com as bibliotecas OpenLDAP mais recentes seja pesquisado primeiro (certifique-se de usar exporta variável).

Ou corrija-o (de preferência) no momento da compilação, executando configurecom a LDFLAGSvariável de ambiente definida com umRPATHque codificará um caminho de pesquisa de biblioteca nos binários que você construir.

Você não forneceu suas configureopções ou caminho de instalação, etc. Usei variações disso no passado:

export LDFLAGS="-L/usr/local/ssl/lib -Wl,-rpath,/usr/local/ssl/lib"

no caso em que eu queira usar um OpenSSL que não seja do sistema, o mesmo se aplica ao uso de uma versão do BerkeleyDB que não seja do sistema. No Solaris, você pode precisar usar "-R" em vez de "-rpath" (se estiver usando gcco vinculador Sun em vez do vinculador GNU):

export LDFLAGS="-L/usr/local/ssl/lib -R/usr/local/ssl/lib"

No seu caso, você provavelmente só precisa definir o rpath ( -Wl,-rpathou -R), não -L(embora eu recomende usar ambos quando para os casos de OpenSSL e BerkeleyDB).

AtualizarVocê está construindo com:

/configure --prefix=/usr --sysconfdir=/etc --enable-slapd --enable-crypt \
    --enable-modules --enable-bdb=mod --enable-hdb=mod --enable-ldap=yes \
    --enable-perl=mod --enable-overlays=mod --with-tls --with-gnu-ld

Observação " --enable-ldap=yes",isso constrói o back-end LDAP estaticamente emslapd, ele não cria um carregável dinamicamente back_ldap.so(ou seja --enable-ldap=mod, ). Uma possibilidade é que você tenha um arquivo perdido back_ldap.so que está tentando carregar em seu servidor e um arquivo moduleload back_ldap. No entanto, slapdnão permitirá que você carregue um módulo dinâmico quando existir um módulo estático com o mesmo nome, portanto, seu slapdbinário não parece ser como você descreveu.

Execute slapd -VVVpara confirmar back-ends estáticos.

Supondo back_ldapque seja estático, você poderá solucionar esse problema e remover qualquer erro moduleloade obsoleto .sopara garantir.

eu tenho umfortesuspeita que haja algum libtool, erro de dependência ou problema de vinculador escondido aqui. Posso reproduzir isso com um back_ldap dinâmico. ldap_add_exté de fato um símbolo não resolvido que não é necessariamente um problema (devido ao explícito dlopen()para módulos), mas esse símbolo não é exportado por slapd. Istoéexportado por libldap.so, mas isso não é uma dependência back_ldap.soe nada mais faz com libldapque seja carregado. (Isso também significa que o conselho que dei acima não resolverá o problema, pois não é tão simples quanto um problema de caminho de biblioteca.)

O que está acontecendo (ou seja, o erro que você está vendo) é que o símbolo ldap_add_extnão está sendo resolvido até que seja necessário (ligação "preguiçosa"). Quando você tenta adicionar um objeto LDAP, ele é finalmente necessário, é claro. Então as rodas saem. (Se você sentir vontade, poderá interrompê-lo no horário de início, exportando, LD_BIND_NOW=1o que desativa a ligação preguiçosa e, em seguida, start slapd, embora as chances sejam de que um símbolo diferente o desative.)

No momento, a opção mais simples é trabalhar com um static back_ldap( --enable-ldap=yese talvez make clean && make depend && make installter certeza de que slapdestá construído corretamente). Uma opção menos simples é usar para contornar o problema da dependência e cruzar os dedos esperando que isso não tenha alguns efeitos colaterais estranhos.LD_PRELOAD=/usr/lib/libldap.soLD_PRELOAD=/usr/lib/libldap_r.so

OK, este e-mail antigo cobre o problema:http://www.openldap.org/lists/openldap-software/200211/msg00469.html slapdestá vinculado a uma estática libldap_r.apor padrão,isso limita os símbolos que estarão disponíveis para aqueles conhecidos no momento do link. Como os módulos dinâmicos são carregados em tempo de execução com dlopen()o vinculador não há visibilidade de seus requisitos (símbolos/bibliotecas).

Pode-se razoavelmente concluir que a construção dinâmica de (alguns) back-ends está praticamente interrompida há algum tempo.

Portanto, não use back-ends dinâmicos (recomendado) ou falsifique a construção (não tão recomendado) com algo como:

make depend && make
rm servers/slapd/slapd
LTSTATIC="" make -e     # alternative to editing the Makefile
make install

Isso se vincula slapdao que libldap_r.sovocê acabou de criar em vez do .a, para que todos os símbolos possam ser carregados quando necessário (também diminui slapdcerca de 15% no disco). Não executei um servidor LDAP operacional com isso, YMMV. Deve haver algumas soluções semelhantes ou alternativas usadas pelas distros...

Responder2

Este não é um problema de configuração, o erro é claro, está dizendo que o openldap está procurando uma função na biblioteca /usr/libexec/openldap/back_ldap-2.4.so.2 que não existe.

No redhat 5, por que você não usa o ldap padrão no formato rpm?

informação relacionada