Tivoli directory server 6.1 installation

A static group using the structural object class groupOfNames and groupOfUniqueNames requires at least one member or uniquemember , respectively. All other object classes taking members require at least one member. This user will automatically be added to the group when a group is created. You can remove this user from the group after if you don't want this user to be a member of the group. Review the additional debug messages and consult the Messages Guide. You must have core file generation enabled in order for core file information to be generated.

See Generating core files for more information about core files and for instructions for enabling core file generation. IBM Tivoli Directory Server contains several tools in addition to the operating system tools to help you determine the source of problems you encounter continued :.

See Logging utilities for more information. If security is violated, the audit log can be used to determine how and when the problem occurred. The most useful resources in debugging an issue with Installation and configuration are as follows: 2.

If installation does not complete, the first place you can look for information is the ldapinst. To find it, search for "ldapinst. Review this log for any messages about why the installation failed.

Basic Debugging — Failed Instance Creation In order to get more debugging information, it is best to use the command line utilities to debug errors. The idsicrt utility provides us with the functionality to trace a failed instance creation and configuration attempt.

Basic Debugging — Failed Database Creation In order to get more debugging information, it is best to use the command line utilities to debug errors. The idscfgdb utility provides us with the functionality to trace a failed database creation and configuration attempt. We cannot access any of the data stored in the backend. To find out what exactly is failing we will typically enable a trace of the server start up. Usually the SystemErr. To resolve the port conflict, with the wsmserver change the default port for the embedded version of IBM WebSphere Application Server - Express from to Edit the following two files and change to Do the same thing in the.

Note: This path does have two subdirectories named DefaultNode. Make one change in each file for a total of two updates. Otherwise use ibmdirctl or WebAdmin to start ibmslapd. Open navigation menu. Close suggestions Search Search. User Settings. Skip carousel. Carousel Previous. Carousel Next. What is Scribd? Explore Ebooks. Bestsellers Editors' Picks All Ebooks.

Explore Audiobooks. Bestsellers Editors' Picks All audiobooks. Explore Magazines. Editors' Picks All magazines. Explore Podcasts All podcasts. Information About the Plug-ins. Parameters for the Configuration Function. Parameters for the Bind Function. Parameters for the Search Function. See also. Plug-in examples. Intended audience for this book This book is intended for directory server administrators who are responsible for maintaining and troubleshooting IBM Tivoli Directory Server and programmers.

The section also describes how to access Tivoli publications online and how to order Tivoli publications. Includes a short product description and architecture diagram, as well as a pointer to the product Information Center and installation instructions. Describes disk requirements and other hardware needs for directories of different sizes and with various read and write rates. Describes known working scenarios for each of these levels of directory and the disk and memory used; also suggests rough rules of thumb.

Contains information about installing, configuring, and using the application for both administrators and users. See this document for information about the JNDI client. Accessing terminology online The Tivoli Software Glossary includes definitions for many of the technical terms related to Tivoli software. In the Tivoli Information Center window, click Tivoli product manuals.

Click the letter that matches the first letter of your product name to access your product library. You can also order by telephone by calling one of these numbers: v In the United States: v In Canada: In other countries, contact your software account representative to order Tivoli publications. To locate the telephone number of your local representative, perform the following steps: 1. Select your country from the list and click Go. Click About this site in the main panel to see an information page that includes the telephone number of your local representative.

Accessibility Accessibility features help users with 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.

You can also use the keyboard instead of the mouse to operate all features of the graphical user interface. Support information If you have a problem with your IBM software, you want to resolve it quickly. About this book vii Conventions used in this book This book uses several conventions for special terms and actions, operating system-dependent commands and paths, and margin graphics.

Typeface conventions This book uses the following typeface conventions: Bold v Lowercase commands and mixed case commands that are otherwise difficult to distinguish from surrounding text v Interface controls check boxes, push buttons, radio buttons, spin buttons, fields, folders, icons, list boxes, items inside list boxes, multicolumn lists, containers, menu choices, menu names, tabs, property sheets , labels such as Tip:, and Operating system considerations: v Keywords and parameters in text Italic v Citations examples: titles of books, diskettes, and CDs v Words defined in text example: a nonswitched line is called a point-to-point line v Emphasis of words and letters words as words example: "Use the word that to introduce a restrictive clause.

Monospace v Examples and code examples v File names, programming keywords, and other elements that are difficult to distinguish from surrounding text v Message text and prompts addressed to the user v Text that the user must type v Values for arguments or command options Operating system-dependent variables and paths This book uses the UNIX convention for specifying environment variables and for directory notation. Server plug-ins extend the capabilities of your Directory Server.

Once the plug-ins are loaded, the server calls the functions in a shared library by using function pointers. A server front-end listens to the wire, receives and parses requests from clients, and then processes the requests by calling an appropriate database back-end function. A server back-end reads and writes data to the database containing the directory entries. If the front-end fails to process a request it returns an error message to the client; otherwise, the back-end is called. After the back-end is called, it must return a message to the client.

Either the front-end or the back-end, but not both can return a message to the client. Note: This differs from the iPlanet server plug-in in that only the front-end of the iPlanet plug-in can send a message back to the client. In this release of the IBM Tivoli Directory Server the following types of server plug-ins are supported: Database plug-ins Can be used to integrate your own database as a back-end to the server.

