IBM Tivoli Directory Server: IBM Tivoli Directory Server...

IBM Tivoli Directory Server

IBM Tivoli Directory Server README

Addendum

Version 5.2

��

Note

Before using this information and the product it supports, read the general information under “Notices,” on page 49.

Twentieth Edition (March 2007)

This edition applies to version 5, release 2, of IBM Tivoli Directory Server and to all subsequent releases and

modifications until otherwise indicated in new editions.

Contents

Preface . . . . . . . . . . . . . . . v

Who should read this book . . . . . . . . . v

Publications . . . . . . . . . . . . . . v

IBM Tivoli Directory Server library . . . . . . v

Related publications . . . . . . . . . . . v

Accessing publications online . . . . . . . vi

Accessibility . . . . . . . . . . . . . . vi

Contacting software support . . . . . . . . . vi

Conventions used in this book . . . . . . . . vii

Typeface conventions . . . . . . . . . . vii

Operating system differences . . . . . . . vii

1.0 Must read known problems . . . . . 1

1.1 Web Administration Tool does not save templates

created with an object class that has no attributes . . 1

1.2 WebSphere Application Server version 5.1 does

not support the Web Administration Tool . . . . . 1

1.3 Installing the embedded version of WebSphere

Application Server - Express . . . . . . . . . 1

Installing the Web Administration Tool into the

embedded version of WebSphere Application

Server - Express . . . . . . . . . . . . 2

1.4 DSML file client throws exception . . . . . . 2

1.5 Nondefault log files need valid path . . . . . 3

1.6 Replication limitations . . . . . . . . . . 3

1.7 Null searches retrieve entries of deleted suffixes . 4

1.8 Fixing an ″SQL0964C Transaction log for database

is full″ error . . . . . . . . . . . . . . 4

1.9 The ldapsearch command with the -h option

gives an error with the DIGEST-MD5 mechanism . . 4

1.10 Number of server threads after migrating from

IBM SecureWay Directory Version 3.2.2 to IBM Tivoli

Directory Server Version 5.2 . . . . . . . . . 5

1.11 Limitations for the bulkload utility . . . . . 5

1.12 Attributes that cannot have associated language

tags . . . . . . . . . . . . . . . . . 5

1.13 After enabling language tags, do not disable

language tags . . . . . . . . . . . . . . 6

1.14 Clarification of information in Installation and

Configuration Guide: creating the DB2 database

owner and database instance owner . . . . . . 6

1.15 DB2 documentation . . . . . . . . . . 7

1.16 Create the key database certificate before setting

up SSL. . . . . . . . . . . . . . . . . 7

1.17 Port settings cannot be changed when

configuring security settings . . . . . . . . . 7

1.18 Remote databases not supported . . . . . . 7

1.19 Before you install: setting kernel parameters for

Solaris and HP-UX . . . . . . . . . . . . 7

1.20 Before you use ldapcfg . . . . . . . . . 8

1.21 Correction to size of attribute cache . . . . . 8

1.22 Corrections to OIDs for sorted search and paged

results features . . . . . . . . . . . . . 9

1.23 Migrating the Web Administration Tool and

upgrading the embedded version of WebSphere

Application Server - Express . . . . . . . . . 9

1.24 Network Information Service (NIS) environment

not supported . . . . . . . . . . . . . . 9

1.25 Default value of ibm-slapdPWEncryption . . . 9

1.26 Migrating from SecureWay Directory 3.2.2:

correction to documentation . . . . . . . . . 9

1.27 Correction to C-Client SDK Programming

Reference: Must free memory used by res . . . . 10

1.28 Adding ibm-slapdFrontEnd objectclass to

configuration file after migration . . . . . . . 10

1.29 Correction to Administration Guide: Missing

word in IP address description . . . . . . . . 10

1.30 Correction to Server Plug-ins Reference: Audit

plug-ins section . . . . . . . . . . . . . 10

Audit plug-ins . . . . . . . . . . . . 10

1.31 Correction to Server Plug-ins Reference:

Appendix C. Plug-in examples . . . . . . . . 15

1.32 Migrating from IBM Directory Server version

4.1 or 5.1 for Windows: correction to documentation . 15

1.33 Upgrading DB2: invalid link in documentation 15

1.34 Incorrect log paths in documentation . . . . 15

1.35 On-line backup and restore not supported . . 16

1.36 Correction to ldapdiff command . . . . . . 16

Synopsis . . . . . . . . . . . . . . 16

Description . . . . . . . . . . . . . 17

Options . . . . . . . . . . . . . . . 17

Examples . . . . . . . . . . . . . . 19

SSL examples . . . . . . . . . . . . . 19

Notes . . . . . . . . . . . . . . . 20

Diagnostics . . . . . . . . . . . . . 20

2.0 Must read known problems -

platform specific . . . . . . . . . . 21

2.1 For AIX only . . . . . . . . . . . . . 21

2.1.1 Locales for InstallShield GUI panels . . . 21

2.1.2 Error code -1 at startup . . . . . . . . 21

2.1.3 Problem with MALLOCTYPE=buckets . . 21

2.1.4 Migrating from IBM Directory Server 4.1 or

5.1 with DB2 7.2 on AIX . . . . . . . . . 21

2.1.5 Correction to Server README . . . . . 26

2.1.6 Support on AIX 5.3 . . . . . . . . . 26

2.1.7 Installing the SSL client, server, or Web

Administration Tool . . . . . . . . . . 27

2.2 For Windows only . . . . . . . . . . . 27

2.2.1 Setting LANG and LC_ALL system

environment variables for nonEnglish

InstallShield GUI installation . . . . . . . 27

2.2.2 Certain UTF-8 supplementary characters do

not display correctly . . . . . . . . . . 27

2.2.3 Difficulties encountered using the Web

Administration GUI console on the Windows

2003 platform . . . . . . . . . . . . . 28

iii

| | | | | | | | | | | | | | | |

2.2.4 Error message using ldapxcfg after

migrating from IBM SecureWay Directory Version

3.2.2 to IBM Tivoli Directory Server Version 5.2 . 28

2.2.5 Use the command line to uninstall IBM

Directory Server on the Windows 2003 platform . 29

2.2.6 Configuration utilities do not work with

DB2 7.2 Fixpack 10 . . . . . . . . . . . 29

2.2.7 GSKit and DB2 installation might fail on

Windows . . . . . . . . . . . . . . 29

2.2.8 Communications error: Exceeding 64

connections/OCH . . . . . . . . . . . 29

2.2.9 Starting IBM Tivoli Directory Server at

operating system startup on Windows platforms . 30

2.2.10 DB2 8.1 Fix Pack 7 not supported on

Windows systems . . . . . . . . . . . 30

2.3 For Solaris Operating Environment Software

only . . . . . . . . . . . . . . . . . 30

2.3.1 Memory requirements for running with DB2

8.1 on Solaris 9 . . . . . . . . . . . . 30

2.3.2 The uninstall archive file requires extra

space . . . . . . . . . . . . . . . 30

2.3.3 The InstallShield GUI requires 350 MB for

the var/tmp directory . . . . . . . . . . 31

2.3.4 Requirements for GSKit on Solaris 9 . . . 31

2.3.5 Native installation under a directory other

than /opt . . . . . . . . . . . . . . 31

2.4 For Linux only . . . . . . . . . . . . 31

2.4.1 CD-ROM does not eject from Linux

machines . . . . . . . . . . . . . . 31

2.4.2 Web Administration Tool is not supported

on Red Hat 3.0 . . . . . . . . . . . . 32

2.4.3 Configuration needs to be run from the

/tmp directory . . . . . . . . . . . . 32

2.4.4 Installation fails on Linux if a group name

ends in "ldap" . . . . . . . . . . . . 32

2.4.5 Additional requirements for Red Hat

Enterprise Linux 3.0 . . . . . . . . . . 33

2.4.6 Additional requirements for SuSE Linux

Enterprise Server 8 . . . . . . . . . . . 33

2.4.7 Unable to compile IBM Tivoli Directory

Server sample programs on Red Hat EL3 . . . 33

2.4.8 Update to supported Linux versions . . . 33

2.4.9 Uninstallation of Web Administration Tool

package fails if ldap user and group do not exist . 34

2.5 For HP-UX only . . . . . . . . . . . 34

2.5.1 Mounting and unmounting the CD . . . . 35

2.5.2 Corrections to installing GSKit . . . . . 36

2.5.3 DB2 installation fails . . . . . . . . 36

2.5.4 Configuration on HP-UX 11i . . . . . . 36

2.5.5 Directory server fails on HP-UX 11i with

DB2 8.1 with FixPak 7, 7a, 8, or 9 . . . . . . 36

3.0 General information, hints and tips 39

3.1 Migrating a replicating environment from 3.2.x

to 5.2 . . . . . . . . . . . . . . . . 39

3.2 Configuring the database in a location other

than /home when /home is an NFS mount . . . 40

3.3 Correction to command in Installation and

Configuration Guide . . . . . . . . . . . 42

3.4 Nonblocking replication . . . . . . . . . 42

3.5 Miscellaneous API information is incorrect . . . 43

LogType enumeration . . . . . . . . . . 43

LDAPAPIInfo . . . . . . . . . . . . . 43

ldap_err2string() . . . . . . . . . . . . 43

ldap_pwdpolicy_err2string() . . . . . . . . 43

ldap_ssl_environment_init() . . . . . . . . 44

ldap_ssl_init() . . . . . . . . . . . . 44

ldap_add_control() . . . . . . . . . . . 44

ldap_set_locale() . . . . . . . . . . . . 44

3.6 Running migration on UNIX-based platforms . . 44

3.7 Replicating Password Policy Attributes . . . . 44

3.8 Increasing secondary log files for password

policy attribute pwdchangedtime . . . . . . . 45

3.9 Moving data to IBM Tivoli Directory Server 5.2

from a previous release without using a migration

utility . . . . . . . . . . . . . . . . 46

3.10 Subset of server management tasks displayed

in Web Administration Tool . . . . . . . . . 46

3.11 Note about using reorg for database tuning . . 47

3.12 Correction to Tuning Guide: DB2 RUNSTATS

command . . . . . . . . . . . . . . . 47

Appendix. Notices . . . . . . . . . . 49

Trademarks . . . . . . . . . . . . . . 50

iv IBM Tivoli Directory Server: IBM Tivoli Directory Server README Addendum

Preface

This document contains the information that you need to administer the IBM Tivoli

Directory Server.

Who should read this book

This document is intended for system administrators.

Publications

Read the descriptions of the IBM Tivoli Directory Server library to determine

which publications you might find helpful. After you determine the publications

you need, see “Accessing publications online” on page vi.

IBM Tivoli Directory Server library

The publications in the IBM Tivoli Directory Server library are:

IBM Tivoli Directory Server Version 5.2 Readme Addendum

Go to the Tivoli Software Library Web site to access the IBM Tivoli Directory

Server Version 5.2 Readme Addendum, which contains important information

that was not included in the Readme files. See “Accessing publications

online” on page vi for information about accessing online publications.

IBM Tivoli Directory Server Version 5.2 Client Readme

Contains last-minute information about the client.

IBM Tivoli Directory Server Version 5.2 Server Readme

Contains last-minute information about the server.

IBM Tivoli Directory Server Version 5.2 Web Administration Tool Readme

Contains last-minute information about the Web Administration Tool. This

Readme is available from the main panel of the Web Administration Tool.

IBM Tivoli Directory Server Version 5.2 Installation and Configuration Guide

Contains complete information for installing the IBM Tivoli Directory

Server client, server, and Web Administration Tool. Includes information

about migrating from a previous version of IBM Tivoli Directory Server or

SecureWay Directory.

IBM Tivoli Directory Server Version 5.2 Tuning Guide

Contains information about tuning the server for better performance.

IBM Tivoli Directory Server Version 5.2 Administration Guide

Contains instructions for performing administrator tasks through the Web

Administration Tool or the command line.

IBM Tivoli Directory Server Version 5.2 Plug-ins Reference

Contains information about writing server plug-ins.

IBM Tivoli Directory Server Version 5.2 C-Client SDK Programming Reference

Contains information about writing LDAP client applications.

Related publications

Information related to the IBM Tivoli Directory Server is available in the following

publications:

v

http://www.ibm.com/software/tivoli/library/

v IBM Tivoli Directory Server Version 5.2 uses the Java Naming and Directory

Interface (JNDI) client from Sun Microsystems. For information about the JNDI

client, refer to the Java Naming and Directory Interface™ 1.2.1 Specification on the

Sun Microsystems Web site at http://java.sun.com/products/jndi/1.2/javadoc/index.html.

v The Tivoli Software Library provides a variety of Tivoli publications such as

white papers, datasheets, demonstrations, redbooks, and announcement letters.

The Tivoli Software Library is available on the Web at: http://www.ibm.com/software/tivoli/library/

v The Tivoli Software Glossary includes definitions for many of the technical terms

related to Tivoli software. The Tivoli Software Glossary is available, in English

only, from the Glossary link on the left side of the Tivoli Software Library Web

page http://www.ibm.com/software/tivoli/library/

Accessing publications online

The publications for this product are available online in Portable Document Format

(PDF) or Hypertext Markup Language (HTML) format, or both in the Tivoli

software library: http://www.ibm.com/software/tivoli/library.

To locate product publications in the library, click the Product manuals link on the

left side of the library page. Then, locate and click the name of the product on the

Tivoli software information center page.

Information is organized by product and includes READMEs, installation guides,

user’s guides, administrator’s guides, and developer’s references.

Note: To ensure proper printing of PDF publications, select the Fit to page check

box in the Adobe Acrobat Print window (which is available when you click

File → Print).

Accessibility

Accessibility features help a user who has a physical disability, such as restricted

mobility or limited vision, to use software products successfully. With this product,

you can use assistive technologies to hear and navigate the interface. After

installation, you also can use the keyboard instead of the mouse to operate all

features of the graphical user interface.

Contacting software support

Before contacting IBM Tivoli Software support with a problem, refer to Tivoli

Software support Web site at:

http://www.ibm.com/software/sysmgmt/products/support/

If you need additional help, contact software support by using the methods

described in the IBM Software Support Guide at the following Web site:

http://techsupport.services.ibm.com/guides/handbook.html

The guide provides the following information:

v Registration and eligibility requirements for receiving support

v Telephone numbers and e-mail addresses, depending on the country in which

you are located

