 |
Plug-in
Programmer's Guide Netscape Directory Server |
| Previous |
Contents |
Index |
DocHome | Next |
This chapter explains how to use the Data Interoperability (DIOP) feature of Netscape Directory Server (Directory Server). The DIOP feature refers to Directory Server's ability to work with a proprietary database, instead of the default database created during installation.
You can now use the enhanced pre-operation interfaces to implement plug-ins that are designed to provide access to alternative directory data stores, instead of the database backend plug-in interface, which is not support in current releases. You do this by developing a custom pre-operation plug-in to provide an alternate functionality for the LDAP operations, such as search, modify, add, and so on. These operations are generally targeted at the root suffix or the null DN (meaning dn:), and your plug-in will have to be designed to intercept these operations and divert them to be serviced by an alternate data source or alternate access methods.
This chapter covers deployment considerations, configuration changes required to use the DIOP feature, a list of supported and unsupported features, and other useful information.
This chapter contains the following sections:
This section explains how to install Directory Server in order to test and use the DIOP feature.
To verify whether the DIOP feature works in Directory Server, your deployment must comprise two instances of Directory Server:
For detailed information on directory deployments, check the Netscape Directory Server Deployment Guide. To understand the role of a configuration Directory Server in a directory deployment, check Managing Servers with Netscape Console.
Because the DIOP plug-in is a pre-operation plug-in, enabling the plug-in will impose certain limitations on the default behavior of Directory Server.
Figure 13-1 illustrates Directory Server deployment required for testing the DIOP feature.
In the above figure, slapd-<configInstance> is the configuration Directory Server and slapd-<diopInstance> is the Directory Server instance with the DIOP plug-in turned on.
To summarize the installation requirements for testing the DIOP feature:
For general information about installing Directory Server, refer to the accompanying Netscape Directory Server Installation Guide. You can also find the documentation for Directory Server at http://enterprise.netscape.com/docs/directory/index.html.
Follow these instructions to create two instances of Directory Server:
For a Directory Server instance to support the DIOP feature, its default configuration needs to be modified -- the server needs to be configured to use the null DN or the root suffix in the server. This can be done by adding the following entry to the dse.ldif file of the server instance in which you want to enable the DIOP feature:
dn:
cn="",cn=mapping tree,cn=config
objectClass:
top
objectClass:
extensibleObject
objectClass:
nsMappingTree
cn: ""
nsslapd-state: container
You can modify the dse.ldif in either of the following ways:
You can also add the above entry by running the ldapmmodify command on the slapd-<diopInstance> server with the an LDIF input file containing the above entry. For example, your command might look like this:
./ldapmodify -h host -p port -w password -D "cn=directory manager" -vcaf ldif_file_containing_the_entry
Once you add the above entry to the server
configuration, the DIOP functionality is enabled in the server.
|
|
|
|
An example plug-in is shipped with the server to show how a DIOP pre-operation plug-in can be used to work with the DIOP-enabled server. For details about the sample plug-in, see Sample DIOP Plug-in. To use the sample plug-in or your own custom plug-in in the server, see Using the DIOP Feature.
|
|
|
|
|
This section explains how you can verify whether the DIOP feature works in Directory Server. After you have successfully installed and configured two instances of Directory Servers, as explained in the preceding sections, follow the instructions in this section.
To help you understand the DIOP feature, a sample plug-in in provided. Details of this plug-in is covered in Sample DIOP Plug-in. It is recommended that you review the sample plug-in first and use that as an example to develop your own plug-in.
To verify the DIOP feature, you may use the sample plug-in or reconfigure Directory Server to use your own plug-in. You can also remove the plug-in altogether from the server.
To help you understand the DIOP feature, a sample DIOP plug-in is included with Directory Server. This section provides an overview of the sample plug-in and explains how you can use the plug-in to verify whether the DIOP feature works in Directory Server. The preceding section, Using the DIOP Feature, explains how you can use the sample plug-in. The next section, Debugging the Plug-in, explains how you can troubleshoot the plug-in.
The sample plug-in is located in the <server_root>/plugins/slapd/slapi/examples directory. The shared library for the plug-in is named libtest-plugin.so and is implemented by
testdatainterop.c[.h]
testdbinterop.c
db.h
located in the same directory.
In the following table, the various required elements of the pre-operation plug-in are identified by the function calls used in the testdatainterop.c (to illustrate the use and simplify understanding).
|
#define PLUGIN_NAME "nullsuffix-preop" static Slapi_PluginDesc plugindesc = {
PLUGIN_NAME, "Netscape", "6.1", "sample pre-operation null suffix
plugin" |
|
|
nullsuffix_init( Slapi_PBlock *pb ) In this function, all the callbacks are set up and will be called by the server for each LDAP operation. Flag used for LDAP operation Callback
SLAPI_PLUGIN_PRE_SEARCH_FN nullsuffix_search SLAPI_PLUGIN_PRE_ADD_FN nullsuffix_add SLAPI_PLUGIN_PRE_MODIFY_FN nullsuffix_modify SLAPI_PLUGIN_PRE_DELETE_FN nullsuffix_delete |
|
|
slapi_op_reserved(pb) is called to determine whether the operation should be handled internally by Directory Server; for example, whether the base on which the operation is applied is a reserved naming context. If slapi_op_reserved() returns a non-zero value, the plug-in does not attempt to handle that operation. It is done by the following code snippet: return PLUGIN_OPERATION_IGNORED; See testdatainterop.c for details. The slapi_op_reserved() function, which can be used for reserving some of the naming contexts in the Directory Server (cn=schema,cn=config,cn=monitor), is called first in the database plug-in and then the call for turning off access control. |
|
|
Any modifications done to the server on the null suffix are processed by the plug-in. The plug-in writes the DN of all modifications received to a standalone BerkleyDB, and trying a simple test using LDIF entries without the required object classes or parent entries will still get processed by the server, populating the database created by the plug-in. See nullsuffix_modify and testdbinterop.c for details. The plug-in has not been coded for the retrieval of those entries but has been coded to demonstrate sparse tree support only. |
|
|
Switching off access control for the operation is done by: slapi_operation_set_flag(op, SLAPI_OP_FLAG_NO_ACCESS_CHECK ); |
|
|
The plug-in cannot control the support for null-suffix in the server. The support for null-suffix is done through configuration modification of the server as shown in . |
|
|
The compiler used on Solaris is Forte. For example: cd <server_root>/plugins/slapd/slapi/examples |
If you need to debug the plug-in installed on a Solaris machine, you can use dbx:
Similar steps can be done on other platforms, using the platform-specific debuggers and commands.
This section contains reference information on APIs that enable the following:
Directory Server implements internal backends for supporting subtrees cn=config, cn=schema, and cn=monitor, which are the reserved naming contexts for the server. For more information about these, check the Netscape Directory Server Configuration, Command, and File Reference.
It may be required in some cases to let the default behavior of the server be preserved and not be intercepted by the custom pre-operation plug-ins. To implement a custom DIOP plug-in without affecting the default behavior of the Directory Server, a new function named slapi_op_reserved() is being made available. For details about this function, see Functions Related to Data Interoperability.
It may be desirable to disable access control checking for operations that are handled by the custom DIOP plug-in. To enable the plug-ins to bypass access control, a new flag, SLAPI_OP_FLAG_NO_ACCESS_CHECK, has been defined. You allow a custom plug-in to bypass access control by setting the flag on the operation-data structure, which is available to the plug-in through the parameter (pblock) setting; see chapter 16, "Parameter Block Reference."
The following functions have been defined for this purpose:
For details about
these
functions, see Functions
Related to Data Interoperability.
| Previous |
Contents |
Index |
DocHome | Next |