☰

Problemas con el backend LDAP en OpenLDAP

tag-icon • tag-icon replication openldap slapd
Problemas con el backend LDAP en OpenLDAP

Buen día;

Después de trabajar en la configuración de un servidor proxy LDAP para replicar datos LDAP, sigo recibiendo el siguiente mensaje:

52a0b5ca send_ldap_result: conexión=-1 op=0 p=3

52a0b5ca send_ldap_result: err=32 coincidente="" texto=""

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

52a0b5ca =>ldap_back_getconn: conexión 0x7f40ea0 obtuvo refcnt=1.

/usr/libexec/slapd: error de búsqueda de símbolo: /usr/libexec/openldap/back_ldap-2.4.so.2: símbolo no definido: ldap_add_ext

Esto es con OpenLDAP 2.4.37 tanto en un host Solaris 10 x86 como en un host RedHat 5.5. Ambos se instalan desde fuentes, incluida la última distribución BDB. sourceserver es la máquina de la que deseo extraer datos y sincronizarlos con destserver (consulte las configuraciones a continuación).

Entonces, lo único que tienen en común las dos máquinas en las que intenté ejecutar el proxy soy yo (¡uf!). ¿El problema es que configuré el proxy al revés? ¿Quizás no puedo agregar una entrada a un servidor LDAP? Con suerte, uno de ustedes puede examinar mis configuraciones a continuación y responder mi pregunta, así como muchas otras.

Mi slapd.conf para el 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, permítanme tirar barro al agua:

Yo usé nm:

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

Y ahí está mi símbolo faltante. ¿¡Qué!?

Respuesta1

Como supone @c4f4t0r, (todavía) no estás teniendo problemas de configuración, estás teniendoconstruir problemas relacionados.

TL;DR:no utilice backends dinámicos, en su mayoría están rotos a menos que juegue con el proceso de compilación. Vaya a la actualización a continuación para conocer los horripilantes detalles...

Probablemente tenga bibliotecas LDAP antiguas o que no sean OpenLDAP en las ubicaciones predeterminadas del sistema. No creo que el configurescript sea lo suficientemente inteligente como para probar esta condición, o que el proceso de compilación sea lo suficientemente sólido para manejarla. Por ejemplo, si libldap.sose encuentra una versión antigua en la ubicación de una biblioteca del sistema, se usará con preferencia a la correcta y recién instalada libldap.soen tiempo de ejecución. Correr ldden contra back_ldap-2.4.sodebería mostrar esto.

Es posible que pueda solucionar este problema (sin reconstruir) agregando el directorio relevante a la variable de entorno LD_LIBRARY_PATHpara que primero se busque el directorio con las bibliotecas OpenLDAP más nuevas (asegúrese de usar exportla variable).

O solucionelo (preferiblemente) en el momento de la compilación, ejecutándolo configurecon la LDFLAGSvariable de entorno configurada con unRPATHque codificará una ruta de búsqueda de biblioteca en los archivos binarios que cree.

No has proporcionado tus configureopciones ni la ruta de instalación, etc. He usado variaciones de esto en el pasado:

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

En el caso de que quiera utilizar un OpenSSL que no sea del sistema, lo mismo se aplica al uso de una versión de BerkeleyDB que no sea del sistema. En Solaris, es posible que necesites usar "-R" en lugar de "-rpath" (si estás usando gccel enlazador Sun en lugar del enlazador GNU):

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

En su caso, probablemente solo necesite configurar rpath ( -Wl,-rpatho -R), no -L(aunque recomiendo usar ambos para los casos de OpenSSL y BerkeleyDB).

ActualizarEstás construyendo con:

/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

Nota " --enable-ldap=yes",esto construye el backend LDAP estáticamente enslapd, no crea un archivo cargable dinámicamente back_ldap.so(es decir --enable-ldap=mod). Una posibilidad es que tengas un archivo perdido back_ldap.so que estás intentando cargar en tu servidor y un archivo moduleload back_ldap. Sin embargo, slapdno le permitirá cargar un módulo dinámico cuando exista un módulo estático con el mismo nombre, por lo que su slapdbinario no parece ser como lo describió.

Ejecute slapd -VVVpara confirmar los backends estáticos.

Suponiendo back_ldapque sea estático, debería poder solucionar este problema y eliminar cualquier error moduleloady obsoleto .sopor si acaso.

tengo unfuerteSospecho que hay algún problema con libtool, error de dependencia o vinculador al acecho aquí. Puedo reproducir esto con un back_ldap dinámico. ldap_add_extDe hecho, es un símbolo no resuelto que no es necesariamente un problema (debido a dlopen()módulos for explícitos), pero ese símbolo no se exporta mediante slapd. Élesexportado por libldap.so, pero eso no es una dependencia de back_ldap.soy nada más causa libldapque se cargue. (Esto también significa que el consejo que di arriba no resolverá el problema, ya que no es tan simple como un problema de ruta de biblioteca).

Lo que está sucediendo (es decir, el error que está viendo) es que el símbolo ldap_add_extno se resuelve hasta que se requiere (enlace "perezoso"). Cuando intentas agregar un objeto LDAP, finalmente es necesario, por supuesto. Entonces las ruedas se desprenden. (Si siente la necesidad, puede romperlo en el momento del inicio exportando, LD_BIND_NOW=1lo que desactiva el enlace diferido y luego iniciar slapd, aunque es probable que un símbolo diferente lo active).

En este momento la opción más sencilla es trabajar con un estático back_ldap( --enable-ldap=yesy quizás make clean && make depend && make installestar seguro de que slapdestá construido correctamente). Una opción menos simple es usar para solucionar el problema de dependencia y cruzar los dedos esperando que no tenga algunos efectos secundarios extraños.LD_PRELOAD=/usr/lib/libldap.soLD_PRELOAD=/usr/lib/libldap_r.so

Bien, este antiguo correo electrónico cubre el problema:http://www.openldap.org/lists/openldap-software/200211/msg00469.html slapdestá vinculado contra una estática libldap_r.ade forma predeterminada,esto limita los símbolos que estarán disponibles para aquellos conocidos en el momento del enlace. Dado que los módulos dinámicos se cargan en tiempo de ejecución con dlopen()el vinculador no tiene visibilidad de sus requisitos (símbolos/bibliotecas).

Se podría concluir razonablemente que la construcción dinámica de (algunos) backends ha estado prácticamente interrumpida durante algún tiempo.

Por lo tanto, no utilice backends dinámicos (recomendado) o modifique la compilación (no tan recomendado) con algo como:

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

Esto se vincula slapdcon el libldap_r.soque acaba de crear en lugar del .a, por lo que todos los símbolos se pueden cargar cuando sea necesario (también hace que slapdel disco sea aproximadamente un 15 % más pequeño). No he ejecutado un servidor LDAP operativo con esto, YMMV. Debe haber algunas soluciones similares o alternativas utilizadas por las distribuciones...

Respuesta2

Esto no es un problema de configuración, el error es claro, le dice que openldap está buscando una función en la biblioteca /usr/libexec/openldap/back_ldap-2.4.so.2 que no está allí.

En redhat 5, ¿por qué no utiliza el ldap estándar en formato rpm?

información relacionada