vi IBM Tivoli Directory Server: IBM Tivoli Directory Server README Addendum

http://java.sun.com/products/jndi/1.2/javadoc/index.html

http://java.sun.com/products/jndi/1.2/javadoc/index.html





http://www.ibm.com/software/sysmgmt/products/support/

http://techsupport.services.ibm.com/guides/handbook.html

v A list of information you should gather before contacting customer support

Conventions used in this book

This reference uses several conventions for special terms and actions and for

operating system-dependent commands and paths.

Typeface conventions

The following typeface conventions are used in this reference:

Bold Lowercase commands or mixed case commands that are difficult to

distinguish from surrounding text, keywords, parameters, options, names

of Java classes, and objects are in bold.

Italic Titles of publications, and special words or phrases that are emphasized

are in italic.

<Italic>

Variables are set off with < > and are in <italic>.

Monospace

Code examples, command lines, screen output, file and directory names

that are difficult to distinguish from surrounding text, system messages,

text that the user must type, and values for arguments or command

options are in monospace.

Operating system differences

This book uses the UNIX convention for specifying environment variables and for

directory notation. When using the Windows command line, replace $variable with

%variable% for environment variables and replace each forward slash (/) with a

backslash (\) in directory paths. If you are using the bash shell on a Windows

system, you can use the UNIX conventions.

Preface vii

viii IBM Tivoli Directory Server: IBM Tivoli Directory Server README Addendum

1.0 Must read known problems

This file contains information about changes and fixes that occurred after the

product documentation had been translated. This file is in English only.

The following information applies cross-platform.

1.1 Web Administration Tool does not save templates created with an

object class that has no attributes

You can create object classes for the IBM® Directory Server Version 5.2 that have no

MAY or MUST attributes. Such object classes can be used to create entries using

other auxiliary object classes. However, if you attempt to create a template through

the Web Administration Tool using such an object class, you are unable to save the

template.

Note: All of the object classes included with the IBM Directory Server Version 5.2

contain MAY and MUST attributes. They can be used to create templates.

1.2 WebSphere Application Server version 5.1 does not support the

Web Administration Tool

The IBM Tivoli® Directory Server version 5.2 Web Administration Tool is supported

by WebSphere® Application Server version 5.0 and any 5.0.x versions. It is not

supported by the WebSphere Application Server version 5.1.

1.3 Installing the embedded version of WebSphere Application Server -

Express

In the Installation and Configuration Guide, Appendix D, in the sections called

″Installing the embedded version of WebSphere Application Server - Express″ and

″Installing the Web Administration Tool into the embedded version of WebSphere

Application Server - Express,″ some of the instructions are incorrect. Use the

following procedures instead.

1. After you download and unzip (or untar) the IBM Directory Server zip or tar

file, change directories to the directory where you expanded the file.

2. Type the following command at a command prompt:

v On Windows® systems:

install.bat -installRoot embWASE_installpath -hostName localhost

v On AIX®, Linux, Solaris, and HP-UX systems:

install.sh -installRoot embWASE_installpath -hostName localhost

where embWASE_installpath is the directory where you are installing the

embedded version of WebSphere Application Server - Express. By convention,

this directory is the appsrv subdirectory of the directory where IBM Tivoli

Directory Server is installed, but you can use any directory.

Install the Web Administration Tool, using either the InstallShield GUI or an

operating system utility for your operating system. After installing the Web

1

Administration Tool, copy the Web Administration Tool to the embedded

version of WebSphere Application Server - Express directory by using the

following commands:

v On Windows systems:

md embWASE_installpath\installableApps\

copy installpath\idstools\IDSWebApp.war installpath\appsrv\installableApps\

v On AIX, Linux, Solaris, and HP-UX systems:

mkdir embWASE_installpath/installableApps/

cp installpath/idstools/IDSWebApp.war installpath/appsrv/installableApps/

where

v embWASE_installpath is the directory where you are installing the embedded

version of WebSphere Application Server - Express. By convention, this

directory is the appsrv subdirectory of the directory where IBM Tivoli

Directory Server is installed, but you can use any directory.

v installpath is the directory where IBM Tivoli Directory Server is installed.

Installing the Web Administration Tool into the embedded

version of WebSphere Application Server - Express

Install the Web Administration Tool into the embedded version of WebSphere

Application Server - Express by using the following command:

v On Windows systems:

"embWASE_installpath\bin\wsadmin.bat" -conntype NONE -c "$AdminApp

install {embWASE_installpath\installableApps\IDSWebApp.war}

{-configroot \"embWASE_installpath\config\"

-node DefaultNode -usedefaultbindings -nodeployejb -appname IDSWebApp.war

-contextroot \"IDSWebApp\"}"

Note: Type the command on one line.

v On AIX, Linux, Solaris, and HP-UX systems:

"embWASE_installpath/bin/wsadmin.sh" -conntype NONE -c "\$AdminApp

install {embWASE_installpath/installableApps/IDSWebApp.war}

{-configroot \"embWASE_installpath/config\"

-node DefaultNode -usedefaultbindings -nodeployejb -appname IDSWebApp.war

-contextroot \"IDSWebApp\"}"

embWASE_installpath is the directory where you are installing the embedded

version of WebSphere Application Server - Express. By convention, this directory is

the appsrv subdirectory of the directory where IBM Tivoli Directory Server is

installed, but you can use any directory.

Note: If you install the Web Administration Tool and the embedded version of

WebSphere Application Server - Express through the InstallShield GUI, these

commands are run automatically.

1.4 DSML file client throws exception

The DSML file client throws the following exception when it is set up to

communicate using SSL and the user tries to connect to an LDAP server that does

not use SSL.

SSL IS ON

javax.naming.CommunicationException: 9.182.21.228:389. Root exception is javax.

net.ssl.SSLProtocolException: end of file

at com.ibm.jsse.bd.a(Unknown Source)

at com.ibm.jsse.b.a(Unknown Source)

at com.ibm.jsse.b.write(Unknown Source)

2 IBM Tivoli Directory Server: IBM Tivoli Directory Server README Addendum

at com.sun.jndi.ldap.Connection.<init>(Connection.java:226)

at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:127)

at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2398)

at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:258)

at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:91)

at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:674)

at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:255)

at javax.naming.InitialContext.init(InitialContext.java:231)

at javax.naming.InitialContext.<init>(InitialContext.java:207)

at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:92)

at com.ibm.ldap.dsml.DsmlRequest.processRequests(DsmlRequest.java:767)

at com.ibm.ldap.dsml.DsmlServer.processDsmlRequest(DsmlServer.java:253)




at com.ibm.ldap.dsmlClient.DsmlFileClient.main(DsmlFileClient.java:203)

The exception is not fatal and the output XML file is generated.

1.5 Nondefault log files need valid path

If you want to store your log files in a nondefault path, you must ensure that the

path is valid. Otherwise you need to create the directory before you can configure

the log files.

1.6 Replication limitations

This release supports subtree replication. Replication can be configured differently

on individual subtrees (for individual replication contexts). This enables a single

server to play different roles for different parts of the Directory Information Tree

(DIT). For example, one subtree on a server could be a leaf replica (consumer), and

another subtree could be a master (supplier) in the topology.

Directory updates, such as those to schema and password policy, do not belong to

any replication context. They are replicated to all consumers based on all the

replication contexts defined on the server. However, if the server contains one

subtree for which it is a master, and another subtree for which it is a replica, the

replication role to be assumed for schema or password policy updates cannot be

determined. Because of this mixed replication mode in the topology, these types of

global updates, schema and password policy, cannot be made. A referral result is

returned causing a replication loop among the replicas and masters. Consequently,

the client is referred between servers until the maximum referral limit is exceeded.

If an administration control is used, an unwilling to perform result is returned.

To avoid this situation, do not assign mixed roles to a single server. Ensure that the

server performs the same server role for each of its subtrees. That is, if a server is a

master for most of its subtrees, it is a master for all of its subtrees. Conversely, if

the server acts as a replica for most of its subtree, it acts as a replica for all of its

subtrees.

Another solution, depending on your situation, is to make both of the subtrees

peer-masters on each of the servers. The master that received the entry, updates the

other peer servers. As peers, the servers receive the entry update but do not

replicate it.

1.0 Must read known problems 3

1.7 Null searches retrieve entries of deleted suffixes

A null search ldapsearch —s sub —b "" objectclass=* returns all the entries found

in the database. If you have deleted a suffix without first removing its entries from

the database, those entries are returned by the null search even though the suffix

no longer exists.

1.8 Fixing an ″SQL0964C Transaction log for database is full″ error

If you are loading a file that contains a large number of entries, you might receive

the following error message:

SQL0964C The transaction log for the database is full.

SQLSTATE=57011

Use the following procedure to increase the size of the transaction log:

1. Determine the current log file size setting by issuing the command:

db2 get db config for ldapdb2 | grep -i logfilsiz

2. Increase the size of the log file size setting by issuing the command:

db2 udpate db cfg for ldapdb2 using LOGFILSIZ <new value>

3. Stop the slapd process.

4. Issue the command:

db2 force applications all

5. Restart slapd process.

Alternately, you can use the bulkload utility to load files with large amounts of

entries.

1.9 The ldapsearch command with the -h option gives an error with the

DIGEST-MD5 mechanism

The DIGEST-MD5 SASL bind mechanism requires that the client be able to resolve

the fully-qualified host name of the server. If the client cannot resolve the server’s

fully-qualified hostname the bind fails with an LDAP_PROTOCOL_ERROR. To

correctly resolve the host name, you might need to make system changes or make

DNS configuration changes, such as enabling reverse DNS mapping.

For example, UNIX® systems have lines in the /etc/hosts file with the syntax:

<IP address><fully qualified distinguished name><alias>

This syntax is used to define the local hostname to the IP address mappings.

If the syntax is something like:

127.0.0.1 localhost

when localhost is resolved, it is seen as the fully qualified distinguished name of

the system. This causes DIGEST-MD5 to fail.

For the DIGEST-MD5 mechanism to work correctly, the syntax must be something

like:

127.0.0.1 ldap.myserver.mycompany.com localhost

The syntax of the line is now such that ldap.myserver.mycompany.com is a valid

fully qualified distinguished name for the localhost system.


1.10 Number of server threads after migrating from IBM SecureWay

Directory Version 3.2.2 to IBM Tivoli Directory Server Version 5.2

In the IBM SecureWay® Directory Version 3.2.2, the default number of server

threads set by the ibm-slapdDBConnections attribute in the slapd32.conf file is 9.

In the IBM Tivoli Directory Server Version 5.2, the default number of server

threads set by the ibm-slapdDBConnections attribute in the ibmslapd.conf file is 15.

The migration process does not change the value specified in version 3.2.2 for the

ibm-slapdDBConnections attribute to the version 5.2 default value of 15. This is not

done so that any optimization that you have done is maintained. For example, if

you had set your ibm-slapdDBConnections attribute in version 3.2.2 to 20, it

remains 20 after the migration to 5.2.

If you had set the value of ibm-slapdDBConnections in version 3.2.2 to a number

less than 15 or used the default setting of 9, you might want to increase that value

to 15 in the ibmslapd.conf file of version 5.2.

1.11 Limitations for the bulkload utility

If you use the bulkload utility to load an LDIF file that contains ACLs on entries

that have a large number of descendant entries, it might seem that bulkload

successfully loaded the data. However, the ACLs might not be propagated to the

descendant entries. This situation occurs because the DB2® transaction log fills up

during ACL processing after the entries have all been loaded. When the transaction

log runs out of space, ACL propagation ceases. This problem is more likely to

occur, if you are using DB2 v7.x . For DB2 v8.1, the default transaction log is

larger, so it can handle larger LDIF files. You can increase the size of the DB2

transaction log to enable bulkload to handle larger LDIF files.

Use the following procedure to increase the size of the transaction log:

1. Determine the current log file size setting by issuing the command:

db2 get db config for <db_name> | grep -i logfilsiz

2. Increase the size of the log file size setting by issuing the command:

db2 udpate db cfg for <db_name> using LOGFILSIZ <new_larger_size>

3. Stop the slapd process.

4. Issue the command:

db2 force applications all

5. Restart slapd process.

If you need to load more than 500,000 entries using the bulkload utility, divide the

LDIF file into multiple files. Each file should contain less than 500,000 entries. Use

the bulkload utility to load each file separately. After loading each file perform a

db2 database backup.

1.12 Attributes that cannot have associated language tags

The following attributes cannot have language tags associated with them:

v objectclass

v member

v uniquemember

v memberURL

v ibm-memberGroup


v userpassword

v secretkey

v ref

1.13 After enabling language tags, do not disable language tags

After enabling the language tag feature, if you associate language tags with the

attributes of an entry, the server returns the entry with the language tags. This

occurs even if you later disable the language tag feature. Because the behavior of

the server might not be what the application is expecting, to avoid potential

problems, do not disable the language tag feature after it has been enabled.

1.14 Clarification of information in Installation and Configuration

Guide: creating the DB2 database owner and database instance owner

The following information is a clarification to the section called ″Before you

configure: creating the DB2 database owner and database instance owner″ in the

Installation and Configuration Guide.

Before you configure the database, you must create a user ID for the user who will

own the DB2 database (the database administrator ID). You will provide this user

ID during configuration when you configure the database. In addition:

v This user ID will own the database instance.

v The database instance will be created in the user’s home directory.

v The instance name will be the same as the user ID.

Note: If you want a database instance name that is different from the user ID, you

must use the ldapcfg command with the -t option to configure the database.

See ″Configuring the database″ for information.

The user ID can be no longer than 8 characters. In addition:

v On Windows platforms, the user must be a member of the Administrators

group.

v On UNIX platforms:

– The user must have a home directory and must be the owner of the home

directory. The primary group ID of this user should group own the user’s

home directory.

For example, in the case of a user named ldapdb2 whose primary group is

dbsysadm, the home directory of ldapdb2 should be owned by user ldapdb2

and group dbsysadm.

DB2 does not allow instance creation if the user ID belongs to general groups

(for example, if the user’s primary group on UNIX is users or staff). It is

better to have a separate group ID for the purpose of database administration.

– The user root must be a member of the user’s primary group. If root is not a

member of this group, add root as a member of the group. (In the example,

the root user should be part of the dbsysadm group.)

– The user’s home directory should be write accessible for the primary group.

– The user’s login shell should be the Korn shell script (/usr/bin/ksh).

– The user’s password must be set correctly and ready to use. For example, the

