Zimbraの「LDAPサーバーが応答しません」起動エラーを修正する：実践的な復旧ガイド

Zimbraが起動時に「」などのエラーで失敗した場合LDAP server not responding、重要なのは単にそのメッセージを消す方法ではありません。真の目標は、正常なLDAP依存関係を復元し、Zimbraが再び設定を読み取れることを確認し、根本原因が不明なまま無関係なサービスを変更しないようにすることです。

このガイドでは、その結果に焦点を当てています。サービスステータス、LDAPチェック、ローカル構成、証明書検証、マルチサーバーLDAP URLについては、Zimbraが文書化したコマンドを使用します。例では、プレースホルダーホスト名を使用しています。ldap1.example.comご自身の環境に合わせて値を変更してください。

成功した回復とはどのようなものか

変更を加える前に、最終目標を明確にしましょう。修理が説得力のあるものとなるのは、以下のすべての条件が満たされている場合です。

• ldap statusslapdLDAPノード上で実行中のプロセスを報告します。
• zmcontrol status影響を受けるホスト上で、LDAPおよびそれに依存するZimbraサービスが実行されていると報告されています。
• LDAPホスト名は、影響を受けるZimbraノードから期待されるアドレスに解決されます。
• 設定されたLDAPポートにアクセス可能です。
• TLSが関与している場合、証明書チェーンが検証され、以前のTLSエラーは解消されます。
• マルチサーバー構成の場合、ldap_url有効ldap_master_urlでアクティブなLDAPホストが意図した順序で含まれている必要があります。
• 再起動後、/var/log/zimbra.logLDAP接続の失敗が繰り返し発生しなくなった。

これらのチェックのいずれかがそれでも失敗する場合は、Zimbraスタック全体を繰り返し再起動するのではなく、そのレイヤーのトラブルシューティングを続けてください。

クイックリファレンス：症状と次の検査

1. LDAP自体がダウンしているかどうかを確認する

ユーザーとしてステータスチェックを実行しますzimbra。

su - zimbra
zmcontrol status
ldap status

Zimbra の LDAP トラブルシューティング ドキュメントでは、slapdプロセスが実際に実行されているかどうかを確認し、Zimbra がそれを認識していることを確認することを推奨していますldap status。LDAP がローカルで実行されていない場合は、メールボックス、MTA、プロキシ、または Web サービスのトラブルシューティングを行う前に、LDAP プロセスを調査してください。LDAP はコア構成の依存関係であるため、構成データを読み取ることができないという理由だけで、下流のサービスが失敗する可能性があります。

参考資料：Zimbra LDAP トラブルシューティングドキュメントおよびZimbra zmcontrol コマンドリファレンス。

2. サービスを変更する前に、LDAP URLを確認してください。

影響を受けたノードで、ローカルのLDAPエンドポイントを調べます。

zmlocalconfig ldap_url
zmlocalconfig ldap_master_url

Zimbra 10 のマルチサーバーに関するドキュメントでは、ldap_urlはノードがクエリを実行する必要のある LDAP サーバーを識別し、 はldap_master_url書き込みに使用されるマスターエンドポイントまたはマスターセットを識別します。Zimbra では、レプリカ URL は通常 のマスターの前に配置されldap_url、マスターはリストに保持されることも説明されています。

このチェックは、サーバー移行、LDAPサーバー置換、IPアドレスの再割り当て、災害復旧、またはローリングアップグレードの後に​​特に重要です。完全に正常なLDAPサーバーであっても、廃止されたホスト名への接続を試みているZimbraノードを支援することはできません。

名前解決とTCP接続性を確認する

getent hosts ldap1.example.com
nc -zv ldap1.example.com 389

DNSが誤ったアドレスを返す場合は、まず名前解決を修正してください。DNSが正しいにもかかわらずポートにアクセスできない場合は、ネットワークルーティング、ホストファイアウォール、セキュリティグループ、またはLDAPデーモンのリスナーを調査してください。TCP接続がタイムアウトしたという理由だけでLDAPパスワードを変更しないでください。タイムアウトは、バインド資格情報が評価される前に発生します。

Zimbraの最新版v10マルチサーバーガイドでは、非LDAPノードは設定時にLDAPマスターに接続する必要があると明記されており、サーバーに接続できない場合はインストールを続行できないと記載されています。詳しくは、Zimbra Daffodil v10マルチサーバーインストールガイドをご覧ください。

3. 修理する内容を決める前にログを読んでください

Zimbraの中央ログを使用して、障害の種類を特定します。

tail -n 100 /var/log/zimbra.log

単一のエラー行ではなく、パターンを探してください。一般的なカテゴリとしては、接続タイムアウト、接続拒否、ホスト名エラー、バインド失敗、TLS検証エラーなどがあります。カテゴリはそれぞれ異なる修復方法が必要となるため、重要です。

• タイムアウトまたはルートなし： DNS、ルーティング、ファイアウォール、またはホストのダウンのいずれかに焦点を当ててください。
• 接続が拒否されました：ホストには到達可能ですが、設定されたポートで接続を受け付けるシステムがないか、ローカルファイアウォールが接続を積極的に拒否しています。
• TLS/SSL検証エラー：証明書と信頼チェーンを確認してください。
• 認証エラーまたはバインドエラーが発生した場合のみ、LDAPパスワードまたはレプリケーション認証情報を調査してください。

証明書が問題となる場合

