Novell Import Conversion Export Utility

The Novell Import Conversion Export utility lets you:

• Import data from LDIF files to the LDAP directory
• Export data from the LDAP directory to an LDIF file
• Migrate data between LDAP servers

The Novell Import Conversion Export utility manages a collection of handlers that read or write data in a variety of formats. Source handlers read data, while destination handlers write data. A single executable module can be both a source and a destination handler. The engine receives data from a source handler, processes the data, then passes the data to a destination handler.

For example, if you want to import LDIF data into an LDAP directory, the Novell Import Conversion Export engine uses an LDIF source handler to read an LDIF file and an LDAP destination handler to send the data to the LDAP directory server. See Troubleshooting LDIF Files for more information on LDIF file syntax, structure, and debugging.

You can run the Novell Import Conversion Export client utility from the command line or from a snap-in to ConsoleOne^TM. The comma-delimited data handler, however, is a command line utility only.

You can use the Novell Import Conversion Export utility in either of the following ways:

• Using the Novell eDirectory Import/Export Wizard
• Using the Command Line Interface

The wizard and the command line interface both give you access to the Novell Import Conversion Export engine, but the command line interface gives you greater options for combining source and destination handlers.

The Novell Import Conversion Export utility replaces both the BULKLOAD and ZONEIMPORT utilities included with previous versions of NDS and eDirectory.

Using the Novell eDirectory Import/Export Wizard

The Novell eDirectory Import/Export Wizard is a ConsoleOne snap-in designed to help you:

• Import data from LDIF files to the LDAP directory
• Export data from the LDAP directory to an LDIF file
• Perform a LDAP server-to-LDAP server data migration

Performing an LDIF Import

1. In ConsoleOne, select Wizard > NDS Import/Export.

2. Click Import LDIF File > Next.

3. Enter the name of the LDIF file containing the data you want to import > click Next.

   Click Advanced to set other LDIF source handler options. Click Help on the Advanced dialog box for more information on the available options.

4. Select the LDAP server where the data will be imported.

   You can store information for several servers and name each set of information. Click New to add a new server.

5. Add the information from Table 31.

   
   Table 31. LDAP Server Options

   Option	Description
   Server DNS name/IP address	Enter the DNS name or IP address of the destination LDAP server.
   Port	Enter the integer port number of the destination LDAP server.
   DER file containing server key used for SSL communication	Enter the name of the DER file containing a server key used for SSL authentication.
   Login method	Click Authenticated Login or Anonymous for the entry specified in the User DN field.
   User DN	Enter the distinguished name of the entry that should be used when binding to the server-specified bind operation.
   Password	Enter the password attribute of the entry specified in the User DN field.

6. Click Next > Finish to begin the LDIF import.

Performing an LDIF Export

1. In ConsoleOne, select Wizard > NDS Import/Export.

2. Click Export LDIF File > Next.

3. Select the LDAP server holding the entries you want to export.

   You can store information for several servers and name each set of information. Click New to add a new server. Click Advanced to set additional options for the LDAP source handler. Click Help on the Advanced dialog box for more information on the available options.

4. Add the information from Table 32.

   
   Table 32. LDAP Server Options

   Option	Description
   Server DNS name/IP address	Enter the DNS name or IP address of the source LDAP server.
   Port	Enter the integer port number of the source LDAP server.
   DER file containing server key used for SSL communication	Enter the name of the DER file containing a server key used for SSL authentication.
   Login method	Click Authenticated Login or Anonymous for the entry specified in the User DN field.
   User DN	Enter the distinguished name of the entry that should be used when binding to the server-specified bind operation.
   Password	Enter the password attribute of the entry specified in the User DN field.

5. Click Next.

6. Specify the search criteria for the entries you want to export.

   
   Table 33. Search Criteria Options

   Option	Description
   Base DN	Enter the base distinguished name for the search request. If this field is left empty, the base DN defaults to "" (empty string).
   Scope	Specifies the scope of the search request.
   Filter	Enter an RFC 1558 compliant search filter. The default is objectclass=*.
   Attributes	Specify the attributes you want returned for each search entry.

