第7章 ログファイルのリファレンス

Red Hat Directory Server (Directory Server) は、ディレクトリーのアクティビティーを監視するのに役立つログを提供します。監視は、障害を素早く検出および修正し、プロアクティブに実施された場合に、障害やパフォーマンスが低下する前に潜在的な問題を予測して解決するのに役立ちます。ディレクトリーを効果的に監視するには、ログファイルの設定と内容を理解する必要があります。

本章では、ログメッセージの完全なリストは提供しません。ただし、本章で紹介している情報は、一般的な問題の開始点として機能し、アクセス、エラー、監査ログの情報をよりよく理解するのに役立ちます。

ログは Directory Server インスタンスごとに保持され、/var/log/dirsrv/slapd-instance ディレクトリーに置かれます。

7.1. アクセスログリファレンス

Directory Server のアクセスログには、ディレクトリーへのクライアント接続に関する詳細情報が含まれます。接続は、同じクライアントからのリクエストシーケンスで、以下の設定になっています。

  • 接続レコード - 接続インデックスおよびクライアントの IP アドレスを提供します。
  • バインドレコード
  • バインド結果レコード
  • レコードの操作要求と操作結果ペアのシーケンス、または接続、クローズ、および破棄レコードの場合の個別レコード
  • バインド解除レコード
  • クローズレコード

次に、アクセスログエントリーの例を示します。 

[23/Jun/2020:16:30:27.388006333 -0400] conn=20 op=5 SRCH base="dc=example,dc=com" scope=2 filter="(&(objectClass=top)(objectClass=ldapsubentry)(objectClass=passwordpolicy))" attrs="distinguishedName"

個別に表示される接続、クローズ、および破棄レコードとは別に、すべてのレコードはペアで表示され、サービスの要求レコードとそれに続く RESULT レコードで設定されます。 

[23/Jun/2020:16:30:27.390881301 -0400] conn=20 op=5 RESULT err=0 tag=101 nentries=0 wtime=0.000035342 optime=0.002877749 etime=0.002911121

RESULT メッセージには、以下のパフォーマンス関連のエントリーが含まれます。

  • wtime: ワーカースレッドが操作をピックアップするまで、操作がワークキューで待機していた時間
  • optime: 実際の操作がタスクを実行するのにかかった時間
  • etime: サーバーが操作を受け取ってから結果をクライアントに返すまでの経過時間
注記

wtime および optime の値により、サーバーがどのように負荷をおよび操作を処理するかに関する有用な情報を提供されます。Directory Server がこれらの統計値を収集するタイミングにより、wtime 値と optime 値の合計は etime の値よりも若干大きくなります。ただし、その違いは無視できるレベルです。

アクセスログには、nsslapd-accesslog-level 属性で設定されるさまざまなロギングのレベルがあります。以下のセクションでは、デフォルトのアクセスログの内容、ログレベル、およびさまざまなログレベルでログに記録されるコンテンツの概要を説明します。

アクセスログの形式を変更することはできません。

7.1.1. アクセスロギングレベル

アクセスロギングのレベルにより、さまざまな量の情報が生成され、さまざまな操作が記録されます。ログレベルは、インスタンスの 「nsslapd-accesslog-level(アクセスログレベル)」設定属性で設定されます。デフォルトのロギングレベルはレベル 256 で、エントリーへのアクセスをログに記録しますが、4 つの異なるログレベルを利用できます。

  • 0 = アクセスログなし
  • 4 = 内部アクセス操作のロギング
  • 256 = エントリーへのアクセスのログ。
  • 512 = エントリーおよび参照情報にアクセスするためのロギング

このレベルは加算されるため、さまざまな種類のロギングを有効にするには、これらのレベルの値を一緒に加算します。たとえば、内部アクセス操作、エントリーアクセス、および参照をログに記録するには、nsslapd-accesslog-level の値を 516 (512+4) に設定します。

7.1.2. デフォルトのアクセスログのコンテンツ

このセクションでは、以下に記載のデフォルトのアクセスロギングレベルの抽出に基づいて、アクセスログの内容の詳細を説明します。

例7.1 アクセスログの例

