Tivoli® SecureWay® Policy Director Performance …publib.boulder.ibm.com/.../en_US/PDF/pd38_perf_tune.pdf4 Preface The Tivoli SecureWay Policy Director Performance Tuning Guide provides

Tivoli® SecureWay® Policy DirectorPerformance Tuning GuideVersion 3.8

October 2001

Tivoli SecureWay Policy Director Performance Tuning Guide

Copyright Notice© Copyright IBM Corporation 2001. All rights reserved. May only be used pursuant to aTivoli Systems Software License Agreement, an IBM Software License Agreement, orAddendum for Tivoli Products to IBM Customer or License Agreement. No part of thispublication may be reproduced, transmitted, transcribed, stored in a retrieval system, ortranslated into any computer language, in any form or by any means, electronic,mechanical, magnetic, optical, chemical, manual, or otherwise, without prior writtenpermission of IBM Corporation. IBM Corporation grants you limited permission to makehardcopy or other reproductions of any machine-readable documentation for your own use,provided that each such reproduction shall carry the IBM Corporation copyright notice. Noother rights under copyright are granted without prior written permission of IBMCorporation. The document is not intended for production and is furnished “as is” withoutwarranty of any kind. All warranties on this document are hereby disclaimed, includingthe warranties of merchantability and fitness for a particular purpose.U.S. Government Users Restricted Rights—Use, duplication or disclosure restricted by GSA ADP ScheduleContract with IBM Corporation.

TrademarksIBM, the IBM logo, Tivoli, the Tivoli logo, and SecureWay are trademarks or registered trademarks ofInternational Business Machines Corporation or Tivoli Systems Inc. in the United States, other countries, or both.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc.in the United States and other countries.

Lotus is a registered trademark of Lotus Development Corporation.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the UnitedStates, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Other company, product, and service names may be trademarks or service marks of others.

NoticesReferences in this publication to Tivoli Systems or IBM products, programs, or services do not imply that theywill be available in all countries in which Tivoli Systems or IBM operates. Any reference to these products,programs, or services is not intended to imply that only Tivoli Systems or IBM products, programs, or servicescan be used. Subject to valid intellectual property or other legally protectable right of Tivoli Systems or IBM, anyfunctionally equivalent product, program, or service can be used instead of the referenced product, program, orservice. The evaluation and verification of operation in conjunction with other products, except those expresslydesignated by Tivoli Systems or IBM, are the responsibility of the user. Tivoli Systems or IBM may have patentsor pending patent applications covering subject matter in this document. The furnishing of this document does notgive you any license to these patents. You can send license inquiries, in writing, to the IBM Director of Licensing,IBM Corporation, North Castle Drive, Armonk, New York 10504-1785, U.S.A.

4

Preface

The Tivoli SecureWay Policy Director Performance Tuning Guide provides performance tuninginformation for an environment consisting of Tivoli SecureWay Policy Director, Version 3.8 withIBM SecureWay Directory defined as the user registry. This guide is regularly updated with thelatest performance information regarding Policy Director.

This guide supplements the performance tuning sample scripts, located at the following Webaddress:

https://www.tivoli.com/secure/support/downloads/secureway/policy_dir/downloads.html

This Web page requires a registered user name and password.

Who Should Read This GuideThis guide is for system administrators responsible for configuring an environment for optimalperformance.

What This Guide ContainsThis guide contains the following main sections:

1. Tuning the IBM LDAP Directory for Policy Director 8 1.1 Back Ups 81.2 When to Tune the LDAP Directory 81.3 Regular Tunings 91.4 Recommended LDAP Directory Tuning Steps 91.5 Recommended LDAP Directory Tuning Details 10

1.5.1 Periodic Tuning Details 101.5.2 One Time Tuning Details 26

1.6 Special Case IBM LDAP Directory Tunings 281.6.1 Using LDAP Cache 28

2. Tuning Policy Director 302.1 Recommended Policy Director Tunings 30

2.1.1 auth-using-compare 302.1.2 user-and-group-in-same-suffix 312.1.3 default-policy-override-support 31

2.2 Special Case Policy Director Tunings 312.2.1 LDAP Admin Account (cn=root) 312.2.2 Load Balancing Between LDAP Replicas 312.2.3 SSL Between PD and LDAP 322.2.4 Auto Migration of PD 3.7 Users During Authentication 322.2.5 SSL and Credential Cache 32

3. Tuning AIX for Policy Director 334. Policy Director’s Use of LDAP Directory 345. Utilities, Scripts and Hints for Managing IBM LDAP Directory Servers 37

5.1 IBM LDAP Directory’s Use of DB2 37

5

5.2 Spreading the Database Across Multiple Physical Disks 395.2.1 Background Information on LDAP Directory Tablespaces 395.2.2 Create File Systems and Directories on the Target Disks 415.2.3 Back Up the Existing Database 415.2.4 Perform a Redirected Restore of the Database 42

5.3 DB2 Backup and Restore 435.4 Monitoring LDAP Performance 445.5 Update Performance and SMP Systems 455.6 Creating Large Numbers of Users 455.7 Using the LDAP Bulkload Utility to Create Policy Director Users 46

5.7.1 Bulkload and ACLs 465.7.2 Preparing for the bulkload Utility 465.7.3 Performing the Bulkload 475.7.4 Adding a Large Number of Members to a Group 51

6. Process Size Limits 556.1 Increasing the Operating System Process Size Limits 556.2 AIX Specific Process Size Limits 55

6.2.1 Setting the Number of AIX Data Segments to Use (LDR_CNTRL) 556.2.2 AIX Data Segments and LDAP Process DB2 Connections 566.2.3 Verifying Process Data Segment Usage 56

7. Troubleshooting 57

PublicationsThis section lists publications in the Tivoli SecureWay Policy Director library and any otherrelated documents. It also describes how to access Tivoli publications online, how to order Tivolipublications, and how to make comments on Tivoli publications.

Tivoli SecureWay Policy Director WebSEAL LibraryThe following documents are available in the /doc directory on the Tivoli SecureWay PolicyDirector WebSEAL, Version 3.8 CD and on the Tivoli Customer Support Web site:

• Tivoli SecureWay Policy Director WebSEAL Installation Guide, GC32-0683Explains how to install, configure, and upgrade Tivoli SecureWay Policy DirectorWebSEAL.

• Tivoli SecureWay Policy Director WebSEAL Administration Guide, GC32-0684Provides a comprehensive set of procedures and reference information for managing theresources of your secure Web domain. This guide also provides you with valuablebackground and conceptual information for a wide range of WebSEAL functionality.

Tivoli SecureWay Policy Director Base LibraryThe following documents are available in the /doc directory on the Tivoli SecureWay PolicyDirector Base CD for your particular platform and on the Tivoli Customer Support Web site. Foradditional sources of information about Tivoli SecureWay Policy Director and related topics,including Lightweight Directory Access Protocol (LDAP) and public key infrastructures, see thefollowing Web site:

6

http://www.ibm.com/redbooks

• Tivoli SecureWay Policy Director Release NotesProvides late-breaking information, such as software limitations, workarounds, and patchavailability.

• Tivoli SecureWay Policy Director Base Installation Guide, GC32-0735Explains how to install, configure, and upgrade Tivoli SecureWay Policy Directorsoftware.

• Tivoli SecureWay Policy Director Base Administration Guide, GC32-0680Describes the concepts and procedures for using Tivoli SecureWay Policy Directorservices. Provides instructions for performing tasks from the pdadmin command lineinterface.

• The following supplemental documentation is available on the Tivoli Customer SupportWeb site only. For information about how to access this Web site, see “AccessingPublications Online” on page viii.

Tivoli SecureWay Policy Director Base Administration API Developer’s ReferenceProvides reference material about using the administration API to enable an application toperform Tivoli SecureWay Policy Director administration tasks. This document describes both

• Tivoli SecureWay Policy Director Base Administration API Developer ReferenceProvides reference material about using the administration API to enable an applicationto perform Tivoli SecureWay Policy Director administration tasks. This documentdescribes both Java™ and C implementations of the administration API.

• Tivoli SecureWay Policy Director Base Authorization ADK Developer ReferenceProvides reference material about using the development tools and authorization API toenable an application to use Tivoli SecureWay Policy Director security. This documentdescribes both Java and C implementations of the authorization API.

• Tivoli SecureWay Policy Director Capacity Planning GuideAssists planners in determining the number of WebSEAL, LDAP, and backend Webservers needed to achieve a required workload.

IBM SecureWay Directory LibraryIBM SecureWay Directory, Version 3.2.1, is shipped on the Tivoli SecureWay Policy DirectorBase CD for your particular platform. If you plan to install the IBM SecureWay Directory server,the following document is available in the /doc/Directory/install_config_guide/��directory:

• IBM SecureWay Directory Installation and Configuration Guide (aparent.htm)Provides installation, configuration, and migration information for IBM SecureWayDirectory components on AIX, Solaris, and Windows operating systems.

http://www.ibm.com/redbooks

7

For more information about IBM SecureWay Directory, see the following Web site:

http://www.software.ibm.com/network/directory/library/

Tivoli SecureWay Policy Director Web Portal ManagerIf you received a Tivoli SecureWay Policy Director Web Portal Manager, Version 3.8 CD withyour particular Tivoli SecureWay Policy Director solution, you can install the Web portalmanager interface. This Web-based interface enables you to perform Tivoli SecureWay PolicyDirector administration tasks. The Web portal manager replaces the management consolepreviously shipped with Tivoli SecureWay Policy Director.

The following document is located in the /doc directory:

• Tivoli SecureWay Policy Director Web Portal Manager Administration Guide,GC32-0736Provides information about installing the Web portal manager and administering TivoliSecureWay Policy Director servers through its use.

Accessing Publications OnlineYou can access many Tivoli publications online at the Tivoli Customer Support Web site:

http://www.tivoli.com/support/documents/

These publications are available in PDF or HTML format, or both. Translated documents are alsoavailable for some products. To access most of the documentation, you need an ID and password.If necessary, you can obtain these from the following Web site:

http://www.tivoli.com/support/getting/

Ordering PublicationsYou can order many Tivoli publications online at the following Web site:

http://www.ibm.com/shop/publications/order

You can also order by telephone by calling one of these numbers:

• In the United States: 800-879-2755• In Canada: 800-426-4968• In other countries, for a list of telephone numbers, see the following Web site:

http://www.tivoli.com/inside/store/lit_order.html

Providing Feedback about PublicationsWe are very interested in hearing about your experience with Tivoli products and documentation,and we welcome your suggestions for improvements. If you have comments or suggestions aboutour products and documentation, contact us in one of the following ways:

• Send an e-mail to [email protected].

http://www.software.ibm.com/network/directory/library/

http://www.tivoli.com/support/documents/

http://www.tivoli.com/support/getting/

http://www.ibm.com/shop/publications/order

http://www.tivoli.com/inside/store/lit_order.html

8

• Complete our customer feedback survey at the following Web site:

http://www.tivoli.com/support/survey/

Contacting Customer SupportIf you have a problem with any Tivoli product, you can contact Tivoli Customer Support. See theTivoli Customer Support Handbook at the following Web site:

http://www.tivoli.com/support/handbook/

The handbook provides information about how to contact Tivoli Customer Support, depending onthe severity of your problem, and the following information:

• Registration and eligibility• Telephone numbers and e-mail addresses, depending on the country you are in• What information you should gather before contacting support

1 Tuning the IBM LDAP Directory for Policy Director

This section provides tuning information for the IBM SecureWay Directory server and relatedDB2 database. In this section, the use of the term IBM LDAP or LDAP refers to the IBMSecureWay Directory, V3.2.1 product (shipped with Tivoli SecureWay Policy Director, Version3.8). IBM LDAP uses a DB2 database for its information storage or backing store. LDAPprovides a layer on top of DB2 that simplifies the performance of updates and searches on theDB2 database.

The tunings recommended in this section are to be performed on all directory servers, bothmasters and replicas. LDAP tunings do not propagate from the master server to the replicaserver.

1.1 Back Ups

It is highly recommended that before proceeding with any of the following tuning steps, the DB2database be backed up. Some of the tuning changes, if not performed properly, can lead to acorrupted DB2 database. The only recovery when the database is corrupted is a restore from aknown backup. If a backup is not available, the LDAP server must be reconfigured.

In addition an initial backup and regular backups of the database are recommended. Thefrequency of the backups depends on the difficulty of recovering the data in case of a failure.

For more information about performing DB2 backup and restore operations, see “DB2 Backupand Restore” on page 43.

1.2 When to Tune the LDAP Directory

The LDAP directory and DB2 database should be tuned or at least have their tunings checkedregularly and after any of the following events:

http://www.tivoli.com/support/survey/

http://www.tivoli.com/support/handbook/

9

• Policy Director is freshly configured into a new LDAP directory.• A large number of users are added to the registry, for example using the LDAP bulkload