password cannot be expired or waiting for a first-time validation of any kind.

(The best way to verify that the password is correctly set is to telnet to the

same computer and successfully log in with that user ID and password.)


– When configuring the database, it is not necessary, but customary, to specify

the home directory of the user ID as the database location. However, if you

specify some other location, the user’s home directory still must have 3 to 4

MB of space available. This is because DB2 creates links and adds files into

the home directory of the instance owner (that is, the User) even though the

database itself is elsewhere. If you do not have enough space in the home

directory, you can either create enough space or specify another directory as

the home directory.

1.15 DB2 documentation

The DB2 documentation library is located at http://www.ibm.com/software/data/db2/library/.

1.16 Create the key database certificate before setting up SSL.

Before setting up SSL communications on your server, you must use the GSKit

utility, gsk6ikm, to create the necessary certificates. See ″Using gsk7ikm″ and

″Secure Sockets Layer″ in the IBM Directory Server Version 5.2 Administration Guide.

1.17 Port settings cannot be changed when configuring security

settings

In chapter 10 of the IBM Tivoli Directory Server version 5.2 Administration Guide in

the section ″Configuring security settings″ the Web Administration task step 3

instructs you to specify the secure port number to use. The port number can no

longer be specified in this task. Omit step 3. If you want to change port numbers

see, ″Chapter 7. Setting up the console″ and ″Chapter 9. Setting server properties″.

1.18 Remote databases not supported

IBM Tivoli Directory Server does not support remote databases.

1.19 Before you install: setting kernel parameters for Solaris and

HP-UX

On Solaris and HP-UX, you might need to update kernel parameters in the

/etc/system file before you configure the database.

With the HP-UX and Solaris versions of DB2, version 8.1, a utility called db2osconf

is provided. The db2osconf utility determines the correct kernel settings for your

computer.

On the Solaris Operating Environment, there are two versions of the db2osconf

utility: one for 64-bit kernels and one for 32-bit kernels. The utility must be run as

root or with the group sys because it accesses the following special devices

(accesses are read-only):

crw-r----- 1 root sys 13, 1 Jul 19 18:06 /dev/kmem

crw-rw-rw- 1 root sys 72, 0 Feb 19 1999 /dev/ksyms

crw-r----- 1 root sys 13, 0 Feb 19 1999 /dev/mem

1. To run the utility, type db2osconf at a command prompt.

Note: To view the usage information for the utility, type db2osconf -h. The

following information is displayed:


http://www.ibm.com/software/data/db2/library/


Usage:

-c # Client only

-f # Compare to current

-h # Help screen

-l # List current

-m <mem in GB> # Specify memory in GB

-n <num CPUs> # Specify number of CPUs

-p <perf level> # Msg Q performance level (0-3)

-s <scale factor> # Scale factor (1-3)

-t <scale factor> # Number of threads

2. Use the output from the db2osconf utility to update the /etc/system file.

The following is an example of output:

set msgsys:msginfo_msgmax = 65535

set msgsys:msginfo_msgmnb = 65535

set msgsys:msginfo_msgmni = 1280

set msgsys:msginfo_msgtql = 1280

set semsys:seminfo_semmni = 1536

set semsys:seminfo_semmns = 3226

set semsys:seminfo_semmnu = 1536

set semsys:seminfo_semume = 240

set shmsys:shminfo_shmmax = 466086297

set shmsys:shminfo_shmmni = 1536

set shmsys:shminfo_shmseg = 240

Total kernel space for IPC:

0.21MB (shm) + 1.47MB (sem) + 1.22MB (msg) == 2.91MB (total)

End suggestions.

Note: If you do not use the -l or -f switches, the db2osconf utility displays the

kernel parameters using the syntax of the /etc/system file. To prevent

errors, you can cut and paste this output directly into the /etc/system

file.

For more information, see the DB2 documentation.

If you make updates to your system configuration, run the utility again.

On DB2 version 7 on Solaris, look in the /opt/IBM/db2/Vdb2version/cfg

directory for files named kernel.param.memory_size. These files contain

information about updating kernel parameters with appropriate values for

computers with different amounts of memory.

1.20 Before you use ldapcfg

Before you use ldapcfg:

v On a UNIX system, log in as root.

v On a Windows system, log on as any user in the Administrators group.

1.21 Correction to size of attribute cache

The instructions in the IBM Tivoli Directory Server Administration Guide version 5.2

for setting the attribute cache and the changelog cache incorrectly lists the default

cache size as 16384000 kilobytes (16 KB). The correct default size is 16384 kilobytes

(16 MB) for both the attribute cache and the changelog cache.

Consequently, command line example is also incorrect. The correct entry is:



add: ibm-slapdcachedattributesize

ibm-slapdcachedattributesize: 16384

1.22 Corrections to OIDs for sorted search and paged results features

The IBM Tivoli Directory Server version 5.2 Administration Guide and the IBM Tivoli

Directory Server version 5.2 C-Client SDK Programming Reference incorrectly list the

OID values for the sorted search and paged results features. The OID values are

switched. The correct OID values for these two features are:

Paged Results: 1.2.840.113556.1.4.319

Sorted Search: 1.2.840.113556.1.4.473

1.23 Migrating the Web Administration Tool and upgrading the

embedded version of WebSphere Application Server - Express

The following statement in ″Migrating the Web Administration Tool and upgrading

the embedded version of WebSphere Application Server - Express″ in the IBM

Tivoli Directory Server Installation and Configuration Guide Version 5.2 is incorrect:

1. Download fix pack 2 for the embedded version of WebSphere Application

Server - Express V5.0 from the Web site where you downloaded IBM Tivoli

Directory Server.

This statement is incorrect. You must contact IBM Support to obtain the fix pack 2

for the embedded version of WebSphere Application Server - Express V5.0.

1.24 Network Information Service (NIS) environment not supported

When you use IBM Tivoli Directory Server in a Network Information Service (NIS)

environment on any operating system platform, the ldapcfg command does not

work correctly. This setup is not supported. However, if you want to use NIS with

IBM Tivoli Directory Server, see the Technote called ″Custom installation and

configuration for Solaris 8.0 operating system in a NIS environment″ for

information about completing the configuration. Technotes can be found at the

following Web address: http://www.ibm.com/software/sysmgmt/products/support/IBMDirectoryServer.html.

1.25 Default value of ibm-slapdPWEncryption

The default value for the ibm-slapdPWEncryption attribute in the Installation and

Configuration Guide is incorrect. The default value for this attribute is imask.

1.26 Migrating from SecureWay Directory 3.2.2: correction to

documentation

If you are migrating from SecureWay Directory 3.2.2, use the information in the

Migration chapter of the Installation and Configuration Guide. However, the bulkload

command syntax (in the post-installation steps) is incorrect. The syntax of the

command should be:

bulkload -i ldiffile -c <yes|no> -d


http://www.ibm.com/software/sysmgmt/products/support/IBMDirectoryServer.html


1.27 Correction to C-Client SDK Programming Reference: Must free

memory used by res

In the C-Client SDK Programming Reference, there is a correction to the

LDAP_SEARCH API category (see ″Chapter 3. API Categories″).

In the Usage section for LDAP_SEARCH, the last sentence of the fifth paragraph

currently reads:

″The results contained in res must be freed when no longer in use by calling

ldap_msgfree().″

This sentence should instead say:

″The memory allocated for res must be freed when no longer in use, whether or

not the operation was successful, by calling ldap_msgfree().″

1.28 Adding ibm-slapdFrontEnd objectclass to configuration file after

migration

If you migrated from IBM SecureWay Directory 3.2.x, you might need to manually

add the ibm-slapdFrontEnd objectclass to the ″cn=Front End, cn=Configuration″

stanza of the ibmslapd.conf file. This might be necessary even if you migrated to

IBM Directory Server 4.1 before migrating to IBM Tivoli Directory Server 5.2.

Look in the ibmslapd.conf file for the stanza that starts with

dn: cn=Front End, cn=Configuration

cn: Front End

Look for the following line in the stanza. If you do not see it, add it to the end of

the stanza:

objectclass: ibm-SlapdFrontEnd

1.29 Correction to Administration Guide: Missing word in IP address

description

In “Chapter 8. Basic server administration tasks,” in the section titled “Managing

server connections,” under “Using Web Administration,” the description of the IP

address is as follows:

“Specifies the IP address of the client that has a to the server.”

This sentence should be:

“Specifies the IP address of the client that has a connection to the server.”

1.30 Correction to Server Plug-ins Reference: Audit plug-ins section

There are several corrections to the Audit plug-ins section of the Server Plug-ins

Reference. The following is the corrected section.

Audit plug-ins

Administrators on some operating systems might want to use the system audit

facilities to log the LDAP audit record with the system-defined record format. To


allow flexibility in logging and record formats, a plug-in interface is provided. The

server uses this interface to provide three types of auditing-related data to the

external audit plug-ins if the auditing configuration is set to on. The data is passed

to the external audit plug-ins through the standard plug-in’s pblock interfaces,

slapi_pblock_set() and slapi_pblock_get().

The three types of audit data available to the external audit plug-ins are:

Audit Configuration Information

This information is used to inform the external audit plug-in that at least

one of the audit configuration options has been changed. The server

expects the plug-in to determine whether to log the audit data associated

with a particular LDAP operation, so it is important for the plug-in to have

the current audit configuration information maintained by the server.

Audit Event Information

This information is used to inform the audit plug-in that certain events

have happened. Event IDs, such as Auditing Started, Auditing Ended, or

Audit Configuration Options Changed, along with a message text

describing the event, are sent by the server to the audit plug-in when such

events occur.

Audit Record Information

This information is the audit data associated with each LDAP request

received by the server. For each LDAP request, if the ibm-audit

configuration option is set, the server provides the header data, control

structure (if available), and operation-specific data to the audit plug-in. It is

up to the audit plug-in to check its own copy of the LDAP audit

configuration options or its platform-specific audit policy to determine

whether to log and how to log the audit data.

The header file, audit-plugin.h, that defines the audit plug-in interface and data

structures is shipped with the IBM Tivoli Directory Server C-Client SDK.

A default audit plug-in is provided and configured with the server. This plug-in

performs the logging and formatting of the LDAP audit record. This default

plug-in can be replaced with the platform-specific audit plug-in, if available, by

changing the plug-in configuration lines in the ibmslapd.conf configuration file or

through the IBM Tivoli Directory Server Web Administration Tool.

Configuration options

The Audit Service has the following configuration options:

ibm-auditLog

Specifies the path name of the audit log. The default is /var/ldap/audit

for UNIX systems and <LDAP install directory>\var\audit for Windows

systems.

ibm-audit: TRUE|FALSE

Enables or disables the audit service. Default is FALSE.

ibm-auditFailedOPonly: TRUE|FALSE

Indicates whether to log only failed operations. Default is TRUE.

ibm-auditBind: TRUE|FALSE

Indicates whether to log the Bind operation. Default is TRUE.

ibm-auditUnbind: TRUE|FALSE

Indicates whether to log the Unbind operation. Default is TRUE.


ibm-auditSearch: TRUE|FALSE

Indicates whether to log the Search operation. Default is FALSE.

ibm-auditAdd: TRUE|FALSE

Indicates whether to log the Add operation. Default is FALSE.

ibm-auditModify: TRUE|FALSE

Indicates whether to log the Modify operation. Default is FALSE.

ibm-auditDelete: TRUE|FALSE

Indicates whether to log the Delete operation. Default is FALSE.

ibm-auditModifyDN: TRUE|FALSE

Indicates whether to log the ModifyRDN operation. Default is FALSE.

ibm-auditExtOPEvent: TRUE|FALSE

Indicates whether to log LDAP V3 Event Notification extended operations.

Default is FALSE.

ibm-auditExtOP: TRUE|FALSE

Indicates whether to log extended operations other than event notification

extended operations. Default is FALSE.

ibm-auditVersion: 1|2

Indicates the auditing version. Default is 2. The audit versions are:

Audit Version 1

Basic Audit functionality.

Audit Version 2

Audit version 2 was introduced in IBM Tivoli Directory Server 5.2.

Audit version 2 writes the audit version into the audit header,

enables the auditing of Transport Layer Security (TLS) in the audit

header, and enables auditing of additional information about

controls.

These options are stored in the LDAP directory to allow dynamic configuration. A

directory entry, cn=audit, cn=localhost, is created to contain these options. The

access to the values of these options are controlled through the access control list

(ACL) model. By default, the LDAP administrator is the owner of this cn=audit

entry. However, with the current ACL functionality, an auditor role can be created

so that only the auditor can change the option values and location of the audit log.

Note: For each modification of these option values, a message is logged in the

slapd error log as well as the audit log to indicate the change.

The values of the audit configuration options are returned when a search of

cn=monitor is requested by the LDAP administrator. These include:

v The value of the audit configuration options.

v The number of audit entries sent to the Audit plug-in for the current auditing

session and for the current server session.

Examples

The following are examples of the various operations:

For auditing version 1:

2001-07-24-15:01:01.345-06:00--V3 Bind--

bindDN:cn=test--client:9.1.2.3:12345--ConnectionID:12--

received:2001-07-24-15:01:01.330-06:00--adminAuthority:Y--success

name: cn=test

authenticationChoice: simple


2001-07-24-15:01:02.367-06:00--V3 Search--



base: o=ibm_us,c=us

scope: wholeSubtree

derefAliases: neverDerefAliases

typesOnly: false

filter: (&(cn=c*)(sn=a*))

Note: See the following examples for the format differences between authenticated

and unauthenticated requests:2001-07-24-15:22:33.541-06:00--V3 unauthenticated Search--

bindDN: <*CN=NULLDN*>--client:9.1.2.2:32412--ConnectionID:18--


2001-07-24-15:22:34.555-06:00--V3 SSL unauthenticated Search--

bindDN: <*CN=NULLDN*>--client:9.1.2.2:32412--ConnectionID:19--


2001-07-24-15:01:03.123-06:00--V3 Add--


received:2001-07-24-15:01:03.100-06:00--adminAuthority:Y--entryAlreadyExists

entry: cn=Jim Brown, ou=sales,o=ibm_us,c=us

attributes: objectclass, cn, sn, telphonenumber

2001-07-24-15:01:04.378-06:00--V3 Delete--




2001-07-24-15:01:05.712-06:00--V3 Modify--


received:2001-07-24-15:01:05.708-06:00--adminAuthority:Y--noSuchObject