[21/Apr/2020:11:39:51 -0700] conn=11 fd=608 slot=608 connection from 207.1.153.51 to 192.18.122.139
[21/Apr/2020:11:39:51 -0700] conn=11 op=0 BIND dn="cn=Directory Manager" method=128 version=3
[21/Apr/2020:11:39:51 -0700] conn=11 op=0 RESULT err=0 tag=97 nentries=0 etime=0
[21/Apr/2020:11:39:51 -0700] conn=11 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(mobile=+1 123 456-7890)"
[21/Apr/2020:11:39:51 -0700] conn=11 op=1 RESULT err=0 tag=101 nentries=1 etime=3 notes=U
[21/Apr/2020:11:39:51 -0700] conn=11 op=2 UNBIND
[21/Apr/2020:11:39:51 -0700] conn=11 op=2 fd=608 closed - U1
[21/Apr/2020:11:39:52 -0700] conn=12 fd=634 slot=634 connection from 207.1.153.51 to 192.18.122.139
[21/Apr/2020:11:39:52 -0700] conn=12 op=0 BIND dn="cn=Directory Manager" method=128 version=3
[21/Apr/2020:11:39:52 -0700] conn=12 op=0 RESULT err=0 tag=97 nentries=0 etime=0
[21/Apr/2020:11:39:52 -0700] conn=12 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(uid=bjensen)"
[21/Apr/2020:11:39:52 -0700] conn=12 op=2 ABANDON targetop=1 msgid=2 nentries=0 etime=0
[21/Apr/2020:11:39:52 -0700] conn=12 op=3 UNBIND
[21/Apr/2020:11:39:52 -0700] conn=12 op=3 fd=634 closed - U1
[21/Apr/2020:11:39:53 -0700] conn=13 fd=659 slot=659 connection from 207.1.153.51 to 192.18.122.139
[21/Apr/2020:11:39:53 -0700] conn=13 op=0 BIND dn="cn=Directory Manager" method=128 version=3
[21/Apr/2020:11:39:53 -0700] conn=13 op=0 RESULT err=0 tag=97 nentries=0 etime=0
[21/Apr/2020:11:39:53 -0700] conn=13 op=1 EXT oid="2.16.840.1.113730.3.5.3"
[21/Apr/2020:11:39:53 -0700] conn=13 op=1 RESULT err=0 tag=120 nentries=0 etime=0
[21/Apr/2020:11:39:53 -0700] conn=13 op=2 ADD dn="cn=Sat Apr 21 11:39:51 MET DST 2020,dc=example,dc=com"
[21/Apr/2020:11:39:53 -0700] conn=13 op=2 RESULT err=0 tag=105 nentries=0 etime=0 csn=3b4c8cfb000000030000
[21/Apr/2020:11:39:53 -0700] conn=13 op=3 EXT oid="2.16.840.1.113730.3.5.5"
[21/Apr/2020:11:39:53 -0700] conn=13 op=3 RESULT err=0 tag=120 nentries=0 etime=0
[21/Apr/2020:11:39:53 -0700] conn=13 op=4 UNBIND
[21/Apr/2020:11:39:53 -0700] conn=13 op=4 fd=659 closed - U1
[21/Apr/2020:11:39:55 -0700] conn=14 fd=700 slot=700 connection from 207.1.153.51 to 192.18.122.139
[21/Apr/2020:11:39:55 -0700] conn=14 op=0 BIND dn="" method=sasl version=3 mech=DIGEST-MD5
[21/Apr/2020:11:39:55 -0700] conn=14 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress
[21/Apr/2020:11:39:55 -0700] conn=14 op=1 BIND dn="uid=jdoe,dc=example,dc=com" method=sasl version=3 mech=DIGEST-MD5
[21/Apr/2020:11:39:55 -0700] conn=14 op=1 RESULT err=0 tag=97nentries=0 etime=0 dn="uid=jdoe,dc=example,dc=com"
[21/Apr/2020:11:39:55 -0700] conn=14 op=2 UNBIND
[21/Apr/2020:11:39:53 -0700] conn=14 op=2 fd=700 closed - U1

接続番号

すべての外部 LDAP 要求が、一連の接続番号 (ここでは conn=11 で、サーバー起動直後の conn=0 から始まります) と共にリスト表示されます。 