7. Click Next.

8. Enter the name of the LDIF file that will store the export information > click Next.

9. Click Finish to begin the LDIF export.

Performing Data Migration between LDAP Servers

1. In ConsoleOne, select Wizard > NDS Import/Export.

2. Click Migrate Data between LDAP Servers > Next.

3. Select the LDAP server holding the entries you want to migrate.

   You can store information for several servers and name each set of information. Click New to add a new server. Click Advanced to set additional options for the LDAP source handler. Click Help on the Advanced dialog box for more information on the available options.

4. Add the information from Table 34.

   
   Table 34. LDAP Server Options

   Option	Description
   Server DNS name/IP address	Enter the DNS name or IP address of the source LDAP server.
   Port	Enter the integer port number of the source LDAP server.
   DER file containing server key used for SSL communication	Enter the name of the DER file containing a server key used for SSL authentication.
   Login method	Click Authenticated Login or Anonymous for the entry specified in the User DN field.
   User DN	Enter the distinguished name of the entry that should be used when binding to the server-specified bind operation.
   Password	Enter the password attribute of the entry specified in the User DN field.

5. Click Next.

6. Specify the following search criteria for the entries you want to migrate:

   
   Table 35. Search Criteria Options

   Option	Description
   Base DN	Enter the base distinguished name for the search request. If this field is left empty, the base DN defaults to "" (empty string).
   Scope	Specifies the scope of the search request.
   Filter	Enter an RFC 2254 compliant search filter. The default is objectclass=*.
   Attributes	Specifies the attributes you want returned for each search entry.

7. Click Next.

8. Select the LDAP server where the data will be migrated.

9. Click Next > Finish.

   NOTE:  Ensure that the schema is consistent across LDAP Services.

Using the Command Line Interface

You can use the command line version of the Novell Import Conversion Export utility to perform the following:

• LDIF imports
• LDIF exports
• Comma-delimited data imports
• Comma-delimited data exports
• Data migration between LDAP servers

The Novell Import Conversion Export utility is installed as part of ConsoleOne. Both a Win32* version (ICE.EXE) and a NetWare^® version (ICE.NLM) are included in the installation. On Linux and Solaris systems, the Import/Export utility is included in the NDSadmutl package.

Novell Import Conversion Export Syntax

The Novell Import Conversion Export utility is launched with the following syntax:

ice general_options
-S[LDIF | LDAP | DELIM] source_options
-D[LDIF | LDAP | DELIM] destination_options

General options are optional and must come before any source or destination options. The -S (source) and -D (destination) handler sections can be placed in any order.

The following is a list of the available source and destination handlers:

• LDIF Source Handler Options
• LDIF Destination Handler Options
• LDAP Source Handler Options
• LDAP Destination Handler Options
• DELIM Source Handler Options
• DELIM Destination Handler Options

General Options

General options affect the overall processing of the Novell Import Conversion Export engine.

Table 36. General Options

Source Handler Options

The source handler option (-S) determines the source of the import data. Only one of the following can be specified on the command line.

Table 37. Source Handler Options

Destination Handler Options

The destination handler options (-D) specify the destination of the export data. Only one of the following can be specified on the command line.

Table 38. Destination Handler Options

LDIF Source Handler Options

The LDIF source handler reads data from an LDIF file then sends it to the Novell Import Conversion Export engine.

Table 39. LDIF Source Handler Options

LDIF Destination Handler Options

The LDIF destination handler receives data from the Novell Import Conversion Export engine and writes it to an LDIF file.

Table 40. LDIF Destination Handler Options

LDAP Source Handler Options

The LDAP source handler reads data from an LDAP server by sending a search request to the server. It then sends the search entries it receives from the search operation to the Novell Import Conversion Export engine.

