Re: LDAP Debug

There are times when LDAPDEBUG is needed. LDAPDEBUG output in the console 
log can both provide additional information on the LDAP operations, as 
shown below, and also information on other things happening on the server 
that could have an impact on the LDAP service (e.g., indexing, 
compacting).   However, the LDAPDEBUG output describing a single operation 
is spread over many lines, often interleaved with similar output from 
other LDAP threads, making it hard to read.  A big advantage of the LDAP 
activity log is that the information from each LDAP operation is collected 
in one record, and that these records can be easily searched, viewed, and 
accessed by programs using standard Notes features.

Because LDAPDEBUG data often yields its secrets only after considerable 
analysis, it is often better to start with a lower level of logging. This 
is both less demanding on the system having the problem, in terms of 
performance and disk space, and less demanding on the analyst.

Because LDAPDEBUG output is usually a jumble of messages from different 
threads, use debug_threadid.  Except for simple cases, you will benefit 
from utilities that separate log data by thread for analysis, such as a 
powerful text editor, or LogThreadTail and LogThreadSplit.

LDAPDEBUG=1 (trace) provides roughly the same information found in the 
LDAP activity log.  The activity log does a better job of correlating IP 
addresses with LDAP operations.  The LDAPDEBUG=1 log shows which entries 
were returned, not just the count given in the activity log.

LDAP>   Found matching entry, Note ID: 5310
LDAP> SendSearchEntry, sending entry CN=Polar Bear,O=org3

LDAPDEBUG=1 also shows which address book views are being searched, and 
how, which can be helpful in understanding performance and configuration 
problems.

LDAP> *** Searching in database C:\Lotus\Domino\Data\names.nsf ...
LDAP>   Type of search: View Search
LDAP>     ... Searching entries for a filter 'sn = bear' in ($LDAPS)
LDAP> GetSearchEntry State

The timestamps on these search messages can be used to identify 
performance issues such as non-optimal database searches.

LDAPDEBUG=3 (trace + args) shows operation arguments, e.g., for the bind 
operation, but LDAPDEBUG=1 shows all the arguments for the search 
operation, which is usually the operation of interest.  LDAPDEBUG=3 does 
not increase the size of the LDAPDEBUG very much.

LDAPDEBUG=7 (trace + args + entry) shows the attributes values returned by 
the search, instead of just the name of the returned entry.  This is 
especially valuable when the problem may involve the client not getting 
back what it expected.  (Compare to LDAPDEBUG=1, above.) However, it can 
greatly increase the size of the LDAPDEBUG output.

LDAP>   Found matching entry, Note ID: 5310
LDAP>   Entry:
LDAP>     dn: CN=Polar Bear,O=org3
LDAP>     cn: Polar Bear
LDAP>     fullname: CN=Polar Bear,O=org3
LDAP>     fullname: CN=Polar Bear
LDAP>     mail: PolarBear@xxxxxxxxx
LDAP> SendSearchEntry, sending entry CN=Polar Bear,O=org3

Higher levels of LDAP debug are generally interesting only when debugging 
specific types of problems, such as access control problems (add 96 to the 
LDAPDEBUG number), or byte-level problems with returned data (add 16 to 
the LDAPDEBUG number).
 
Walter Scanlan 
Senior Software Engineer
Domino & Workplace for iSeries
507-286-6088
wscanlan@xxxxxxxxxx