LDAP障害をPAM / NSSに使用するときに対処しますか？
NSSを介したPAM認証およびディレクトリサービスにOpenLDAPサーバーの冗長ペアを使用しています。これまでのところ100％信頼性がありますが、永遠に完璧に動作するものはありません。
LDAPサーバーの障害から回復するための戦いのチャンスを得るために、今どのような手順を実行する必要がありますか？私の非公式のテストでは、ディレクトリサーバーが戻るまですべてのユーザー名/ uidルックアップがハングするため、すでに認証されたシェルでさえほとんど役に立たないようです。
これまでのところ、私は2つのことだけを思いついた。
- LDAPサーバー自体でNSS-LDAPおよびPAM-LDAPを使用しないでください。
- ローカルサブネットからの公開鍵認証のみを受け入れるすべてのボックスにルートレベルのアカウントを作成し、その鍵を適切に保護します。ログインすると、これがどれだけうまくいくかはわかりません。すべてのユーザーIDルックアップがハングするため、何も実行できないと思われます。
他に何か提案はありますか？
ネットワークベースの認証のルール＃1：常にローカルアカウントを使用できるようにします。
ルール＃1を超えて（そして、死んだサーバーと通信しようとするnss_ldapの背後でブロックされることなくそれを有用にするために）：
Pam_ldap/nss_ldapを使用すると、bind_policyを「ソフト」（サーバー障害が発生するとすぐに戻る）に設定できます。これにより、ブロッキングの問題が解消されます。 timelimit値を設定して、LDAPサーバーに接続できない場合にnss_ldapが返されるようにすることもできます。これには他の影響があることに注意してください（SSHでのソフトフェイルによりLDAPアカウントにアクセスできなくなり、散発的な障害により一部のLDAPUIDのユーザー名が不明になるなど。
文書化されていないnss_ldapオプションもいくつかあります：nss_reconnect_tries、nss_reconnect_sleeptime、nss_reconnect_maxsleeptime、およびnss_reconnect_maxconntries。これらは、名前が示すとおりに機能し、障害の回避に役立ちます。 LDAPサーバーなし bind_policyをソフトに設定します（これが私が行っていることです-3回の再接続試行で最大10秒のスリープ= LDAPサーバーを待機する最大30秒の遅延）。