object: cn=Jim Brown, ou=sales,o=ibm_us,c=us

add: mail

delete: telephonenumber

2001-07-24-15:01:06.534-06:00--V3 ModifyDN--


received:2001-07-24-15:01:06.530-06:00--adminAuthority:Y--noSuchObject


newrdn: ou=r&d

deleteoldrdn: true

2001-07-24-15:01:07.913-06:00--V3 Unbind--



For auditing version 2:

v Bind: (Administrator account status is displayed only if the bind is an

administrator bind.)

AuditV2--2005-07-19-10:01:12.630-06:00DST--V3 Bind--bindDN: cn=root--client:

127.0.0.1:43021--connectionID: 1--received: 2005-07-19-10:01:12.389-06:00DST--Success

name: cn=root

authenticationChoice: simple


v Search:

AuditV2--2005-09-09-10:49:01.863-06:00DST--V3 Search--bindDN: cn=root--client:


controlType: 1.3.6.1.4.1.42.2.27.8.5.1

criticality: false

base: o=ibm,c=us

scope: wholeSubtree


typesOnly: false

filter: (&(cn=C*)(sn=A*))

v Add:

AuditV2--2005-09-09-10:50:55.316-06:00DST--V3 Add--bindDN: cn=root--client:


entry: cn=U1,ou=Austin,o=IBM,c=US

attributes: objectclass, cn, sn, telephonenumber, internationaliSDNNumber,

title, seealso, postalcode,facsimiletelephonenumber, ibm-entryuuid

v Modify:

AuditV2--2005-09-09-10:51:07.103-06:00DST--V3 Modify--bindDN: cn=root--client:


object: cn=U1,ou=Austin,o=IBM,c=US

replace: postalcode

v Modify DN:

AuditV2--2005-09-09-10:52:14.590-06:00DST--V3 ModifyDN--bindDN: cn=root--client:



newrdn: cn=U1A

deleteoldrdn: true

v Delete:

AuditV2--2005-09-09-10:52:36.381-06:00DST--V3 Delete--bindDN: cn=root--client:


controlType: 1.3.6.1.4.1.42.2.27.8.5.1

criticality: false

entry: cn=U1A,ou=Austin,o=ibm,c=us

v Unbind:

AuditV2--2005-09-09-10:51:07.143-06:00DST--V3 Unbind--bindDN: cn=root--client:


v Extended Operation:

AuditV2--2005-09-09-10:57:11.647-06:00DST--V3 extended operation--bindDN: cn=root--client:


OID: 1.3.18.0.2.12.6

Each extended operation can have its own specific data. See the description of

each extended operation in the IBM Tivoli Directory Server Programming Reference

for specific details.

v Auditing of Controls: Each control audited contains the controlType and the

criticality. If the audit version is set to version 2 or higher, the server audits

additional information about the controls sent on an operation. This information

is placed just after the header and before the operation specific data. The

following example is an add operation with the password policy control.



controlType: 1.3.6.1.4.1.42.2.27.8.5.1

criticality: false


attributes: objectclass, cn, sn, telephonenumber, internationaliSDNNumber, title,

seealso, postalcode, facsimiletelephonenumber, ibm-entryuuid

v Auditing of a transaction: When the server receives an operation within a

transaction, the transaction ID is audited in both the audit header and in the list


of controls. Note that the transaction ID is placed just before the results of the

operation in the header. The following is an example of an add operation within

a transaction.


9.53.21.70:17805--connectionID: 8--received: 2005-09-09-10:57:11.447-06:00DST--transactionID:

11262814319.53.21.7017805--Success

controlType: 1.3.18.0.2.10.5

criticality: true


attributes: objectclass, cn, sn, telephonenumber, internationaliSDNNumber, title,

seealso, postalcode, facsimiletelephonenumber, ibm-entryuuid

v Auditing of operation with the Proxy Authorization Control: The following is

an example of a control with additional information that is audited only if the

version is set to 2 or higher:

AuditV2--2005-09-09-14:45:08.844-06:00DST--V3 Search--bindDN: cn=root--client: 1

27.0.0.1:4371--connectionID: 10--received: 2005-09-09-14:45:04.858-06:00DST--Suc

cess

controlType: 2.16.840.1.113730.3.4.18

criticality: true

ProxyDN: dn:cn=user1,o=ibm,c=us

base: o=ibm,c=us

scope: wholeSubtree


typesOnly: false

filter: (cn=A*)

1.31 Correction to Server Plug-ins Reference: Appendix C. Plug-in

examples

For corrections to the example in “Appendix C. Plug-in examples,” as well as a

new example, see the Technote entitled “Incorrect example in Server Plug-ins

Reference.” Technotes can be found at the following Web address:


1.32 Migrating from IBM Directory Server version 4.1 or 5.1 for

Windows: correction to documentation

In the Installation and Configuration Guide, in the "Migration from previous releases"

chapter, in the section called "Migration from IBM Directory Server version 4.1 or

5.1 for Windows installations," the following information should be added:

If the DB2 version on your system is at a level that is supported by IBM Tivoli

Directory Server version 5.2, the DB2 migration is automated. If your DB2 is not at

a supported level, refer to the DB2 installation and configuration documentation

for information about migrating DB2.

1.33 Upgrading DB2: invalid link in documentation

In the Server README, the section called "Upgrading to a new level of DB2"

contains a link to a document that no longer exists. For information about

upgrading your level of DB2, see the DB2 documentation.

1.34 Incorrect log paths in documentation

In the Installation and Configuration Guide, incorrect paths are given for logs:




v In "Appendix K. IBM Tivoli Directory Server configuration schema," in the

"Attributes" section:

– In "ibm-slapdBulkloadErrors" the default path for the bulkload error log

should be:

- c:\program files\ibm\ldap\var\bulkload.log on Windows systems

- /var/ldap/bulkload.log on AIX, Linux, Solaris, and HP-UX systems– In "ibm-slapdCLIErrors" the default path for the DB2 error log should be:

- c:\program files\ibm\ldap\var\db2cli.log on Windows systems

- /var/ldap/db2cli.log on AIX, Linux, Solaris, and HP-UX systemsv In the "Troubleshooting" chapter, in the "Debugging" section under "DB2 errors

logged":

– The path for the ibmslapd.log file should be:

- c:\program files\ibm\ldap\var\ibmslapd.log on Windows systems

- /var/ldap/ibmslapd.log on AIX, Linux, Solaris, and HP-UX systems– The path for the DB2 error log should be:

- c:\program files\ibm\ldap\var\db2cli.log on Windows systems

- /var/ldap/db2cli.log on AIX, Linux, Solaris, and HP-UX systems

1.35 On-line backup and restore not supported

In the Administration Guide in the section called "The IBM Tivoli Directory Server"

in "Directory overview", the following statement is in the first paragraph:

"This version uses IBM DB2 as the backing store to provide per LDAP operation

transaction integrity, high performance operations, and on-line backup and restore

capability."

This statement is incorrect. On-line backup and restore are not supported in IBM

Tivoli Directory Server 5.2.

1.36 Correction to ldapdiff command

The information in the IBM Tivoli Directory Server version 5.2 Administration Guide

about the ldapdiff command contains some inaccurate information. Use the

following information instead.

The LDAP replica synchronization tool

Synopsis

ldapdiff -b baseDN -sh host -ch host [-a] [-C countnumber]

[-cD dn] [-cK keyStore] [-cw password] -[cN keyStoreType]

[-cp port] [-cP keyStorePwd] [-ct trustStoreType] [-cT trustStore]

[-cY trustStorePwd] [-cZ] [-F] [-j] [-L filename] [-sD dn]

[-sK keyStore] [-sw password] -[sN keyStoreType] [-sp port]

[-sP keyStorePwd] [-st trustStoreType] [-sT trustStore]

[-sY trustStorePwd] [-sZ]

or

ldapdiff -S -sh host -ch host [-a] [-C countnumber][-cD dn]

[-cK keyStore] [-cw password] -[cN keyStoreType] [-cp port]

[-cP keyStorePwd] [-ct trustStoreType] [-cT trustStore]


|

|||

|

|

|||||||

|

|||

[-cY trustStorePwd] [-cZ] [-j][-L filename] [-sD dn]

[-sK keyStore] [-sw password] [-sN keyStoreType] [-sp port]

[-sP keyStorePwd] [-st trustStoreType] [-sT trustStore]

[-sY trustStorePwd] [-sZ]

Description

This tool synchronizes a replica server with its master. To display syntax help for

ldapdiff, type:

ldapdiff -?

Options

The following options apply to the ldapdiff command. There are two

subgroupings that apply specifically to either the supplier server or the consumer

server.

-a Specifies to use server administration control for writes to a read-only

replica.

-b baseDN

Use searchbase as the starting point for the search instead of the default. If

-b is not specified, this utility examines the LDAP_BASEDN environment

variable for a searchbase definition.

-C countnumber

Counts the number of entries to fix. If more than the specified number of

mismatches are found, the tool exits.

-F This is the fix option. If specified, content on the consumer replica is

modified to match the content of the supplier server. This cannot be used if

the -S is also specified.

-j Indicates to ignore the operational attributes in the LDIF file.

-L If the -F option is not specified, use this option to generate an LDIF file for

output. The LDIF file can be used to update the consumer to eliminate the

differences.

-S Specifies to compare the schema on both of the servers.

Options for a replication supplier

The following options apply to the consumer server and are denoted by an initial

’s’ in the option name.

-sD dn Use dn to bind to the LDAP directory. dn is a string-represented DN.

-sh host

Specifies the host name.

-sK keyStore

Specify the name of the SSL key store file with default extension of jks. If

the key store file is not in the current directory, specify the fully-qualified

key store filename. This key store file must contain the SSL certificate

extracted from the key database (kdb) file used by the supplier LDAP

server

This parameter effectively enables the -sZ switch.

When you use the -sK parameter, you must also use the following flags

with valid values: -sP, -sN, -sT, -sY, -st.


||||

|

||

|

|

|||

|||

||||

|||

||||

||

||||

||

|||

||

||

||||||

|

||

-sN keyStoreType

The type of the SSL key store. For this version of ldapdiff the only

supported type is jks. This parameter is ignored if neither -sZ nor -sK is

specified.

-sp ldapport

Specify an alternate TCP port where the ldap server is listening. The

default LDAP port is 389. If -sp is not specified and -sZ is specified, the

default LDAP SSL port 636 is used.

-sP keyStorePwd

Specify the key store password. This password is required to access the

encrypted information in the key store file, which may include one or more

private keys. This parameter is ignored if neither -sZ nor -sK is specified.

-st trustStoreType

The type of the SSL trust store. For this version of ldapdiff the only

supported type is jks. This parameter is ignored if neither -sZ nor -sT is

specified.

-sT trustStore

Specify the name of the SSL trust store file with default extension of jks. If

the trust store file is not in the current directory, specify the fully-qualified

trust store filename. This trust store file can be the same as or different

from the file keyStore (see the description of the -sK flag). This is sufficient

if the supplier LDAP server is using the SSL server authentication. If the

supplier LDAP server is using the SSL server client authentication, then the

default certificate from trustStore must be extracted and added to the key

database (kdb) used by the supplier LDAP server.

This parameter effectively enables the -sZ switch.

-sw password | ?

Use password as the password for authentication. Use the ? to generate a

password prompt. Using this prompt prevents your password from being

visible through the ps command.

-sY The password for the trusted store file. This password is required to access

the encrypted information in the trust store file, which can include one or

more private keys.

-sZ Use a secure SSL connection to communicate with the LDAP server.

Options for a replication consumer

The following options apply to the consumer server and are denoted by an initial

’c’ in the option name.

-cD dn Use dn to bind to the LDAP directory. dn is a string-represented DN.

-ch host

Specifies the host name.

-cK keyStore

Specify the name of the SSL key store file with default extension of jks. If

the key store file is not in the current directory, specify the fully-qualified

key store filename. This key store file must contain the SSL certificate

extracted from the key database (kdb) file used by the consumer LDAP

server.

This parameter effectively enables the -cZ switch. The -cK parameter also

requires you to provide the following flags with appropriate values: -cP,

-cN, -cT, -cY, -ct.


||||

||||

||||

||||

|||||||||

|

||||

||||

||

|||

||

||

||||||

|||

-cN keyStoreType

The type of the SSL key store. For this version of ldapdiff the only

supported type is jks. This parameter is ignored if neither -cZ nor -cK is

specified.

-cp ldapport

Specify an alternate TCP port where the ldap server is listening. The

default LDAP port is 389. If -cp is not specified and -cZ is specified, the

default LDAP SSL port 636 is used.

-cP keyStorePwd

Specify the key store password. This password is required to access the

encrypted information in the key store file, which can include one or more

private keys. This parameter is ignored if neither -cZ nor -cK is specified.

-ct trustStoreType

The type of the SSL trust store. For this version of ldapdiff the only

supported type is jks. This parameter is ignored if neither -cZ nor -cT is

specified.

-cT trustStore

Specify the name of the SSL trust store file with default extension of jks. If

the trust store file is not in the current directory, specify the fully-qualified

trust store filename. This trust store file can be same as or different from

the file keyStore (see the -sK flag description). This is sufficient if the

supplier LDAP server is using the SSL server authentication. If the

consumer LDAP server is using the SSL server client authentication, then

the default certificate from trustStore must be extracted and added to the

key database (kdb) used by the consumer LDAP server.

This parameter effectively enables the -cZ switch.

-cw password | ?

Use password as the password for authentication. Use the ? to generate a

password prompt. Using this prompt prevents your password from being

visible through the ps command.

-cY The password for the trusted store file. This password is required to access

the encrypted information in the trust store file, which can include one or

more private keys.

-cZ Use a secure SSL connection to communicate with the LDAP server.

Examples

ldapdiff -b <baseDN> -sh <supplierhostname> -ch <consumerhostname> [options]

or

ldapdiff -S -sh <supplierhostname> -ch <consumerhostname> [options]

SSL examples

ldapdiff -b <baseDN> -sh <supplierhostname> -sp 636 -sD <bindDN> -sw <bindpw> -sZ

-sK <KeyStore> -sP <keyStorePwd> -sN jks -sT <trustStore> -sY <trustStorePwd>

-st jks -ch <consumerhostname> -cp 636 -cD <bindDN> -cw <bindpw> -cZ -cK <KeyStore>

-cP <keyStorePwd> -cN jks -cT <trustStore> -cY <trustStorePwd> -ct jks

