IBM Tivoli Directory Server, Version 6.3

Logging utilities

IBM® Tivoli® Directory Server Version 6.3 provides several logs that can be viewed either through the Web Administration Tool or the system command line. See the IBM Tivoli Directory Server Version 6.3 Administration Guide for information about viewing the logs. See Using the Messages Guide to resolve errors for information about resolving error messages that you find in the logs.

By default, all the logs listed in this section are in the directory_server_instance_name/logs (or directory_server_instance_name\logs on Windows®) directory. The file names shown are the defaults, but you can change both the paths and the file names for the logs. See the IBM Tivoli Directory Server Version 6.3 Administration Guide for information. The IBM Tivoli Directory Server logs are:

Administration server log (ibmdiradm.log)
An administration server is a limited LDAP server that accepts searches and extended operations to stop, start, and restart the LDAP server. The administration server log allows you to view status and errors encountered by the administration server.

A sample of the log looks like this:

05/06/2010 02:05:57 PM GLPADM056I Admin server starting.
05/06/2010 02:05:58 PM GLPCOM025I The audit plugin is successfully loaded from 
  libldapaudit.so.
05/06/2010 02:05:58 PM GLPCOM022I The database plugin is successfully loaded from 
  libback-config.so.
05/06/2010 02:05:58 PM GLPADM060I The admin server backup and restore server 
  configuration entry is not enabled.
05/06/2010 02:05:58 PM GLPCOM024I The extended Operation plugin is successfully 
  loaded from libloga.so.
05/06/2010 02:05:58 PM GLPCOM003I Non-SSL port initialized to 3546.
05/06/2010 02:05:58 PM GLPADM028I Admin server audit logging is started.
05/06/2010 02:05:58 PM GLPADM004I 6.3.0.0       ibmdiradm started
05/06/2010 02:05:58 PM GLPSRV048I Started 5 worker threads to handle client requests.
Administration server audit log (adminaudit.log)
Administration server audit logging is used to improve the security of the administration server. The directory administrator and administrative group members can use the records stored in the audit log to check for suspicious patterns of activity in an attempt to detect security violations. If security is violated, the audit log can be used to determine how and when the problem occurred and perhaps the amount of damage done.

Since the Administration server is integrated with the directory server's code base, to fine grain the auditing configuration, in addition to ibm-audit, auditing is extended to include audit configuration attributes such as ibm-auditbind, ibm-auditunbind, ibm-auditExtOp, ibm-auditSearch, ibm-auditVersion, and ibm-slapdLog. For the audit configuration changes to take effect, the Administration server must receive the dynamic update configuration request or you must restart the Administration server.

Note:
If any additional “MAY" attributes are specified, the server will ignore the values and no error messages will be written.

A sample of the log looks like this:

2010-01-15-19:59:17.130-06:00GLPADM028I Admin Server audit logging 
is started.
AuditV3--2010-01-16-22:04:50.93986-06:00--V3 Bind--bindDN: CN=ROOT
  --client: 127.0.0.1:3665--connectionID: 0--received: 
	2010-01-16-22:04:50.93986-06:00--Success
AuditV3--2010-01-16-22:04:50.93986-06:00--V3 Search--bindDN: CN=ROOT
  --client: 127.0.0.1:3665--connectionID: 0--received: 
	2010-01-16-22:04:50.93986-06:00--Success
AuditV3--2010-01-16-22:04:50.93986-06:00--V3 Unbind--bindDN: CN=ROOT
  --client: 127.0.0.1:3665--connectionID: 0--received:
	 2010-01-16-22:04:50.93986-06:00--Success
AuditV3--2010-01-16-22:08:09.94185-06:00--V3 Bind--bindDN: CN=ROOT
  --client: 127.0.0.1:3678--connectionID: 1--received:
	 2010-01-16-22:08:09.94185-06:00--Invalid credentials
AuditV3--2010-01-16-22:08:09.94185-06:00--V3 Unbind--bindDN: --client:
	 127.0.0.1:3678--connectionID: 1--received:
	 2010-01-16-22:08:09.94185-06:00--Success
Server audit log (audit.log)
Audit logging is used to improve the security of the directory server. The primary directory administrator and administrative group members with AuditAdmin and ServerConfigGroupMember roles can use the activities stored in the Server audit log to check for suspicious patterns of activity in an attempt to detect security violations. If security is violated, the Server audit log can be used to determine how and when the problem occurred and perhaps the amount of damage done. This information is very useful, both for recovery from the violation and, possibly, in the development of better security measures to prevent future problems.

The Server audit log records the DN's of the Administrative Group members and their assigned roles each time the server starts and anytime their roles change. The format of the record is displayed. Records to be logged after server starts is as follows:

<date>-<time>--<message ID> Administrative roles assigned to <user DN> 
are: <role> <role> ...

