nss_ldapとnscdの罠

ということでインタラプトされながらstraceとかして調べてわかった(つもりの)こと:

  • LDAPによるUNIXアカウント管理/認証は、nscdがいないと遅い
  • あと、システム全体やLDAPサーバの起動・再起動等で、LDAPサーバが動作していないと、rootとかldap自身とかのグループ検索がタイムアウトするので悲惨。
  • なので、/etc/ldap.confにnss_initgroups_ignoreusers root,ldap,...のようにシステムアカウントを列挙しないといけない
  • ところが、そこに「nscd」を「列挙」してしまうと、なぜか/var/run/nscd/socketが作成されなくなる。そのためにnscd -g(ステータス取得)とかnscd -K(デーモン停止)とかが動作せず、/etc/init.d/nscd stopやrestartも失敗する。
  • ということで、/etc/passwdからnscd以外を抽出して/etc/ldap.confのnss_initgroups_ignoreusersに書けばよい?(←今ココ)

追記:夜が明けたら(というか年が明けたら)、シェルやsuを含め、ほとんどのコマンドが"broken pipe"とか言ってシステム全体が操作不能状態になっていた。念力でnscdをkillして修復したが、わけがわからない。あけましておめでとうございます。

追記2:これだろうか。
http://www.linux.or.jp/JF/JFdocs/LDAP-Implementation-HOWTO/pamnss.html

さらに言えば、NSS と NSCD の使用は大量のファイルデスクリプタを開いてしまいます。そのため、システム上の使えるファイルデスクリプタが簡単に不足してしまいます (これはシステムをハングさせかねません)。

しかし

# cat /proc/sys/fs/file-max 
206054

なのだが…。あるいはnscdのulimitのopen files (1024)のほうか?

追記3:ひょっとしてこれか!
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401758
nss_ldapのバージョンもこのバグレポートより古いし、似たようなバグレポートにあるテストも見事に再現する。RHEL4のBugzillaにも「nss_ldapが古くてバグバグだけど、backportできなくて直ってない」とある。もうnscdはとめるか…