
おはよう;
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
実行することで、これを修正します。LDFLAGS
RPATH
これにより、ビルドするバイナリにライブラリ検索パスがハードコードされます。
オプションやインストール パスなどが指定されていませんconfigure
。私は過去にこれに似たバリエーションを使用しました:
export LDFLAGS="-L/usr/local/ssl/lib -Wl,-rpath,/usr/local/ssl/lib"
非システム OpenSSL を使用する場合、非システム バージョンの BerkeleyDB を使用する場合も同様です。Solaris では、"-rpath" の代わりに "-R" を使用する必要がある場合があります ( gcc
GNU リンカーではなく 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バックエンドを静的に構築しますslapd
back_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 install
slapd
LD_PRELOAD=/usr/lib/libldap.so
LD_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
.a
slapd
答え2
これは設定の問題ではありません。エラーは明らかで、openldap が /usr/libexec/openldap/back_ldap-2.4.so.2 ライブラリで存在しない関数を探していることを示しています。
Redhat 5 では、なぜ rpm 形式の標準 LDAP を使用しないのですか?