Table 41. LDAP Source Handler Options

LDAP Destination Handler Options

The LDAP destination handler receives data from the Novell Import Conversion Export engine and sends it to an LDAP server in the form of update operations to be performed by the server.

Table 42. LDAP Destination Handler Options

DELIM Source Handler Options

The DELIM source handler reads data from a comma-delimited data file, then sends it to the destination handler.

Table 43. DELIM Source Handler Options

DELIM Destination Handler Options

The DELIM destination handler receives data from the source handler and writes it to a comma-delimited data file.

Table 44. DELIM Destination Handler Options

Examples

Listed below are sample commands that can be used with the Novell Import Conversion Export command line utility for the following functions: 

• Performing an LDIF Import
• Performing an LDIF Export
• Performing a Comma-Delimited Import
• Performing a Comma-Delimited Export
• Performing a Data Migration between LDAP Servers

Performing an LDIF Import

To perform an LDIF import, combine the LDIF source and LDAP destination handlers, for example:

ice -S LDIF -f entries.ldif -D LDAP -s server1.acme.com -p 389 -d cn=admin,c=us -w secret

This command line reads LDIF data from ENTRIES.LDIF and sends it to the LDAP server server1.acme.com at port 389 using the identity cn=admin,c=us, and the password "secret."

Performing an LDIF Export

To perform an LDIF export, combine the LDAP source and LDIF destination handlers, for example:

ice -S LDAP -s server1.acme.com -p 389 -d cn=admin,c=us -w password -F objectClass=* -c sub -D LDIF -f server1.ldif

This command line performs a subtree search for all objects in the server server1.acme.com at port 389 using the identity cn=admin,c=us, and the password "password," and outputs the data in LDIF format to SERVER1.LDIF.

Performing a Comma-Delimited Import

To perform a comma-delimited import, use a command similar to the following:

ice -SDELIM -f/tmp/in.csv -F/tmp/order.csv -ncn -lo=acme -DLDAP -sserver1.acme.com -p389 -dcnadmin,c=us -wsecret

This command reads comma-delimited values from the C:\TMP\IN.CSV file and reads the attribute order from the C:TMP\ORDER.CSV file. For each attribute entry in IN.CSV, the attribute type is specified in ORDER.CSV. For example, if IN.CSV contains the following:

pat,pat,engineer,john

Then ORDER.CSV would contain the following:

dn,cn,objectclass,title,sn

The information in ORDER.CSV could be input directly using the -t option.

The data is then sent to the LDAP server server1.acme.com at port 389 using the identity cn=admin,c=us, and password "secret."

This example specifies that cn should become the new DN for this object using the -n option, and this object was added to the organization container acme using the -l option.

Performing a Comma-Delimited Export

To perform a comma-delimited export, use a command similar to the following:

ice -SLDAP -sserver1.acme.com -p389 -dcn=admin,c=us -wpassword -lobjectClass=* -csub -DDELIM -f/tmp/server1.csv -Forder.csv

This command line performs a subtree search for all objects in the server server1.acme.com at port 389 using the identity cn=admin,c=us, and password "password" and outputs the data in comma-delimited format to the /TMP/SERVER1.CSV file.

Performing a Data Migration between LDAP Servers

To perform a data migration between LDAP servers, combine the LDAP source and LDAP destination handlers, for example:

ice -S LDAP -s server1.acme.com -p 389 -d cn=admin,c=us -w password -F objectClass=* -c sub -D LDAP -s server2.acme.com -p 389 -d cn=admin,c=us -w secret

This particular command line performs a subtree search for all objects in the server server1.acme.com at port 389 using the identity cn=admin,c=us with the password "password," and sends it to the LDAP server server2.acme.com at port 389 using the identity cn=admin,c=us and the password "secret."

Conversion Rules

The Novell Import Conversion Export engine lets you specify a set of rules that describe processing actions to be taken on each record received from the source handler and before the record is sent on to the destination handler. These rules are specified in XML (either in the form of an XML file or XML data stored in the directory) and solve the following problems when importing entries from one LDAP directory to another:

