【389 Directory Server番外編】トラブルシューティングの極意。ログ解析、レプリケーション不整合、DB破損からの生還

「ログを見ても原因がわからない」それが一番のトラブルです。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
全8回の「389 Directory Server講座」、お役に立っていますでしょうか？
構築手順通りにやれば動くのは当たり前。インフラエンジニアの真価が問われるのは、「動かなくなった時」です。

「朝起きたらLDAPサーバーが停止していた」「レプリケーションが片方向だけ止まっている」「特定のユーザーだけ検索できない」……。
LDAPのトラブルは、往々にして原因が深く、エラーメッセージも不親切なことが多いものです。
特に389 DSは高機能な分、裏側で動いている仕組み（CSN、RUV、プラグイン、Berkeley DB）を理解していないと、復旧操作のつもりが「トドメを刺す」結果になりかねません。

本記事は、本編講座の番外編として、ログレベルの調整による深層解析、起動しないサービスの原因特定、レプリケーション不整合の強制解除、そしてデータベース破損時のデータ救出方法まで、現場で生き残るためのノウハウを徹底解説します。

---

第1章：ログ解析の達人技。エラーログとアクセスログの相関関係

トラブルシューティングの第一歩はログを見ることです。
しかし、/var/log/dirsrv/slapd-{instance}/errors を漫然と眺めているだけでは不十分です。
プロは「アクセスログで事象を特定し、エラーログで原因を探る」という手順を踏みます。

ログレベルの動的変更

デフォルトのログレベルでは、重要な情報が出力されていないことがあります。
389 DSは、サービスを再起動することなくログレベルを変更できます。
これは本番運用中に調査を行う上で必須の機能です。

# 現在のログレベル確認
dsconf localhost config get nsslapd-errorlog-level

# 詳細なトレースログを出力（レプリケーションデバッグ用）
# ※ディスク容量を圧迫するため、調査後は必ず戻すこと！
dsconf localhost config replace nsslapd-errorlog-level=8192

主なログレベル値（ビットマスク）:

• 0: デフォルト（エラーのみ）
• 256: 接続/切断の詳細（誰がいつ繋いできたか）
• 8192: レプリケーションの詳細（同期エラー調査に必須）
• 262144: ACI（アクセス制御）処理の詳細（権限不足の原因調査）

アクセスログ解析のワンライナー

アクセスログは膨大ですが、grep と awk を組み合わせれば、一瞬で異常を検知できます。

# エラー（result=0以外）を返した検索クエリを抽出
grep "RESULT" access | grep -v "err=0" | awk '{print $1, $2, $14, $15}'

err=32 (No Such Object) や err=49 (Invalid Credentials) が多発している場合、特定のクライアントアプリの設定ミスや、攻撃の可能性があります。

---

第2章：サービスが起動しない！ 起動プロセスの完全解剖

systemctl start dirsrv@localhost が失敗し、Journalctl にも有益な情報がない。
これは最も心臓に悪い瞬間です。

原因1: dse.ldif の構文エラー

389 DSの設定ファイル /etc/dirsrv/slapd-localhost/dse.ldif は手動編集可能ですが、非常に厳格です。
行末の余分なスペース、LDIFの規約違反（Base64が必要なのに平文で書いた等）、空行の挿入位置ミスだけで起動しなくなります。

対処法:
/etc/dirsrv/slapd-localhost/ ディレクトリには、自動バックアップファイルが存在します。

• dse.ldif.bak: 直前の変更前のバックアップ
• dse.ldif.startOK: 最後に正常起動したときの設定

迷わず dse.ldif.startOK を dse.ldif にコピーして上書きしてください。
これで起動しなければ、原因は設定ファイル以外にあります。

原因2: 証明書・権限周りの不備

