Guten Morgen;
Nachdem ich daran gearbeitet habe, einen LDAP-Proxyserver zum Replizieren von LDAP-Daten einzurichten, erhalte ich immer wieder die folgende Meldung:
52a0b5ca send_ldap_result: conn=-1 op=0 p=3
52a0b5ca send_ldap_result: err=32 matched="" text=""
52a0b5ca ==> ldap_back_add("dc=basecorp,dc=net")
52a0b5ca =>ldap_back_getconn: conn 0x7f40ea0 hat refcnt=1 abgerufen.
/usr/libexec/slapd: Fehler bei der Symbolsuche: /usr/libexec/openldap/back_ldap-2.4.so.2: undefiniertes Symbol: ldap_add_ext
Dies ist mit OpenLDAP 2.4.37 sowohl auf einem Solaris 10 x86-Host als auch auf einem RedHat 5.5-Host der Fall. Beide sind aus Quellen installiert, einschließlich der neuesten BDB-Distribution. Der Quellserver ist die Maschine, von der ich Daten abrufen und mit dem Zielserver synchronisieren möchte (siehe Konfigurationen unten).
Das Einzige, was die beiden Maschinen, auf denen ich versucht habe, den Proxy auszuführen, gemeinsam haben, bin ich (pfui!). Liegt das Problem daran, dass ich den Proxy falsch eingerichtet habe? Vielleicht darf ich keinen Eintrag zu einem LDAP-Backend hinzufügen? Hoffentlich kann einer von euch meine Konfigurationen unten prüfen und meine Frage sowie viele andere da draußen beantworten.
Meine slapd.conf für den 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
Zum Schluss gestatten Sie mir noch, etwas Dreck ins Wasser zu werfen:
Ich habe nm verwendet:
[root@buildtest01 ~]# nm /usr/libexec/openldap/back_ldap-2.4.so.2 | grep ldap_add
U ldap_add_ext
Und da ist mein fehlendes Symbol. Was zum Teufel!?
Antwort1
Wie @c4f4t0r vermutet, haben Sie (noch) keine Konfigurationsprobleme - Sie habenBuild-bezogene Probleme.
Kurz zusammengefasst:Verwenden Sie keine dynamischen Backends, diese funktionieren meistens nicht, wenn Sie nicht am Build-Prozess herumfummeln. Die grausigen Details finden Sie im folgenden Update ...
Sie haben wahrscheinlich alte oder nicht OpenLDAP-LDAP-Bibliotheken in den Standardsystemspeicherorten. Ich glaube nicht, dass das configureSkript intelligent genug ist, um auf diesen Zustand zu testen, oder dass der Build-Prozess robust genug ist, um damit umzugehen. Wenn beispielsweise eine alte libldap.soBibliothek in einem Systemspeicherort gefunden wird, wird sie der korrekten und libldap.sozur Laufzeit neu installierten vorgezogen. Das Ausführen lddvon against back_ldap-2.4.sosollte dies zeigen.
Sie können dies möglicherweise beheben (ohne neu zu erstellen), indem Sie das entsprechende Verzeichnis zur Umgebungsvariablen hinzufügen, LD_LIBRARY_PATHsodass zuerst das Verzeichnis mit den neuesten OpenLDAP-Bibliotheken durchsucht wird (achten Sie auf exportdie Variable).
Oder beheben Sie das Problem (vorzugsweise) zur Build-Zeit, indem Sie configuredie LDFLAGSUmgebungsvariable mit einemRPATHDadurch wird ein Bibliothekssuchpfad in die von Ihnen erstellten Binärdateien fest codiert.
Sie haben weder Ihre configureOptionen noch den Installationspfad usw. angegeben. Ich habe in der Vergangenheit Variationen davon verwendet:
export LDFLAGS="-L/usr/local/ssl/lib -Wl,-rpath,/usr/local/ssl/lib"
Falls ich ein nicht systemeigenes OpenSSL verwenden möchte, gilt das Gleiche für die Verwendung einer nicht systemeigenen Version von BerkeleyDB. Unter Solaris müssen Sie möglicherweise „-R“ anstelle von „-rpath“ verwenden (wenn Sie gccden Sun-Linker statt den GNU-Linker verwenden):
export LDFLAGS="-L/usr/local/ssl/lib -R/usr/local/ssl/lib"
-Wl,-rpathIn Ihrem Fall müssen Sie wahrscheinlich nur den R-Pfad ( oder ) festlegen -R, nicht -L(obwohl ich in den Fällen von OpenSSL und BerkeleyDB die Verwendung beider empfehle).
AktualisierenSie bauen mit:
/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
Notiz " --enable-ldap=yes",Dadurch wird das LDAP-Backend statisch inslapd, es erstellt kein dynamisch ladbares Modul back_ldap.so(d. h. --enable-ldap=mod). Eine Möglichkeit ist, dass Sie ein verirrtes Modul haben back_ldap.so , das Sie in Ihren Server laden möchten, und ein nicht benötigtes moduleload back_ldap. slapdEs erlaubt Ihnen jedoch nicht, ein dynamisches Modul zu laden, wenn ein statisches Modul mit demselben Namen vorhanden ist, sodass Ihre slapdBinärdatei nicht so aussieht, wie Sie es beschrieben haben.
Ausführen slapd -VVV, um statische Backends zu bestätigen.
Vorausgesetzt, back_ldapes handelt sich um ein statisches System, sollten Sie in der Lage sein, dieses Problem zu umgehen und vorsichtshalber alle fehlerhaften moduleloadund veralteten Daten zu entfernen..so
Ich habe einstarkIch vermute, dass hier ein Libtool-, Abhängigkeits- oder Linker-Problem lauert. Ich kann dies mit einem dynamischen Back_LDAP reproduzieren. ldap_add_extist in der Tat ein nicht aufgelöstes Symbol, das nicht unbedingt ein Problem darstellt (aufgrund der expliziten dlopen()für Module), aber dieses Symbol wird nicht von exportiert slapd. EsIstexportiert von libldap.so, aber das ist keine Abhängigkeit von back_ldap.sound nichts anderes bewirkt, libldapdass es geladen wird. (Das bedeutet auch, dass der Rat, den ich oben gegeben habe, das Problem nicht lösen wird, da es nicht so einfach ist wie ein Bibliothekspfadproblem.)
Was passiert (also der Fehler, den Sie sehen), ist, dass das Symbol ldap_add_extnicht aufgelöst wird, bis es benötigt wird („träge“ Bindung). Wenn Sie versuchen, ein LDAP-Objekt hinzuzufügen, wird es natürlich endlich benötigt. Dann geht alles schief. (Sollten Sie den Drang verspüren, können Sie es beim Start unterbrechen, indem Sie „exportieren“, LD_BIND_NOW=1wodurch die verzögerte Bindung deaktiviert wird, und dann „starten“ slapd, obwohl die Wahrscheinlichkeit groß ist, dass ein anderes Symbol es auslöst.)
Derzeit ist die einfachste Möglichkeit, mit einem statischen back_ldap( zu arbeiten --enable-ldap=yesund vielleicht make clean && make depend && make installsicherzustellen, dass slapdes richtig aufgebaut ist). Eine weniger einfache Möglichkeit besteht darin, das Abhängigkeitsproblem zu umgehen und die Daumen zu drücken, dass dies keine merkwürdigen Nebenwirkungen hat.LD_PRELOAD=/usr/lib/libldap.soLD_PRELOAD=/usr/lib/libldap_r.so
OK, diese alte E-Mail behandelt das Problem:http://www.openldap.org/lists/openldap-software/200211/msg00469.html
slapdlibldap_r.aist standardmäßig mit einer statischen Verbindung verknüpft ,Dadurch werden die Symbole begrenzt, die zum Zeitpunkt der Verknüpfung bekannt sind.. Da die dynamischen Module zur Laufzeit mit dlopen()dem Linker geladen werden, hat dieser keinen Einblick in ihre Anforderungen (Symbole/Bibliotheken).
Man könnte vernünftigerweise zu dem Schluss kommen, dass der dynamische Aufbau (einiger) Backends seit einiger Zeit ziemlich defekt ist.
Verwenden Sie also entweder keine dynamischen Backends (empfohlen) oder verfälschen Sie den Build (nicht unbedingt empfohlen) mit etwas wie:
make depend && make
rm servers/slapd/slapd
LTSTATIC="" make -e # alternative to editing the Makefile
make install
Dies verknüpft slapdmit dem libldap_r.sogerade erstellten anstelle des .a, sodass alle Symbole bei Bedarf geladen werden können (es macht slapddie Festplatte außerdem um etwa 15 % kleiner). Ich habe damit noch keinen funktionsfähigen LDAP-Server ausgeführt, Ihre Erfahrung kann abweichen. Es muss ähnliche oder alternative Lösungen geben, die von Distributionen verwendet werden ...
Antwort2
Dies ist kein Konfigurationsproblem. Der Fehler ist eindeutig und zeigt Ihnen an, dass OpenLDAP in der Bibliothek /usr/libexec/openldap/back_ldap-2.4.so.2 nach einer Funktion sucht, die nicht vorhanden ist.
Warum verwenden Sie unter Redhat 5 nicht das Standard-LDAP im RPM-Format?