[21/Apr/2020:11:39:51 -0700] conn=11 fd=608 slot=608 connection from 207.1.153.51 to 192.18.122.139

内部 LDAP 要求は、デフォルトではアクセスログに記録されません。内部アクセス操作のロギングを有効にするには、「nsslapd-accesslog-level(アクセスログレベル)」設定属性でアクセスログレベル 4 を指定します。

ファイル記述子

外部 LDAP クライアントから Directory Server へのすべての接続には、オペレーティングシステムからのファイル記述子またはソケット記述子 (この場合は fd=608) が必要です。fd=608 は、使用された利用可能なファイル記述子の合計プールの中の、ファイル記述子番号 608 であったことを示しています。 

[21/Apr/2020:11:39:51 -0700] conn=11 fd=608 slot=608 connection from 207.1.153.51 to 192.18.122.139

スロット番号

スロット番号 (この場合は slot=608) はアクセスログのレガシー部分で、ファイル記述子と同じ意味を持ちます。アクセスログのこの部分は無視します。 

[21/Apr/2020:11:39:51 -0700] conn=11 fd=608 slot=608 connection from 207.1.153.51 to 192.18.122.139

操作番号

特定の LDAP 要求を処理するには、Directory Server は必要な一連の操作を実行します。特定の接続では、すべての操作要求と操作結果のペアに op=0 で始まる一連の操作番号が割り当てられ、実行される個別の操作を特定します。 

[21/Apr/2020:11:39:51 -0700] conn=11 op=0 RESULT err=0 tag=97 nentries=0 etime=0

「デフォルトのアクセスログのコンテンツ」 では、バインド操作の要求と結果のペアを op=0 とし、次に LDAP 検索の要求と結果のペアを op=1 のように行います。アクセスログのエントリー op=-1 は、通常この接続の LDAP 要求が外部 LDAP クライアントによって発行されず、代わりに内部で開始されたことを意味します。

メソッドのタイプ

メソッド番号 (この場合は method=128) は、クライアントによって使用された LDAPv3 バインドメソッドを示します。 

[21/Apr/2020:11:39:51 -0700] conn=11 op=0 BIND dn="cn=Directory Manager" method=128 version=3

可能なバインドメソッドの値は次の 3 つです。

  • 認証の場合は 0
  • ユーザーパスワードを使用した単純なバインドの場合は 128
  • 外部認証メカニズムを使用する SASL バインドの場合は sasl

バージョン番号

バージョン番号 (この場合は version=3) は、LDAP クライアントが LDAP サーバーとの通信に使用した LDAP バージョン番号 (LDAPv2 または LDAPv3 のいずれか) を示します。 

[21/Apr/2020:11:39:51 -0700] conn=11 op=0 BIND dn="cn=Directory Manager" method=128 version=3

エラー番号

エラー番号 (この場合は err=0) は、実行された LDAP 操作から返された LDAP 結果コードを提供します。LDAP エラー番号 0 は、操作が成功したことを意味します。LDAP 結果コードのより包括的なリストは、「LDAP の結果コード」 を参照してください。 

[21/Apr/2020:11:39:51 -0700] conn=11 op=0 RESULT err=0 tag=97 nentries=0 etime=0

タグ番号

タグ番号 (この場合は tag=97) は、返される結果のタイプを示します。これは、ほとんどの場合、実行された操作のタイプを反映します。使用されるタグは LDAP プロトコルからの BER タグです。 

[21/Apr/2020:11:39:51 -0700] conn=11 op=0 RESULT err=0 tag=97 nentries=0 etime=0

表7.1 一般的に使用されるタグ

タグ説明

tag=97

クライアントのバインド操作の結果。

tag=100

検索されている実際のエントリー。

tag=101

検索操作からの結果。

tag=103

変更操作からの結果。

tag=105

追加操作からの結果。

tag=107

削除操作からの結果。

tag=109

moddn 操作からの結果。

tag=111

比較操作からの結果。

tag=115

検索を実行したエントリーが、必要なエントリーへの参照を保持する場合の検索参照。検索参照は参照に関して表現されます。

tag=120

拡張操作からの結果。