• Schema differences
• Hierarchical differences
• Missing information

There are three types of conversion rules:

Table 45. Conversion Rules

You can enable conversion rules in both the Novell eDirectory Import/Export Wizard and the command line interface. For more information on XML rules, see Using XML Rules.

Using the Novell eDirectory Import/Export Wizard

1. In ConsoleOne, select Wizard > NDS Import/Export.

2. Click the task you want to perform.

3. Click Advanced > complete the following options:

   Option	Description
   Schema Rules	Specifies the location of an XML schema mapping rule to be used by the engine.
   Placement Rules	Specifies the location of an XML placement rule to be used by the engine.
   Creation Rules	Specifies the location of an XML creation rule to be used by the engine.

4. Click Close.

5. Follow the online instructions to finish your selected task.

Using the Command Line Interface

You can enable conversion rules with the -p, -c, and -s general options on the Novell Import Conversion Export executable. For more information, see General Options.

Table 46. Conversion Rules Options

For all three options, URL must be one of the following:

• A URL of the following format:

  file://[path/]filename

  The file must be on the local file system.

• An RFC 2255-compliant LDAP URL that specifies a base level search and an attribute list consisting of a single attribute description for a singled-valued attribute type.

Using XML Rules

The Novell Import Conversion Export conversion rules use the same XML format as DirXML^TM. For more information on DirXML, see DirXML Administration Guide.

Schema Mapping Rules

The <attr-name-map> element is the top level element for the schema mapping rules. Mapping rules determine how the import schema interacts with the export schema. They associate specified import class definitions and attributes with corresponding definitions in the export schema.

Mapping rules can be set up for attribute names or class names.

• For an attribute mapping, the rule must specify that it is an attribute mapping, a name space (nds-name is the tag for the source name), the name in the eDirectory name space, and then the other name space (app-name is the tag for the destination name) and the name in that name space. It can specify that the mapping applies to a specific class, or it can be applied to all classes with the attribute.
• For a class mapping, the rule must specify that it is a class mapping rule, a name space (eDirectory or the application), the name in that name space, and then the other name space and the name in that name space.

The following is the formal DTD definition of schema mapping rules.

<!ELEMENT attr-name-map (attr-name | class-name)*>

<!ELEMENT attr-name (nds-name, app-name)>
<!ATTLIST attr-name 
          class-name    CDATA    #IMPLIED>

<!ELEMENT class-name (nds-name, app-name)>