utility.• The DB2 database is restored from a back up.

The backed up database contains the settings of certain database tunings. These include the DB2configuration parameter settings, table indexes, and database optimizations achieved by runningthe runstats and reorgchk commands.

1.3 Regular Tunings

It is important to tune the LDAP directory regularly or at least check the tunings regularly. Themost important tuning step to repeat periodically is the DB2 reorgchk command. As updates areperformed on the database, performance steadily decreases. Regular running of the reorgchkcommand recovers this degradation. It is recommended that a reorgchk be performed no laterthan after 10,000 updates. As an alternative, it can be repeated daily at off peak times.

If the database contains 3 or more million users, run the DB2 runstats command along with thereorgchk command.

1.4 Recommended LDAP Directory Tuning Steps

To tune the LDAP directory and DB2 database, it is recommended that you follow these steps inthis order. Note that these steps are performed on the directory server machine(s).

1. On Solaris, increase the shared memory maximum operating system parameter.2. Tune the DB2 configuration parameter settings.3. Check and create any missing DB2 table indexes.4. Fix LDAP ACL permissions for users created with the bulkload utility.5. Check for and create missing LDAP ACL entries on LDAP suffixes.6. If database contains 3 or more million users, perform a DB2 runstats command on the

objectclass table.7. Perform a DB2 reorgchk command.

Note that performing a DB2 reorgchk command is one of the most important steps forperformance, yet it is often overlooked. It provides valuable information to the DB2 optimizerfor optimizing queries to the database. You should perform this step last so that the DB2optimizer can make its decisions based on the most up-to-date state of the database.

The following tuning steps also are recommended, but have no specific order in which they mustbe completed. These steps usually need to be performed only once.

1. Turn off the LDAP Change Log function if it is configured.2. Increase the number of LDAP connections to DB2.3. Enable LDAP concurrent read/write.4. Order the LDAP suffixes for optimal searches by Policy Director.

Detailed information on each of these tuning steps is provided in following sections.

10

1.5 Recommended LDAP Directory Tuning Details

In the following sections, various commands are provided as examples. For UNIX systems, it isimportant to distinguish the user environment under which these commands are run. Unlessotherwise stated, all commands that start with db2 are run as the ldapdb2 user. All othercommands are run as the root user. Note that this implies that the DB2 instance user for theLDAP database is the configuration default of ldapdb2. If the default is changed at LDAPconfiguration time, run the DB2 command under the context of the configured user, instead ofldapdb2.

When logged in as the root user on UNIX systems, it is possible to switch to the ldapdb2 user byrunning the following command:

su – ldapdb2

1.5.1 Periodic Tuning Details

1.5.1.1 Increasing the Shared Memory Maximum (shmmax) on Solaris

On Solaris systems, the shared memory maximum (shmmax) operating system parameter mustbe increased from its default to enable the DB2 processes to grow as a result of recommendedincreases to its cache buffering parameters. If the shared memory maximum is not increased,DB2 runs with a very small cache. DB2 on AIX does not have this problem.

The shared memory maximum is specified in bytes. It is recommended that shmmax be set tothe size of physical memory. For example, if the LDAP server has 1 GB of physical memory,recommended shared memory maximum is to 1073741824.

To display the current shared memory maximum setting, run the following command:

sysdef | grep -i shmmax

To update the shared memory maximum setting, edit the /etc/system file. Find the linecontaining the shmsys:shminfo_shmmax script and change its setting to the desired value.

Warning: Changes to shared memory maximum do not take effect until the system is rebooted.Use the sysdef command to display the setting being used by the operating system.

If the shared memory maximum has not been set large enough for the DB2 cache, the followingmessage is displayed (when running the db2 connect to ldapdb2 command):

SQL1478W The database has been started but only one buffer poolhas been activated. SQLSTATE=01626

A similar message might appear when starting LDAP using the slapd command.

11

1.5.1.2 Tuning DB2 Configuration Parameter Settings

The database configuration parameters that affect Policy Director performance are BUFFPAGE,buffer pool, DBHEAP, SORTHEAP, MAXLOCKS, and MINCOMMIT. These parameters aredescribed in the following sections.

1.5.1.2.1 BUFFPAGEAlong with the DB2 reorgchk parameter, the BUFFPAGE configuration parameter is one of themost important tuning parameters. Unlike DB2 reorgchk, BUFFPAGE is less frequentlyoverlooked, since it typically only needs to be done one time. It can be sometimes overlookedwhen the parameter is tuned and later the database is restored from a backup with a previoussetting.

The BUFFPAGE parameter sets the size of the DB2 cache. Because of this, it affects the DB2database’s use of memory.

The main benefit of the DB2 cache is the caching of table indexes, which makes LDAP queriesgo fast. Table indexes improve the time it takes to find data on the disk.

As an alternative to, or in conjunction with the DB2 cache, you can use the LDAP cache toimprove the speed of LDAP queries. It is more efficient in terms of both memory usage andspeed, yet is not typically recommended for the following reasons:

• The contents of the LDAP cache tend to get invalidated for most types of update operations.• It is not possible to cache millions of users in memory because of the large amount of

memory required. Even with sufficient memory, the time to load the cache with a significantnumber of users is too long to make a performance improvement practical.

There may be certain environments where the LDAP cache is beneficial, particularly for smallnumber of user, read only environments. For more information, see “Using LDAP Cache”onpage 28.

1.5.1.2.1.1 Recommended BUFFPAGE Setting

Allocate as much memory as possible to the DB2 cache. Consider the current system memoryconsumption, including DB2 base memory consumption, and allocate the remainder of physicalmemory to the DB2 cache. Do not set the DB2 cache so high that it exceeds the availablephysical memory and pages to disk. A guideline is to define the DB2 cache from 50% to 75% ofthe machine’s physical memory. This usually leaves more than enough memory for the operatingsystem and other applications.

The DB2 cache uses 4 KB of physical memory per BUFFPAGE. For example, a BUFFPAGEsetting of 32000 uses 128 MB of memory. The minimum recommended setting for BUFFPAGEis 16000, or 12.8 buffers per thousand Policy Director users in the LDAP directory (whichever islargest). For example, for one million Policy Director users, set the BUFFPAGE parameter to noless than 12800.

12

The following table provides guidelines:

Number of Policy DirectorUsers

Minimum RecommendedBUFFPAGE setting

DB2 Cache Memory Usage

10,000 16000 64 KB100,000 16000 64 MB1,000,000 16000 64 MB10,000,000 128000 512 MB

For best performance, set the BUFFPAGE parameter to greater than the minimumrecommendation. For example, for a system with millions of users, an optimal size is to specify2 GB of memory and a 256000 setting for BUFFPAGE.

1.5.1.2.1.2 BUFFPAGE Memory Usage Warnings

Because the BUFFPAGE parameter causes DB2 to allocate memory, use caution when changingthe BUFFPAGE setting. If this is set too high, DB2 can exhaust all physical memory and pagingspace and not start. This process can leave a core dump, but there is typically no message in theLDAP error log when this occurs. On AIX systems, the system error log might indicate theprocess ended due to memory allocation failure. To view the error log, use the errrpt –a | morecommand.

In some cases, restoring a DB2 database can result in a database that cannot start due to memoryallocation failures. This occurs when the backed up database has a BUFFPAGE setting thatexceeds the machine’s memory capacity. Note that the DB2 configuration parameters are savedand restored with a backed up database. In some cases, the DB2 restore fails. For informationabout working around this problem, see “Troubleshooting” on page 57.

1.5.1.2.1.3 BUFFPAGE Dependency on Buffer Pool

The BUFFPAGE parameter is only used if the buffer pool is defined with a size of –1. To obtainthe current setting for the buffer pool, run the following commands:

db2 connect to ldapdb2db2 "select * from syscat.bufferpools"

Verify that the NPAGES column is defined as –1. If not, run the following command to definethe size to –1:

db2 "alter bufferpool ibmdefaultbp size –1"

Note: Changes to DB2 configuration parameters do not take effect until the database is restartedwith db2stop and db2start.

13

1.5.1.2.1.4 Setting BUFFPAGE

To obtain the current setting of the DB2 BUFFPAGE parameter, run the following command:

db2 get database configuration for ldapdb2 | grep BUFFPAGE

To set the BUFFPAGE parameter, run the following command:

db2 update database configuration for ldapdb2 usingBUFFPAGE size

where size is the new value.

On successful completion of the update command, the following message is displayed:

SQL1482W The BUFFPAGE parameter will only be used if one ofthe buffer pools is defined with a size of -1.

This message indicates to check the buffer pool size. It does not mean that BUFFPAGE is setincorrectly. For more information, see “BUFFPAGE Dependency on Buffer Pool” on page 12.


1.5.1.2.2 DBHEAP, SORTHEAP, MAXLOCKS, and MINCOMMIT

1.5.1.2.2.1 Recommended DBHEAP, SORTHEAP, MAXLOCKS, and MINCOMMITSettings

This section provides the recommended settings for DBHEAP, SORTHEAP, MAXLOCKS, andMINCOMMIT configuration parameters.

Set DBHEAP to its default of 1200 plus 25 for each amount that BUFFPAGE is incrementedabove its default of 1000. Always set SORTHEAP to 2500, MAXLOCKS to 100, andMINCOMMIT to 25. The MINCOMMIT parameter controls the number of commits that aregrouped together before updates are written to disk. Regardless of the setting, updates aredelayed no longer than 1 second from the time of the commit. Setting MINCOMMIT to 25improves update performance. The following table provides guidelines:

BUFFPAGE DBHEAP SORTHEAP MAXLOCKS MINCOMMIT1000 (default) 1200

(default)256 (default) 10 (default) 1 (default)

16000 1800 2500 100 2532000 2500 2500 100 2564000 3800 2500 100 25128000 6300 2500 100 25256000 11000 2500 100 25

14

1.5.1.2.2.2 Setting DBHEAP, SORTHEAP, MAXLOCKS and MINCOMMIT

To obtain the current setting for the DBHEAP, SORTHEAP, MAXLOCKS and MINCOMMITparameters, run the following command:

db2 get database configuration for ldapdb2 | egrep \‘DBHEAP|SORTHEAP|MAXLOCKS|MINCOMMIT’

To set the DB2 configuration parameters, run the following command:

db2 update database configuration for ldapdb2 using \parm_name parm_value

where parm_name specifies the parameter that you want to change and parm_value is the valuethat you want to assign. On successful completion, the following message is displayed:

DB20000I The UPDATE DATABASE CONFIGURATION commandcompleted successfully.

DB21026I For most configuration parameters, allapplications must disconnect from this database beforethe changes become effective.


1.5.1.2.3 Example Script for Setting the DB2 ConfigurationParameters

The following do_tunings.sh script provides an example of setting the DB2 configurationparameters. It also stops and restarts DB2.

Run this script as the ldapdb2 user. However, before you do, ensure that you update theBUFFPAGE and DBHEAP settings to values appropriate for the machine being tuned (asdescribed in previous sections).

db2 get database configuration for ldapdb2 | egrep \'BUFFPAGE|DBHEAP|SORTHEAP|MAXLOCKS|MINCOMMIT'

db2 update database configuration for ldapdb2 using BUFFPAGE 16000db2 update database configuration for ldapdb2 using DBHEAP 1800db2 update database configuration for ldapdb2 using SORTHEAP 2500db2 update database configuration for ldapdb2 using MAXLOCKS 100db2 update database configuration for ldapdb2 using MINCOMMIT 25

db2 connect to ldapdb2db2 "alter bufferpool ibmdefaultbp size -1"

db2 select "* from syscat.bufferpools"

db2 terminatedb2 force application allsleep 5db2stop

15

db2start

Note that if the LDAP server is running when you run this script, the script becomes unusable andyou must restart it. An indication that this has occurred is when the ldapsearch command failswith an operations error message. To fix this problem, restart the LDAP server.

1.5.1.3 Checking and Creating Missing DB2 Table Indexes

In rare cases, the LDAP server can drop one or more of its DB2 table indexes. Since DB2 tableindexes are critical to LDAP performance, you should check them regularly.

The following check_indexes.sh script checks for the existence of DB2 table indexes that areimported for LDAP and Policy Director performance. The script assumes that it is being usedagainst an ldapdb2 database that is configured for Policy Director. If the database is notconfigured for use with Policy Director, the script reports several missing indexes.

The script prints out a suggested DB2 create command for any missing indexes. It prints out acolon-separated index definition when it finds indexes that are not expected. These unexpectedindexes come from other products using LDAP and are used for informational purposes. Thesecond field of the colon-separated list of extra indexes is the name of the index. To delete theseunexpected indexes, you can run the following command:

db2 drop index index_name

where index_name is the name of the index.

Run this script as the ldapdb2 user. The file system owner of the file is the ldapdb2 user and thefile system group is dbsysadm.