tag=121

中間操作の結果

注記

tag=100 および tag=115 は、それ自体が結果タグではないため、アクセスログに記録される可能性はほとんどありません。

エントリー数

nentries は、LDAP クライアントの要求に一致することが検出されたエントリーの数を示します (この場合は nentries=0)。 

[21/Apr/2020:11:39:51 -0700] conn=11 op=0 RESULT err=0 tag=97 nentries=0 etime=0

経過時間

etime は、経過時間 (この場合は etime=3)、または Directory Server が LDAP 操作を実行するのにかかった時間 (秒単位) を示します。 

[21/Apr/2020:11:39:51 -0700] conn=11 op=1 RESULT err=0 tag=101 nentries=1 etime=3 notes=U

etime 値が 0 の場合は、操作の実行に実際には 0 ナノ秒かかったことを意味します。

LDAP 要求タイプ

LDAP 要求タイプは、LDAP クライアントによって発行されている LDAP 要求のタイプを示します。可能な値は次のとおりです。

  • 検索の SRCH
  • 変更の MOD
  • 削除の DEL
  • 追加の ADD
  • moddn の MODDN
  • 拡張操作の EXT
  • 破棄操作の ABANDON

LDAP 要求によってエントリーがソートされた場合、メッセージ SORT serialno がログに記録され、その後にソートされた候補エントリーの数が続きます。以下に例を示します。 

[04/May/2020:15:51:46 -0700] conn=114 op=68 SORT serialno (1)

丸かっこで囲まれた数字は、ソートされた候補エントリーの数を指定します。この場合は 1 です。

LDAP 応答タイプ

LDAP 応答タイプは、LDAP クライアントによって発行されている LDAP 応答を示します。以下の 3 つの値を使用できます。

  • RESULT
  • ENTRY
  • LDAP 参照または検索参照である REFERRAL

検索インジケーター

Directory Server は、ログエントリーの notes フィールドで検索に関する追加情報を提供します。以下に例を示します。 

[21/Apr/2016:11:39:51 -0700] conn=11 op=1 RESULT err=0 tag=101 nentries=1 etime=3 notes=U

次の検索インジケーターがあります。

ページ検索インジケーター: notes=P

リソースが制限された LDAP クライアントでは、LDAP サーバーが検索操作の結果を返す速度を制御できます。実行された検索で LDAP 制御拡張を使用して検索結果を単純にページングすると、DirectoryServer は notes=P ページ検索インジケーターをログに記録します。このインジケーターは情報を提供するもので、それ以上のアクションは必要ありません。

詳細は、RFC 2696 を参照してください。

インデックス化されていない検索インジケーター:notes=A および notes=U

属性がインデックス化されていない場合、Directory Server はそれらを直接データベースで検索する必要があります。この手順では、インデックスファイルを検索する場合よりも多くのリソースが消費されます。

以下のインデックス化されていない検索インジケーターをログに記録できます。

  • notes=A

    フィルターのすべての候補属性はインデックス化されておらず、完全なテーブルスキャンが必要でした。これは、nsslapd-lookthroughlimit パラメーターで設定した値を超える可能性があります。

  • notes=U

    この状態は以下の状況で設定されます。

    • 少なくとも 1 つの検索用語がインデックス化されていない。

    • 検索操作時に、nsslapd-idlistscanlimit パラメーターで設定された制限に達した。詳細は 「nsslapd-idlistscanlimit」 を参照してください。

      インデックス化されていない検索は、以下のシナリオで発生します。

  • 検索に使用されるインデックスファイル内で、nsslapd-idlistscanlimit パラメーターの値に達した。
  • インデックスファイルが存在しない。

  • インデックスファイルが検索で必要な方法で設定されなかった。

    今後の検索を最適化するには、インデックスに頻繁に検索されるインデックス化されていない属性を追加します。詳細は、Directory Server 管理ガイドの該当するセクションを参照してください。

    注記

    通常、インデックス化されていない検索には時間がかかるため、インデックス化されていない検索インジケーターには大きな etime 値が伴うことがよくあります。

単一の値の他に、notes フィールドには notes=P,A および notes=U,P の値の組み合わせを使用できます。