A database plug-in can consist of all or only a portion of the functions discussed in this document. For example, the rdbm database back-end is a database plug-in. It provides functions that enable the server to interact with the DB2 database. For example, you can write a plug-in that checks new entries before they are added to the directory. Audit plug-ins Are used to improve the security of the directory server.

A default audit plug-in is provided with the server. Depending on the audit configuration parameters, this plug-in might log an audit entry in the default or specified audit log for each LDAP operation the server processed. If security is violated, the audit log can be used to determine how and when the problem occurred and perhaps the amount of damage done.

This information is very useful, both for recovery from the violation and, possibly, in the development of better security measures to prevent future problems. You can also write your own audit plug-ins to either replace, or add more processing to, the default audit plug-in. DN partitioning plug-ins Tivoli Directory Server provides an option to users to dynamically load customer written DN partitioning function during server runtime.

The existing hash algorithm that is used to partition data is statically linked by the Tivoli Directory Server. However, with DN partitioning function implemented as a plug-in, the existing hash algorithm can be easily replaced with the customer written DN partitioning plug-in resulting in the Tivoli Directory Server being more flexible and adaptive.

The existing hash algorithm however remains as the default DN partitioning plug-in, which is loaded during server startup if no customized code is available. A server plug-in can return a message to the client as well. However, make sure that the server returns only one message. Writing a plug-in A pblock is an opaque structure in which many parameters are stored. It is used to communicate between the server and your plug-ins. Application program interfaces APIs are provided for your plug-ins to get or set parameters in this structure.

Notes: 1. Plug-ins must be written using reentrant system calls. There is no global mutex issue that the plug-in writer has to be concerned about in terms of interacting with the server.

However, because each request is serviced by a thread, and each thread might exercise the plug-in code, if there is any shared resource that the plug-in code creates, then mutex might be needed to protect the resources. Start by writing your functions. Include slapi-plugin. You also can find a set of function prototypes for the available functions in the slapi-plugin. Decide the input parameters for your functions.

Depending on the type of plug-in you are writing, you might need to work with a different set of parameters. The following output is received from your functions: return code You can have the return code set to 0, which means that the server continues the operation.

A return code of non-zero means that the server stops processing the operation. For example, if you have a pre-operation bind function that authenticates a user, it returns a non-zero after the authentication has been completed successfully. Otherwise, you can return a 0 and let the default bind operation continue the authentication process.

For each operation, make sure there is only one LDAP result sent. If you use the default database, do not have the post-operation return a message to the client. The server can then use it to continue with the processing of the operations requested by the user.

Call slapi APIs in the libslapi library file. Write an initialization function for your plug-in to register your plug-in functions.

Export your initialization function from your plug-in shared library. Use an. For other UNIX platforms, the exportation of the function is automatic when you create the shared library. Compile and link your server plug-in object files with whatever libraries you need, and libslapi library file. Add a plug-in directive in the server configuration file. The syntax of the plug-in directive is: attributeName: plugin-type plugin-path init-func args On a Windows NT operating system, in the ibmslapd.

This attribute is one of the attributes contained in objectclasses, such as ibm-slapdRdbmBackend and ibm-slapdLdcfBackend. For instance, in ibmslapd. In this entry, a database plug-in is specified by using the ibm-slapdPlugin attribute so that the server knows where and how to load this plug-in.

If there is another plug-in to be loaded, such as a changelog plug-in, then specify it using another ibm-slapdPlugin attribute. Writing a plug-in 5 6 Server Plug-ins Reference Chapter 3.

Database plug-ins Database plug-ins can be used to integrate your own database as a back-end to the server. A database plug-in can consist of all or a portion of the functions discussed in this section. LDAP protocol-related functions Are the default database functions. When you write a database plug-in you might not want to provide every function to handle the default database operations. You might need to provide some stub functions, however, which are used to send back an unwilling to perform message to the client when a particular function is not active.

Back-end-related functions Are used to initialize or shut down the back-end and to handle back-end-specific configuration. Note: Stand-alone, user-supplied server back-end plug-ins are not supported. However, they are supported when used in parallel with IBM-supplied server back-end plug-ins. Operation plug-ins The following plug-in functions can be performed before or after an LDAP operation.

Extended operation plug-ins LDAP operations can be extended with your own extended operation functions provided by a plug-in. After receiving and processing an extended operation request, an extended operation plug-in function might itself send an extended operation response back to a client or let the server send such a response. If the plug-in has not sent an LDAP result message to the client, the plug-in returns an LDAP result code and the server sends this result code back to the client.

The list of OIDs which is listed in the ibm-slapdPlugin directive in ibmslapd. This list of extended operations can be queried by performing a search of the root DSE. For example, in the Windows NT environment to specify an extended operation plug-in in the ibmslapd. The myExtendedOp function that is registered in the initialization is used to handle the extended-operations.

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 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. Operation plug-ins 11 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. 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. 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. Note: There is no plug-in interface to the administration daemon audit.

Configuration options The Audit Service has the following configuration options: ibm-slapdLog Specifies the path name of the audit log. Default is TRUE. Default is 3.