or

ldapdiff -S -sh <supplierhostname> -sp 636 -sD <bindDN> -sw <bindpw> -sZ

-sK <KeyStore> -sP <keyStorePwd> -sN jks -sT <trustStore> -sY <trustStorePwd>

-st jks -ch <consumerhostname> -cp 636 -cD <bindDN> -cw <bindpw> -cZ -cK <KeyStore>

-cP <keyStorePwd> -cN jks -cT <trustStore> -cY <trustStorePwd> -ct jks


||||

||||

||||

||||

|||||||||

|

||||

||||

||

|

|

|

|

|

||||

|

||||

Notes

If no DN arguments are provided, the ldapdiff command waits to read a list of

DNs from standard input. To break out of the wait, use Ctrl+C or Ctrl+D.

The content of a client’s key store file (or trust store file) is managed with the

gsk7ikm utility. For more information about this Java™ utility, see "Using gsk7ikm"

in the Administration Guide. The gsk7ikm utility is used to define the set of trusted

certification authorities (CAs) that are to be trusted by the client. By obtaining

certificates from trusted CAs, storing them in the key database file, and marking

them as ’trusted’, you can establish a trust relationship with LDAP servers that use

’trusted’ certificates issued by one of the trusted CAs. The gsk7ikm utility can also

be used to obtain a client certificate, so that client and server authentication can be

performed.

If the LDAP servers accessed by the client use server authentication only, it is

sufficient to define one or more trusted root certificates in the key database file.

With server authentication, the client can be assured that the target LDAP server

has been issued a certificate by one of the trusted CAs. For example, if the LDAP

server is using a high-assurance VeriSign certificate, you should obtain a CA

certificate from VeriSign, import it into your key store file, and mark it as trusted.

If the LDAP server is using a self-signed server certificate, the administrator of the

LDAP server can supply you with an extracted copy of the server’s certificate file.

Import the certificate file into your key store file and mark it as trusted.

If the LDAP servers accessed by the client use client and server authentication, it is

necessary to do one of the following:

v Create a key pair using gsk7ikm and request a client certificate from a CA. After

receiving the signed certificate from the CA, store the certificate in the client

trust store file. This certificate also must be added to the key database file used

by the LDAP server.

v Cross-exchange the self signed certificates: Extract the certificate from the key

database file used by the LDAP server and add it to the key store file, and

extract the certificate from the trust store file and add it to the key database used

by the LDAP server.

Diagnostics

Exit status is 0 if no errors occur. Errors result in a non-zero exit status and a

diagnostic message being written to standard error.


|

||

|||||||||

|||||||||

||

||||

||||

|

||

2.0 Must read known problems - platform specific

This information applies to the following operating systems:

2.1 For AIX only

The following information applies only to the AIX operating system.

2.1.1 Locales for InstallShield GUI panels

For the READMEs to display correctly in the InstallShield GUI panels the

following languages need to use the correct locales:

Table 1.

Language Locale

Japanese Ja_JP

Traditional Chinese Zh_TW

2.1.2 Error code -1 at startup

If DB2 is not already started, you might see the following message when starting

the server:

Error code -1 from odbc string:" SQLConnect " ldapdb2b.

This occurs because the IBM Directory Server is trying to connect to DB2, before

DB2 is started. If you see the message:

SQL1063N DB2START processing was successful.

you can ignore the previous error message because the Directory Server has started

DB2 and subsequently connected to it.

2.1.3 Problem with MALLOCTYPE=buckets

The performance enhancing MALLOCTYPE=buckets environment requires:

v The AIX 5.2 operating system Maintenance Level 03 that contains a fix for APAR

IY50668.

v The ibmslapd command must be started in a login session that has the ulimit

for data and memory set to unlimited.

# ulimit -d unlimited

# ulimit -m unlimited

2.1.4 Migrating from IBM Directory Server 4.1 or 5.1 with DB2

7.2 on AIX

If you are migrating from IBM Directory Server 4.1 on AIX, you must upgrade

your DB2 version to DB2 Enterprise Server Edition 8.1, 64-bit. Complete

instructions were not given in the Installation and Configuration Guide for this

migration. Therefore, use the following information to migrate from IBM Directory

Server 4.1 or 5.1 with DB2 7.2 on AIX.

21

To migrate an existing IBM Directory Server 4.1 or 5.1 on AIX and migrate DB2

Enterprise Server Edition 7.2, 32-bit, to DB2 Enterprise Server Edition 8.1, 64-bit,

use the following procedure:

Pre-installation steps:

1. Migrate the DB2 instance. Before you can migrate a DB2 instance, all

applications using any databases owned by the instance must be terminated.

To prepare a DB2 instance for migration, use the following procedure:

a. Log in as the DB2 instance owner.

b. Be sure that there are no applications using any databases owned by this

DB2 instance. To get a list of all applications owned by the instance, use

the db2 list applications command. You can end a session by entering the

db2 terminate command. Do not force termination of applications using

the db2 force applications all command, because some applications might

have unexpected behavior when they are terminated using this command.

See the DB2 Command Reference for detailed information about these

commands.

c. When all applications are complete, stop all database server processes

owned by the DB2 instance by entering the db2stop command.

d. Stop the DB2 license daemon by entering the db2licd end command.

e. Stop all command line processor sessions by entering the db2 terminate

command in each session that was running the command line processor.

f. Enter the db2_kill command to clean up any remaining DB2 resources.

g. Log off. 2. Verify that the database can be migrated. There are also migration

considerations you should take into account if you are using the Version 2

user exit program.

DB2 provides the db2ckmig migration command, which is used to verify

whether all cataloged databases can be migrated. The db2imigr command

uses the db2ckmig command to verify whether the cataloged databases can be

migrated.

To ensure that you can migrate the instance, run the db2ckmig command. If

instance migration failed, you must correct the errors reported by this

command. You can run the db2ckmig command again to verify that the errors

have been corrected, and then migrate the instance.

For detailed information about the db2ckmig command, refer to the DB2

Command Reference.

To verify that all cataloged databases can be migrated, perform the following

steps:

a. Log in as the instance owner.

b. Enter the following command:

db2ckmig ldapdb2 -l /home/ldapdb2/mig.log

c. Check the log file. The log file displays the errors that occur when you run

the db2ckmig command. If it shows any errors, perform corrective actions.

d. Check that the migration log file is empty before continuing with the

instance migration.

e. Back up the database after making corrections. 3. Install DB2 Enterprise Server Edition 8.1, 64-bit.

4. Back up the previous versions of the slapd32.conf or ibmslapd.conf and any

schema files from the /usr/ldap/etc directory to a directory that is not a

subdirectory of /usr/ldap.


These include files with the following file extensions:

v .oc

v .at

v .conf

and the following files:

v V3.ldapsyntaxes

v V3.matchingrules

v V3.modifiedschema 5. If you installed with the InstallShield GUI, uninstall using the InstallShield

GUI. However, do not uninstall DB2. If you installed using native utilities, do

not uninstall yet.

You can check to see if you installed IBM Directory Server with the

InstallShield GUI by using the following procedure: Look in the /usr/ldap

directory. If you have a subdirectory named _uninst, you installed with the

InstallShield GUI, and you must uninstall with the InstallShield GUI. (Do not

use smit to uninstall). To start the installation, change directories to the

/usr/ldap/_uninst directory, and type ./uninstall, and complete the

uninstallation. Then you must manually remove anything left in the

/usr/ldap directory. (See the IBM Directory Server Installation and Configuration

Guide for your release.)

6. Migrate the DB2 instance. Only local cataloged databases that reside in the

DB2 instance are checked for migration. Uncataloged databases might be

unusable after the instance has been migrated.

After an instance is ready for migration, use the db2imigr command to

migrate the instance as follows:

a. Log in as a user with root authority.

b. If the library_path environment variable is set to /usr/lib and there is a

link in /usr/lib to the Version 7 libdb2 shared library, this can cause an

error when using the db2imigr command. To fix the error, reset the

library_path environment variable so that it does not reference the libraries

in those paths by entering the following command:

unset LIBPATH

c. Run the db2imigr command as follows:

/usr/opt/db2_08_01/instance/db2imigr [-d] [-a AuthType]

[-u fencedID] InstName

where

v -d sets the debug mode that you can use for problem determination.

This parameter is optional.

v -a AuthType specifies the authentication type for the instance. Valid

authentication types are (SERVER), (CLIENT), and (DCS). If the -a

parameter is not specified, the authentication type defaults to (SERVER),

if a DB2 server is installed. Otherwise, the AuthType is set to (CLIENT).

This parameter is optional.

Notes:

1) The authentication type of the instance applies to all databases

owned by the instance.

2) While authentication type (DCE) is an optional parameter, it is not

valid to choose (DCE) for this command

2.0 Must read known problems - platform specific 23

v -u fencedID is the user under which the fenced user-defined functions

(UDFs) and stored procedures will run. This parameter is optional only

when a DB2 Run-Time Client is installed. It is required for all other DB2

products.

v InstName is the login name of the instance owner. 7. Convert the DB2 instance to a 64-bit width, using the following procedure:

a. Log in as a user with root authority.

b. Run the db2iupdt command as follows:

/usr/opt/db2_08_01/instance/db2iupdt -w 64 InstName

c. After migrating the DB2 instance, reset LIBPATH to its original setting 8. Migrate the database owned by the instance, using the following steps:

a. Log on with a user ID that has SYSADM authority, such as the instance

owner.

b. Ensure that the database you want to migrate is cataloged.

c. While logged on as the instance owner, type db2start.

d. Type db2.

e. At the DB2 command prompt, type the following:

migrate database DATABASE-NAME

9. Initialize the database manager configuration parameter UTIL_IMPACT_LIM

to its default value. The UTIL_IMPACT_LIM configuration parameter did not

exist for UDB 7.1 and on migration to Enterprise Server Edition 8.1 it is

assigned a value of 0. The valid range for this parameter is 1 to 100. Use the

following procedure:

a. Log on with a user ID that has SYSADM authority.

b. Run db2.

c. At the DB2 command prompt, type the following:

update database manager configuration using UTIL_IMPACT_LIM value

value should be kept low: between 1 and 10.10. If you installed using operating system utilities, uninstall IBM Directory

Server 4.1 or 5.1, using operating system utilities.

You can check to see if you installed IBM Directory Server with operating

system utilities by using the following procedure: Look in the /usr/ldap

directory. If you have a subdirectory named _uninst, you installed with the

InstallShield GUI, and you must uninstall with the InstallShield GUI. (Do not

use smit to uninstall in this case). If you do not have a subdirectory named

_uninst, you installed using operating system utilities, and you must uninstall

using operating system utilities. (See the IBM Directory Server Installation and

Configuration Guide for your release for instructions.)

Installation steps:

11. Install IBM Tivoli Directory Server 5.2 using the InstallShield GUI or SMIT.

(See the Installation and Configuration Guide for instructions.)

Post-installation steps:

12. Migrate the configuration and schema by executing the migrate52 script. Type

the following commands at a command prompt:

cd installpath/etc

../sbin/migrate52 -s backuppath

where backuppath is the path where you backed up the files in step 4 on page

22.


Note: You must run the migrate52 script even if you did not modify the

previous schema. There are new schema files and entries in the

ibmslapd.conf file that are not compatible with previous versions.

13. Try to start the server by typing ibmslapd. If the server comes up in

configuration only mode, do the following:

a. Unconfigure the database without destroying it. (The database instance

and database are kept, but the ibmslapd.conf file is updated.) Use the

ldapucfg -d command: For example:

# ldapucfg -d

You have opted to unconfigure the existing database ’ldapdb2’.

Do you want to....

(1) Leave this database on your system (just unconfigures), or

(2) Completely erase the database (and any data in it)?: 1

You have chosen the following actions:

Database ’ldapdb2’ in instance ’ldapdb2’ will be unconfigured.

Database ’ldapdb2’ will be left on your system.

Instance ’ldapdb2’ will be left on your system.

Do you want to....

(1) Continue with the above actions, or

(2) Exit without making any changes: 1

Unconfiguring IBM Tivoli Directory Server Database.

Removing local loop back from database: ’ldapdb2’.

Removed local loop back from database: ’ldapdb2’.

Unconfiguring database: ’ldapdb2’

Unconfigured database: ’ldapdb2’

Starting database manager for instance: ’ldapdb2’.

Started database manager for instance: ’ldapdb2’.

Unconfigured IBM Tivoli Directory Server Database.

IBM Tivoli Directory Server Unconfiguration complete.

b. Configure the existing database instance and database, and update the

ibmslapd.conf file, using the following command:

ldapcfg -l /home/ldapdb2 -a ldapdb2 -w <password> -d ldapdb2 -t ldapdb2

For example:

# ldapcfg -l /home/ldapdb2 -a ldapdb2 -w ldaptest -d ldapdb2 -t ldapdb2 -n

You have chosen the following actions:

Database ’ldapdb2’ will be configured in instance ’ldapdb2’.

Configuring IBM Tivoli Directory Server Database.

Cataloging instance node: ’ldapdb2’.

Cataloged instance node: ’ldapdb2’.



Updating the database: ’ldapdb2’

Updated the database: ’ldapdb2’

Updating the database manager: ’ldapdb2’

Updated the database manager: ’ldapdb2’

Enabling multi-page file allocation: ’ldapdb2’

Enabled multi-page file allocation: ’ldapdb2’

Configuring database: ’ldapdb2’

Configured database: ’ldapdb2’

Adding local loop back to database: ’ldapdb2’.

Added local loop back to database: ’ldapdb2’.

Stopping database manager for instance: ’ldapdb2’.

Stopped database manager for instance: ’ldapdb2’.




Configured IBM Tivoli Directory Server Database.

IBM Tivoli Directory Server Configuration complete.

14. If you are not using DB2 7.2 for anything other than IBM Directory Server,

uninstall it.

2.1.5 Correction to Server README

The third paragraph under ″Application Support on AIX for 64-bit Applications″ in

the Server README reads:

At this time, the CRAM-MD5 SASL plug-in is a separate dynamically loadable

shared object for 32 and 64 bit LDAP applications. To correctly select and load the

appropriate 64-bit module, the environmental variable IBMLDAP_CONF must be

set to a location other than /etc. At this new location, you need to create a copy of

the /etc/ldap.conf file and replace the following entry:

plugin sasl CRAM-MD5 ldap_plugin_sasl_cram-md5 ldap_plugin_init