VLV 関連エントリー

検索に仮想リストビュー (VLV) が含まれる場合、適切なエントリーがアクセスログファイルに記録されます。他のエントリーと同様に、VLV 固有のエントリーは、要求と応答の情報を並べて表示します。 

VLV RequestInformation ResponseInformation

RequestInformation の形式は次のとおりです。 

beforeCount:afterCount:index:contentCount

クライアントが position-by-value の VLV 要求 (最初の部分の形式) を使用する場合、要求情報は beforeCount: afterCount: value になります。

ResponseInformation 形式は次のとおりです。 

targetPosition:contentCount (resultCode)

以下の例では、VLV 固有のエントリーを強調表示しています。 

[07/May/2020:11:43:29 -0700] conn=877 op=8530 SRCH base="(ou=People)" scope=2 filter="(uid=*)"
[07/May/2020:11:43:29 -0700] conn=877 op=8530 SORT uid
[07/May/2020:11:43:29 -0700] conn=877 op=8530 VLV 0:5:0210 10:5397 (0)
[07/May/2020:11:43:29 -0700] conn=877 op=8530 RESULT err=0 tag=101 nentries=1 etime=0

上記の例では、最初の部分 0:5:0210 は VLV 要求情報です。

  • beforeCount は 0 です。
  • afterCount は 5 です。
  • 値は 0210 です。

2 番目の部分 10:5397(0) は VLV 応答情報です。

  • targetPosition は 10 です。
  • contentCount は 5397 です。
  • (resultCode) は (0) です。

検索範囲

エントリー scope=n は、実行する検索の範囲を定義します。n には、0、1、または 2 の値を指定できます。

  • ベース検索の場合は 0
  • 1 レベル検索の場合は 1
  • サブツリー検索の場合は 2

拡張操作 OID

例7.1「アクセスログの例」の EXT oid="2.16.840.1.113730.3.5.3" または EXT oid="2.16.840.1.113730.3.5.5" などの拡張操作 OID は、実行されている拡張操作の OID を提供します。表7.2「Directory Server でサポートされる LDAPv3 拡張操作」に、 Directory Server でサポートされる LDAPv3 拡張操作とその OID の部分的なリストを示します。

表7.2 Directory Server でサポートされる LDAPv3 拡張操作

拡張操作名説明OID

Directory Server レプリケーション要求の開始

レプリケーションセッションが必要であることを示すために、レプリケーションイニシエーターによって送信されます。

2.16.840.1.113730.3.5.3

Directory Server のレプリケーション応答

Start Replication Request Extended Operation または End Replication Request Extended Operation に対応して、レプリケーションレスポンダーによって送信されます。

2.16.840.1.113730.3.5.4

Directory Server のレプリケーション終了要求

レプリケーションセッションが終了することを示すために送信されます。

2.16.840.1.113730.3.5.5

Directory Server レプリケーションエントリー要求

エントリーとその状態情報 (csn および UniqueIdentifier) を保持し、レプリカの初期化の実行に使用されます。

2.16.840.1.113730.3.5.6

ディレクトリーサーバーの一括インポートの開始

インポートされる接尾辞と共に一括でインポートすることを要求するためにクライアントにより送信され、一括インポートが開始されることを示すためにサーバーによって送信されます。

2.16.840.1.113730.3.5.7

ディレクトリーサーバーの一括インポートの完了

一括インポートの終了を通知するためにクライアントによって送信され、それを確認するためにサーバーによって送信されます。

2.16.840.1.113730.3.5.8

シーケンス番号の変更

この場合の csn=3b4c8cfb000000030000 の変更シーケンス番号は、この特定の命名コンテキストでレプリケーションが有効になっていることを示すレプリケーション変更シーケンス番号です。

破棄メッセージ

破棄メッセージは、操作が中断されていることを示します。 

[21/Apr/2020:11:39:52 -0700] conn=12 op=2 ABANDON targetop=1 msgid=2 nentries=0 etime=0

nentries=0 は、操作が中断される前に送信されたエントリーの数を示します。etime=0 の値は経過した時間 (秒単位) を示し、targetop=1 は以前に開始した操作 (アクセスログの以前に表示される) からの操作値に対応します。