Note that the script shows an example of the usage of the DB2 cursor function. The usage ofDB2 cursors is one of the few ways to pace the output of a search that returns a large number ofresults. This is an alternative to using LDAP search, which does not provide a suitable pacingmechanism.

The check_indexes.sh script is as follows:

# script to determine whether all tables that exist have an index on eid # andany other index important to PD

db2 connect to ldapdb2 >/dev/null

cat << EOF | sort >noneid_idxs_needed.tmpALIASEDOBJECT:ALIASEDOBJECT:+ALIASEDOBJECT_T+EID:DALIASEDOBJECT:RALIASEDOBJECT:+RALIASEDOBJECT_T+EID:DCN:CN:+CN_T+EID:DCN:RCN:+RCN_T+EID:DDESCRIPTION:DESCRIPTION:+DESCRIPTION_T+EID:DDESCRIPTION:RDESCRIPTION:+RDESCRIPTION_T+EID:DLDAP_DESC:LDAP_DESC_AEID:+DEID+AEID:DLDAP_ENTRY:LDAP_ENTRY_PEID2:+PEID:DLDAP_ENTRY:LDAP_ENTRY_PEID:+EID+PEID:DLDAP_ENTRY:LDAP_ENTRY_TRUNC:+DN_TRUNC:DMAIL:MAIL:+MAIL_T+EID:DMAIL:RMAIL:+RMAIL_T+EID:DMEMBER:MEMBER:+MEMBER_T+EID:UMEMBER:RMEMBER:+RMEMBER_T+EID:D

16

OBJECTCLASS:OBJECTCLASS:+OBJECTCLASS+EID:DOBJECTCLASS:ROBJECTCLASS:+ROBJECTCLASS+EID:DPRINCIPALNAME:PRINCIPALNAME:+PRINCIPALNAME_T+EID:DPRINCIPALNAME:RPRINCIPALNAME:+RPRINCIPALNAME_T+EID:DSECAUTHORITY:RSECAUTHORITY:+RSECAUTHORITY+EID:DSECAUTHORITY:SECAUTHORITY:+SECAUTHORITY+EID:DSECDN:RSECDN:+RSECDN+EID:DSECDN:SECDN:+SECDN+EID:DSECUUID:RSECUUID:+RSECUUID+EID:DSECUUID:SECUUID:+SECUUID+EID:DSN:RSN:+RSN+EID:DSN:SN:+SN+EID:DSYS:RSYS:+RSYS_T+EID:DSYS:SYS:+SYS_T+EID:DTARGETSERVICE:RTARGETSERVICE:+RTARGETSERVICE_T+EID:DTARGETSERVICE:TARGETSERVICE:+TARGETSERVICE_T+EID:DTELEPHONENUMBER:RTELEPHONENUMBER:+RTELEPHONENUMBER+EID:DTELEPHONENUMBER:TELEPHONENUMBER:+TELEPHONENUMBER+EID:DTSNAME:RTSNAME:+RTSNAME+EID:DTSNAME:TSNAME:+TSNAME+EID:DTSTYPE:RTSTYPE:+RTSTYPE+EID:DTSTYPE:TSTYPE:+TSTYPE+EID:DUID:RUID:+RUID_T+EID:DUID:UID:+UID_T+EID:DUNIQUEMEMBER:RUNIQUEMEMBER:+RUNIQUEMEMBER_T+EID:DUNIQUEMEMBER:UNIQUEMEMBER:+UNIQUEMEMBER_T+EID:UEOF

print "Finding all defined indexes"

db2 "list tables" | nawk '{if ($2 == "LDAPDB2"){print $1}}' | sort>all_tables.tmp

rm -f eid_idxs.tmprm -f noneid_idxs.tmpfor i in `cat all_tables.tmp`;do

db2 describe indexes for table ldapdb2.$i show detail | grep LDAPDB2 | \nawk -v tbl=$i '{

if ($5 == "+EID" && $3 == "D"){fn = "eid_idxs.tmp"

} else {fn = "noneid_idxs.tmp"

}print tbl":"$2":"$5":"$3 >> fn#print tbl >> "all_tables.tmp"

}'done

# Determine whether there are any missing eid indexes

print "Checking for missing EID indexes"

sort eid_idxs.tmp >eid_idxs_sorted.tmpmv eid_idxs_sorted.tmp eid_idxs.tmp

# create the set of tables that have an eid indexcat eid_idxs.tmp | nawk -F ":" '{print $1}' | sort -u >eid_idx_tables.tmp

diff all_tables.tmp eid_idx_tables.tmp | grep "<" | nawk '{if ($2 != "CHANGE" &&

$2 != "LDAP_DESC" &&$2 != "LDAP_ENTRY" &&$2 != "LDAP_NEXT_EID" &&$2 != "PROGRESS" &&$2 != "REGISTER"){

print $2}

}' >potential_missing.tmp

for i in `cat potential_missing.tmp`;do

17

db2 "declare c cursor with hold for select * from $i" >/dev/nulldb2 "open c" >/dev/nulldb2 fetch c for 1 row | grep selected | nawk '{print $1}' >hasrow.tmphasrow=`cat hasrow.tmp`rm -f hasrow.tmpdb2 "close c" >/dev/null

if [ $hasrow = 1 ];thenprint "Missing index: $i"print " Recommend recovery: db2 create index $i""I on $i(eid)"

fidone

rm -f potential_missing.tmprm -f eid_idxs.tmprm -f eid_idx_tables.tmp

# Determine whether there are any missing non-eid indexesprint "Checking for missing non-EID indexes"

sort noneid_idxs.tmp >noneid_idxs_sorted.tmpmv noneid_idxs_sorted.tmp noneid_idxs.tmp

# create lists with index names removed for comparison purposescat noneid_idxs_needed.tmp | nawk -F ":" '{print $1":"$3":"$4}' | \

sort >nbi_needed_short.tmpcat noneid_idxs.tmp | nawk -F ":" '{print $1":"$3":"$4}' | sort >nbi_short.tmp

diff nbi_needed_short.tmp nbi_short.tmp | grep "<" | \nawk '{print $2}' >potential_missing.tmp

for i in `cat potential_missing.tmp`;do

tbl=ècho $i | nawk -F ":" '{print $1}'`

# Determine whether the table is even defined in this databasetbl_defined=`grep $tbl all_tables.tmpìf [ "X$tbl_defined" != "X" ];then

# Determine whether the table as any data

db2 "declare c cursor with hold for select * from $tbl">/dev/null

db2 "open c" >/dev/nulldb2 fetch c for 1 row | grep selected | nawk '{print $1}'

>hasrow.tmphasrow=`cat hasrow.tmp`rm -f hasrow.tmpdb2 "close c" >/dev/null

if [ $hasrow = 1 ];then

indx_def_coded=ècho $i | nawk -F ":" '{print $2}'`

indx_name=`cat noneid_idxs_needed.tmp | \nawk -F ":" -v idx_def=$indx_def_coded \

-v tbl=$tbl '{if ($1 == tbl && $3 == idx_def){

print $2exit

}}'`

indx_def=ècho $indx_def_coded | nawk -F "+" '{for (i=2;i<NF;i++){

idx = idx""$i","}idx = idx""$NFprint idx

}'`

18

uniq_flag=ècho $i | nawk -F ":" '{print $3}'ìf [ $uniq_flag = "U" ];then

uniq_flag=uniqueelse

unset uniq_flagfi

print "Missing index: $i"print " Recommend recovery: db2 create $uniq_flag “ \

”index $indx_name on $tbl($indx_def)"fi

fidone

rm -f potential_missing.tmp

print "Checking for additional non-EID indexes (information purposes only)"print "If any additional non-EID indexes are found, they will be listed below."

diff nbi_needed_short.tmp nbi_short.tmp | grep ">" | \nawk '{print $2}' >additional_idxs.tmp

for i in `cat additional_idxs.tmp`;do

tbl=ècho $i | nawk -F ":" '{print $1}'`

# Determine whether the table as any data

db2 "declare c cursor with hold for select * from $tbl" >/dev/nulldb2 "open c" >/dev/nulldb2 fetch c for 1 row | grep selected | nawk '{print $1}' >hasrow.tmphasrow=`cat hasrow.tmp`rm -f hasrow.tmpdb2 "close c" >/dev/null

if [ $hasrow = 1 ];then

idx=ècho $i | nawk '{print substr($1,index($1,":")+1)}'`

full_name=`cat noneid_idxs.tmp | grep $tbl | grep $idx`

print $full_name

fidone

rm -f additional_idxs.tmp

rm -f nbi_needed_short.tmprm -f nbi_short.tmp

rm -f noneid_idxs_needed.tmprm -f noneid_idxs.tmprm -f all_tables.tmp

db2 terminate >/dev/null

1.5.1.4 Fixing Up LDAP ACLs

When Policy Director creates or imports a user, it applies ACLs to protect the LDAP objects thatit creates. For large numbers of users, this results in a large number of ACLs, which is aperformance concern.

When the LDAP bulkload utility is used to create a large numbers of users, it is recommendedthat ACL support be turned off. Bulkload does not perform well with ACL support turned on.

19

As a work around to this problem, it is possible to remove the Policy Director-created ACLs andmodify Policy Director objects to inherit their ACLs from key LDAP entries that contain thedesired protections. Note that this step can be skipped if there are fewer than 10,000 PolicyDirector users defined in the registry and those users are created using Policy Directoradministration functions. For less than 10,000 users, performance problems do not exist. Formore information about using the LDAP bulkload utility, see “Using the LDAP Bulkload Utilityto Create Policy Director Users” on page 46. For more information about how Policy Directoruses LDAP ACLs, see “Policy Director’s Use of LDAP Directory” on page 34.

The following fixacls.sh script implements the recommended ACL inheritance fix. You can runthis script multiple times in case you make an incorrect selection for ACL inheritance the firsttime. You also can modify this script to fix those objects that do not have the Policy Directordefined ACLs (for example, bulkloaded users). However, the disadvantage to making thismodification is that you can only run the script one time. If this is acceptable, remove deletecommands similar to the following:

db2 delete from aclperm where eid in (select eid from objectclass \where eid > $i and eid < $j and objectclass = 'SECMAP')

and add the following clause to all update commands as follows:

and eid in (select eid from src where aclsrc = -1)

This change also makes the script run faster when used as a check to ensure that bulkloaded userACLs have been fixed.

Run this script as the ldapdb2 user. The file system owner of the file is the ldapdb2 user and thefile system group is dbsysadm.

Note that this script makes use of eid ranges to pace the processing of the DB2 updatecommands. The number of entries to process in a single update must be limited, due to thepotential for the DB2 transaction log growing to exceed available disk space. The DB2transaction log is used to back out partial updates in the event that the command fails in themiddle of making an update. DB2 treats update commands as atomic operations. Either theupdate succeeds or fails.

Ignore any errors messages similar to No row was found. These type of messages indicatethat no update was necessary for the particular range being processed.

The fixacls.sh script is as follows:

# Script to fix up the acls for policy director objects with secmap, secuser, and# secpolicydata objectclasses and LDAP user objects with inetorgperson objectclass.## The script first determines the EIDs to use for inheritance. Some help from the# user is prompted in the form of choosing a suffix. Next, a general cleanup of# null entries in the aclperm table is done. The final steps involve looping# through all eids in the system and doing the following.# 1) Set the source table for objects with specific objectclasses to inherit from the# identified suffixes.# 2) Delete entries in the aclperm table that step one makes no longer necessary.

20

# The following defines the maximum number of updates that will be done at one time.# This is important in order to keep the size of the change log small.grouping=50000

db2 connect to ldapdb2 >/dev/null

# obtain eid of secauthority=default for PD object acl inheritancedb2 "select ldap_entry.eid from ldap_entry where dn_trunc = 'SECAUTHORITY=DEFAULT'" | \ awk '{if (index($0,"-")){getline;print $1}}' >eid.tmppdobj_acl_inherit=`cat eid.tmp`

# obtain eid for LDAP user acl inheritanceprint Enter the DN of a suffix from which LDAP users inherit their ACLs.print Below are some possible choices:

# get the eids for all suffixesdb2 select eid from ldap_entry where peid = -1 | \ awk '{if (index($0,"-")){getline;while ($1 != ""){print $1;getline}}}' >eid.tmpsuf_eids=`cat eid.tmp`

# get the dns from the eidsrm -f suf_dns.tmpfor i in $suf_eids;do

db2 select ldap_entry.dn_trunc from ldap_entry where eid = $i | \ awk '{if (index($0,"-")){getline;print $1}}' >>suf_dns.tmp

done

# filter out the pseudo suffixes and printcat suf_dns.tmp | grep -iv "cn=localhost" | grep -iv "secauthority=default"

read dn?"Enter DN (must be all capitals letters) or Ctrl-c to exit: "