<!ELEMENT nds-name (#PCDATA)>

<!ELEMENT app-name (#PCDATA)>


You can have multiple mapping elements in the file. Each element is processed in the order that it appears in the file. If you map the same class or attribute more than once, the first mapping takes precedence.

The following samples illustrate how to create a schema mapping rule.

Schema Rule 1: The following rule maps the source's surname attribute to the destination's sn attribute for the inetOrgPerson class.

<attr-name-map>
   <attr-name class-name="inetOrgPperson">
      <nds-name>surname</nds-name>
      <app-name>sn</app-name>
   </attr-name>
</attr-name-map>

Schema Rule 2: The following rule maps the source's inetOrgPerson class definition to the destination's User class definition.

<attr-name-map>
   <class-name>
      <nds-name>inetOrgPerson</nds-name>
      <app-name>User</app-name>
   </class-name>
</attr-name-map>

Schema Rule 3: The following example contains two rules. The first rule maps the source's Surname attribute to the destination's sn attribute for all classes that use these attributes. The second rule maps the source's inetOrgPerson class definition to the destination's User class definition.

<attr-name-map>
   <attr-name>
      <nds-name>surname</nds-name>
      <app-name>sn</app-name>
   </attr-name>
   <class-name>
      <nds-name>inetOrgPerson</nds-name>
      <app-name>User</app-name>
   </class-name>
</attr-name-map>

Sample Command: If the schema rules are saved to an SR1.XML file, the following command instructs the utility to use the rules while processing the 1ENTRY.LDF file and to send the results to a destination file, OUTT1.LDF.

ice -o -sfile://sr1.xml -SLDIF -f1entry.ldf -c -DLDIF 
-foutt1.ldf

Create Rules

Create rules specify the conditions for creating a new entry in the destination directory. They support the following elements:

• Required Attributes: Specifies that an add record must have values for all of the required attributes, or the add fails. The rule can supply a default value for a required attribute. If a record does not have a value for the attribute, the entry is given the default value. If the record has a value, the record value is used.

• Matching Attributes: Specifies that an add record must have the specific attributes and match the specified values, or the add fails.

• Templates: Specifies the distinguished name of a template object in eDirectory. The Novell Import Conversion Export utility does not currently support specifying templates in create rules.

The following is the formal DTD definition for create rules:

<!ELEMENT create-rules (create-rule)*>

<!ELEMENT create-rule (match-attr*, 
                       required-attr*, 
                       template?) >
<!ATTLIST create-rule 
          class-name    CDATA   #IMPLIED
          description   CDATA   #IMPLIED>

<!ELEMENT match-attr    (value)+ >
<!ATTLIST match-attr
          attr-name      CDATA    #REQUIRED>

<!ELEMENT required-attr (value)*>
<!ATTLIST required-attr 
          attr-name     CDATA   #REQUIRED>

<!ELEMENT template EMPTY>
<!ATTLIST template
          template-dn   CDATA   #REQUIRED>


You can have multiple create rule elements in the file. Each rule is processed in the order that it appears in the file. If a record does not match any of the rules, that record is skipped and the skipping does not generate an error.

The following examples illustrate how to format create rules.

Create Rule 1: The following rule places three conditions on add records that belong to the inetOrgPerson class. These records must have givenName and Surname attributes. They should have an L attribute, but if they don't, the create rule supplies a default value of Provo for them.

<create-rules>
   <create-rule class-name="inetOrgPerson">
      <required-attr attr-name="givenName"/>
      <required-attr attr-name="surname"/>
      <required-attr attr-name="L">
         <value>Provo</value>
      </required-attr>
   </create-rule>
</create-rules>

Create Rule 2: The following create rule places three conditions on all add records, regardless of their base class:

• The record must contain a givenName attribute. If it doesn't, the add fails.
• The record must contain a Surname attribute. If it doesn't, the add fails.
• The record must contain an L attribute. If it doesn't, the attribute is set to a value of Provo.

<create-rules>
   <create-rule>
      <required-attr attr-name="givenName"/>
      <required-attr attr-name="Surname"/>
      <required-attr attr-name="L">
         <value>Provo</value>
      </required-attr>
   </create-rule>
</create-rules>

Create Rule 3: The following create rule places two conditions on all records, regardless of base class:

• The rule checks to see if the record has a uid attribute with a value of ratuid. If it doesn't, the add fails.
• The rule checks to see if the record has an L attribute. If it does not have this attribute, the L attribute is set to a value of Provo.

<create-rules>
   <create-rule>
      <match-attr attr-name="uid">
         <value>cn=ratuid</value>
      </match-attr>
      <required-attr attr-name="L">
         <value>Provo</value>
      </required-attr>
   </create-rule>
</create-rules>

Sample Command: If the create rules are saved to an CRL.XML file, the following command instructs the utility to use the rules while processing the 1ENTRY.LDF file and to send the results to a destination file, OUTT1.LDF.

ice -o -cfile://cr1.xml -SLDIF -f1entry.ldf -c -DLDIF 
-foutt1.ldf

Placement Rules

Placement rules determine where an entry is created in the destination directory. They support the following conditions for determining whether the rule should be used to place an entry:

• Match Class: If the rule contains any match class elements, an objectClass specified in the record must match the class-name attribute in the rule. If the match fails, the placement rule is not used for that record.

• Match Attribute: If the rule contains any match attribute elements, the record must contain an attribute value for each of the attributes specified in the match attribute element. If the match fails, the placement rule is not used for that record.

• Match Path: If the rule contains any match path elements, a portion of the record's dn must match the prefix specified in the match path element. If the match fails, the placement rule is not used for that record.

The last element in the rule specifies where to place the entry. The placement rule can use zero or more of the following:

• PCDATA: Uses parsed character data to specify the DN of a container for the entries.

• Copy the Name: Specifies that the RDN of the old DN is used in the entry's new DN.

• Copy the Attribute: Specifies the naming attribute to use in the entry's new DN. The specified naming attribute must be a valid naming attribute for the entry's base class.

• Copy the Path: Specifies that the source DN should be used as the destination DN.

• Copy the Path Suffix: Specifies that the source DN, or a portion of its path, should be used as the destination DN. If a match-path element is specified, only the part of the old DN that matches the prefix attribute of the match-path element is used as part of the entry's DN.

The following is the formal DTD definition for the placement rule.

<!ELEMENT placement-rules (placement-rule*)>
<!ATTLIST placement-rules
          src-dn-format    (%dn-format;)   "slash"
          dest-dn-format   (%dn-format;)   "slash"
          src-dn-delims    CDATA           #IMPLIED
          dest-dn-delims   CDATA           #IMPLIED>

<!ELEMENT placement-rule (match-class*,
                          match-path*,
                          match-attr*,
                          placement)>
<!ATTLIST placement-rule
          description      CDATA            #IMPLIED>

<!ELEMENT match-class      EMPTY>
<!ATTLIST match-class
          class-name       CDATA            #REQUIRED>

<!ELEMENT match-path       EMPTY>
<!ATTLIST match-path
          prefix           CDATA            #REQUIRED>

<!ELEMENT match-attr       (value)+ >
<!ATTLIST match-attr
          attr-name        CDATA            #REQUIRED>

<!ELEMENT placement        (#PCDATA | 
                           copy-name | 
                           copy-attr | 
                           copy-path | 
                           copy-path-suffix)* >


You can have multiple placement-rule elements in the file. Each rule is processed in the order that it appears in the file. If a record does not match any of the rules, that record is skipped, and the skipping does not generate an error.

The following examples illustrate how to format placement rules. The scr-dn-format="ldap" and dest-dn-format="ldap" attributes set the rule so that the name space for the dn in the source and destination is LDAP format.

The Novell Import Conversion Export utility only supports source and destination names in LDAP format.

Placement Example 1: The following placement rule requires that the record have a base class of inetOrgPerson. If the record matches this condition, the entry is placed immediately subordinate to the test container and the left-most component of its source dn is used as part of its dn.

<placement-rules src-dn-format="ldap" dest-dn-format="ldap">
    <placement-rule> 
       <match-class class-name="inetOrgPerson"></match-class>
       <placement>o=test<copy-name/></placement> 
    </placement-rule> 
 </placement-rules>

With this rule, a record with a base class of inetOrgPerson and with the following dn:

dn: cn=Kim Jones, ou=English, ou=Humanities, o=UofZ

would have the following dn in the destination directory:

dn: cn=Kim Jones, o=test

Placement Example 2: The following placement rule requires that the record have an sn attribute. If the record matches this condition, the entry is placed immediately subordinate to the test container and the left-most component of its source dn is used as part of its dn.

<placement-rules src-dn-format="ldap" dest-dn-format="ldap">
    <placement-rule> 
       <match-attr attr-name="sn"></match-attr> 
       <placement>o=test<copy-name/></placement> 
    </placement-rule> 
 </placement-rules>

With this rule, a record with the following dn and sn attribute:

dn: cn=Kim Jones, ou=English, ou=Humanities, o=UofZ
sn: Jones

would have the following dn in the destination directory:

dn: cn=Kim Jones, o=test

Placement Example 3: The following placement rule requires the record to have an sn attribute. If the record matches this condition, the entry is placed immediately subordinate to the test container and its sn attribute is used as part of its dn. The specified attribute in the copy-attr element must be a naming attribute of the entry's base class.

<placement-rules src-dn-format="ldap" dest-dn-format="ldap">
  <placement-rule> 
    <match-attr attr-name="sn"></match-attr> 
    <placement>o=test<copy-attr attr-name="sn"/></placement>
  </placement-rule> 
</placement-rules>

With this rule, a record with the following dn and sn attribute:

dn: cn=Kim Jones, ou=English, ou=Humanities, o=UofZ
sn: Jones

would have the following dn in the destination directory:

dn: cn=Jones, o=test

Placement Sample 4: The following placement rule requires the record to have an sn attribute. If the record matches this condition, the source dn is used as the destination dn.

<placement-rules src-dn-format="ldap" dest-dn-format="ldap">
    <placement-rule> 
       <match-attr attr-name="sn"></match-attr> 
       <placement><copy-path/></placement> 
    </placement-rule> 
 </placement-rules>

Placement Sample 5: The following placement rule requires the record to have an sn attribute. If the record matches this condition, the entry's entire DN is copied to the test container.

<placement-rules src-dn-format="ldap" dest-dn-format="ldap">
    <placement-rule> 
       <match-attr attr-name="sn"></match-attr> 
       <placement>o=test<copy-path-suffix/></placement> 
    </placement-rule> 
 </placement-rules>

With this rule, a record with the following dn and sn attribute:

dn: cn=Kim Jones, ou=English, ou=Humanities, o=UofZ
sn: Jones

would have the following dn in the destination directory:

dn: cn=Kim Jones, ou=English, ou=Humanities, o=UofZ, o=test

Sample Command: If the placement rules are saved to an PR1.XML file, the following command instructs the utility to use the rules while processing the 1ENTRY.LDF file and to send the results to a destination file, FOUTT1.LDF

ice -o -pfile://pr1.xml -SLDIF -f1entry.ldf -c -DLDIF 
-foutt1.ldf

LDAP Bulk Update/Replication Protocol

The Novell Import Conversion Export utility uses the LDAP Bulk Update/Replication Protocol (LBURP) to send asynchronous requests to an LDAP server. This guarantees that the requests are processed in the order specified by the protocol and not in an arbitrary order influenced by multiprocessor interactions or the operating system's scheduler.

LBURP also lets the Novell Import Conversion Export utility send several update operations in a single request and receive the response for all of those update operations in a single response. This adds to the network efficiency of the protocol.

LBURP works as follows:

1. The Novell Import Conversion Export utility binds to an LDAP server.
2. The server sends a bind response to the client.
3. The client sends a start LBURP extended request to the server.
4. The server sends a start LBURP extended response to the client.
5. The client sends zero or more LBURP operation extended requests to the server.

   These requests can be sent asynchronously. Each request contains a sequence number identifying the order of this request relative to other requests sent by the client over the same connection. Each request also contains one or more LDAP update operations.

6. The server processes each of the LBURP operation extended requests in the order specified by the sequence number and sends an LBURP operation extended response for each request.
7. After all of the updates have been sent to the server, the client sends an end LBURP extended request to the server.
8. The server sends an end LBURP extended response to the client.

The LBURP protocol lets Novell Import Conversion Export present data to the server as fast as the network connection between the two will allow. If the network connection is fast enough, this lets the server stay busy processing update operations 100% of the time because it never has to wait for Novell Import Conversion Export to give it more work to do.

The LBURP processor in eDirectory also commits update operations to the database in groups to gain further efficiency in processing the update operations. LBURP can greatly improve the efficiency of your LDIF imports over a traditional synchronous approach.

LBURP is enabled by default, but you can choose to disable it during an LDIF import.

To enable or disable LBURP during an LDIF import:

1. In ConsoleOne, select Wizard > NDS Import/Export.

2. Click Import LDIF File > Next.

3. Enter the name of the LDIF file containing the data you want to import > click Next.

4. Select the LDAP server where the data will be imported.

5. Click Advanced > click Use LBURP.

6. Follow the online instructions to complete the remainder of the LDIF import wizard.

   IMPORTANT:  Since LBURP is a relatively new protocol, eDirectory servers prior to version 8.5 (and most non-eDirectory servers) do not support it. If you are using the Novell eDirectory Import/Export Wizard to import an LDIF file to one of these servers, you must disable the LBURP option for the LDIF import to work.

You can use the command line option to enable or disable LBURP during an LDIF import. To do so, use the option -B.

Migrating Schema Between LDAP Directories

You can refer to Application Notes on the Novell Developer Portal for more information about migrating schema between LDAP directories.

Improving the Speed of LDIF Imports

In cases where you have thousands or even millions of records in a single LDIF file you are importing, consider the following:

• Importing Directly to a Server with a Read/Write Replica
• Using LBURP
• Configuring the Database Cache
• Using Simple Passwords
• Using Indexes Appropriately

Importing Directly to a Server with a Read/Write Replica

If it's possible to do so, select a destination server for your LDIF import that has read/write replicas containing all the entries represented in the LDIF file. This will maximize network efficiency.

Avoid having the destination server chain to other eDirectory servers for updates. This can severely reduce performance. However, if some of the entries to be updated are only on eDirectory servers that are not running LDAP, you might have to allow chaining to import the LDIF file.

For more information on replicas and partition management, see Managing Partitions and Replicas.

Using LBURP

Novell Import Conversion Export maximizes network and eDirectory server processing efficiency by using LBURP to transfer data between the wizard and the server. Using LBURP during an LDIF import greatly improves the speed of your LDIF import.

For more information on LBURP, see LDAP Bulk Update/Replication Protocol.

Configuring the Database Cache

The amount of database cache available for use by eDirectory has a direct bearing on the speed of LDIF imports, especially as the total number of entries on the server increases. When doing an LDIF import, you might want to allocate the maximum memory possible to eDirectory during the import. After the import is complete and the server is handling an average load, you can restore your previous memory settings. This is particularly important if the import is the only activity taking place on the eDirectory server.

See Maintaining Novell eDirectory for more information on configuring the eDirectory database cache.

Using Simple Passwords

eDirectory uses public and private key pairs for authentication. Generating these keys is a very CPU-intensive process. With eDirectory 8.6, you can choose to store passwords using the simple password feature of the Novell Modular Authentication Service^TM (NMAS^TM). When you do this, passwords are kept in a secure location in the directory, but key pairs are not generated until they are actually needed for authentication between servers. This greatly improves the speed with which an object that has password information can be loaded.

To enable simple passwords during an LDIF import:

1. In ConsoleOne, click Wizard > NDS Import/Export.

2. Click Import LDIF File > Next.

3. Enter the name of the LDIF file containing the data you want to import > click Next.

4. Select the LDAP server where the data will be imported.

5. Click Advanced > click Store NMAS Simple Passwords/Hashed Passwords.

6. Follow the online instructions to complete the remainder of the Wizard.

If you choose to store passwords using simple passwords, you must use an NMAS-aware Novell Client^TM to log in to the eDirectory tree and access traditional file and print services. NMAS must also be installed on the server. LDAP applications binding with name and password will work seamlessly with the simple password feature.

For more information on NMAS, see Novell Modular Authentication Services Installation and Administration Guide.

Using Indexes Appropriately

Having unnecessary indexes can slow down your LDIF import because each defined index requires additional processing for each entry having attribute values stored in that index. You should make sure that you don't have unnecessary indexes before you do an LDIF import, and you might want to consider creating some of your indexes after you have finished loading the data reviewed predicate statistics to see where they are really needed.

See Index Manager for more information on tuning indexes.