第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
タグ | 説明 |
---|---|
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 の部分的なリストを示します。
拡張操作名 | 説明 | 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 レプリケーションエントリー要求 |
エントリーとその状態情報 ( | 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 RESULTerr=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=3mech=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
のログメッセージに追加されるコードで、接続終了に関する追加情報を提供します。
接続コード | 説明 |
---|---|
A1 | クライアントが接続をアボートしました。 |
B1 | 破損した BER タグが見つかりました。BER タグ (ネットワーク経由で送信されているデータをカプセル化する) が受信時に破損している場合、B1 接続コードがアクセスログに記録されます。BER タグは、物理レイヤーのネットワークの問題や、すべてのリクエストの結果を受け取る前に LDAP クライアントがアボートした等、不適切な LDAP クライアント操作により破損する可能性があります。 |
B2 |
BER タグが |
B3 | 破損した BER タグが見つかりました。 |
B4 | サーバーがデータの応答をフラッシュしてクライアントに戻せなかった。 |
P2 | 接続の終了または破損が検出されている。 |
T1 |
クライアントが、指定した |
T2 |
|
U1 | クライアントがバインド解除要求を送信した後に、サーバーによって接続が終了された。バインド解除要求が送信されると、サーバーは常に接続を終了します。 |