中断する操作をメッセージ ID が探すことができたかどうかによって、2 種類のログ ABANDON メッセージが記録される可能性があります。メッセージ ID が操作 (targetop) を見つけるのに成功した場合は、上記のようなログが記録されます。しかし、メッセージ ID が操作を見つけられなかった場合や、ABANDON 要求が送信される前に操作がすでに終了した場合は、以下のようなログが記録されます。 

[21/Apr/2020:11:39:52 -0700] conn=12 op=2 ABANDON targetop=NOTFOUND msgid=2

targetop=NOTFOUND は、中断する操作が不明な操作であるか、すでに完了していることを示します。

メッセージ ID

メッセージ ID(ここでは msgid=2) は、LDAP SDK クライアントによって生成された LDAP 操作識別子です。メッセージ ID は操作番号とは異なる値となる可能性がありますが、同じ操作を識別します。メッセージ ID は ABANDON 操作に使用され、破棄されるクライアント操作をユーザーに通知します。 

[21/Apr/2020:11:39:52 -0700] conn=12 op=2 ABANDON targetop=NOTFOUND msgid=2
注記

Directory Server の操作番号は 0 から始まり、ほとんどの LDAP SDK/クライアント実装では、メッセージ ID 番号は 1 から始まります。通常、メッセージ ID が Directory Server の操作番号に 1 を加えた値と等しくなるのはこのためです。

SASL マルチステージバインドロギング

Directory Server では、マルチステージバインドのログは明示的です。バインドプロセスの各段階がログに記録されます。これらの SASL 接続のエラーコードは、実際には戻りコードです。例7.1「アクセスログの例」では、SASL バインドは現在進行中であるため、戻りコードが err=14 になります。つまり、接続は開いたままで、対応する進捗ステートメント SASL bind in progress があります。 

[21/Apr/2020:11:39:55 -0700] conn=14 op=0 BIND dn="" method=sasl version=3 mech=DIGEST-MD5
[21/Apr/2020:11:39:55 -0700] conn=14 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress

SASL バインドのロギングでは、sasl メソッドの後に LDAP バージョン番号 および使用される SASL メカニズムが続きます。GSS-API メカニズムのケースを以下に示します。 

[21/Apr/2020:12:57:14 -0700] conn=32 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI
注記

以前は、バインド要求行ではなく、認証された DN (アクセス制御の決定に使用される DN) が BIND 結果行にログインされるようになりました。 

[21/Apr/2020:11:39:55 -0700] conn=14 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=jdoe,dc=example,dc=com"

SASL バインドでは、バインド要求行に表示される DN 値はサーバーによって使用されず、したがって該当しません。ただし、認証された DN が監査目的で使用する必要のある DN である場合 (SASL バインド)、これを明確にログに記録することが重要です。この認証済み DN をバインド結果行にログとして記録すると、どの DN がどの DN であるかを明確にできます。

7.1.3. 追加のアクセスロギングレベルのアクセスログコンテンツ

本セクションでは、Directory Server のアクセスログで利用可能な追加のアクセスロギングレベルについて説明します。

例7.2「内部アクセス操作レベルのアクセスログの抜粋 (レベル 4)」では、内部操作をログに記録するアクセスログレベル 4 が有効です。

例7.2 内部アクセス操作レベルのアクセスログの抜粋 (レベル 4)

[12/Jul/2020:16:45:46 +0200] conn=Internal op=-1 SRCH base="cn=\22dc=example,dc=com\22,cn=mapping tree,cn=config"scope=0 filter="objectclass=nsMappingTree"attrs="nsslapd-referral" options=persistent
[12/Jul/2020:16:45:46 +0200] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1etime=0
[12/Jul/2020:16:45:46 +0200] conn=Internal op=-1 SRCH base="cn=\22dc=example,dc=com\22,cn=mapping tree,cn=config"scope=0 filter="objectclass=nsMappingTree" attrs="nsslapd-state"
[12/Jul/2020:16:45:46 +0200] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1etime=0

アクセスログレベル 4 では、内部操作のログが有効になります。これにより、実行される検索の詳細の他に、検索ベース、スコープ、フィルター、および要求された検索属性がログに記録されます。