# obtain eid of the entered DNdb2 "select ldap_entry.eid from ldap_entry where dn_trunc = '$dn'" | \ awk '{if (index($0,"-")){getline;print $1}}' >eid.tmpldapuser_acl_inherit=`cat eid.tmp`

rm -f eid.tmprm -f suf_dns.tmp

#print $ldapuser_acl_inherit

if [ "X$ldapuser_acl_inherit" = "X" ];then print "Error: Invalid DN or DN does not exist" exit -1fi

# Do some general cleanup of unused entries in the LDAP ACL table

21

# delete entries from the aclperm table that have null acldn'sprint Deleting entries from the aclperm table that have null acldn\'sdb2 "delete from aclperm where acldn like '' "

# get the maximum eid

db2 "select * from ldap_next_eid" | \ awk '{if (index($0,"-")){getline;print $1}}' >eid.tmpmax_eids=`cat eid.tmp | awk '{print $1}'`rm -f eid.tmp

#print $max_eids

# loop doing the acl fixups

i=0while [ $i -le $max_eids ]; do j=$(( $i+$grouping+1 ))

print updating entries $i through $j : timestamp = $SECONDS seconds

cmd="db2 update src set aclsrc = $pdobj_acl_inherit where eid \ in (select eid from src where eid in (select eid from objectclass \ where eid > $i and eid < $j and objectclass = 'SECMAP'))" print $cmd $cmd

# delete entries from the aclperm table for this objectclass cmd="db2 delete from aclperm where eid in (select eid from objectclass \ where eid > $i and eid < $j and objectclass = 'SECMAP')" print $cmd $cmd

cmd="db2 update src set aclsrc = $pdobj_acl_inherit where eid in \ (select eid from src where eid in (select eid from objectclass \ where eid > $i and eid < $j and objectclass = 'SECUSER'))" print $cmd $cmd

# delete entries from the aclperm table for this objectclass cmd="db2 delete from aclperm where eid in (select eid from objectclass \ where eid > $i and eid < $j and objectclass = 'SECUSER')" print $cmd $cmd

cmd="db2 update src set aclsrc = $pdobj_acl_inherit where eid in \ (select eid from src where eid in (select eid from objectclass where \ eid > $i and eid < $j and objectclass = 'SECPOLICYDATA'))" print $cmd $cmd

22

# delete entries from the aclperm table for this objectclass cmd="db2 delete from aclperm where eid in (select eid from objectclass \ where eid > $i and eid < $j and objectclass = 'SECPOLICYDATA')" print $cmd $cmd

cmd="db2 update src set aclsrc = $ldapuser_acl_inherit where eid in \ (select eid from src where eid in (select eid from objectclass where \ eid > $i and eid < $j and objectclass = 'INETORGPERSON'))" print $cmd $cmd

# delete entries from the aclperm table for this objectclass cmd="db2 delete from aclperm where eid in (select eid from objectclass \ where eid > $i and eid < $j and objectclass = 'INETORGPERSON')" print $cmd $cmd

i=$(( $j - 1 ))done

1.5.1.5 Checking and Creating Missing LDAP ACL Entries on LDAP Suffixes

In rare cases, a configuration error can cause one or more of the LDAP ACLs on suffix objects tobe removed. Since the ACL definitions on suffix objects are critical to providing the protectionsthat Policy Director puts in place, it is important to check them. This is really a functionalproblem, not a performance problem.

The following check_ldap_acls.sh script checks each suffix for the existence of the PolicyDirector expected ACLs and produces LDIF output for any that are missing.

Run this script as the root user. The file system owner of the file is ldapdb2 user and the filesystem group is dbsysadm.

The script expects two inputs: the name of the LDAP server (ldaphost) and the cn=root user’spassword (ldappwd). It assumes the LDAP administrative user is cn=root.

Run the script first to see what changes it reports. For example:

check_ldap_acls.sh ldaphost ldappwd

Run the script a second time, piping the output to ldapadd, to perform the changes on the LDAPserver. For example:

check_ldap_acls.sh ldaphost ldappwd | \ldapadd -h ldaphost -D cn=root -w ldappwd

23

The check_ldap_acls.sh script is as follows:

# script to check and produce LDIF for fixing up ACLs on LDAP suffixes. The# goal is to get the LDAP ACLs to the values preferred by Policy Director.

usage(){

print "Usage: $0 <ldap host> <ldap password>"exit -1

}

if [ "X$1" = "X" ] || [ "X$2" = "X" ];then usagefi

ldaphost=$1ldappwd=$2

# a function to compare the results of the suffix searches on ACL attributes and generate# LDIF to add anything that is missing

search_compare_fix(){

# input srchbase=$1 prev_result=$2 # a file name

ldapsearch -h $ldaphost -D cn=root -w $ldappwd -s base -b $srchbase "objectclass=*" \ ownerpropagate entryowner aclpropagate aclentry | sort >cur_result.tmp

if [ "X`cat cur_result.tmp`" = "X" ];then rm -f cur_result.tmp return fi

diff $prev_result cur_result.tmp | grep "<" | awk -v dn=$srchbase '{

attr = substr($2,1,index($2,"=")-1) val = substr($2,index($2,"=")+1)

print "" print "dn: "dn print "changetype: modify"

if (attr == "aclentry"){ print "add: "attr }else{ print "replace: "attr } print attr": "val

24

}'

rm -f cur_result.tmp}

# First, check "secauthority=default" suffixes

cat << EOF >sec_req_acls.tmpaclentry=group:CN=IVACLD-SERVERS,CN=SECURITYGROUPS,SECAUTHORITY=DEFAULT:normal:rscaclentry=group:CN=REMOTE-ACL-USERS,CN=SECURITYGROUPS,SECAUTHORITY=DEFAULT:normal:rscaclentry=group:CN=SECURITYGROUP,SECAUTHORITY=DEFAULT:object:ad:normal:rwsc:sensitive:rwsc:critical:rwscaclpropagate=TRUEentryowner=group:CN=SECURITYGROUP,SECAUTHORITY=DEFAULTownerpropagate=TRUEEOF

search_compare_fix secauthority=default sec_req_acls.tmp

# Now, check non-"secauthority=default" suffixes

cat << EOF >nonsec_req_acls.tmpaclentry=group:CN=ANYBODY:normal:rscaclentry=group:CN=IVACLD-SERVERS,CN=SECURITYGROUPS,SECAUTHORITY=DEFAULT:normal:rscaclentry=group:CN=REMOTE-ACL-USERS,CN=SECURITYGROUPS,SECAUTHORITY=DEFAULT:normal:rscaclentry=group:CN=SECURITYGROUP,SECAUTHORITY=DEFAULT:object:ad:normal:rwsc:sensitive:rwsc:critical:rwscaclpropagate=TRUEentryowner=access-id:CN=ROOTownerpropagate=TRUEEOF

ldapsearch -L -h $ldaphost -D cn=root -w $ldappwd -s base -b "" "objectclass=*" namingcontexts| \ grep "namingcontexts:" | grep -iv "CN=SCHEMA" | grep -iv"SECAUTHORITY=DEFAULT" | \ grep -iv "CN=LOCALHOST" | awk '{print $2}' >suffixes.tmp

for i in `cat suffixes.tmp`;do

search_compare_fix $i nonsec_req_acls.tmp

done

rm -f suffixes.tmprm -f nonsec_req_acls.tmprm -f sec_req_acls.tmp

25

1.5.1.6 Performing a DB2 runstats Command on the objectclass Table

If your database contains 3 million users or more, run the DB2 runstats command on theobjectclass table to improve LDAP start up time performance.

Do not perform any updates while the runstats command is in progress. This includes certainPolicy Director pdadmin commands, such as creating and deleting users and groups. Updatesare blocked until the completion of the runstats command.

This concern does not apply to LDAP searches. LDAP searches are not blocked by the runstatscommand. There is only a slight degradation in search performance while the runstats commandis in progress. For example, Policy Director authentications are not affected by the progress ofrunstats command.

It takes about 10 minutes to perform a runstats command for the objectclass table on a 400 MHzSun machine with 3 million users. Typically, a 5 million users database takes about 15 minutesfor LDAP to start. However, after running the runstats command, it takes less than a minute.

To use the runstats command, run the following commands:

db2 connect to ldadpb2db2 runstats on table ldapdb2.objectclass with distribution and \

detailed indexes all shrlevel reference

If you receive the following error message, this indicates that a connection does not existwith the ldapdb2 database:

SQL2310N The utility could not generate statistics.Error "-1024" was returned

To resolve this problem, run the db2 connect to ldapdb2 command and retry the runstatscommand. The performance benefit from running the runstats command is immediate. It also isnot necessary to perform a db2stop/db2start sequence following a runstats command.

1.5.1.7 Performing a DB2 reorgchk Command

DB2 reorgchk is one of the most important and often overlooked DB2 tuning commands. It isoften overlooked because it is not a one-time tuning item. As updates are performed on the DB2database, performance steadily decreases. The reorgchk command recovers this degradation andneeds to be repeated periodically. As a guideline, it is recommended that you run the reorgchkcommand after every 10,000 updates. It also is recommended that you stop LDAP before runningthis command to prevent any DB2 queries or updates from occurring while reorgchk is inprogress. Although database queries and updates might work, they will be very slow and mighttime out.

Note that it takes about 20 minutes to perform a reogrchk command on a 400 MHz Sun machinewith 3 million users. The performance benefit is immediate and it is not necessary to perform adb2stop/db2start sequence following a reorgchk command.

26

To run the reorgchk command, enter the following commands:

db2 connect to ldapdb2db2 reorgchk update statistics on table all

In addition to improving performance, the reorgchk command reports statistics on the tables andindexes in the database, including statistics on the organization of DB2 tables. These statistics arefor information purposes only.

1.5.2 One Time Tuning Details

1.5.2.1 Turning Off the LDAP Change Log If It Has Been Configured

The LDAP Change Log significantly slows down LDAP update performance. This functioncauses all updates to LDAP to be recorded in a separate change log DB2 database (that is, adifferent database from the one used to hold the LDAP server Directory Information Tree). Thechange log database can be used by other applications to query and track LDAP updates.However, Policy Director does not use the change log functionality.

To check whether the change log has been configured, determine whether theCN=CHANGELOG pseudo suffix is defined by running the following command:

ldapsearch –h <ldapserver> -D cn=root –w <ladppwd> -s base–b “” “objectclass=*” | \grep “CN=CHANGELOG”

If this command returns any results, change log is configured. To unconfigure the LDAP changelog, run the following command:

ldapucfg –g

1.5.2.2 Increasing the Number of LDAP Connections to DB2

It is recommended that you define the highest number of LDAP connections to DB2. Thenumber of DB2 connections is directly related to the level of concurrency that LDAP achieveswhen communicating with DB2. The number of DB2 connections is controlled by the ibm-slapdDbConnections parameter in the /etc/slapd32.conf file. On the AIX operating system, themaximum number of connections is 8.

If the number of DB2 connections is increased beyond its maximum value, the maximum value isused.

The following table shows the recommended settings by operating system:

Operating System ibm-slapdDbConnectionsAIX 8

All others 30

The DB2 connections parameter is defined on the LDAP server machine.

27

1.5.2.3 Enabling LDAP Concurrent Read/Write

It is recommended that LDAP concurrent read/write be enabled. LDAP concurrent read/writeenables read operations to run concurrently with write operations. By default, read operations areblocked by write operations. A slight disadvantage to enabling LDAP concurrent read/write isthe chance that race conditions can occur. For example, an LDAP entry may be updated at thesame time that it is read. This can result in search failures, but is only a temporary condition.

LDAP concurrent read/write is enabled through an environment variable calledLDAP_CONCURRENTRW. Setting it to ON enables it.

To define LDAP environment variables, do either of the following:

• To define LDAP environment variables in the command shell (before starting slapd), runthe following commands:

stop LDAP (slapd process)export LDAP_CONCURRENTRW=ONstart LDAP

• To define LDAP environment variables in the slap32.conf file, add the following entriesto the file as follows:

dn: cn=Front End,cn=Configurationobjectclass: topobjectclass: ibm-slapdFrontEndibm-slapdSetEnv: LDAP_CONCURRENTRW=ON

The performance improvements from the use of LDAP_CONCURRENTRW also apply to LDAPreplica servers, which receive updates from the master server during propagation.

1.5.2.4 Ordering LDAP Suffixes for Optimal Policy Director Searches

It is recommended that the LDAP suffixes be ordered in the /etc/slapd32.conf file such that themost common suffixes are listed last. The most common suffixes are those in which PolicyDirector users are most likely to be found. Policy Director searches each suffix until a user isfound. Note that the fewer suffixes that have to be searched to find a user, the faster theauthentication performance.

The suffixes are defined in the /etc/slapd32.conf file by the ibm-slapdSuffix parameter. List thepseudo suffixes first, for example, CN=SCHEMA and CN=LOCALHOST.

