SSSDを触り始めた理由である、nslcd+nscd と結局どっちがエェねんという疑問をまとめていきます。
SSSD といっぱいタイピングしていると ssh が sssh になってしまう病気にかかるので要注意です。
関連記事
システムの用途
nslcd（Name Service LDAP Connection Daemon） はその名の通りLDAPとの接続を担うだけなので、キャッシュ担当の nscd (Name Service Cache Daemon) がいないと毎回LDAPに接続することになり、不健康となるためセットで使うのが基本です。SSSDは認証管理＋キャッシュの役割を併せ持つので、デーモンとしては１つになります。LDAP以外の様々な認証機能を使えるのも強みですね。
LDAP周りだけでいえば、基本的には機能にそれほどの違いはないため、無理に入れ替えるほどではなく、新環境を構築する際に検討する程度になると思われます。
SSSDの方が若干設定ファイル数は少なくなりますが、そんなものは自動化で微々たるものですので、それよりもSSSDが多機能な分、設定内容がわかりづらい構成ですので最初はおツラいかもしれません。
キャッシュの性質
有効期限
nscd は positive-time-to-live(秒) の間はキャッシュを保持し、過ぎたら再取得をします。存在しないデータは、negative-time-to-live(秒) の間は失敗としてキャッシュし、過ぎたら再取得をします。SSSD は少し変わっていて、[各ドメイン]と[nss]の設定を使って……今回の例でいうと
[domain/default] の entry_cache_timeout(秒) × [nss] の entry_cache_nowait_percentage(%)
がキャッシュの有効期限となります。entry_cache_timeout = 1200 と entry_cache_nowait_percentage = 50 なら、600秒が期限です。存在しないデータは、entry_negative_timeout(秒) を過ぎたら再取得となります。
最初はわかりづらいですが、設定項目ごとに設定できるセクションが決まっているので、man sssd.conf を見るときは、どこのセクションの設定かをしっかり確認しましょう。
認証サーバーダウン時の挙動
LDAPなどのリモートの認証プロバイダに接続できなくなった時、nscd はキャッシュ済みで positive-time-to-live(秒) 期限内のデータは正しく結果を返すことができますが、新規取得時や期限がきれたデータは再取得をしようとするので、復旧するまでずっとエラーになります。
SSSD は新規取得時はエラーになるものの、キャッシュデータは期限内であろうと過ぎていようと、半永久的にキャッシュデータを返してくれます。これは、offline周りの設定で調整できますが、デフォでNoLimitになっているためです。そのため耐障害性がnscdよりも強く、これだけでも十分に採用する価値はあります。
デーモンダウン
nslcd がダウンするのは nscd から見れば認証サーバーがダウンするのと同じなので、新規or期限切れのデータの取得はエラーになります。nscd がダウンしても、nslcd が毎回リモートに接続するだけで障害にはなりません……が、認証サーバーがキャパシティオーバーする可能性はあります。SSSDがダウンしたら、完全に認証機能が沈黙します。
ほぼほぼ落ちないシステムとはいえ、どちらにするにせよ大切な部位なので、monitなどで確実に起動状態を保つ仕組みがよさげです。
また、そもそもリモート認証は一般ユーザーの利用に留め、サービスを動かすためのミドルウェアなどには関連を一切持たせない設計がベターです。
（※一般ユーザーの sudo で restart したらミドルウェアの HOME や PWD などの環境変数に /home/example_user が入ることでミドルウェアの運用に支障が出る場合があるため）
この２つさえ抑えておけば、どちらを選ぶにしても、そうそう不都合は起きないでしょう。
ということで、あえて選ぶならば、sssd.conf の理解が面倒という点を除けば、SSSDが優位と言ってよさそうです。耐障害性がキモではありますが、設定に慣れれば nsswitch.conf 以外は sssd.conf と sshd_config の２ファイルで完結するため、非常に扱いやすいです。
認証周りはディストリビューションのメジャーバージョンが上がるごとに微妙な変化によってイラついてきたので、当分の間SSSDで落ち着けるのであればSSSDにしてしまって良さそうな感触です。