以下の例では、アクセスロギングレベル 768 (512 + 256) が有効化され、エントリーおよび参照へのアクセスがログに記録されます。この抜粋では、最初の行に表示される検索リクエストへの応答として、6 つのエントリーと 1 つの参照が返されています。 

[12/Jul/2020:16:43:02 +0200] conn=306 fd=60 slot=60 connection from 127.0.0.1 to 127.0.0.1
[12/Jul/2020:16:43:02 +0200] conn=306 op=0 SRCH base="dc=example,dc=com" scope=2 filter="(description=*)" attrs=ALL
[12/Jul/2020:16:43:02 +0200] conn=306 op=0 ENTRY dn="ou=Special
[12/Jul/2020:16:43:02 +0200] conn=306 op=0 ENTRY dn="cn=Accounting Managers,ou=groups,dc=example,dc=com"
[12/Jul/2020:16:43:02 +0200] conn=306 op=0 ENTRY dn="cn=HR Managers,ou=groups,dc=example,dc=com"
[12/Jul/2020:16:43:02 +0200] conn=306 op=0 ENTRY dn="cn=QA Managers,ou=groups,dc=example,dc=com"
[12/Jul/2020:16:43:02 +0200] conn=306 op=0 ENTRY dn="cn=PD Managers,ou=groups,dc=example,dc=com"
[12/Jul/2020:16:43:02 +0200] conn=306 op=0 ENTRY dn="ou=Red Hat Servers,dc=example,dc=com"
[12/Jul/2020:16:43:02 +0200] conn=306 op=0 REFERRAL

コネクションの説明

接続の説明 (この場合は conn=Internal) は、接続が内部接続であることを示しています。操作番号 op=-1 も、操作が内部で開始されたことを示しています。 

[12/Jul/2020:16:45:46 +0200] conn=Internal op=-1 ENTRY dn="cn=\22dc=example,dc=com\22,cn=mapping tree,cn=config"

Options Description

オプションの説明 (options=persistent) は、通常の検索操作とは異なる、永続的な検索が実行されることを示しています。永続的な検索は、監視形式として使用し、特定の設定に対する変更の発生時にその変更を返すように設定できます。

この例では、ログレベル 512 と 4 の両方が有効になっているため、内部アクセス操作およびエントリーと参照へのアクセスの両方がログに記録されます。 

[12/Jul/2020:16:45:46 +0200] conn=Internal op=-1 SRCH base="cn=\22dc=example,dc=com\22,cn=mapping tree,cn=config"scope=0 filter="objectclass=nsMappingTree"attrs="nsslapd-referral" options=persistent

7.1.4. 一般的な接続コード

接続コードは、closed のログメッセージに追加されるコードで、接続終了に関する追加情報を提供します。

表7.3 一般的な接続コード

接続コード説明

A1

クライアントが接続をアボートしました。

B1

破損した BER タグが見つかりました。BER タグ (ネットワーク経由で送信されているデータをカプセル化する) が受信時に破損している場合、B1 接続コードがアクセスログに記録されます。BER タグは、物理レイヤーのネットワークの問題や、すべてのリクエストの結果を受け取る前に LDAP クライアントがアボートした等、不適切な LDAP クライアント操作により破損する可能性があります。

B2

BER タグが nsslapd-maxbersize 属性値よりも長い。この設定属性の詳細は、「nsslapd-maxbersize(最大メッセージサイズ)」 を参照してください。

B3

破損した BER タグが見つかりました。

B4

サーバーがデータの応答をフラッシュしてクライアントに戻せなかった。

P2

接続の終了または破損が検出されている。

T1

クライアントが、指定した idletimeout 期間内に結果を受信しなかった。この設定属性の詳細は、「nsslapd-idletimeout(デフォルトのアイドルタイムアウト)」 を参照してください。

T2

ioblocktimeout 期間が経過した後に、サーバーは接続を終了します。この設定属性の詳細は、「nsslapd-ioblocktimeout(IO ブロックのタイムアウト)」 を参照してください。

U1

クライアントがバインド解除要求を送信した後に、サーバーによって接続が終了された。バインド解除要求が送信されると、サーバーは常に接続を終了します。