with:

plugin sasl CRAM-MD5 ldap_plugin_sasl_cram-md5_64 ldap_plugin_init

The above description is inaccurate. The name of the file to be copied is incorrect,

and it is not clear what the IBMLDAP_CONF environment variable should be set

to.

The corrected description follows:

At this time, the CRAM-MD5 SASL plug-in is a separate, dynamically loadable

shared object for 32 and 64 bit LDAP applications. To correctly select and load the

appropriate 64-bit module, you must:

1. Create a copy of the /usr/ldap/etc/ibmldap.conf file. Because the copy must

be named ibmldap.conf, you must create the copy in a directory other than

usr/ldap/etc

2. In the copied file, replace the following entry:

plugin sasl CRAM-MD5 ldap_plugin_sasl_cram-md5 ldap_plugin_init

with

plugin sasl CRAM-MD5 ldap_plugin_sasl_cram-md5_64 ldap_plugin_init

3. After you have replaced the entry, set the IBMLDAP_CONF environment

variable to the directory path where the copied file is located. Do not include

the file name in the path.

2.1.6 Support on AIX 5.3

The IBM Tivoli Directory Server 5.2 client and server are now supported on AIX

5.3. Read the following before you install:

v APARs IY58143 and IY61889 for AIX 5.3 are required.

v Fix Pack 2 (5.2.0-TIV-ITDS-FP0002) for IBM Tivoli Directory Server 5.2 is

required.

v Use AIX operating system utilities (SMIT or installp), instead of the

InstallShield GUI, to install IBM Tivoli Directory Server. See "Installing IBM

Tivoli Directory Server using AIX utilities" in the IBM Tivoli Directory Server

version 5.2 Installation and Configuration Guide for information.


v IBM Network Authentication Services (NAS) 1.4.0.1 is required.

v The Web Administration Tool is not supported on AIX 5.3.

2.1.7 Installing the SSL client, server, or Web Administration

Tool

If you want an SSL client, server, or Web Administration Tool, first install the

non-SSL client, server, or Web Administration Tool and then install the SSL fileset.

The SSL filesets are not documented in the IBM Directory Server version 5.2

Installation and Configuration Guide or the IBM Directory Server version 5.2 Client

Readme. (To use SSL, you must also install GSKit.)

v For the client: install ldap.client and ldap.max_crypto_client

v For the server: install ldap.server and ldap.max_crypto_server

v For the Web Administration Tool: install ldap.webadmin and

ldap.max_crypto_webadmin

2.2 For Windows only

The following information applies only to Windows® platforms.

2.2.1 Setting LANG and LC_ALL system environment variables

for nonEnglish InstallShield GUI installation

For the InstallShield GUI installation to bring up the same language that the

operating system is using, two variables need to be set in the system environment

v LANG = <locale>

v LC_ALL = <locale>

where <locale> is the locale that the operating system is using.

Go to http://www.microsoft.com/globaldev/ for a list of Microsoft® locale values.

2.2.2 Certain UTF-8 supplementary characters do not display

correctly

IBM Directory Server supports UTF-8 (Unicode Transformation Format, 8-bit form)

to use Unicode characters, which contains MS932 (Shift JIS) characters plus

supplementary characters not defined in MS932. Supplementary characters might

be displayed as square box in Internet Explorer running on Windows NT and

Windows 2000. See Figure 1.

If this occurs, install one of the East Asian language kits. Depending on your

environment, install the Japanese, Korean, Simplified Chinese or Traditional

Figure 1. Unicode Code Point U+9DD7 displayed as a square


http://www.microsoft.com/globaldev/

Chinese language kit which is included in your Windows NT and Windows 2000

CDs. For example, Unicode code point U+9DD7 is one of the supplementary

characters in the Japanese environment. With the correct language kit installed, the

supplementary character is displayed correctly. See Figure 2.

Note: This problem is not observed in Windows XP.

2.2.3 Difficulties encountered using the Web Administration

GUI console on the Windows 2003 platform

Web Administration errors occur if all the following conditions exist:

v Web Administration is installed locally

v Web Administration runs on a locally installed version of Microsoft Internet

Explorer

v Web Administration uses the locally installed embedded version of WebSphere

Application Server - Express, V5.0

v An IP address or hostname is part of the URL used to access Web

Administration

To avoid these errors:

1. If the embedded version of WebSphere Application Server - Express, V5.0 is

running locally, add http://localhost to the list of trusted sites.

2. If the embedded version of WebSphere Application Server - Express, V5.0 is

running on a remote machine, add the IP address or host name of the machine

on which the Web application server is running to the list of trusted sites.

http://<IP address> or http://<hostname>

To add a Web address to the Trusted Site list:

1. Click Tools -> Internet Options -> Security -> Trusted Site -> Sites.

2. Type the Web address in the Web site field.

3. Click Add.

4. Click OK.

To log on to the Web Administration Tool on the local machine, open an Internet

Explorer Web browser and type the following in the Address field:

http://localhost:9080/IDSWebApp/IDSjsp/Login.jsp

To log on to the Web Administration Tool on a remote machine, open an Internet

Explorer Web browser and type the following in the Address field:

http://<IP address> or <hostname>:9080/IDSWebApp/IDSjsp/Login.jsp

2.2.4 Error message using ldapxcfg after migrating from IBM

SecureWay Directory Version 3.2.2 to IBM Tivoli Directory

Server Version 5.2

After migrating from version 3.2.2 to version 5.2, if you use ldapxcfg, you might

receive the following error message:

Either the specified user id or the password is invalid.

Figure 2. U+9DD7 displayed correctly


To avoid this situation ensure that you have followed the following procedure

from the Installation and Configuration Guide:

Creating the DB2 database owner

Before you install, create or be sure that you have created the user ID that will

own the DB2 database used to store the directory data. You will be asked to

provide this user ID and its password during configuration, which runs

automatically after installation and system restart. The user ID must be 8

characters or less, and it must be a member of the Administrators group. If you are

creating a new database, a DB2 instance with the same name as the user ID will be

created to hold the database.

2.2.5 Use the command line to uninstall IBM Directory Server

on the Windows 2003 platform

If you have migrated from IBM Directory Server Version 5.1, the IBM Tivoli

Directory Server Version 5.2 cannot be uninstalled using the Add/Remove

Programs option in the Control Panel.

To uninstall the IBM Tivoli Directory Server, type the following at a command

prompt:

cd <installpath>\_uninst

set JAVA_HOME=<installpath>\_jvm\jre\bin

uninstall

Where installpath is the location where the IBM Tivoli Directory Server Version 5.2

server is installed.

2.2.6 Configuration utilities do not work with DB2 7.2 Fixpack

10

The ldapcfg and ldapxcfg utilities do not work with DB2 7.2 Fp10.

Do not to upgrade to this level of DB2, if you want to use ldapcfg or ldapxcfg

utilities to configure the database. If you do upgrade to Fix pack 10, you must

configure the database manually.

2.2.7 GSKit and DB2 installation might fail on Windows

On Windows , the InstallShield installation of GSKit and DB2 might fail, if the path

to where the IBM Tivoli Directory Server product zip file is unzipped contains

spaces in the directory names. To ensure the successful installation of GSKit and

DB2, the path to where the Directory Server product is unzipped must not contain

any spaces in the directory names.

2.2.8 Communications error: Exceeding 64 connections/OCH

On Windows, if you have clients that are generating many connections to the

server and the connections are being refused, the server might log error messages

similar to the following to the ibmslapd.log file:

Feb 11 14:36:04 2004 Communications error: Exceeding 64 connections/OCH - dropping socket.

If you see these errors, do the following:

1. Stop the server.

2. Save a copy of your ibmslapd.conf.

3. Insert the following in the section that starts with ’dn:

cn=FrontEnd,cn=Configuration’:

ibm-slapdSetenv: SLAPD_OCHANDLERS=5


4. Restart your server.

If you continue to receive error messages, increase environment variable by 5 until

you stop receiving error messages.

2.2.9 Starting IBM Tivoli Directory Server at operating system

startup on Windows platforms

In IBM Tivoli Directory Server, the server (the ibmslapd process) is started

manually through the Services window or by the ibmslapd command. If you try to

start the server automatically by updating the Startup Type in the Services

window to Automatic, errors occur when you restart the computer. This is because

DB2 must be running before the ibmslapd process can start.

If you want the server to start automatically, you can create a batch file to start the

ibmslapd process. The batch file should be invoked after all the services are

started, so that DB2 will be completely up and running before the ibmslapd

process starts.

The following is an example of commands in a .bat file that you can add to the

Startup folder to start the server:

@echo off

%LDAPHome%\bin\ibmdirctl [-h <hostname>] [-D <adminDN>] [-w <password>]

[-p <portnumber>] start -- [ibmslapd options]

Note: Be sure that the Startup Type for the IBM Tivoli Directory Admin Daemon

entry in the Services window is set to Automatic. If it is not, the

administration daemon control program (ibmdirctl) will not work.

2.2.10 DB2 8.1 Fix Pack 7 not supported on Windows systems

DB2 8.1 Fix Pack 7 is not supported on Windows systems.

2.3 For Solaris Operating Environment Software only

The following information applies only to the Solaris Operating Environment

Software.

2.3.1 Memory requirements for running with DB2 8.1 on

Solaris 9

If you are running DB2 8.1 on Solaris 9, the IBM Tivoli Directory requires a

minimum of 640 MB of memory.

2.3.2 The uninstall archive file requires extra space

When using the InstallShield GUI to install the IBM Tivoli Directory Server on

Solaris, a large uninstall archive file is created in the /opt/IBMldapc/_uninst

directory. If you are installing from the server InstallShield package this archive file

is 300 MB. Iif you are installing from the client InstallShield GUI package this

archive file is 70 MB. This space is not considered when space is checked during

the installation process. You must ensure that this extra space is available in the

/opt partition before installing the Directory Server.


2.3.3 The InstallShield GUI requires 350 MB for the var/tmp

directory

The InstallShield GUI installation for Solaris uses a significant amount of space in

the /var/tmp directory. If you are installing all of the features, you need 350 MB of

free space in the /var/tmp directory.

If your /var/tmp directory does not have enough space, you can set a soft link for

/var/tmp to point to another directory that has sufficient space such as the /tmp

directory. For example, from the /var directory you can enter the command:

ln -s /tmp/tmp tmp

After issuing that command, the InstallShield GUI uses the space in the /tmp

directory instead of the /var/tmp directory.

2.3.4 Requirements for GSKit on Solaris 9

In the Installation and Configuration Guide, the requirements for GSKit on Solaris 9

are incorrect. Use the following information instead.

On Solaris 9, the following patch is required for the gsk runtime: 111711-06. There

are no patches required at this time for the gsk SDK 2.

2.3.5 Native installation under a directory other than /opt

If you perform a native installation and install the IBM Tivoli Directory Server in a

directory other than /opt, be aware that soft links are created in the /opt directory

that point to the binaries in the new installation directory.

2.4 For Linux only

The following information applies only to the Linux operating systems.

2.4.1 CD-ROM does not eject from Linux machines

When installing the server from a CD-ROM using the native RPM installation

method on a Linux machine, the CD-ROM fails to eject. To eject the CD-ROM, you

must either reboot your system or stop the ibmdiradm process.

To stop the ibmdiradm process issue the following command to obtain the PID

number of the ibmdiradm process:

ps -ef |grep ibmdiradm

This command returns output similar to this example:

ldap 7048 1 0 10:26 pts/1 00:00:00 /usr/bin/ibmdiradm














In this example the PID for ibmdiradm is 7048. To stop the ibmdiradm process,

issue the following command:

kill -9 <PID>

In this example, 7084 is the PID, so the command is:

kill -9 7084

After ejecting the CD-ROM, restart the ibmdiradm process by issuing the

command:

ibmdiradm

Note: This problem does not occur if you use the InstallShield GUI installation

method.

2.4.2 Web Administration Tool is not supported on Red Hat 3.0

The embedded version of WebSphere Application Server - Express, V5.0 does not

support the Red Hat Enterprise Linux 3.0 operating system. Consequently, you

cannot use the Web Administration Tool on that platform. You can, however, install

the embedded version of WebSphere Application Server - Express, V5.0 on another

machine in your topology that uses a different operating system, for example

Windows 2000, and use the Web Administration Tool on that machine to

administer the server on the machine with the Red Hat Enterprise Linux 3.0

operating system.

2.4.3 Configuration needs to be run from the /tmp directory

The configuration of local loopback for DB2 fails if it is performed from the current

working directory (pwd). The configuration of local loopback for DB2 needs to be

performed from a directory that is writable to both the root administrator ID and

the instance owner user ID.

To change from the pwd directory to the tmp directory perform the following

steps:

1. If you are not already logged on as root, issue the following command to

obtain root privileges to run the ldapcfg command:

su - root

2. Change directories from the pwd directory to the tmp directory. Issue the

command:

cd /tmp

3. Invoke the ldapcfg utility with the appropriate configuration options. For

example:

ldapcfg -u "cn=root" -p <adminpwd> -s "o=ibm,c=us" -a <dbuserID>

-w <dbuserpw> -d <dbname> -l <dblocation>

2.4.4 Installation fails on Linux if a group name ends in "ldap"

On Linux systems, both InstallShield GUI installation and native installation fail if

there is a group name defined on the computer that ends in the string "ldap".

Before you install, be sure that there are no groups defined whose names end in

the string "ldap". If you want a group name that ends in "ldap", create the group

(as well as the DB2 database and database instance owner) after installation

completes, but before you configure. (See the Installation and Configuration Guide for

information about the DB2 database owner.)


2.4.5 Additional requirements for Red Hat Enterprise Linux 3.0

For Red Hat Enterprise Linux 3.0 Advanced Server and Enterprise Server versions

the following additional prerequisites must be installed:

v RHEL 3 Update 1

v DB2 v8.1 fixpack 5

2.4.6 Additional requirements for SuSE Linux Enterprise

Server 8

For SuSE Linux Enterprise Server 8, be sure that the following packages are

installed:

v glibc-locale

v glibc-i18ndata

2.4.7 Unable to compile IBM Tivoli Directory Server sample

programs on Red Hat EL3

The following errors might occur when compiling the sample code provided in the

/usr/ldap/example directory on a RedHat system:

