Access Log Content
218 Red Hat Directory Server Configuration, Command, and File Reference • May 2005
Abandon Message
The abandon message, in this case
[21/Apr/2005:11:39:52 -0700] conn=12
op=2 ABANDON targetop=1 msgid=2 nentries=0 etime=0
, indicates that an
operation has been aborted, where
nentries=0
indicates the number of entries
sent before the operation was aborted,
etime=0
value indicates how much time
(in seconds) had elapsed, and
targetop=1
corresponds to an operation value
from a previously initiated operation (that appears earlier in the access log).
There are two possible log
ABANDON
messages, depending on whether the message
ID succeeds in locating which operation was to be aborted. If the message ID
succeeds in locating the operation (the
targetop
) then the log will read as above.
However, if the message ID does not succeed in locating the operation or if the
operation had already finished prior to the
ABANDON
request being sent, then the
log will read as follows:
[21/Apr/2005:11:39:52 -0700] conn=12 op=2 ABANDON
targetop=NOTFOUND msgid=2
where
targetop=NOTFOUND
indicates the operation to be aborted was either an
unknown operation or already complete.
Message ID
The message ID, in this case
msgid=2
, is the LDAP operation identifier, as
generated by the LDAP SDK client. The message ID may have a different value
than the Red Hat Directory Server Operation Number but identifies the same
operation. The message ID is used in the context of an
ABANDON
operation and tells
the user which client operation is being abandoned.
SASL Multi-Stage Bind Logging
In Directory Server, logging for multi-stage binds is explicit. Each stage in the
bind process is logged, and, where appropriate, the progress statement
SASL
bind in progress
is included.
In logging a SASL bind, the
sasl
method is followed by the LDAP version
number (see “Version Number”) and the SASL mechanism used, as shown below
with the GSS-API mechanism.
NOTE The Directory Server operation number starts counting at 0, and, in
the majority of LDAP SDK/client implementations, the message ID
number starts counting at 1, which explains why the message ID is
frequently equal to the Directory Server operation number plus 1.