Zimbraは、ルートCAまたは中間CAの有効期限切れが原因でLDAP通信が失敗する事例を記録しています。商用証明書の検証に役立つコマンドは次のとおりです。

/opt/zimbra/bin/zmcertmgr verifycrt comm   commercial.key commercial.crt commercial_ca.crt

関連する商用証明書ファイルを含むディレクトリ（通常は ）から実行してください/opt/zimbra/ssl/zimbra/commercial/。検証が失敗した場合は、手っ取り早く TLS 検証を無効にするのではなく、証明書チェーンを修正してください。

参照: Zimbra の期限切れルート CA および LDAP TLS 障害に関するガイダンス。

4. 置換後のLDAPエンドポイントの検証後にのみ、古いLDAPエンドポイントを修正する

設定されているホスト名が古く、かつ正しいアクティブな LDAP サーバーを既に確認済みの場合、zimbraユーザーとしてローカル設定を更新してください。例:

zmlocalconfig -e ldap_url="ldap://ldap1.example.com:389"
zmlocalconfig -e ldap_master_url="ldap://ldap1.example.com:389"

レプリカを含むデプロイメントの場合、リストを1台のサーバーに絞り込むのではなく、環境向けに文書化されたトポロジを使用してください。Zimbra v10のドキュメントには、読み取り時にレプリカが最初にリストされ、マスターも含まれる例が示されています。マルチマスター環境には、独自の順序付け要件があります。

これらのサンプルURLをそのままコピーしないでください。まず、プロトコル、ホスト名、ポート、および意図するマスター/レプリカの役割を確認してください。デプロイメントでLDAPSまたはStartTLSを使用している場合は、起動を成功させるためにプレーンなLDAPに暗黙的に切り替えることなく、セキュリティ設計を維持してください。

5. 一度再起動してから、依存関係チェーン全体を検証します。

根本的な原因を修正した後、Zimbraを再起動してください。

zmcontrol restart

次に、以下を確認します。

ldap status
zmcontrol status

エラーメッセージが変わるだけの再起動では不十分です。/var/log/zimbra.log接続障害が繰り返し発生していないか再確認し、サーバーの役割に応じた通常の管理操作またはユーザー操作をテストしてください。

6. マルチサーバー環境では、追加のレプリケーションチェックが必要です。

LDAPレプリカまたは複数のマスターを実行している場合、レプリケーションが正常に機能していなくても、サーバーにアクセスできる場合があります。Zimbraは、zmreplchkレプリケーション検証用のユーティリティについてドキュメントで説明しています。

/opt/zimbra/libexec/zmreplchk

マルチマスターシステムの場合、Zimbraのドキュメントでは、正常な状態をエラーコード0の同期状態と説明しています。正確な復旧手順は、シングルマスターレプリケーション、マルチマスターレプリケーション、または進行中の移行のいずれであるかによって異なります。

Zimbra LDAPマルチマスターレプリケーションに関するガイダンスと、最新のZimbra 10マルチサーバーに関するドキュメントを参照してください。

トラブルシューティングの方向転換のタイミング

以下のいずれかに該当する場合は、これを単なる接続の問題として扱うのをやめてください。

• slapdホスト名とポートの設定が正しいにもかかわらず、起動しません。
• ログには、ネットワークエラーではなく、データベースバックエンドまたはLDAPデータストアのエラーが報告されています。
• 接続が復旧した後も、レプリケーションの同期が取れていない状態が続く。
• 移行後、LDAPマスターとレプリカ間でパスワードが異なる場合がある。
• 設定されたホスト名がサーバーに属していないため、LDAPリスナーはバインドできません。

その時点では、問題は単なる「サーバーが応答しない」状態ではなく、LDAPデータベースの復旧、レプリケーション認証情報、移行状態、またはサーバーの識別情報に関係している可能性があります。Zimbraの移行に関するドキュメントには、DNS、ホスト名の不一致、ローカル設定のパスワードの誤り、古いLDAPサーバーへの古い参照などが、LDAPの起動を妨げる可能性があることが具体的に記載されています。

やってはいけないこと

• 初期トラブルシューティングの手順として、LDAPデータベースファイルを削除しないでください。
• 認証に問題があるレイヤーであることを証明するまでは、LDAPパスワードをリセットしないでください。
• レプリカが1つ応答しているからといって、すべてのLDAP URLからマスターを削除してはいけません。
• 接続を成功させるためだけにTLS検証を無効にしないでください。
• zmcontrol restart生成されたログを読まずに繰り返し実行しないでください。

最終復旧チェックリスト

• LDAPホスト名は、目的のホストに解決されます。
• 影響を受けるZimbraノードからLDAPポートにアクセスできます。
• ldap_urlそして、ldap_master_url現在のトポロジーに一致させる。
• 暗号化されたLDAPを使用する場合、TLS証明書チェーンは有効です。
• ldap statusレポートslapdが実行中です。
• zmcontrol status必要なサービスが実行されていることを示します。
• レプリケーションは、該当する場合、同期されています。
• /var/log/zimbra.logLDAPの障害が繰り返し発生しなくなりました。

この手順の主な制約は、「LDAPサーバーが応答しない」という現象が単一の根本原因ではなく、依存関係の症状であるということです。これは、LDAPプロセスの停止、古いURL、DNSの不具合、ポートのブロック、証明書の失敗、レプリケーションの問題、または認証情報の誤りなど、さまざまな原因で発生する可能性があります。したがって、最も安全な方法は、各レイヤーを順番に検証し、問題が発生したレイヤーのみを変更することです。