/tmp/cc4gpYbT.o(.text+0x2b57): In function `write_tmp_file’:

: the use of `mktemp’ is dangerous, better use `mkstemp’

/tmp/cc4gpYbT.o(.text+0x1821): In function `getPassword’:

: undefined reference to `errno’

/lib/libldif.a(line64.o)(.text+0x110d): In function `str_getline’:

: undefined reference to `__ctype_b’

collect2: ld returned 1 exit status

make: *** [ldapsearch] Error 1

This is a RedHat compiler/linker problem. This problem is documented in Red

Hat Bugzilla #111928: glibc 2.3 causes linking problems with Undefined Symbol

__ctype_b and others.

If the solution from Red Hat does not work for you, try the following workaround:

1. Save the makefile.ex as makefile.ex.orig

2. Change the makefile.ex around line 60 as follows:

DEFINES = -DLINUX -D_GCC3 3

3. Confirm the makefile links to the correct libpthread.so library.

Note: Sometimes Red Hat has more than one libpthread.so library on the

system. To find out whether libpthread.so is the correct library, issue the

command:

strings libpthread.so | grep errno

If the return is

__errno_location _h_errno _h_errno_location

then it is the correct one.

4. Add the path of libpthread.so to the LFLAGS in makefile.ex file.

5. Download Ctype.c from RedHat. Ctype.c needs to be statically compiled and

linked with the examples.

2.4.8 Update to supported Linux versions

IBM Tivoli Directory Server version 5.2 is supported on the following Linux

versions:


xSeries Linux

The client is supported on the following versions of xSeries Linux:

v Red Hat Enterprise Linux AS release 3

v Red Hat Enterprise Linux ES release 3

v UnitedLinux 1.0

v SuSE Linux Enterprise Server 8

The server is supported on the following versions of xSeries Linux:

v UnitedLinux 1.0 (including SP2)



v Red Hat Enterprise Linux ES release 3

zSeries Linux

The client is supported on the following versions of zSeries Linux:



The server is supported on the following versions of zSeries Linux:



iSeries and pSeries for Linux

The client is supported on the following versions of iSeries and pSeries for

Linux:


v UnitedLinux 1.0


The server is supported on the following versions of iSeries and pSeries

Linux:



Note: On POWER5-based hardware, the minimum level of Red Hat

Enterprise Linux supported is Red Hat Enterprise Linux release 3,

update 3.

2.4.9 Uninstallation of Web Administration Tool package fails if

ldap user and group do not exist

On Linux systems, if you try to uninstall the ldap-webadmind-5.2-1 package and

the ldap user and group are not present on the computer, the uninstallation fails.

To successfully uninstall this package, you can do one of the following:

v Create the ldap user and group, and then uninstall.

v Run the rpm command with the --noscripts option. For example:

rpm -e ldap-webadmind-5.1-1 --noscripts

2.5 For HP-UX only

This information applies to the HP-UX operating system only.


2.5.1 Mounting and unmounting the CD

To ensure that the product is correctly installed, use the following procedures to

mount and unmount the CD.

Mounting the CD

1. To verify that the Portable File Systems (PFS) daemons are enabled and active

issue the command:

ps -aef | grep pfs

If the output of the command shows pfs_mountd, pfsd and the corresponding

rpc processes as in the following example, go to step 3.

ps -aef | grep pfs

root 20381 17407 0 14:04:51 pts/tb 0:00 /usr/sbin/pfs_mountd

root 20388 20387 0 14:05:20 pts/tb 1:06 pfsd.rpc

root 20382 20381 0 14:04:51 pts/tb 0:00 pfs_mountd.rpc

root 20387 17407 0 14:05:20 pts/tb 0:00 /usr/sbin/pfsd

Otherwise, continue to step 2 to start the PFS daemons.

2. To start the PFS processes on an HP-UX machine, issue the commands:

nohup /usr/sbin/pfs_mountd &

nohup /usr/sbin/pfsd &

3. Mount the CD to /SD_CDROM or any other directory that can act as mount

point. This directory needs to exist before running the pfs_mount command. If

you need to create this directory issue the command:

mkdir /SD_CDROM

To mount the CD issue the command:

/usr/sbin/pfs_mount <CD_device_name> <mount_point_dir>

Where <CD_device_name> is the device name of the cd drive on the machine,

and <mount_point_dir> is the directory that is acting as the mount point. For

example:

/usr/sbin/pfs_mount /dev/dsk/c0t2d2 /SD_CDROM

The CD is now mounted and the products can be installed.

Unmounting the CD

To unmount the and eject the CD:

1. After you have installed the IBM Tivoli Directory Server, obtain the process id

(pid) for the ibmdiradm process that is started by the installation. Issue the

command:

ps -aef | grep ibmdiradm

ldap 7868 1 0 00:41:28 pts/ta 0:00 /usr/IBMldap/bin/ibmdiradm

2. Stop the ibmdiradm process. Issue the command:

kill -9 <ibmdiradm_pid>

where <ibmdiradm_pid> is the process id. For example:

kill -9 7868

3. Ensure that no other process is using the CD.

4. Unmount the CD. Issue the command:

/usr/sbin/pfs_umount /SD_CDROM

Where /SD_CDROM is the mount point.


5. Eject the CD.

Note: If the CD fails to eject issue the command:

/usr/sbin/pfs_umount -c <CD_device_name>

For example:

/usr/sbin/pfs_umount -c /dev/dsk/c0t2d2

and then eject the CD.

2.5.2 Corrections to installing GSKit

You can install the GSKit package (gsk7bas.tar.Z) through the command line or

through sam, a GUI utility for system administration.

To install GSKit:

1. Download or copy the GSKit package to /tmp.

2. Run the following command to change to the /tmp directory:

cd /tmp

3. Uncompress and untar the package:

zcat gsk7bas.tar.Z | tar -xvf -

4. Run the following command to install:

swinstall -s /tmp/gsk7bas gsk7bas

where

v -s specifies the full_path of the software source.

v gsk7bas contains the Restricted GSKit Base Toolkit install image.

See Appendix I, ″Setting up GSKit to support CMS key databases″, in the IBM

Tivoli Installation and Configuration Guide for more information about setting up

GSKit after installation.

2.5.3 DB2 installation fails

To install DB2, the locale setting must be C (that is, you must call export LANG=C

and export LC_ALL=C), otherwise db2_install fails.

2.5.4 Configuration on HP-UX 11i

During configuration of IBM Tivoli Directory Server 5.2 on HP-UX 11i, if you

receive an error message from the configuration program, check to see if the /java

directory under /usr/IBMldap is linked to the correct Java directory. For Java 1.4.1,

/usr/IBMldap/java should be linked to: /opt/java1.4

If the link is incorrect, correct it and then rerun the configuration program.

2.5.5 Directory server fails on HP-UX 11i with DB2 8.1 with

FixPak 7, 7a, 8, or 9

If you are using IBM Tivoli Directory Server 5.2 on HP-UX 11i with DB2 8.1 with

FixPak 7, 7a, 8, or 9, the directory server might fail with the following message:


069:15:30:54 T1 381169 2087 usec SQLAllocConnect() => 0,henv = 1, hdbc = 1

069:15:30:54 T1 retrieving SQLERROR info

069:15:30:54 T1 henv=0,hdbc=1,native retcode = -1366; state = " ";

message = "[IBM][CLI Driver] SQL1366N A se

curity plug-in "IBMOSauthclient" processing error occurred on the client. Reason code = "7".

"

This problem will be fixed in FixPak 10 by the fix for DB2 APAR IY71676. You can

either apply FixPak 10 or return to an earlier DB2 FixPak level.


3.0 General information, hints and tips

This information applies to the AIX, Windows, Solaris Operating Environment

Software, and Linux platforms.

3.1 Migrating a replicating environment from 3.2.x to 5.2

When migrating from 3.2.x to 5.2, you need to unconfigure the database. Before

unconfiguring the database, you might want to ensure that all replication changes

have been completed.

Stop the master server and issue the following command to ensure that all changes

have been replicated. This example assumes that the name of the user, instance

and database are ldapdb2.

For UNIX platforms:

su -ldapdb2 -c "db2 connect to ldapdb2;

select count (id) from ldapdb2.change"

Note: If not issuing this command as the root, you need to provide the

database instance owner password.

For Windows platforms:

db2cmd

In the new DB2 command window issue the following commands:

set DB2INSTANCE=ldapdb2

db2 connect to ldapdb2

select count (id) from ldapdb2.change

If the count is 0, then all changes have been replicated and the replica and master

are synchronized. You can proceed with regular migration (exporting the database

to an LDIF file, migrating and so on). Otherwise you might want to restart the

master in read only mode and wait for all of the updates to be replicated. This is

important if you have a topology that is heterogeneous, for example, 3.2.x replicas

and 4.1 replicas with a 5.2 master.

If you are moving your whole enterprise to 5.2 from 3.2.x, you can:

1. Create an LDIF file using db2ldif on the master.

2. Unconfigure the database on all the servers.

3. Install the IBM Directory Server Version 5.2 on each server.

4. Perform the migration procedure.

5. Use the ldif2db or bulkload command to load the master’s data on to the

replicas. This ensures that the replicas are synchronized with the master.

6. Start the master and the replicas.

7. Use the Web Administration Tool Replication management ->Manage queues

to resume replication or issue the following command:

ldapexop -h <hostname> -D <binddn> -w <password>

-op controlrepl -action resume -rc <contextDN>

39

3.2 Configuring the database in a location other than /home when

/home is an NFS mount

The information in Appendix J of the Installation and Configuration Guide is missing

steps. Use the following information instead.

On UNIX systems, if you use NFS automount, you must configure everything

manually to create the database in a location other than /home. Performing

manual configuration in this situation also avoids the problem of the ldapcfg

command trying to write to /home.

Notes:

1. The following steps assume that you want to set up a database where the

instance owner is ldapdb2, the DB2 instance is ldapdb2, and the database name

is ldapdb2.

2. It is strongly recommended that you save a copy of any system file before

editing it.

To set up the database:

1. Create a group named dbsysadm for the database administrators:

groupadd [-g <gid>] dbsysadm

Note: The groupadd command on some Linux distributions requires that the

group ID number (gid) be specified using the -g <gid> syntax. To find

an available group ID number, type

cat /etc/group

Red Hat automatically assigns the next available gid if the -g option is

not specified.

2. Add users root and ldap to the dbsysadm group:

usermod -G dbsysadm root

usermod -G dbsysadm ldap

3. Create a user account (ldapdb2) for the DB2 instance:

useradd -g dbsysadm -m ldapdb2

4. Set the password for the user account (ldapdb2):

passwd ldapdb2

Enter the new password when prompted. Record your password for future

reference.

5. Create the database instance:

<LDAPHOME>/db2/instance/db2icrt -u ldapdb2 ldapdb2

where <LDAPHOME> is:

v /usr/ldap on Linux operating systems

v /opt/IBMldaps on Solaris operating systems

v /usr/IBMldap on HP-UX operating systems

Attention: On AIX only, use the following command:

<LDAPHOME>/db2/instance/db2icrt -w 64 -u ldapdb2 ldapdb2

where <LDAPHOME> is /usr/ldap

6. Before performing this step, save a copy of the /etc/services file.


Update the /etc/services file to include a line for local loopback:

echo "ldapdb2svc 3700/tcp" >> /etc/services

echo "ldapdb2svci 3701/tcp" >> /etc/services

7. Log in as the database user ID:

su - ldapdb2

8. Start the database manager:

db2start

9. Create the database under the instance:

db2 create db ldapdb2 on <location> using codeset UTF-8 territory US

Note: If you omit using codeset UTF-8 territory US, the database is created

in the local code page. However, using the local code page does affect

performance. The database requires at least 80Mb of free space available

on the file system. Use df -k to verify this before creating the database.

10. Enable multi-page file allocation:

db2empfa ldapdb2

Note: This is a performance enhancement, and it cannot be undone after

being run.

11. Update some of the DB2 tuning variables:

db2 update db cfg for <databasename> using <parm> <newvalue>

DB2 Parameter Minimum value allowed

APPLHEAPSZ 2048

PCKCACHESZ 360

SORTHEAP 256

For example:

db2 update db cfg for ldapdb2 using APPLHEAPSZ 1280

Note: At this point, the database is created. However, for IBM Tivoli Directory

Server, the use of a local loopback database connection is required. To

enable local loopback perform the following steps:

a. Update the database for local loopback connections:

db2 update dbm cfg using SVCENAME ldapdb2svc

db2 catalog tcpip node ldapdb2n remote localhost server ldapdb2svc

db2 catalog db ldapdb2 as ldapdb2b at node ldapdb2n authentication client

db2set DB2COMM=TCPIP

b. Restart the database manager:

db2stop

db2start

12. The database is fully configured. You can update the configuration file to use

this database. In the <LDAPHOME>etc/ibmslapd.conf file, find the following

stanza:

dn: cn=Directory,cn=RDBM Backends,cn=IBM Directory,cn=Schemas,cn=Configuration

objectclass: top

objectclass: ibm-slapdRdbmBackend

cn: Directory

ibm-slapdPlugin: database /bin/libback-rdbm.dll rdbm_backend_init

ibm-slapdDbConnections: 15

ibm-slapdSuffix: cn=localhost

ibm-slapdReadOnly: FALSE

Add the following lines:


ibm-slapdDbInstance: ldapdb2

ibm-slapdDbAlias: ldapdb2b

ibm-slapdDbUserId: ldapdb2

ibm-slapdDbUserPw: <user pw>

ibm-slapdDbLocation: <user defined location>

The resulting stanza is:

dn: cn=Directory,cn=RDBM Backends,cn=IBM Directory,cn=Schemas,cn=Configuration

objectclass: top

objectclass: ibm-slapdRdbmBackend

cn: Directory

ibm-slapdPlugin: database /bin/libback-rdbm.dll rdbm_backend_init

ibm-slapdDbInstance: ldapdb2

ibm-slapdDbAlias: ldapdb2b

ibm-slapdDbUserId: ldapdb2

ibm-slapdDbUserPw: <user pw>

ibm-slapdDbLocation: <user defined location>

ibm-slapdDbConnections: 15

ibm-slapdSuffix: cn=localhost

ibm-slapdReadOnly: FALSE

13. If you used a UTF-8 datastore as described in step 9 on page 41, in the stanza:

dn: cn=Front End, cn=Configuration, you must uncomment the line:

#ibm-slapdSetEnv: DB2CP=1208

The database is ready for the Directory server to use. The first startup takes longer

because the server must create its own tablespaces and bufferpools.

3.3 Correction to command in Installation and Configuration Guide

In the Installation and Configuration Guide, in "Chapter 13. After you install and

configure," in the section entitled "Starting the application server to use the Web

Administration Tool", the command for Windows operating systems in step 2 is

incorrect. The correct command is:

startServer.bat server1

3.4 Nonblocking replication

In non-blocking mode, replication does not stop when an error occurs. Rather, the

error is logged and the offending update is skipped, and replication continues with

the next update in the queue. When run in this mode, the directory administrator

needs to periodically check for errors in the logs, and take corrective action, if

necessary.

1. While the servers are running, issue the following command on each of the

supplier servers:

ldapmodify -D <adminDN> -w <adminpw> -f <config.ldif>

Where <config.ldif> contains the following information:

# Remove the original plugin line:

dn: cn=Directory, cn=RDBM Backends, cn=IBM Directory, cn=Schemas,

cn=Configuration

changetype: modify

delete: ibm-slapdPlugin

ibm-slapdPlugin: replication /lib/libldaprepl.a replInit

-

#Following a blank line add the new plug-in line:

add: ibm-slapdPlugin

ibm-slapdPlugin: replication /lib/libldaprepl.a replInit nonblocking

maxskippedreplerrors=50


Notes:

a. The library file name and path are platform specific:

v AIX operating systems - /lib/libldaprepl.a

v HP-UX operating systems - /lib/libldaprepl.sl

v Linux operating systems - /lib/libldaprepl.so

v Solaris operating systems - /lib/libldaprepl.so

v Windows operating systems - \bin\libldaprepl.dllb. There must be two blank spaces between the library file (libldaprepl.*) and

the command (replInit). If you copy this example from the PDF version of

this document to create your LDIF file, the two spaces might not be

preserved. Ensure that there are two blank spaces between libldaprepl.* and

replInit.

c. The maxskippedreplerrors=50 means that the number of skipped updates

have been limited to 50. You can set this limit to whatever you want. When

it is reached, the next error blocks replication.2. Stop and restart the servers.

3.5 Miscellaneous API information is incorrect

In the IBM Directory Server C-Client SDK Programming Reference Version 5.2, there

are several items that are incorrect. The following is the correct information.

LogType enumeration

The following data structure definition has changed. The following definition of

LogType is correct:

LogType ::= ENUMERATED {

SlapdErrors (1),

CLIErrors (2),

AuditLog (4),

BulkloadLog (8),

AdminErrors (16),

AdminAudit (32),

Debug OutputFile(64)

}

LDAPAPIInfo

The following data structure definition has changed. The following LDAPAPIInfo

structure definition is correct:

typedef struct ldapapiinfo {

int ldapai_info_version; /* version of this struct (1) */

int ldapai_api_version; /* revision of API supported */

int ldapai_protocol_version; /* highest LDAP version supported */

char **ldapai_extensions; /* names of API extensions */

const char *ldapai_vendor_name; /* name of supplier */

int ldapai_vendor_version; /* supplier-specific version times 100 */

} LDAPAPIInfo;

ldap_err2string()

For this API, a protocol has changed. The following protocol is correct:

const char *ldap_err2string(int error);

ldap_pwdpolicy_err2string()


const char *ldap_pwdpolicy_err2string(int err);


ldap_ssl_environment_init()


int ldap_ssl_environment_init(

const char *keydatabase,

const char *keydatabase_pw,

int ssl_timeout,

int *pSSLReasonCode) ;

ldap_ssl_init()


LDAP *ldap_ssl_init(

char *host,

int port,

const char *name);

ldap_add_control()


int ldap_add_control(

const char *oid, ber_len_t len ,

char *value,

int isCritical,

LDAPControl ***ctrlList);

ldap_set_locale()


int ldap_set_locale(const char *locale);

3.6 Running migration on UNIX-based platforms

To successfully migrate from a previous release on UNIX-based platforms, you

must log in as root before running the migration script (migrate52).

3.7 Replicating Password Policy Attributes

The user-related elements of the password policy are stored in the entries as

operational attributes. These attributes are subject to modifications even on a

read-only replica, so replicating these attributes are carefully considered.

pwdChangedTime

The pwdChangedTime attribute is replicated on all replicas, to enable

expiration of the password.

pwdReset

The pwdReset attribute is replicated on all replicas, to deny access to

operations other than bind and modify password.

pwdHistory

The pwdHistory attribute is replicated to writable replicas. This attribute

does not need to be replicated to a read-only replica, as the password is

never directly modified on this server.

pwdAccountLockedTime, pwdExpirationWarned, pwdFailureTime,

pwdGraceUseTime

The pwdAccountLockedTime, pwdExpirationWarned, pwdFailureTime and

pwdGraceUseTime attributes are replicated to writable replicas, making the

password policy global for all servers. When the user entry is replicated to

a read-only replica, these attributes are not replicated. This means that the


number of failures, the number of grace logins and the locking take place

on each replicated server. For example, the effective number of failed

attempts on a user password is:

N x M

where N is the number of servers and M is the value of pwdMaxFailure

attribute. Replicating these attributes to a read-only replica can reduce the

number of tries globally but can also introduce some inconstancies in the

way the password policy is applied.

There are times when the values of pwdAccountLockedTime,

pwdExpirationWarned, pwdFailureTime and pwdGraceUseTime are

replicated. If the user’s password is reset, thereby clearing some of these

attributes, this action is replicated to the read-only replicas. Also, if an

administrator on the master server uses the administrative control to

overwrite the values of these attributes on the master server, this forced

write of the operational attributes is also replicated to read-write and

read-only replicas.

3.8 Increasing secondary log files for password policy attribute

pwdchangedtime

The current implementation of ibm-pwdpolicy queries the database, finding all

user entries without the related password policy attributes. ibm-pwdpolicy then

builds a list of entry IDs (EIDs) and populates the pwdpolicy attribute

pwdchangedtime.

If an error is returned with rc == operations error, check <instance_home>/logs/db2cli.log. If the transaction log file is full, increase the secondary log files to a

larger size. For example, to increase the maximum number of secondary log files to

30, use the following DB2 command:

db2 update db cfg for <dbname> using LOGSECOND 30

Increasing LOGSECOND enables DB2 to open more temporary transaction log

files. These files can be freed up after the transaction is complete and reset to a

smaller number. You might have to adjust the value of LOGSECOND depending

on the size of the directory. Make sure your file system has enough room for these

files.

Related configuration values can be retrieved by calling:

db2 get db cfg for <dbname> | grep log

..

Number of primary log files (LOGPRIMARY) = 3

Number of secondary log files (LOGSECOND) = 30

Changed path to log files (NEWLOGPATH) =

Path to log files =

/<home>/<user1>/NODE0000/SQL00001/SQLOGDIR/

Overflow log path

(OVERFLOWLOGPATH) =

...


3.9 Moving data to IBM Tivoli Directory Server 5.2 from a previous

release without using a migration utility

Notes:

1. The following instructions assume you have installed IBM Tivoli Directory

Server 5.2 on your computer, and configured the server with a database

already.

2. You must install the latest IBM Tivoli Directory Server 5.2 Fix Pack on the

server. Go to the IBM Tivoli Directory Server Support Web site at

http://www-306.ibm.com/software/sysmgmt/products/support/IBMDirectoryServer.html to get the latest Fix Pack.

3. You must also install the correct version of DB2 (DB2 Version 8.1 with FixPak

2). DB2 Version 8.1 Enterprise Server Edition with FixPak 2 is included with

IBM Tivoli Directory Server 5.2 and is installed if a supported version of DB2 is

not detected on your system.

To import data onto an IBM Tivoli Directory Server 5.2 server from a previous

release of IBM Directory Server, where migration is not possible, do the following:

1. Use the db2ldif utility to save data on the previous release of IBM Directory

Server system:

db2ldif -o <outputfile>

where <outputfile> is your LDIF file. See ″db2ldif utility″ in the IBM Tivoli

Directory Server Administration Guide Version 5.2 at the following URL:

http://publib.boulder.ibm.com/tividd/td/IBMDirectoryServer5.2.html

2. Save any V3.* schema files to a different directory.

3. Configure a suffix on the new IBM Tivoli Directory Server 5.2 system:

ldapcfg -s <suffix>

where <suffix> is the suffix you want to add. See ″Using the ldapcfg utility″ in

the IBM Tivoli Directory Server Installation and Configuration Guide Version 5.2 at

the following URL:


4. Update the schema as necessary on the new IBM Tivoli Directory Server 5.2

system using the Web Administration Tool or command line utility. See

″Dynamic schema″ in the IBM Tivoli Directory Server Administration Guide

Version 5.2.

5. Transfer the LDIF file from the previous release of IBM Directory Server system

to your new IBM Tivoli Directory Server 5.2 system.

6. Use the bulkload or ldif2db utilities to import your LDIF file. See ″bulkload

utility″ or ″ldif2db utility″ in the IBM Tivoli Directory Server Administration Guide

Version 5.2.

7. If you have errors, such as the bulkload fails, you must update the schema

again. Use the bulkload or ldif2db utilities to import the LDIF file again.

Update the schema again to correct any remaining errors.

3.10 Subset of server management tasks displayed in Web

Administration Tool

In the Web Administration Tool, the server management tasks that are displayed in

the Navigation area vary depending on your authority, the capabilities of the

server you are logging on to, or both.






For example, for a z/OS server, even if you are logged on as an administrator, you

will see only Schema management and Directory management.

3.11 Note about using reorg for database tuning

In the Performance Tuning Guide, there is a list of guidelines for performing a reorg

to improve performance. The following note should be added to the list of

guidelines:

Note: Indices marked with an asterisk in a reorgchk output are only contenders

for reorging; reorging them might or might not necessarily improve

performance.

The list of guidelines can be found in the following section of the Performance

Tuning Guide:

See ″DB2 tuning.″ Go to ″Optimization and organization (reorgchk and reorg),″

and then to ″Database organization (reorgchk and reorg),″ and then see″Performing

a reorg.″

3.12 Correction to Tuning Guide: DB2 RUNSTATS command

In the Performance Tuning Guide, there is an error in the section that discusses the

DB2 RUNSTATS command.

See "DB2 tuning" (Chapter 3 in the PDF version). Go to ″Optimization and

organization (reorgchk and reorg),″ and then to "Optimization."

The last sentence in the section, discussing the DB2 RUNSTATS command, states

"You can use ALL for all tables." This statement is not correct. If you use the ALL

parameter, the following error occurs:

SQL0104N An unexpected token "ALL" was found following "TABLE".

Expected tokens may include: "<valid-table-name>".

SQLSTATE=42601


Appendix. Notices

This information was developed for products and services offered in the U.S.A.

IBM might not offer the products, services, or features discussed in this document

in other countries. Consult your local IBM representative for information on the

products and services currently available in your area. Any reference to an IBM

product, program, or service is not intended to state or imply that only that IBM

product, program, or service may be used. Any functionally equivalent product,

program, or service that does not infringe any IBM intellectual property right may

be used instead. However, it is the user’s responsibility to evaluate and verify the

operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter in

this document. The furnishing of this document does not give you any license to

these patents. You can send license inquiries, in writing, to:

IBM Director of Licensing

IBM Corporation

North Castle Drive

Armonk, NY 10504-1785

U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the IBM

Intellectual Property Department in your country or send inquiries, in writing, to:

IBM World Trade Asia Corporation Licensing

2-31 Roppongi 3-chome, Minato-ku

Tokyo 106, Japan

The following paragraph does not apply to the United Kingdom or any other

country where such provisions are inconsistent with local law:

INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS

PUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER

EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED

WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS

FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or

implied warranties in certain transactions, therefore, this statement may not apply

to you.

This information could include technical inaccuracies or typographical errors.

Changes are periodically made to the information herein; these changes will be

incorporated in new editions of the information. IBM may make improvements

and/or changes in the product(s) and/or the program(s) described in this

information at any time without notice.

Any references in this information to non-IBM Web sites are provided for

convenience only and do not in any manner serve as an endorsement of those Web

sites. The materials at those Web sites are not part of the materials for this IBM

product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it

believes appropriate without incurring any obligation to you.

49

Licensees of this program who wish to have information about it for the purpose

of enabling: (i) the exchange of information between independently created

programs and other programs (including this one) and (ii) the mutual use of the

information which has been exchanged, should contact:

IBM Corporation

Department MU5A46

11301 Burnet Road

Austin, TX 78758

U.S.A.

Such information may be available, subject to appropriate terms and conditions,

including in some cases, payment of a fee.

The licensed program described in this document and all licensed material

available for it are provided by IBM under terms of the IBM Customer Agreement,

IBM International Program License Agreement, or any equivalent agreement

between us.

Any performance data contained herein was determined in a controlled

environment. Therefore, the results obtained in other operating environments may

vary significantly. Some measurements may have been made on development-level

systems and there is no guarantee that these measurements will be the same on

generally available systems. Furthermore, some measurement may have been

estimated through extrapolation. Actual results may vary. Users of this document

should verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers of

those products, their published announcements or other publicly available sources.

IBM has not tested those products and cannot confirm the accuracy of

performance, compatibility or any other claims related to non-IBM products.

Questions on the capabilities of non-IBM products should be addressed to the

suppliers of those products.

This information contains examples of data and reports used in daily business

operations. To illustrate them as completely as possible, the examples include the

names of individuals, companies, brands, and products. All of these names are

fictitious and any similarity to the names and addresses used by an actual business

enterprise is entirely coincidental.

If you are viewing this information softcopy, the photographs and color

illustrations may not appear.

Trademarks

The following terms are trademarks of International Business Machines

Corporation in the United States, or other countries, or both:

AIX DB2 IBM SecureWay Tivoli WebSphere

Java and all Java-based trademarks and logos are trademarks or registered

trademarks of Sun Microsystems, Inc. in the United States and other countries.

Microsoft, Windows, and Windows NT are registered trademarks of Microsoft

Corporation.


UNIX is a registered trademark in the United States and/or other countries

licensed exclusively through X/Open Company Limited.

Linux is a trademark of Linus Torvalds in the United States, other countries, or

both.

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

of others.

Appendix. Notices 51

��

Printed in USA

IBM Tivoli Directory Server: IBM Tivoli Directory Server...

Documents

Transcript of IBM Tivoli Directory Server: IBM Tivoli Directory Server...