NSSDB（/etc/dirsrv/slapd-localhost/*.db）の権限が root になっていたり、パスワードファイル pin.txt が読めなかったりするケースです。

チェック項目:

ls -l /etc/dirsrv/slapd-localhost/

すべてのファイルオーナーが dirsrv:dirsrv であることを確認してください。
特に、手動で証明書をインポートした後に root 権限のまま放置されていることが多いです。

原因3: PIDファイルやロックファイルの残留

停電などでサーバーが強制終了した場合、プロセスはいないのにロックファイルが残ることがあります。
/var/run/dirsrv/ 配下のPIDファイルを確認し、プロセスが存在しないのにファイルがある場合は削除してみてください。

---

第3章：レプリケーションの悪夢。スプリットブレインとRUVの亡霊

マルチマスター構成で、サーバーを1台廃止（撤去）した後に、エラーログに以下のような警告が出続けることがあります。

Warning: repl-agmt …: The consumer has a different replica ID …
Error: NSMMReplicationPlugin – changelog program – … Failed to extract stats

これは、削除したはずのサーバーの情報（RUV: Replica Update Vector）が、他のサーバーに残存している「RUVのゾンビ化」現象です。

CLEANALLRUV タスクの実行

このゾンビを成仏させるには、CLEANALLRUV という特別なタスクを実行する必要があります。
単にレプリケーションアグリーメント（設定）を削除するだけでは、RUV（履歴データ）は消えません。

手順:

1. 削除したい（廃止した）サーバーの Replica ID を特定します。
（構築時に決めた 1〜65535 の数字です。忘れた場合は dsconf localhost replication list や、dse.ldif のバックアップから推測します）

2. 生きている全マスターサーバーで以下のコマンドを実行します。

# 例: Replica ID "3" の情報を抹消する
dsconf localhost replication cleanallruv --replica-id 3 --confirm

3. タスクの進行状況を確認します。

dsconf localhost replication tasks list

ステータスが「Successfully cleaned RUV」になれば完了です。

---

第4章：認証・検索トラブル。ユーザーが見つからない、ログインできない

「ユーザーは存在するのにログインできない」。
SSSDやPAMの設定を疑う前に、LDAPサーバー側で起きていることを確認しましょう。

アカウントロック (nsAccountLock)

パスワードの入力を何度も間違えると、アカウントがロックされます。
この時、userPassword 属性が変わるわけではなく、nsAccountLock: true という属性が追加されます。

# ロック状態の確認
dsidm localhost user get uid=taro | grep nsAccountLock

# ロック解除
dsidm localhost account unlock uid=taro

スキーマ違反 (Object Class Violation)

ユーザー情報を更新しようとしたら Object Class Violation (err=65) が出る。
これは、必須属性（MUST）が欠けているか、許可されていない属性（MAYにない）を追加しようとした場合に発生します。
特にOpenLDAPから移行した直後に、nis スキーマと rfc2307bis スキーマの違いで発生しがちです。

Get Effective Rights (実効権限)

ACIの設定ミスで「見えない」のか、本当にデータがないのか。
dsctl や GUI (Cockpit) にある “Get Effective Rights” 機能を使えば、「誰が」「どのエントリに対して」「どんな権限を持っているか」をシミュレーションできます。

---

第5章：データベース破損からの生還。論理破損と物理破損

ファイルシステムの障害や、無理な強制終了により、Berkeley DBファイルが破損することがあります。
サービスが起動しなくなった場合の「最後の切り札」を紹介します。

オフライン・エクスポート (db2ldif)

389 DSが起動していなくても、DBファイルが生きていれば、コマンドラインツールでデータをLDIF形式で引き抜くことができます。
これはDBの再構築（ダンプ＆リストア）としても有効です。

# サービス停止を確認
systemctl stop dirsrv@localhost

# データの救出 (-n: バックエンド名, -a: 出力ファイル)
db2ldif -Z localhost -n userRoot -a /root/rescue_data.ldif

もし db2ldif すらエラーで動かない場合は、Berkeley DBのツール（db_recover など）を使う手もありますが、非常にリスクが高いです。
その場合は、直近のバックアップLDIFを使うか、レプリケーション相方からの全同期（Total Init）を行う方が安全です。

データベースの再作成とインポート (ldif2db)

救出したLDIFを使って、データベースをクリーンな状態で作り直します。

# 既存の破損DBディレクトリを退避
mv /var/lib/dirsrv/slapd-localhost/db/userRoot /var/lib/dirsrv/slapd-localhost/db/userRoot.corrupt
mkdir /var/lib/dirsrv/slapd-localhost/db/userRoot
chown dirsrv:dirsrv /var/lib/dirsrv/slapd-localhost/db/userRoot

# データのインポート（同時にインデックスも再生成される）
ldif2db -Z localhost -n userRoot -i /root/rescue_data.ldif

これで、論理破損やインデックスのズレが解消され、正常に起動できるようになります。

---

第6章：パフォーマンス劣化の真犯人。「Unindexed Search」と「Resource Limit」

「急にLDAPが重くなった」。
CPU使用率が100%に張り付いている場合、ほぼ間違いなく「インデックスが効いていない検索（Unindexed Search）」が大量に投げられています。

犯人の特定方法 (notes=U)

アクセスログを解析し、notes=U が付いているクエリを探します。

grep "notes=U" /var/log/dirsrv/slapd-localhost/access | tail -n 20

見つかったクエリの検索条件（Filter）を見て、足りないインデックスを追加（eq や sub）し、reindex を実行します。

All IDs Threshold (検索制限)

インデックスがあっても、ヒット件数が多すぎる（デフォルト4000件以上）場合、389 DSは「インデックスを使うのを諦めて全件検索する」という挙動を取ることがあります。
これを制御するのが nsslapd-allidsthreshold パラメータです。
大規模環境ではこの値を増やす（例: 20000）チューニングが必要になる場合があります。

ファイルディスクリプタ (LimitNOFILE)

接続数が数千を超えると、OSのファイルオープン上限に達して接続拒否が発生します。
systemd のユニットファイル設定を確認してください。

systemctl show dirsrv@localhost | grep LimitNOFILE

デフォルトは8192や16384になっていることが多いですが、大規模環境では 65535 程度まで引き上げる必要があります。
/etc/systemd/system/dirsrv@.service.d/limits.conf を作成して上書きします。

---

第7章：クライアント側の泥沼。SSSDキャッシュの消し方

サーバー側は正常なのに、クライアントで「ユーザーが見つからない」「パスワードが古いまま」という現象が起きることがあります。
犯人は SSSD (System Security Services Daemon) の強力すぎるキャッシュです。

キャッシュの削除コマンド

「何かおかしい」と思ったら、まずはこれを試してください。

# 全キャッシュの破棄
sss_cache -E

# 特定ユーザーのみ更新
sss_cache -u taro

それでも直らない場合（LDBファイルの削除）

sss_cache コマンドでも整合性が取れない重症の場合、キャッシュデータベースファイル（.ldb）を物理削除します。

systemctl stop sssd
rm -f /var/lib/sss/db/*
rm -f /var/lib/sss/mc/*
systemctl start sssd

これは荒療治ですが、最も確実にクライアントの状態をリセットできます。

デバッグログの出力

認証エラーの理由（パスワード間違いなのか、証明書エラーなのか、アクセス制限なのか）を知るには、デバッグレベルを上げます。

# /etc/sssd/sssd.conf
[domain/default]
debug_level = 9  # 最大レベル

再起動後、/var/log/sssd/sssd_default.log や /var/log/sssd/sssd_ldap.log を確認します。
膨大なログが出ますが、ここにはLDAPとの通信内容が全て記録されています。

---

まとめ：トラブルシューティングは「仮説・検証」のループ

お疲れ様でした！
番外編では、389 Directory Serverのディープなトラブルシューティングの世界を解説しました。

今回の重要ポイント：

• ログレベルを動的に変更し、詳細情報を掴むのが解決への近道。
• 起動しないときは dse.ldif.startOK への巻き戻しを試す。
• レプリケーション不整合は CLEANALLRUV で対処する。
• DB破損時は db2ldif でデータを救出し、作り直すのが最短ルート。

これで「389 Directory Server講座」の全コンテンツが完結しました。
本講座が、あなたのインフラエンジニアとしてのキャリアを支える一助となれば幸いです。

May the Logs be with you. (ログと共に在れ)