When planning the LDAP directory tree structure, it is recommended that you define the leastnumber of suffixes as possible. In most cases, it is only necessary to create a suffix for users andthe secauthority=default suffix, which is used to hold Policy Director server information. Formore information, see the Tivoli SecureWay Policy Director Base Installation Guide.

28

1.6 Special Case IBM LDAP Directory Tunings

This section contains tunings that are not normally recommended, but there may be someenvironments where they are useful.

1.6.1 Using LDAP Cache

The LDAP cache is more efficient in memory usage and speed than the DB2 cache.Disadvantages to the LDAP cache is that it gets invalidated on most update operations and cantake too long to load. The environments that gain most from LDAP caching are those with smallregistries sizes and few updates.

Keep in mind that increasing the LDAP cache size can cause the slapd process memory size toexceed system limits. For information about increasing these limits, see “Process Size Limits”on page 55.

1.6.1.1 Setting the LDAP Cache Parameters

The LDAP cache parameters that are recommended for use with Policy Director areRDBM_CACHE_SIZE and RDBM_FCACHE_SIZE. These parameters are defined to LDAPwith environment variables. To define LDAP cache environment variables, do either of thefollowing:

• To define the LDAP cache environment variables in the command shell (before startingslapd), run the following commands:

stop LDAP (slapd process)export RDBM_CACHE_SIZE=<value>export RDBM_FCACHE_SIZE=<value>start LDAP (slapd process)

• To define the LDAP cache environment variables in the slap32.conf file, add thefollowing entries to the file as follows:

dn: cn=Front End,cn=Configurationobjectclass: topobjectclass: ibm-slapdFrontEndibm-slapdSetEnv: RDBM_CACHE_SIZE=<value>ibm-slapdSetEnv: RDBM_FCACHE_SIZE=<value>

For information on the definition of these and other LDAP cache parameters, see the IBMSecureWay Directory documentation.

1.6.1.2 Choosing the LDAP Cache Values for the Policy Director

The primarily use of the LDAP cache is for caching authenticated users. There are a couple ofways to choose values for the LDAP cache parameters. One is to base the choice on the numberof users to be cached. Another is to base the choice on the amount of memory available forcaching. Both ways require information on the memory usage per cached user and the number ofcache entries used per cached user.

29

For Policy Director, the memory usage per cached user is approximately 3 KB and the number ofcache entries used (per cached user) is 4 for the entry cache and 5 for the filter cache. The entrycache is controlled by RDBM_CACHE_SIZE and the filter cache is controlled byRDBM_FCACHE_SIZE. These approximations vary greatly with the various Policy Directorconfiguration settings and usage.

The following lists items that affect Policy Director’s use of LDAP cache resources:

• User-and-group-in-same-suffix setting in the webseald.conf file• Default-policy-override-support setting in the webseald.conf file• Ordering and number of LDAP suffixes in the /etc/slapd32.conf file• Whether the user was created using Version 3.7 or Version 3.8 of Policy Director. Related to

this is the usage of the PD38_SCHEMA_OFF environment variable. See note below.• Authenticating through GSO junctions

Note that an LDAP registry containing users that were created using an earlier version of PolicyDirector do not immediately benefit from the LDAP cache. The reason for this is that PolicyDirector performs an automatic migration of pre-Version 3.8 users to the new attributes enabledby the Policy Director, Version 3.8 schema. This automatic migration causes updates to LDAPthat invalidate or remove users from the cache. For information about the PD38_SCHEMA_OFFparameter and turning off automatic migration, see “Tuning Policy Director” on page 30.

1.6.1.2.1 Choosing Based on the Number of Users to be Cached

Use the following formulas for choosing the LDAP cache settings:

LDAP entry cache size = <# of PD users> * 4LDAP filter cache size = <# of PD users> * 5Memory requirements = <# of PD users> * 3 KB

1.6.1.2.2 Choosing Based on the Amount of Memory Available forCaching

Use the following formulas for choosing the LDAP cache settings:

<# of PD users cached> = <desired memory usage> / 3 KBLDAP cache size = <# of PD users> * 4LDAP filter cache size = <# of users> * 5

1.6.1.2.3 Example Cache Size Settings

The following table provides guidelines for cache size settings. Because these settings might notapply in every case, it is necessary to verify them (as explained in the following section).

# of PDusers

Entry CacheSize

Filter CacheSize

MemoryUsage

Additional Data SegmentsNeeded (AIX)

10,000 40000 50000 30 MB 050,000 200000 250000 150 MB 0

30

100,000 400000 500000 300 MB 1

1.6.1.2.4 Verifying the LDAP Cache Resources Usage

Typically, there are two things to verify regarding the LDAP cache settings. One is whethercache misses have been eliminated and another is if the LDAP process memory usage is asexpected.

To verify that cache misses have been eliminated, issue the following commands periodicallywhile LDAP searches are in progress:

ldapsearch –h ldap_host -s base –b “cn=monitor” “objectclass=*” | \grep entry_cache_miss

If all results come from the LDAP cache, the entry_cache_miss count remains constantthroughout the usage of LDAP.

To verify the LDAP cache memory usage is as expected, watch the process memory growth asusers are cached. The UNIX ps utility is recommended. For example, the following ps commandshows the current memory size of the LDAP process:

ps –e –o vsz –comm | grep slapd

Repeat this command periodically to determine what the memory size is when it levels off.

To verify that the LDAP cache memory usage does not exceed process size limits, watch theslapd process and verify that it does not end unexpectedly. If the slapd process ends afterincreasing the LDAP cache, it is probably due to exceeding memory limits.

2 Tuning Policy Director

The following sections provide tuning information for Policy Director.

2.1 Recommended Policy Director Tunings

2.1.1 auth-using-compare

The default setting for the auth-using-compare option in the /opt/pdweb/etc/webseald.conf fileis yes. This setting is recommended. Authentication performance is 25% to 30% slower whenauth-using-compare is set to no than when it is set to yes.

With auth-using-compare set to no, Policy Director authenticates using the traditional LDAPbind and unbind commands. With auth-using-compare set to yes, Policy Director authenticateswith the IBM LDAP unique search command. The auth-using-compare option is ignored foriPlanet LDAP.

31

2.1.2 user-and-group-in-same-suffix

The default setting for the user-and-group-in-same-suffix option in the/opt/pdweb/etc/webseald.conf file is no. If possible, it is recommended that this option be set toyes. When set to yes, Policy Director assumes the user, and the group the user is a member of,are in the same suffix. When set to no, Policy Director searches every suffix for a given user’sgroup membership.

The performance impact is reduced LDAP searches. Authentication performance is directlyrelated to the number of LDAP search operations that are performed.

2.1.3 default-policy-override-support

The default setting for the default-policy-override-support option in the/opt/pdweb/etc/webseald.conf file is no. If possible, it is recommended that this option be set toyes. When set to yes, Policy Director ignores personal policy overrides during authentication. Inthis case, the global policy is effective for all users. When set to no, policy overrides arehonored.

The performance impact to this recommendation is reduced LDAP searches duringauthentication. Authentication performance is directly related to the number of LDAP searchoperations that are performed.

2.2 Special Case Policy Director Tunings

2.2.1 LDAP Admin Account (cn=root)

When Policy Director is configured, it creates LDAP user accounts that are used to access theLDAP directory. The LDAP server administrator can set ACLs in the directory that allow ordeny these Policy Director server users from accessing parts of the directory tree. The additionalACL checking associated with each LDAP search results in a slight performance reduction ofapproximately 10%.

To eliminate the ACL checking, change the account that the Policy Director servers use to accessLDAP to the root administrator of the LDAP directory. This is usually the cn=root account.

The options that control this are bind-dn and bind-pwd in the/opt/PolicyDirector/etc/ivmgrd.conf and /opt/pdweb/etc/webseald.conf files.

2.2.2 Load Balancing Between LDAP Replicas

Policy Director can balance its authentication load between multiple LDAP servers. Inenvironments where the LDAP server is the bottleneck, each additional LDAP server results in alinear improvement to authentication performance.

Note that authentication performance also depends on the authentication load throughput of thePolicy Director WebSEAL servers and the junctioned backend Web servers (if they are used).

32

The performance improvement for adding an LDAP server is apparent only if the LDAP server isthe bottleneck.

The /opt/PolicyDirector/etc/ldap.conf file controls the definition of the LDAP server (orservers) for use during authentication.

2.2.3 SSL Between PD and LDAP

The communication protocol between Policy Director and LDAP can be TCP or Secure SocketsLayer (SSL). Because traffic between Policy Director and LDAP is light in comparison toHTTP/HTTPS traffic and because communication is over a static SSL session, the performancedifference between using TCP or SSL between Policy Director and LDAP is approximately 10%.

2.2.4 Auto Migration of PD 3.7 Users During Authentication

Policy Director, Version 3.8, provides a more efficient organization of LDAP attributes amongPolicy Director user objects than previous versions of Policy Director. This is enabled throughthe use of a new schema in Version 3.8. The efficiency gain is in the number of operationsrequired to perform authentication. This results in improved authentication performance. Formore information on the Version 3.8 organization of attributes among LDAP objects, see “PolicyDirector’s Use of LDAP Directory” on page 34.

If users are created on a version of Policy Director earlier than Version 3.8, Policy Directorautomatically migrates those users to the Version 3.8 schema definitions during authentication.This results in updates to LDAP and can result in reduced performance. In many cases, automaticis not even noticed.

If performance problems are seen when authenticating users created using a previous version ofPolicy Director, automatic migration might be the cause. To turn off automatic migration, set thePD38_SCHEMA_OFF environment variable. For example, to define the PD38_SCHEMA_OFFenvironment variable before starting Policy Director, enter the following commands:

export PD38_SCHEMA_OFF=1pd_start start

This environment variable can be set to any value. Only the existence of the variable is required.

2.2.5 SSL and Credential Cache

The following parameters in the /opt/pdweb/etc/webseald.conf file control how often users re-authenticate:

[ssl]ssl-v2-timeout = 100ssl-v3-timeout = 7200ssl-max-entries = 4096[session]max-entries = 4096timeout = 3600inactive-timeout = 600

33

The ssl-max-entries and max-entries options control the size of the SSL and credential caches,respectively.

Increases to the SSL and credential cache sizes can cause the WebSEAL process memory usageto exceed system limits. For information about increasing these limits, see “Process SizeLimits” on page 55.

The SSL session cache uses about 250 bytes of process memory per entry and the credentialcache uses about 8.3 KB of process memory per entry.

3 Tuning AIX for Policy Director

It is recommended that you define the following environment variables in the command shell:

When starting Policy Director servers, define the following:

• SPINLOOPTIME=650 (for SMP machines)• MALLOCMULTIHEAP=1 (for SMP machines)• AIXTHREAD_MUTEX_DEBUG=OFF• AIXTHREAD_SCOPE=S

When starting the LDAP server, define the following:

