AD サーバーを照会し、認証に使用するために nslcd を実行しているサーバーがあり、これは期待どおりに動作しています。ここで、AD サーバーの負荷を軽減するために nscd を導入しました。結果は少し奇妙です。nscd プロセスを通常どおり (nscd ユーザーまたは root ユーザーとして) 実行している場合、デーモンは結果を返しません。
[root@ldap-auth-test ~]# id testuser1
id: testuser: No such user
さて、なぜ動作しないのかを確認するために、プロセスをトレースしてみました。
strace -p 8327 -f -s 1000
同時に、testuser1に再度IDを付与しました。今回は、
[root@ldap-auth-test ~]# id testuser1
uid=10004(testuser1) gid=10046(A-TESTGROUP1) groups=10046(A-TESTGROUP1) context=root:system_r:unconfined_t:SystemLow-SystemHigh
これが偶然かどうか確かめるために何度も試してみましたが、そうではないことがわかりました。スレッドにアタッチしないようにしましたが、スレッドにアタッチしていないときは nscd が動作していないことがわかりました。どなたか助けていただければ幸いです。
[root@ldap-auth-test ~]# lsb_release -a
LSB Version: :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: CentOS
Description: CentOS release 5.5 (Final)
Release: 5.5
Codename: Final
追記：私も同じ質問をしましたスタックオーバーフローどこに質問したらよいか分からないので、無関係なものも削除します。誰かがどれが関係あるか指摘してくれたら、無関係なものを削除します。
編集:: nslcd をデバッグ モードで実行すると、nscd を strace しない限り、デーモンはクエリに nslcd を使用しないことがわかりました。つまり、strace を使用しない限り、クエリはまったく実行されません。
答え1
SELinux はおそらく nslcd_selinux(8) であり、strace で実行されているときの動作の違いを説明するのに役立ちます (setuid を期待しているプロセスも同様です)