See the section "Creating the administrative group" in IBM Tivoli Directory Server Version 6.3 Administration Guide to know more about administrative roles and permissions required to access various objects.

The following is a sample of the Server audit log:

2010-01-16-17:38:15.484-06:00--GLPSRV023I Audit logging started. 
The audit configuration options are:
 ibm-slapdLog = C:\idsslapd-ldaptest\logs\audit.log,
  ibm-auditVersion = true,ibm-audit = true,
	ibm-auditFailedOPonly = true,ibm-auditBind = true,
  ibm-auditUnbind = true,ibm-auditSearch = true,
  ibm-auditAdd = true,ibm-auditModify = true,
  ibm-auditDelete = true,ibm-auditModifyDN = true,
  ibm-auditExtOPEvent = true,ibm-auditExtOp = true,
  ibm-auditAttributesOnGroupEvalOp = true,ibm-auditCompare = true,
  ibm-auditGroupsOnGroupControl = true.
2010-01-16-17:38:15.656-06:00--GLPSRV009I IBM Tivoli Directory (SSL), 
	Version 6.3	Server started.
AuditV3--2009-01-16-17:39:28.468-06:00--V3 anonymous Search--bindDN:
<*CN=NULLDN*>--client: 127.0.0.1:3792--connectionID: 1
--received: 2009-01-16-17:39:28.453-06:00-- No such object
controlType: 1.3.6.1.4.1.42.2.27.8.5.1
criticality: false
base: cn=monitor
scope: wholeSubtree
derefAliases: neverDerefAliases
typesOnly: false
filter: (objectclass=*)
Bulkload error log (bulkload.log)
The idsbulkload (or bulkload) command is used to load entries. The bulkload log allows you to view status and errors related to bulkload.

For example, the command bulkload -I ldapdb2 -i bad.ldif was used to load entries for instance ldapdb2 from an invalid LDIF file named bad.ldif, which contained the following lines:

dn: cn=abc,o=sample
objectclass:person
cn:caaa
sn:abc

The following bulkload error log resulted:

04/05/09 09:31:19 GLPCTL113I Largest core file size creation limit for 
         the process (in bytes): '-1'(Soft limit) and '-1'(Hard limit).
04/05/09 09:31:19 GLPCTL114I Largest file size creation limit for 
         the process (in bytes): '-1'(Soft limit) and'-1'(Hard limit).
04/05/09 09:31:19 GLPCTL115I Maximum data segment limit for 
         the process (in bytes): '-1'(Soft limit) and '-1'(Hard limit).
04/05/09 09:31:19 GLPCTL116I Maximum physical memory limit for 
         the process (in bytes): '-1'(Soft limit) and '-1'(Hard limit).
04/05/09 09:31:19 GLPBLK072I Bulkload started.
04/05/09 09:31:19 GLPBLK050I Extracting parent DNs ...
04/05/09 09:31:19 GLPBLK116E Invalid line detected: 3
04/05/09 09:31:19 GLPBLK044I 1 errors detected during parsing phase.
04/05/09 09:31:20 GLPBLK073I Bulkload completed.
Tools log (idstools.log)
The tools log contains status and error messages related to the configuration tools, such as idscfgdb, idsucfgdb, idscfgchglog, idsucfgchglog, idscfgsuf, idsucfgsuf, idsdnpw, idsxcfg, idsxinst, idscfgsch, and idsucfgsch.

The following is a sample of the tools log:

Jan 09 16:41:02 2006 GLPDPW009I Setting the directory server administrator DN.
Jan 09 16:41:02 2006 GLPDPW010I Set the directory server administrator DN.
Jan 09 16:41:02 2006 GLPDPW006I Setting the directory server administrator 
	password.
Jan 09 16:41:11 2006 GLPDPW007I Set the directory server administrator 
	password.
Jan 09 16:41:17 2006 GLPCDB035I Adding database 'ldaptest' to directory server
	 instance: 'ldaptest'.
Jan 09 16:41:18 2006 GLPCTL017I Cataloging database instance node: 'ldaptest'.
Jan 09 16:41:19 2006 GLPCTL018I Cataloged database instance node: 'ldaptest'.
Jan 09 16:41:19 2006 GLPCTL008I Starting database manager for database
	 instance: 'ldaptest'.
Jan 09 16:41:22 2006 GLPCTL009I Started database manager for database
	 instance: 'ldaptest'.
Jan 09 16:41:22 2006 GLPCTL026I Creating database: 'ldaptest'.
Jan 09 16:43:11 2006 GLPCTL027I Created database: 'ldaptest'.
Jan 09 16:43:11 2006 GLPCTL034I Updating the database: 'ldaptest'
Jan 09 16:43:19 2006 GLPCTL035I Updated the database: 'ldaptest'
Jan 09 16:43:19 2006 GLPCTL020I Updating the database manager: 'ldaptest'.
Jan 09 16:43:22 2006 GLPCTL021I Updated the database manager: 'ldaptest'.
Jan 09 16:43:23 2006 GLPCTL023I Enabling multi-page file allocation:
	 'ldaptest'