• SPINLOOPTIME=650 (for SMP machines)• MALLOCMULTIHEAP=1 (for SMP machines

34

4 Policy Director’s Use of LDAP Directory

35

User DataSuffix: secAuthority=Default

dn: cn=Joe Smith,…,c=usobjectclass: inetOrgPersonobjectclass: ePersonobjectclass: organizationalPersonobjectclass: personobjectclass: topcn: Joe Smithsn: Smithuserpassword: {iMASK} ***uid: anything

Perf hint: define only 2 suffixesSuffix: c=us

dn: secAuthority=Default,cn=Joe Smith,…,c=us

objectclass: secUserobjectclass: eUserobjectclass: cimManagedElementobjectclass: topsecauthority: Defaultseclogintype: Default:LDAPprincipalname: jsmithsecpwdvalid: truesecacctvalid: truesecuuid: f80dc9f8-488c-11d4-98cf-0004ac5e5097sechaspolicy=falsesecpwdlastchanged: 20000622223220.0Z

dn: cn=Default, secAuthority=Default,cn=Joe Smith,…,c=usobjectclass: secPolicyobjectclass: ePasswordPolicyobjectclass: topcn: Default

dn: cn=PolicyData,secAuthority=Default,cn=Joe Smith,…,c=usobjectclass: secPolicyDataobjectclass: topcn: PolicyDatasecpwdlastchanged: 20000622223220.0Z

dn: secUUID= f80dc9f8-488c-11d4-98cf-0004ac5e5097,cn=Users,secAuthority=Default

objectclass: secMapobjectclass: topsecdn: Joe Smith,…,c=ussecuuid: f80dc9f8-488c-11d4-98cf-0004ac5e5097

*** user policy overrides ***

dn: cn=Users,secAuthority=Default

New in PD 3.8

36

Default Policy Data

dn: cn=Default,cn=Policies,secAuthority=Defaultobjectclass: secPolicyobjectclass: ePasswordPolicyobjectclass: topcn: Defaultmaxfailedlogins: 10numberwarndays: 5passwordmaxage: 7862400passwordminage: 0passwordmaxrepeatedchars: 2passwordminalphachars: 4passwordmindiffchars: 3passwordminlength: 8passwordminotherchars: 1passwordreusenum: 5passwordtimereuse: 0timeexpirelockout: 180

cn=Policies,secAuthority=Default

Suffix: secAuthority=Default

37

ACL Usage on IBM LDAPSuffix: secAuthority=Defaultaclentry: group:CN=SECURITYGROUP,SECAUTHORITY=DEFAULT:object:ad:normal:rwsc:sensitive:rwsc:critical:rwsc

dn: cn=Joe Smith,…,c=usobjectclass: inetOrgPerson

Suffix: c=usaclentry: group:CN=ANYBODY:normal:rscaclentry: group:CN=SECURITYGROUP,SECAUTHORITY=DEFAULT:object:ad:normal:rwsc:sensitive:rwsc:critical:rwsc

dn: secAuthority=Default,cn=Joe Smith,…,c=usobjectclass: secUseraclentry: group:CN=SECURITYGROUP,SECAUTHORITY=DEFAULT:object:ad:normal:rwsc:sensitive:rwsc:critical:rwsc

dn: cn=Default, secAuthority=Default,cn=Joe Smith,…,c=usobjectclass: secPolicy

dn: cn=PolicyData,secAuthority=Default,cn=Joe Smith,…,c=usobjectclass: secPolicyData

dn: secUUID= f80dc9f8-488c-11d4-98cf-0004ac5e5097,cn=Users,secAuthority=Default

dn: cn=Users,secAuthority=Default… …

5 Utilities, Scripts and Hints for Managing IBM LDAPDirectory Servers

5.1 IBM LDAP Directory’s Use of DB2

The following Web site contains information on IBM LDAP’s use of DB2:

http://www.ibm.com/software/network/directory/library/

The key to understanding LDAP’s use of DB2 is the Entry ID, or EID. Every LDAP object isidentified in DB2 by its EID. The following lists various commands for finding entries andattributes based on EIDs and finding EIDs based on entries and attributes.

• To find the full name of a table, run the following command:

db2 list tables | grep -i src

38

• To describe a table, run the following command:

db2 describe table ldapdb2.src

• To find the last EID in LDAP, run the following command:

db2 "select * from ldap_next_eid"

• To find a user's EID given a name using the DN, run the following commands:

db2 "select eid from ldap_entry where dn_trunc = 'OU=EPERSON'"db2 "select ldap_entry.eid,dn_trunc from ldap_entry where dn_trunc= 'CN=IVUSER1,OU=EPERSON'"

• To find a user's EID given a name using principalname, run the following command:

db2 "select eid from ldapdb2.principalname where principalname ='IVUSER1'

• To find the user's DN given an EID, enter the following:db2 "select ldap_entry.dn_trunc from ldap_entry where eid = 100"db2 "select ldap_entry.eid,dn_trunc from ldap_entry where eid =100" #also displays the eid

ACL/owner source table search commands are as follows:

• To display the ACL source table for EID 100, run the following command:

db2 "select * from src where eid = 100"

• To display the ACL source table for EIDs between 100 and 110, run the followingcommand:

db2 "select * from src where eid < 110 and eid > 100"

• To find the EIDs that do not have a default ACL inheritance (acl owner is -1) from thefirst 100 entries, run the following command:

db2 "select * from src where aclsrc = -1 and eid < 100 and eid >2"

• To find EIDs in the ACL source table that are not suffixes and do not have a default ACLinheritance (from the first 60 entries), run the following commands:

db2 "select eid from src where aclsrc = -1 and eid > 1 and eid< 60 and eid not in (select ldap_entry.eid from ldap_entry wherepeid = -1)"

db2 "select eid from src where aclsrc = -1 and eid > 1 and eid< 60 and eid in (select deid from ldap_desc where deid != aeid)"

• To find the EIDs in the ACL/owner source table that do not have a default ACL sourceand are descendants of suffix with EID 3, run the following command:

db2 "select src.eid from src,ldap_desc,ldap_entry where aclsrc = -1 and src.eid > 1 and src.eid < 60 and deid = src.eid and aeid=3and peid != -1 and ldap_entry.eid = src.eid"

39

• To find in the ACL/owner source table for the first ten users who are descendants of EID4 (secauthority=default), run the following command:

db2 "select * from src where src.eid in (select deid fromldapdb2.ldap_desc where (aeid= 4 and deid <10 and deid != 4))"

ACL/owner source table update commands are as follows:

• To update the ACL source table for EID 100, run the following command:

db2 "update src set aclsrc = 3 where eid = 100"

• To update the ACL source table for all EIDs that are not suffixes and do not have adefault ACL inheritance (from the first 60 entries), run the following command:

db2 "update src set aclsrc = 3 where eid in (select eid from srcwhere aclsrc = -1 and eid > 1 and eid < 60 and eid not in (selectldap_entry.eid from ldap_entry where peid = -1))"

• To show the ancestors of an EID (from the descendent table), run the followingcommand:

db2 "select * from ldap_desc where deid = 100"

• To find the EID for all suffixes, enter the following commands:

db2 "select ldap_entry.eid from ldap_entry where peid = -1"db2 "select ldap_entry.eid,dn_trunc from ldap_entry where peid = -1"

• To assist in finding the EID for the first user bulk loaded (first non-PD created user), runthe following commands:db2 "select ldap_entry.eid,dn_trunc from ldap_entry,objectclasswhere objectclass.eid < 50 and objectclass.objectclass = 'EPERSON'and objectclass.eid = ldap_entry.eid"

db2 "select * from objectclass where objectclass = 'EPERSON' andeid < 50"

5.2 Spreading the Database Across Multiple Physical Disks

As the database grows, it becomes necessary and desirable to spread the database across multiplephysical disk drives. Better performance can be achieved by spreading entries across multipledisks. In terms of performance, one 20 GB disk is not as good as two 10 GB disks. Thefollowing sections describe how to configure DB2 to spread the ldapdb2 database acrossmultiple disks.

5.2.1 Background Information on LDAP Directory Tablespaces

When the LDAP Directory creates a database for a directory, it uses the DB2 create databasecommand to create a database named ldapdb2 with the default database settings. This means thatthe database has three System Managed Space (SMS) tablespaces.

40

To view these tablespaces, run the following DB2 commands:

db2 connect to ldapdb2db2 list tablespaces

Example output is as follows:

Tablespaces for Current Database

Tablespace ID = 0Name = SYSCATSPACEType = System managed spaceContents = Any dataState = 0x0000

Detailed explanation:Normal

Tablespace ID = 1Name = TEMPSPACE1Type = System managed spaceContents = Temporary dataState = 0x0000


Tablespace ID = 2Name = USERSPACE1Type = System managed spaceContents = Any dataState = 0x0000


The LDAP Directory is stored in the user tablespace (USERSPACE1). By default, there is onlyone container or directory for the user tablespace. To view the contents of the user tablespace,use the following DB2 command:

db2 list tablespace containers for 2

Example output is as follows:

Tablespace Containers for Tablespace 2

Container ID = 0Name =/export/home/ldapdb2/ldapdb2/NODE0000/SQL00001/SQLT0002.0Type = Path

The container or directory that DB2 uses for tablespace 2 is/export/home/ldapdb2/ldapdb2/SQL00001/SQLT0002.0. It contains all the files for the LDAPdirectory tables. The biggest table, ldap_entry, contains the majority of the LDAPdirectory information.

41

5.2.2 Create File Systems and Directories on the Target Disks

The first step in spreading the DB2 database across multiple disk drives is to create and formatthe file systems and directories on the physical disks that the database is to be spread out across.Here are some guidelines:

• Because DB2 spreads the database equally across all directories, it is a good idea to make allof the file systems, directories, or both the same size.

• All directories to be given to DB2 must be completely empty. Note that AIX and Solarisoperating systems create a lost+found directory at the root of any created file system. Toavoid having to delete the lost+found directory, create a subdirectory at the same level of thelost+found directory. For example, create a directory named c for DB2 container.

• The DB2 instance user must have write permission on the created directories. For AIX andSolaris operating systems, the following command gives the proper permissions:

chown ldapdb2 directory name

The following are operating system-specific guidelines:

• For the AIX operating system, create the file system with the Large File Enabled option. Thisis one of the options on the Add a Journaled File System smitty menu.

• For AIX and Solaris operating systems, set the file size limit to unlimited or large enough toallow the creation of a file as large as the file system. On the AIX operating system, the/etc/security/limits file controls system limits and -1 means unlimited. On the Solarisoperating system, the ulimit command controls system limits.

5.2.3 Back Up the Existing Database

To back up the existing database, follow these steps:

1. Stop the LDAP Directory Server process (slapd).2. To close all DB2 connections, enter the following commands:

db2 force applications alldb2 list applications

A message similar to the following is displayed:

SQL1611W No data was returned by Database System Monitor.

3. To initiate the backup process, run the following command:

db2 backup db ldapdb2 to [file system | tape device]

When the database has been backed up successfully, a message similar to the following isdisplayed:

Backup successful. The timestamp for this backup image is :20000420204056

42

Note: Ensure that the backup process was successful before proceeding. The next step destroysthe existing database in order to recreate it. If the backup was not successful, the existing databaseis lost. It is not necessary, but might be a good idea to verify the success of the backup byrestoring to a separate machine.

5.2.4 Perform a Redirected Restore of the Database

A DB2 redirected restore restores the specified database tablespace to multiple containers ordirectories. For the purposes of the following example, assume that the following directories forcontaining tablespace 2 have been created, have the correct permissions to allow write access bythe ldapdb2 instance owner, and are empty.

/disks/1/c/disks/2/c/disks/3/c/disks/4/c/disks/5/c

Follow these steps for a redirected restore:

1. To start the DB2 restore process, run the following command:

db2 restore db ldapdb2 from [location of backup] replaceexisting redirect

Messages similar to the following are displayed:

SQL2539W Warning! Restoring to an existing database that isthe same as the backup image database. The database files willbe deleted.

SQL1277N Restore has detected that one or more tablespacecontainers are inaccessible, or has set their state to'storage must be defined'.

DB20000I The RESTORE DATABASE command completed successfully.

2. To define the containers for tablespace 2, run the following command:

db2 "set tablespace containers for 2 using (path \'/disks/1/c', path '/disks/2/c', path '/disks/3/c', \path '/disks/4/c', path '/disks/5/c')"

Note that this command can become very long if many containers are defined. It can becomeso long as to not fit within the limits of a shell command. In this case, you can put thecommand in a file and run within the current shell using the dot notation. For example,assume that the command is in a file named set_containers.sh. The following command runsit in the current shell:

. set_containers.sh

43

On completion of the DB2 set tablespace command, a message similar to the following isdisplayed:

DB20000I The SET TABLESPACE CONTAINERS command completedsuccessfully.

If you receive the following message, it usually indicates that one of the containers is notempty, or that write permissions is not enabled for the ldapdb2 user:

SQL0298N Bad container path. SQLSTATE=428B2

Note that a newly-created file system on AIX and Solaris contains a directory namedlost+found. You should create a directory at the same level as lost+found to hold thetablespace and reissue the set tablespace command. If you have problems, refer to the DB2documentation. The following files also might be of interest.

<ldapdb2 home dir>/sqllib/Readme/en_US/Release.Notes<ldapdb2 home dir>/sqllib/db2dump/db2diag.log

The db2diag.log file contains some fairly low-level details, which can be difficult tointerpret.

3. Continue the restore to new tablespace containers. This step takes the most time to complete.The time varies depending on the size of the directory. To continue the restore to the newtablespace containers, run the following command:

db2 restore db ldapdb2 continue

If anything goes wrong with the redirected restore, and you want to restart the restore process,it might be necessary to first issue the following command:

db2 restore db ldapdb2 abort

5.3 DB2 Backup and Restore

The fastest way to back up and restore the database is to use DB2 backup and restorecommands. LDAP alternatives, such as db2ldif and ldif2db, are generally much slower incomparison.

A disadvantage to using DB2 backup and restore commands is that the backed up databasecannot be restored across dissimilar hardware platforms. For example, you cannot backup anAIX database and restore it to a Solaris machine. An alternative to DB2 backup and restore isan LDIF export and import. These commands work across dissimilar hardware platforms, butthe process is slower. For more information on the use of these commands, refer to the DB2documentation.

An important advantage of using DB2 backup and restore commands is the preservation of DB2configuration parameters and reorgchk database optimizations in the backed up database. Therestored database has the same tunings as the backed up database. This is not the case withLDAP db2ldif and ldif2db.

44

Be aware that if you restore over an existing database, any tunings on that existing database arelost. Check all DB2 configuration parameters after performing a restore. Also, if you do notknow whether a reorgchk was performed before the database was backed up, run reorgchk afterthe restore. The DB2 commands to perform backup and restore operations are as follows:

db2 force applications alldb2 backup db ldapdb2 to <directory or device>db2 restore db ldapdb2 from <directory or device> replace existing

where <directory or device> is the name of a directory or device where the backup is stored.

The most common error that occurs on a restore is a file permission error. Following are somereasons why this error might occur:

• The DB2 instance owner does not have permission to access the specified directory and file.One way to solve this is to change directory and file ownership to the DB2 instance owner.For example, run the following command:

chown ldapdb2 file or dir

• The backed up database is spread across multiple directories, and those directories do notexist on the target machine of the restore. Spreading the database across multiple directoriesis accomplished with a redirected restore. To solve this problem either create the samedirectories on the target machine or perform a redirected restore to specify the properdirectories on the new machine. If creating the same directories, ensure that the owner of thedirectories is ldapdb2. For more information about redirected restore, see “Spreading theDatabase Across Multiple Physical Disks” on page 39.

Backup and restore operations are required to get an LDAP replica initially synchronized with anLDAP master or anytime master and replica get out of sync. A replica can get out of sync, if it isundefined to the master. In this case, the master does not know about the replica and does notsave updates on a propagation queue for that replica.

If a newly configured master LDAP directory is to be loaded with initial data, you can use bulkloading utilities to speed up the process. This is another case in which the replica is not informedof updates and a manual backup and restore is required to get the replica synchronized with themaster.

5.4 Monitoring LDAP Performance

To monitor performance for IBM SecureWay and Netscape iPlanet Directory, use the ldapsearchcommand as follows:

ldapsearch -h ldap_host -s base -b cn=monitor objectclass=*

where ldap_host is the name of the LDAP host.

This commands returns several statistics. An interesting statistic in terms of monitoringperformance is opsinitiated, which indicates the number of LDAP operations that were initiatedsince the LDAP server started. The ldapsearch command itself accounts for 3 of theseoperations. Therefore, for any given interval, the throughput for that interval is the difference

45

between opsinitiated at the start and end of that interval, less 3 for the ldapsearch divided by thelength of the interval.

Following is a more precise description of this calculation:

tput = (opsinitiated(at stop time) - opsinitiated(at start time) - 3)/ (<stop time> - <start time>)

5.5 Update Performance and SMP Systems

IBM SecureWay Directory serializes updates to the LDAP master server. This means updateperformance does not benefit from having more than one processor on the LDAP master server.Searching performance benefits from multiple processors on the LDAP server.

5.6 Creating Large Numbers of Users

The following table shows the recommended utility to use for creating various numbers of users:

Number of Users toCreate

Utility to Use Initial SizeConsiderations

Up to 10,000 Policy Director’spdadmin command orldapadd

None

10,000 to 100s ofthousands

LDAP bulkload utility See thefollowing text

100s of thousands tomillions

Customized bulk loadingscripts

None

Note that you should not use the bulkload utility if the registry contains more than a few hundredthousand users. bulkload drops and recreates table indexes, which takes progressively longer asmore users exist in the database. A customized bulk loading script would not drop indexes, so isless affected by the existing users in the database.

Disadvantages to using the bulkload utility and the custom bulk loading scripts (as opposed topdadmin or ldapadd) are as follows:

• The LDAP bulkload utility and custom bulk loading scripts require LDAP to be down duringtheir operation.

• The LDAP bulkload utility and custom bulk loading scripts do not handle LDAP replication.Replication must be done manually, for example using DB2 backup and restore commands.

• Bulkload recreates table indexes, which can be slow on incremental loads. Other utilities donot. Creating indexes can take hours if the database is in the millions.

• Bulkload can be difficult to use, but the custom bulk loading scripts are more difficult to use.

The following sections describe the LDAP bulkload utility and the customized bulk loadingscripts.

46

5.7 Using the LDAP Bulkload Utility to Create Policy DirectorUsers

The LDAP bulkload utility is a general purpose tool for creating large numbers of LDAP entries.You can use this utility to create large a number of Policy Director users. Although not typicallyrecommended, bulkload also is useful in creating a large number of groups.

If bulkload is used to create a group with a large number of members, the authentication of thoseusers defined to that group becomes very slow. The ldapadd utility is recommended for creatinglarge numbers of members of a group. Refer to later sections in this guide for more information.Data added through bulkload is not replicated. If replicas are defined, they must be manuallysynchronized. This is best accomplished using DB2 backup and restore commands.

A consideration when using bulkload is the potential for having to update the LDIF descriptionof a user when a new version of Policy Director is installed.

5.7.1 Bulkload and ACLs

Because bulkload ACL support is slow, it is not a good idea to use bulkload options that createACLs. Instead, bulkload users without ACLs can add the ACLs using the script described in the“Fixing up LDAP ACLs” section on page18.

5.7.2 Preparing for the bulkload Utility

The bulkload utility requires a significant amount of temporary disk space. Space is required fora LDIF file, DB2 import tables, and DB2 indexing. The following table shows the requirementsfor the LDIF file and the DB2 import tables assuming 50,000 users or more are being bulkloaded.

Description Approximate disk space requirements (in MB)LDIF file 50DB2 import tables 150 (about 3 times the LDIF requirements)

The following is an explanation of the DB2 indexing space requirements.

DB2 uses Tablespace 1 for temporary space. One use of temporary space is for indexing.Indexing occurs during the bulkload process. The directory defined for tablespace 1 must belarge enough to hold the largest index.

The directory setting for tablespace 1 can be determined by running the following DB2commands. Remember to switch to the DB2 instance owner before running these commands.

db2 connect to ldapdb2db2 list tablespace containers for 1

Typically, the Tablespace 1 directory is located in the following directory on an AIX system:

/home/ldapdb2/ldapdb2/NODE0000/SQL00001/SQLT0001.0

47

To check the capacity of the Tablespace 1 directory on an AIX or Solaris system, enter thefollowing command:

df -k <tablespace 1 directory>

5.7.3 Performing the Bulkload

The bulkload utility is described in detail in the LDAP documentation. Following are examplescripts that perform the bulkload for a specific directory organization. Note that these scriptshave very little error checking and should be used with care. Ensure that you read the scriptsbefore using them. Modifications will be required.

The first script is used to create the LDIF file. Note that this script has a dependency on thepduuidgen utility, which is shipped with Policy Director. Note that you will need to modify thisscript for your particular directory tree structure.

The follow script is based on a tree structure that has users at cn=user,c=us. Items to modify inthis script are the DNs and the secdn attribute.

Place this script in a file named pd_user_ldif_ibm.sh. It is called by this name in the subsequentscript.

# Script to create the LDIF for PD users

start_user=$1end_user=$2

usage(){print "Usage: $0 <start user number> <end user number>"exit -1

}

if [[ "X$1" = "X" ]] || [[ "X$2" = "X" ]] thenusage

fi

if [[ "X`which uuidgen`" = "X" ]] && \[[ "X`which /opt/PolicyDirector/./sbin/pduuidgen`" = "X" ]] then

print "$0 requires uuidgen from DCE package or"print " pduuidgen from the PD 3.8 package"print "The entire DCE or PD product is probably not necessary."print "Try just getting the following files and putting them

in"print "appropriate places: (pd)uuidgen and libdce.so"exit -1

fiif [[ "X`which uuidgen`" != "X" ]] then

uuidgen=uuidgenelse

uuidgen=/opt/PolicyDirector/./sbin/pduuidgenfi

48

# set the password for all users here# Note that setting all passwords to the same value is not a goodsecurity policy.# It is better to initialize passwords to some initial secret onlyknown by the# administrator and user.passwd=pdpass

# set the password last change value here# The following uses April 19, 2001.# It is a good idea to set this to the past and force a passwordchange.secpwdlastchanged=20010419005109.0Z

# iterate through user numbers generating LDIF outputnum_users=$(( $end_user - $start_user + 1 ))user_num=$start_user$uuidgen -n $num_users | while [[ $user_num -le $end_user ]] do

# get the next uuid hereread uuid

#The LDIF for the tuning guide example follows:cat << EOF

dn: cn=PDuser$user_num,c=usobjectclass: inetOrgPersonobjectclass: ePersonobjectclass: organizationalPersonobjectclass: personobjectclass: topcn: PDuser$user_numsn: Perfuserpassword: $passwduid: PDuser$user_num

dn: secAuthority=Default,cn=PDuser$user_num,c=usobjectclass: secUserobjectclass: eUserobjectclass: cimManagedElementobjectclass: topsecauthority: Defaultseclogintype: Default:LDAPsecpwdvalid: trueprincipalname: PDuser$user_numsecuuid: $uuidsechaspolicy: falsesecpwdlastchanged: $secpwdlastchangedsecacctvalid: true

dn: secUUID=$uuid,cn=Users,secAuthority=Defaultobjectclass: secMapobjectclass: topsecdn: cn=PDuser$user_num,c=ussecuuid: $uuid

dn: cn=PolicyData,secAuthority=Default,cn=PDuser$user_num,c=us

49

objectclass: secPolicyDataobjectclass: topcn: PolicyDatasecpwdlastchanged: $secpwdlastchanged

EOF

user_num=$(( $user_num + 1 ))done

This second script calls the script to create the LDIF file and invokes the bulkload utility. Whenrunning this script, do not be alarmed if it appears to hang. The parsing phase of bulkload is alengthy process and grows exponentially with the size of the LDIF file. This is the reason forsplitting up the users in 50,000 user groups.

This script can be placed in a file named user_bulk.sh:

# Script to use the LDAP bulkload utility to create PD users.# It generates an LDIF file and feeds it into bulkload.# Control variables allow the dividing of users into multiple# groups for bulkload purposes. It is recommended that# groups of 50,000 users be used. A continue.user_bulk file is# created and can be used to stop the script at the end of the# current bulkload phase.## Disk requirements:# - 50MB in the current directory for a 50K user LDIF file. Adjust# this for groupings other than 50K.# - 3 times the LDIF space for the ldapimport directory, named in# LDAPIMPORT

# Control variablesstart=1finish=500000increment=50000

export logfile=user_bulk.outrm -f $logfile #remove log file

export ldif_file=users.ldif

# ldapimport directory# IMPORTANT: the directory you name will be deleted and recreated!# Choose it carefully!# Make sure there is enough space for 3 times the LDIF file sizeldapimportdir=/FSperf/ldif/ldapimport

export SCHEMACHECK=NOexport ACLCHECK=NOexport REMOVETMP=NOexport LDAPIMPORT=$ldapimportdir

# clean up the any previous import directoryrm -fr $LDAPIMPORT #uncomment if REMOVETMP=NOmkdir $LDAPIMPORT

50

# Bulkload help:# usage: bulkload [-i inputfile] [-f configfile] [-c <yes|no>] [-a<yes|no>]# -i: LDIF file to load.# -f: configuration file.# -c: create indexes?# -a: check for attribute aliases?

# function to create the LDIF file

do_create_ldif(){echo bulkload start time create user ldif $start $end: \$SECONDS 2>&1 | tee -a $logfilepd_user_ldif_ibm_newschema.sh $start $end >$ldif_fileecho bulkload stop time create user ldif $start $end: \

$SECONDS 2>&1 | tee -a $logfile}

# function to do the bulkload parse phase

do_parse(){export ACTION=PARSEONLY

echo bulkload start time parse users $start $end: \$SECONDS 2>&1 | tee -a $logfile

bulkload -i $ldif_file -a no 2>&1 | tee -a $logfileecho bulkload stop time parse user: $SECONDS 2>&1 | \

tee -a $logfile}

# function to do the bulkload load phase

do_load(){export ACTION=LOADONLY

echo bulkload start time load users $start $end: $SECONDS \2>&1 | tee -a $logfile

bulkload -i $ldif_file -a no 2>&1 | tee -a $logfileecho bulkload stop time load user: $SECONDS 2>&1 | tee -a \

$logfile}

# kill slapd if runningslapd_pid=`ps -ef | grep slapd |

awk '{if ($1 == "ldap")print $2}'ìf [[ "X$slapd_pid" != "X" ]] then

print "$0: killing slapd"kill $slapd_pid

fi

echo $finish >continue.user_bulkexit=0

while [ $exit != 1 ];doend=$(( $start + $increment -1 ))

#Next line is for AIX, and doesn't seem to be needed

51

#rm -f /usr/ldap/etc/bulkload_statusdo_create_ldifdo_parsedo_loadnext=`cat continue.user_bulk | awk '{ print $1 }'`start=$(( $start + $increment ))

if [[ $next -lt $start ]] thenexit=1

fidone

Following are some reminders of items to do after the completion of bulkload:

• After a large bulk load, perform a reorgchk. The bulkload utility does not automaticallyperform this and it is needed for good performance.

• If there are any replicas, manually synchronize them with the updated database. LDAPreplicas are not aware of the changes made by the bulkload utility. DB2 backup and restoreare a good way to perform the manual synchronization.

5.7.4 Adding a Large Number of Members to a Group

To add a large number of members to a group, use the ldapadd utility with increments of 10,000users at a time. The reason for breaking them up into increments is the potential for running outof disk space for the DB2 transaction log, which is another part of the DB2 database that is storedin tablespace 1. The DB2 transaction log is used to back out any changes to an entry in the eventthat a failure occurs before the changes are complete and committed to the database. Thetransaction log contains a record of the progress of the ldapadd.

If more than 10,000 members are added at a time, this log can become very large. If the filesystem for tablespace 1 runs out of space, the ldapmodify fails. It is recommended that youperform a DB2 backup before adding a large group. Running out of disk space can put thedatabase in an unrecoverable state.

Use the following script to create the large group LDIF. Place this in a file namedpd_group_ldif_ibm.sh. It is called by this name in the subsequent script.

# script to create LDIF output for a large PD group

group_name=$1action=$2start_user=$3end_user=$4

usage(){print "Usage: $0 <group name> create|add" \

"[<start user number> <end user number>]"print "The user number paramters are only applicable" \

"to adding users"print "For example:"print " $0 PDLargeGroup create"print " $0 PDLargeGroup add 1 10000"exit -1

}

52

if [[ "X$1" = "X" ]] || [[ "X$2" = "X" ]] thenusage

fi

if [[ $action != "create" ]] && [[ $action != "add" ]] thenusage

fi

if [[ $action = "add" ]] thenif [[ "X$3" = "X" ]] || [[ "X$4" = "X" ]] then

usagefi

elseif [[ "X$3" != "X" ]] || [[ "X$4" != "X" ]] then

usagefi

fi

if [[ $action = "create" ]] then# action is create

if [[ "X`which uuidgen`" = "X" ]] && \[[ "X`which /opt/PolicyDirector/./sbin/pduuidgen`" = "X" ]] then

print "$0 requires uuidgen from DCE package or"print " pduuidgen from the PD 3.8 package"print "The entire DCE or PD product is probably not necessary."print "Try just getting the following files and putting them in"print "appropriate places: (pd)uuidgen and libdce.so"exit -1

fiif [[ "X`which uuidgen`" != "X" ]] then

uuidgen=uuidgenelse

uuidgen=/opt/PolicyDirector/./sbin/pduuidgenfi

# generate LDIF to create the group

# change thisuuid=`$uuidgen`cat << EOF

dn: cn=$group_name,c=usobjectclass: accessGroupobjectclass: topcn: $group_namemember: secAuthority=Default

dn: secAuthority=Default,cn=$group_name,c=usobjectclass: secGroupobjectclass: topsecauthority: Defaultcn: $group_namesecuuid: $uuidsechaspolicy: false

dn: secUUID=$uuid,cn=Groups,secAuthority=Defaultobjectclass: secMapobjectclass: top

secdn: cn=$group_name,c=ussecuuid: $uuidEOF

else

# action is add# generate LDIF to add members to an existing group

cat << EOFn: cn=$group_name,c=uschangetype: modifyadd: member

53

EOF

# create the members# iterate through user numbers generating LDIF outputuser_num=$start_userwhile [[ $user_num -le $end_user ]] do

print "member: cn=PDuser$user_num,c=us"

user_num=$(( $user_num + 1 ))done

fi

This second script calls the script to create the LDIF file and invokes the ldapmodify utility. Thisscript can be placed in a file named group_ldapmod.sh.

# Script to use the ldapadd and ldapmodify utilities to create# and add members to a large PD group. A large PD group# is one that contains many members.## It generates ldif files and feeds them into ldapadd and# ldapmodify. Control variables allow the specifying of# the group name and the dividing of users into multiple chunks# for ldapmodify purposes. It is recommended that no more than# 10,000 users be grouped together in a single ldapmodify.# Otherwise, the transaction log may exceed available disk# space. A continue.group_ldapmod file is created and can be# used to stop the script at the next chunk of users.## disk requirements:# - 300KB is required in the current directory for an ldif file# of 10K users in a group.

# change thisgroup_name=PDLargeGroup

# control variablesstart=1# modify finish# change thisfinish=100000increment=10000

# LDAP admin password# change thisadminpw=ldappw

export logfile=group_ldapmod.outrm -f $logfile #remove log file

export ldif_file=group.ldif

do_create_group(){echo $0 start time, create group ldif: \

$SECONDS 2>&1 | tee -a $logfilepd_group_ldif_ibm.sh $group_name create >$ldif_fileecho $0 stop time, create group ldif: \

$SECONDS 2>&1 | tee -a $logfile

54

echo $0 start time, ldapadd group: $SECONDS \2>&1 | tee -a $logfile

ldapadd -D cn=root -w $adminpw -f $ldif_file 2>&1 \| tee -a $logfile

echo $0 stop time, ldapadd group: $SECONDS 2>&1 \| tee -a $logfile

}

do_add_members(){echo $0 start time, create group members ldif, $start $end: \

$SECONDS 2>&1 | tee -a $logfilepd_group_ldif_ibm.sh $group_name add $start $end >$ldif_fileecho $0 stop time, create group members ldif, $start $end: \

$SECONDS 2>&1 | tee -a $logfileecho $0 start time, ldapmodify group, $start $end: $SECONDS \

2>&1 | tee -a $logfileldapmodify -D cn=root -w $adminpw -f $ldif_file 2>&1 \

| tee -a $logfileecho $0 stop time, ldapmodify group, $start $end: $SECONDS 2>&1

\| tee -a $logfile

}

# want slapd running for ldapadd and ldapmodifyprint "$0: checking for slapd"

slapd_pid=`ps -ef | grep slapd |awk '{if ($1 == "ldap")print $2}'ìf [[ "X$slapd_pid" = "X" ]] then

print "$0: ERROR - slapd must be running for thisscript" \

"to succeed."exit -1

fi

# create the groupdo_create_group

echo $finish >continue.group_ldapmodexit=0

# add members to the group in chunkswhile [ $exit != 1 ];do

end=$(( $start + $increment -1 ))

do_add_members

next=`cat continue.group_ldapmod | awk '{ print $1 }'`start=$(( $start + $increment ))if [[ $next -lt $start ]] then

exit=1fi

done

When you have completed these scripts, perform the same checks as at the end of abulkload utility. Refer to “Performing the Bulkload”on page 47 for details.

55

6 Process Size Limits

On UNIX platforms, some of LDAP and Policy Director tunings in this document results inprocess sizes that exceed the operating system default limits. This section describes how toincrease the operating system limits so that the affected processes do not run out of memory andcrash.

When a process runs out of memory, it often ends. In some cases, it leaves a core dump file, anerror message, or an error log entry. On AIX systems, the system error log may indicate that theprocess ended due to memory allocation failure. Use the errrpt –a | more command to displaythe error log.

6.1 Increasing the Operating System Process Size Limits

On AIX, the process size limits are defined in the /etc/security/limits file. A value of -1indicates there is no limit or unlimited. The names of the limits to increase are data and rss.

On Solaris, the process size limits are defined by the ulimit command. A value of unlimited canbe specified on the command. The names of the limits to increase are data and vmemory.

The easiest setting to use for the process size limits is unlimited. That way, the system processsize limits are enabled to allow the maximum process growth from tuning changes.

6.2 AIX Specific Process Size Limits

In addition to the settings in the /etc/security/limits file, the AIX operating system hasanother limitation on process size. This is the number of data segments that a processuses. By default, a process uses a single 256 MB data segment that is shared for bothdata and stack. You can define a process to use up to 8 additional segments. Eachsegment is 256 MB in size.

6.2.1 Setting the Number of AIX Data Segments to Use (LDR_CNTRL)

In AIX 4.3.3, the number of segments that a process uses for data is controlled by theLDR_CNTRL environment variable. It is defined in the command shell before starting theprocess that is to be affected. For example, enter the following command to define one additionaldata segment:

export LDR_CNTRL=LDR_CNTRL=MAXDATA=0x10000000<start process>unset LDR_CNTRL

It is a good idea to unset the LDR_CNTRL, so that it does not unintentionally affect otherprocesses.

Unlike other environment variables for the LDAP slapd process, LDR_CNTRL has no affect ifspecified in the front-end variable section of the slapd32.conf file.

56

The following table shows the LDR_CNTRL setting and memory increase for various numbers ofdata segments:

Number of Additional DataSegments

LDR_CNTRL Setting Process Memory LimitIncrease

0 (default) Unset 256 MB1 MAXDATA=0x10000000 512 MB2 MAXDATA=0x20000000 768 MB3 MAXDATA=0x30000000 1 MB4 MAXDATA=0x40000000 1.25 GB5 MAXDATA=0x50000000 1.5 GB6 MAXDATA=0x60000000 1.75 GB7 MAXDATA=0x70000000 2 GB8 MAXDATA=0x80000000 2.25 GB

If an invalid setting is used for LDR_CNTRL, it is ignored and the default one segment usage isdefined.

6.2.2 AIX Data Segments and LDAP Process DB2 Connections

Another use of segments in AIX is that they can be used for shared memory communicationbetween processes. The LDAP server process, slapd, makes use of shared memory segments forconnections to DB2. The number of segments that the LDAP process uses for DB2 connectionsis defined by the ibm-slapdDbConnections parameter in the /etc/slapd32.conf file.

The total number of segments used by a process cannot exceed 8. This is the sum of theadditional data segments and the shared memory segments. If the sum is greater than 8, thedifference is made up in reduced DB2 connections. No message is given nor does the LDAPserver fail when the sum of the segment uses exceeds 8. This is typically not a concern, sincecache sizes large enough to make a significant reduction in DB2 connections are not practical.For more information, see “Using LDAP Cache” on page 28.

6.2.3 Verifying Process Data Segment Usage

If the perfagent.tools are installed, the /usr/bin/svmon -P pid command shows the memoryusage of a process. In the output, identify the segments labeled shmat/mmap. Segments with anInuse column of 0 are for data segments that are available for process growth. Segments with anInuse column greater than 1 are for data segments in which the process has already grown.Segments with an Inuse column of 1 are usually found in the slapd process and represent theshared memory segments being used for DB2 connections.

57

7 Troubleshooting

• Problem: When starting sladp, you receive a message similar to the following:

SQL1478W The database has been started but only one buffer pool hasbeen activated. SQLSTATE=01626” on “db2 connect to ldapdb2

Cause: On Solaris, this is typically due to the shmsys:shminfo_shmmax parameter in/etc/system directory not being set high enough to support the DB2 cache.

Solution: Change the value of the shmsys:shminfo_shmmax parameter and reboot thesystem. For more information, see “Increasing the Shared Memory Maximum(shmmax) on Solaris” on page 10.

• Problem: LDAP/DB2 fails to start and there is no message in the LDAP error log. It returnsto the command prompt when attempting to start slapd.

Cause: The DB2 BUFFPAGE parameter is set too high for the available physical memoryand paging space.

Solution: Decrease the BUFFPAGE parameter value.

• Problem: After a DB2 restore, LDAP and DB2 fail to start with a message indicating thatthe database needs to be migrated.

Cause: See “BUFFPAGE Memory Usage Warnings” on page 12 for reasons why thisoccurs.

Solution: Create a script that continuously loops and sets the DB2 BUFFPAGE parameterevery 5 seconds. Run the script during the restore process. Ensure that the bufferpool isdefined with a size of –1 before running the script. For example:

db2 connect to ldapdb2while [ 1 = 1 ];do

sleep 5db2 update database configuration for ldapdb2 usingBUFFPAGE 16000

done

• Problem: The ldapsearch command returns with operations error. Policy Director returnserrors indicating the registry is not available.

Cause: DB2 has forcefully been stopped using db2 terminate and possibly db2stop anddb2start.

Solution: Restart LDAP.

• Problem: ldapsearch commands do not fail, but do not return results when results areexpected.

58

Cause: Authentication parameters on ldapsearch were either not specified or incorrectlyspecified. For example, the −D and −w parameters were not specified.

Solution: Reissue the command with the authentication parameters specified, for example,–D and –w.

• Problem: DB2 runstat fails with the following message:

SQL2310N The utility could not generate statistics.Error "-1024" was returned

Cause: A DB2 connection does not exist.

Solution: Run the db2 connect to ldapdb2 command and try again.

• Problem: A Policy Director server ends unexpectedly, but leaves no message or error logentry.

Cause: The process ran out of memory, due to lack of paging space or system process limits.

Solution: Either increase the machine’s physical memory, the operating system’s pagingspace or increase the system process limits and try again. For information about increasingthe system process limits, see “Process Size Limits” on page 55.

Documents

Tivoli® SecureWay® Policy Director Performance …publib.boulder.ibm.com/.../en_US/PDF/pd38_perf_tune.pdf4 Preface The Tivoli SecureWay Policy Director Performance Tuning Guide provides