OpenLDAP の LDAP バックエンドの問題

OpenLDAP の LDAP バックエンドの問題

おはよう;

LDAP データを複製するために LDAP プロキシ サーバーの設定に取り組んだ後、次のメッセージが繰り返し表示されます。

52a0b5ca 送信ldap結果: 接続=-1 オペレーション=0 p=3

52a0b5ca send_ldap_result: err=32 一致しました="" テキスト=""

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

52a0b5ca =>ldap_back_getconn: conn 0x7f40ea0 が refcnt=1 を取得しました。

/usr/libexec/slapd: シンボル検索エラー: /usr/libexec/openldap/back_ldap-2.4.so.2: 未定義のシンボル: ldap_add_ext

これは、Solaris 10 x86 ホストと RedHat 5.5 ホストの両方で OpenLDAP 2.4.37 を使用している状態です。両方とも、最新の BDB ディストリビューションを含むソースからインストールされています。sourceserver は、データを取得して destserver に同期するマシンです (以下の構成を参照)。

つまり、プロキシを実行しようとした 2 台のマシンに共通しているのは、私だけです (うーん!)。プロキシを逆に設定したことが問題なのでしょうか? おそらく、LDAP バックエンドにエントリを追加できないのでしょうか? 皆さんのうちの誰かが、以下の私の構成を調べて、私や他の多くの質問に答えてくれることを願っています。

プロキシ用の slapd.conf:

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

最後に、水に泥を投げ入れさせてください。

nmを使用しました:

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

そして、私の失われたシンボルがあります。何ですって!?

答え1

@c4f4t0rが推測したように、(まだ)設定の問題ではなく、ビルド関連の問題

要約:動的バックエンドを使用しないでください。ビルド プロセスをいじらない限り、ほとんどが壊れてしまいます。恐ろしい詳細については、以下の更新にスキップしてください...


デフォルトのシステム ロケーションに、古いまたは OpenLDAP 以外の LDAP ライブラリがある可能性があります。 configureスクリプトがこの状態をテストできるほどスマートではない、またはビルド プロセスがこれを処理できるほど堅牢ではないと思います。たとえば、libldap.soシステム ライブラリのロケーションに古いライブラリが見つかった場合、実行時に正しい新しくインストールされたライブラリよりも優先して使用されますlibldap.so。実行する lddと、back_ldap-2.4.soこれが表示されます。

関連するディレクトリを環境変数に追加して、LD_LIBRARY_PATH最新の OpenLDAP ライブラリがあるディレクトリが最初に検索されるようにすることで、これを (再構築せずに) 修正できる可能性があります (export変数を確認してください)。

または、ビルド時に環境変数を次のように設定してconfigure実行することで、これを修正します。LDFLAGSRPATHこれにより、ビルドするバイナリにライブラリ検索パスがハードコードされます。

オプションやインストール パスなどが指定されていませんconfigure。私は過去にこれに似たバリエーションを使用しました:

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

非システム OpenSSL を使用する場合、非システム バージョンの BerkeleyDB を使用する場合も同様です。Solaris では、"-rpath" の代わりに "-R" を使用する必要がある場合があります ( gccGNU リンカーではなく Sun リンカーを使用している場合)。

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

あなたの場合、おそらく rpath (-Wl,-rpathまたは-R)を設定するだけで済みます-L(ただし、OpenSSL と BerkeleyDB の場合は両方を使用することをお勧めします)。


アップデート構築するもの:

/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

注記 " --enable-ldap=yes"、これはLDAPバックエンドを静的に構築しますslapdback_ldap.soでは、動的にロード可能な(つまり)は作成されません--enable-ldap=mod。 1 つの可能性として、back_ldap.so サーバーにロードしようとしている と、不要な があることが挙げられますmoduleload back_ldap。 ただし、 では、slapd同じ名前の静的モジュールが存在する場合、動的モジュールをロードできないため、バイナリslapdは説明したとおりにはなりません。

slapd -VVV静的バックエンドを確認するために実行します。

静的であると仮定するとback_ldap、この問題を回避でき、誤った内容moduleloadや古い内容を.so適切に削除できるはずです。

私は強いlibtool、依存関係エラー、またはリンカーの問題が潜んでいる疑いがあります。動的back_ldapでこれを再現できます。ldap_add_extは確かに未解決のシンボルですが、必ずしも問題ではありません(モジュールの明示的なためdlopen())が、そのシンボルはによってエクスポートされていませんslapdは によってエクスポートされますlibldap.soが、 の依存関係ではなくback_ldap.so、 がロードされる原因となるものは他にありませんlibldap。(これは、ライブラリ パスの問題ほど単純ではないため、上記のアドバイスでは問題を解決できないことも意味します。)

何が起こっているか (つまり、表示されているエラー) は、シンボルがldap_add_ext要求されるまで解決されない (「遅延」バインディング) ことです。LDAP オブジェクトを追加しようとすると、当然ながら最終的に要求されます。その後、車輪が外れます。(必要に応じて、エクスポートしてLD_BIND_NOW=1遅延バインディングをオフにしてから開始することで、起動時にこれを解除できますslapdが、別のシンボルがそれをトリップする可能性があります。)

現時点では、最も単純なオプションは、静的back_ldap( )を使用して、正しく構築されていることを確認する--enable-ldap=yesことです。それほど単純ではないオプションは、依存関係の問題を回避するために を使用し、奇妙な副作用がないことを祈ることです。make clean && make depend && make installslapdLD_PRELOAD=/usr/lib/libldap.soLD_PRELOAD=/usr/lib/libldap_r.so


さて、この古い電子メールが問題をカバーしています:http://www.openldap.org/lists/openldap-software/200211/msg00469.html slapdデフォルトでは静的にリンクされていますlibldap_r.aこれにより、リンク時に認識されるシンボルが制限されます。動的モジュールは実行時にロードされるため、dlopen()リンカーではその要件 (シンボル/ライブラリ) が認識されません。

(一部の)バックエンドの動的構築は、しばらくの間、かなり壊れていたと合理的に結論付けることができるかもしれません。

したがって、動的バックエンドを使用しない (推奨) か、次のような方法でビルドを偽造します (あまり推奨されません)。

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

これは、 の代わりに先ほど構築したslapdにリンクするため、必要なときにすべてのシンボルを読み込むことができます (ディスク上のサイズも約 15% 小さくなります)。私はこれを使用して LDAP サーバーを運用したことがありません。結果は人によって異なります。ディストリビューションによって、同様のソリューションまたは代替ソリューションが使用されているはずです...libldap_r.so.aslapd

答え2

これは設定の問題ではありません。エラーは明らかで、openldap が /usr/libexec/openldap/back_ldap-2.4.so.2 ライブラリで存在しない関数を探していることを示しています。

Redhat 5 では、なぜ rpm 形式の標準 LDAP を使用しないのですか?

関連情報