Jan 09 16:43:37 2006 GLPCTL024I Enabled multi-page file allocation:
	 'ldaptest'
Jan 09 16:43:38 2006 GLPCDB005I Configuring database 'ldaptest' for 
	directory server instance: 'ldaptest'.
Jan 09 16:43:39 2006 GLPCDB006I Configured database 'ldaptest' for 
	directory server instance: 'ldaptest'.
Jan 09 16:43:39 2006 GLPCDB003I Added database 'ldaptest' to directory 
	server instance: 'ldaptest'.
DB2® log (db2cli.log)
Database errors that occur as a result of LDAP operations are recorded in the DB2 log.

The following is a sample of the DB2 log:

2006-09-13-19:18:29.native retcode = -1031; state = "58031"; 
       message = "SQL1031N"  
	The database directory cannot be found on the indicated file system.  

SQLSTATE=58031

"
2006-09-13-19:18:29.native retcode = -1018; state = "E8"; 
       message = "SQL1018N"  
	The node name "idsinode" specified in the CATALOG NODE command 
already exists.

"
2006-09-13-19:18:30.native retcode = -1026; state = "C8"; 
       message = "SQL1026N"  
	The database manager is already active.
Lost and found log (lostandfound.log)
The lost and found log archives entries that were replaced due to replication conflict resolution. The log of these entries allows you to recover the data in the replaced entries if necessary.

The information logged for each replaced entry includes:

The following is a sample of the lost and found log:

#Entry DN: cn=t6,o=ut1,c=us
#Operation type:Add
#Corrective action:Replace
#Entry createTimestamp: 20061106211242.000000Z
#Entry modifyTimestamp: 20061030202533.000000Z
#Supplier address: 9.53.21.187
dn: cn=t6,o=ut1,c=us
objectclass: person
objectclass: top
sn: aa
cn: aa
cn: t6
description: this should not be here
ibm-entryuuid: 0c4559de-0a76-4c91-96e4-5ae81d405466
Server log (ibmslapd.log)
The server log contains status and error messages related to the server.

The following is a sample of the server log with no errors:

Sep 13 14:31:04 2006  GLPL2D014E Suffix entry has not been created for 
 entry cn=Robert Dean, ou=In Flight Systems, ou=Austin, o=sample.
Sep 13 14:31:04 2006  GLPRDB002W ldif2db: 0 entries have been successfully 
 added out of 50 attempted.
Sep 13 14:39:41 2006  GLPCOM024I The extended Operation plugin is 
 successfully loaded from libevent.dll.
Sep 13 14:39:41 2006  GLPCOM024I The extended Operation plugin is 
 successfully loaded from libtranext.dll.
Installation and uninstallation logs
In addition, there are logs created during installation and uninstallation. The InstallShield GUI installation and uninstallation logs are: ldapinst.log, ldapuninst.log and ldaplp_inst.log (for language packs). For more information about these logs, see Troubleshooting installation and uninstallation.
Backup status file (dbback.dat)
The Administration Server reads entry from the server configuration file that contains backup and restore configuration details if the directory server is with RDBM back-end. If the server backup entries are not present or not enabled in the directory server instance's configuration file, then the Administration Server will log a message such as "The admin server backup and restore server configuration entry is not enabled." in the ibmdiradm.log file during the directory server startup. If the backuprestore LDAP extended operation is initiated at this stage when the backup entries are not present or not enabled, it will result in a "Protocol error" and the Administration Server will log a message such as "Unsupported extended operation request OID '1.3.18.0.2.12.81'" in the ibmdiradm.log file.
Note:
If the directory server is a Proxy Server, then the backup configuration entry will not be read and the LDAP extended operation for backups and restores will not be registered.

If the entry is present and enabled, the Administration Server will check the backup location from the configuration for the date and time of current backup. Monitor searches can be used to fetch latest snapshot of the data pertaining backup/restore. The file dbback.dat is the prime source for monitor searches to fetch their data from. The dbback.dat file is created at a backup location that you specify when configuring backup, for example <backup_location>/BACKUP_FILES.

The dbback.dat file records information like "is backup configured", "database backup location", "date and time of the last backup", "is online backup configured for database and changelog", and other backup related information. This information can be very handy in troubleshooting issues. For example, if restore fails one of the reasons for failure could be that no backup image is available at the configured backup locations. This can be deduced by performing monitor searches or analyzing dbback.dat to fetch the backup information. The timestamp for the last backup is NONE in this case.

If no backup is available at the configured locations, the timestamp for the last backup will be NONE and restore requests will fail.

Note:
User must not edit the contents of the dbback.dat file manually.

[ Top of Page | Previous Page | Next Page ]