title: LDAP server logging and debugging link: https://onemoretech.wordpress.com/2007/12/13/ldap-server-logging-and-debugging/ author: lembobro description: post_id: 590 created: 2007/12/13 20:36:40 created_gmt: 2007/12/13 20:36:40 comment_status: open post_name: ldap-server-logging-and-debugging status: publish post_type: post

LDAP server logging and debugging

For me, logging and debugging are the two most important weapons in the directory operations arsenal.

I’m going to tackle the details of how to set this up on various products in future posts, but for now I’ll make some general comments about the state of things today.

The main point that needs to be made is that the quality of logging and debugging facilities are oft-neglected but highly critical factors in not so much how well it works — but how well you as an admin can work with it.

The first issue that comes up is the blurring of the distinction between the two types of server feedback. Logging is something you need to do at some minimal level all the time. Access and error logs should be consulted often, at least daily, whether by eyeballing them or running an analysis script against them. Debugging is something you do when that logging, or some event, triggers an alert that “something is wrong”.

The Netscape family of directories, which include the latest releases from Sun and Red Hat, include fairly good logging and debugging facilities. I say fairly because the logging sometimes, er, often, leaves much to be desired in the level of detail I consider the minimal necessary to properly monitor directory operations and performance. But it is pretty easily configurable so that you can increase the number and quality of things reported. The only problem is that you quickly lose “legibility” the highter you crank things, and have to resort to some kind of scripting to make any sense of what’s being reported.

Debugging is a separate mode of a Netscape directory invoked using a command line switch while starting the server. Turning on debugging gives you a pretty massive amount of information to work with, again necessitating that you have a script that can analyze what’s getting dumped to the console.

OpenLDAP is another directory server with decent facilities for both logging and debugging, and I’m actually pretty satisfied with both the access and error information the operational logging provides. Among LDAP servers, OpenLDAP is the most protocol-centric, and so if you set it to just the right level of logging you’ll get very complete information about what the directory is not only doing, but most importantly what it is being asked to do.

Debugging is also invoked from the command line at daemon startup in OpenLDAP, and the information provided can be just as extensive as what a Netscape server provides. That’s no accident. The original Netscape directory and OpenLDAP share a common heritage in the origin of their respective slapd executables.

I’ve left Oracle’s Internet Directory for last, because it’s the one I have the least flight time with and because I’m still trying to figure out how to get a decent level of operational detail from it for day to day use. Oracle seems to have conflated operational logging and debugging together, a disease that infects most Java application servers, and the result is not pretty.

The biggest problem I have with Oracle is that they don’t divide access and error reporting into separate logs. OpenLDAP has this same shortcoming, but the effect is not as bad as in Oracle because the information conveyed in the OpenLDAP log is almost exclusively LDAP protocol related. By setting the log levels carefully, you can eliminate reporting of library related errors (which are best investigated in debugging mode anyway). That kind of granularity, for the dizzying array of numeric levels afforded, just doesn’t exist for Oracle Directory.

Copyright 2004-2019 Phil Lembo