The directory managed by your directory server is contained in a database. This chapter describes the procedures you use to manage your database in the following sections:
"Managing Databases Using LDIF"
"Backing Up and Restoring Your Database"
"Managing Database Parameters"
"Managing the Referential Integrity Plug-in"
"Managing Database Transaction Logging"
"Exporting Databases to LDIF"
"Importing Databases From LDIF"
"Deleting LDIF Files"
Exporting Databases to LDIF
Exporting your database to LDIF can be useful if you want to back up your database, copy your database to another directory server, export your database to another application, or add an index setting for a currently existing attribute. You can export your database to LDIF either by using the Directory Server Console, or by using the slapd (Windows NT) or ns-slapd (Unix) command-line utility. This section describes both these methods in the following sections:
"Exporting to LDIF Using the Server Console"
"Exporting to LDIF From the Command Line"
To export your database to LDIF from the Directory Server Console:
On the Directory Server Console select the Configuration tab.
From the Console menu select Export. The Export Database dialog box displays.
The Export Database dialog box displays.
If you are running the Directory Server Console on the server's host machine, skip to Step 4. Otherwise, if you want to export to a file on the local machine, select "Local machine". To export to a file on the server's host, select "Server machine."
Enter the full path and filename you want the server to use to store the LDIF file in the text box provided. Netscape recommends that you use the <NSHOME>/slapd-<serverID>/ldif directory on the server's host machine to store LDIF files.
Netscape recommends that you use the <NSHOME>/slapd-<serverID>/ldif directory on the server's host machine to store LDIF files.
If you chose "Local machine" in Step 3, enter the path relative to the machine where you are running the Directory Server Console. Otherwise, enter the path relative to the server's host machine.
If you chose to export a file to the local machine, or if you are running the Directory Server Console on the server's host machine, you can also click Browse to select the path and filename.
If you want to export the whole directory, select the "Entire database" radio button. If you want to export only a single suffix or a particular subtree, select the Subtree radio button and then enter the suffix or subtree you want to export in the Subtree text box. You can also click Browse to select a suffix or subtree.
Click OK.
You can export your database to LDIF using the slapd (Windows NT) or ns-slapd (Unix) command-line utility with the db2ldif keyword. For information on where you can find the command line utilities, see "Finding the Command-Line Utilities".
Use one of the following syntaxes to export your database to LDIF from the command-line. Parameters in brackets [ ] are optional.
On Windows NT:
slapd db2ldif -f <slapd.conf> -a <output_file> [-d <debug_level> -n -r -s <include_suffix> -x <exclude_suffix>]
On Unix:
ns-slapd db2ldif -f <slapd.conf> -a <output_file> [-d <debug_level> -n -r -s <include_suffix> -x <exclude_suffix>]
where <slapd.conf> is the location of your configuration file. The slapd.conf file is under <NSHOME>/slapd-<serverID>/config. Enter the full path to the slapd.conf file you want to use.
ns-slapd and slapd Parameters for Exporting Databases
-a. Defines the output file in which the server saves the exported LDIF. This file is stored by default in the directory where the command-line utility resides.
-d. (Optional) Specifies the debug level to use during the db2ldif runtime. Debug levels are defined in "Log Level".
-f. Specifies the slapd.conf configuration file to use for the conversion process. Use the full path to the slapd.conf file with this argument. For information on where to find directory server configuration files, see "Directory Server Configuration Files".
-n. (Optional) Specifies that entry IDs are not to be included in the LDIF output. The entry IDs are necessary only if the db2ldif output is to be used as input to db2index.
-r. (Optional) If you intend to import the LDIF file into a consumer server, you must specify this argument. -r causes the server to include the copiedFrom attribute and its contents in the LDIF output. The replication process requires this information. If you use -r, you also need to specify the suffix you want exported using the -s option.
-s. (Optional) Specifies the suffix or suffixes to include in the export. You may use multiple -s arguments. This parameter is optional. If you do not specify -s or -x, the server exports all suffixes within the database. If you use both -x and -s arguments with the same suffix, the -x operation takes precedence. Exclusion always takes precedence over inclusion.
-x. (Optional) Specifies a suffix or suffixes to exclude in the export. You may use multiple -x arguments. This parameter is optional. If you do not specify -s or -x, the server exports all suffixes within the database. If you use both -x and -s arguments with the same suffix, the -x operation takes precedence. Exclusion always takes precedence over inclusion.
Database to LDIF Examples
Windows NT:
slapd db2ldif -f c:\Netscape\Server4\slapd-dirserver\config\slapd.conf -a output.ldif -s o=airius.com
Unix:
ns-slapd db2ldif -f /usr/Netscape/Server4/slapd-dirserver/config/slapd.conf -a output.ldif -s o=airius.com
Importing Databases From LDIF
You can import LDIF files into your database from the Directory Server Console or by using the slapd (Windows NT) or ns-slapd (Unix) command-line utility. This section describes both these methods.
When you import an LDIF file using ldif2db or by specifying the "Overwrite Entire Database" option through the Server Console, a snapshot of o=NetscapeRoot is saved to a file and stored by default in <NSHOME>/slapd-<serverID>/confbak. If you need to, you can restore the configuration information in the directory by importing the most recent file in this directory. The files are named according to the date on which the import took place as follows:
YYYY_MM_DD_HHMMSS.ldif
For example, if the file was saved at 42 seconds past 10 PM on July 30, 1998, it would be named:
1998_07_30_224244.ldif
In most cases, you will want to add the configuration information to the existing data instead of overwriting your existing data. To do this from the server console, when you import the LDIF file, clear the "Overwrite Entire Database" option on the Import dialog box. You can also use ldapmodify as follows:
ldapmodify -D "<BindDN>" -w <BindDN password> -c -a -f <NSHOME>/slapd-<serverID>/confbak/filename.ldif
For example,
ldapmodify -D "cn=directory manager"-w mypassword -c -a -f /Netscape/Server4/slapd-mydirserver/confbak/1998_07_30_224244.ldif
For better performance, you should use the server console to import an LDIF file only if the LDIF file contains a relatively small number of entries (less than 10,000), or if you are importing and overwriting the existing database. Otherwise, you should use the command line. This section describes:
"Importing LDIF From the Server Console"
"Importing LDIF From the Command Line"
You can use the Directory Server Console to import the LDIF file into a directory server database using the Import command. For best performance, you should use the server console to import an LDIF file only if the LDIF file contains a relatively small number of directory entries (less than 10,000), or if you intend to overwrite the existing database. Otherwise, you should use the command-line. For more information, see "Importing LDIF From the Command Line".
Note. You cannot import an LDIF file that contains a root entry unless you bind to the directory as the Root DN (Directory Manager). This is because by default, access to the root entry is denied to everyone except the Root DN.
To import LDIF using the Directory Server Console:
WARNING! This process will overwrite your existing database, if any.
From the Console menu, select Import. This displays the Import Database dialog box.
If you are running the Directory Server Console on the server's host machine, skip to Step 4. Otherwise, if you want to import a file from the local machine, select "From local machine". If you want to import a file from the server's host, select "From server machine."
Enter the full path to the LDIF file in the field provided. If you chose to import a file from the local machine, or if you are running the Directory Server Console on the server's host machine, you can also click Browse to select the file you want to import.
If you chose to import a file from the local machine, or if you are running the Directory Server Console on the server's host machine, you can also click Browse to select the file you want to import.
Select the import method you want the server to use. There are two options: Overwrite Entire Database. You can only choose this option if you chose to import a file on the server's host (in Step 3) or if you are running the Directory Server Console on the server's host machine. When you import using this option, the server deletes the entire contents of the database and imports the LDIF file. If you do not want the server to overwrite the o=NetscapeRoot suffix, select the Preserve Configuration checkbox. If the directory server is running, you are prompted to shut it down.The server must be shut down before you can import using this option. WARNING! The Netscape Administration Server uses the o=NetscapeRoot suffix to store information about installed Netscape Servers. Deleting this suffix could force you to reinstall all of your Netscape 4.x servers, including the directory server. Netscape strongly recommends you choose to preserve this configuration unless directed otherwise by Netscape Technical Support or other procedures outlined in the directory server documentation. Append Data to Database. When you import using this option, the server does not delete the contents of the directory before adding the entries from the LDIF file. You should only use this option if you are importing an LDIF file with a relatively small number of entries (less than 10,000). The server must be running to use this option. You cannot import an LDIF file that creates a root entry (such as o=airius.com) using the "Append Data to Database" option unless you bind to the directory as the root DN, for example, cn=Directory Manager. Instead, you must use the "Overwrite Entire Database" option. The optional settings you can specify include:
Overwrite Entire Database. You can only choose this option if you chose to import a file on the server's host (in Step 3) or if you are running the Directory Server Console on the server's host machine. When you import using this option, the server deletes the entire contents of the database and imports the LDIF file. If you do not want the server to overwrite the o=NetscapeRoot suffix, select the Preserve Configuration checkbox.
If the directory server is running, you are prompted to shut it down.The server must be shut down before you can import using this option.
WARNING! The Netscape Administration Server uses the o=NetscapeRoot suffix to store information about installed Netscape Servers. Deleting this suffix could force you to reinstall all of your Netscape 4.x servers, including the directory server. Netscape strongly recommends you choose to preserve this configuration unless directed otherwise by Netscape Technical Support or other procedures outlined in the directory server documentation.
Append Data to Database. When you import using this option, the server does not delete the contents of the directory before adding the entries from the LDIF file. You should only use this option if you are importing an LDIF file with a relatively small number of entries (less than 10,000). The server must be running to use this option.
You cannot import an LDIF file that creates a root entry (such as o=airius.com) using the "Append Data to Database" option unless you bind to the directory as the root DN, for example, cn=Directory Manager. Instead, you must use the "Overwrite Entire Database" option.
The optional settings you can specify include:
Add Only. LDIF file may contain modify and delete instructions in addition to the default add instructions. If you want the server to ignore operations other than add, select the "Add only" checkbox.
Continue on Error. If you want the server to continue with the import even if errors occur, select the "Continue on error checkbox".
Read / Values From Files. If you want the server to interpret values that begin with a forward slash "/" or a drive letter "C:\" as file names, select the Read / values from files checkbox. If you select this option, the contents of these files, rather than the file names, will be stored in the directory.
File for Rejects. The server keeps a record of all entries that it cannot import. This might happen, for example, if an entry already exists in the database or if there is no parent object for the entry you are trying to add. If you leave this field blank, the server will not record rejects. By default, the server stores the rejects file in the same directory where the LDIF file you are importing is stored. If you want, you can specify a full path where you want the server to store the file.
Importing LDIF From the Command Line
You can convert your LDIF file to an ldbm database file using the slapd (Windows NT) or ns-slapd (Unix) command-line utility. These utilities create the database in the location specified in the "directory" parameter in your slapd.ldbm.conf file and create the index files that are specified in the slapd.ldbm.conf "Attribute to be Indexed" parameter.
For more information, see the "Database" parameter and the "Attribute to be Indexed" parameter in Chapter 16, "Configuration Parameters."
For information on where you can find the command-line utilities in your directory server installation, see "Finding the Command-Line Utilities".
To import LDIF from the command line:
From the command line, change to <NSHOME>/slapd-<serverID>/db. Where <NSHOME> is the directory where you installed the directory server and <serverID> is the name of your directory server. The directory server database must be stored in this directory.
Make a backup of all the files in the db directory. Although you can delete the files, you may want to move them to a backup location instead, because deleting these files deletes your directory database.
Change to <NSHOME>/bin/slapd/server.
Run the slapd (Windows NT) or ns-slapd (Unix) command-line utility as follows. Parameters in brackets [ ] are optional. Windows NT: slapd ldif2db -f <slapd.conf> -i <ldif_file> [-d <debug_level> -n <backend_number> -O -s <include_suffix> -x <exclude_suffix>] Unix: ns-slapd ldif2db -f <slapd.conf> -i <ldif_file> [-d <debug_level> -n <backend_number> -O -s <include_suffix> -x <exclude_suffix>] where <ldif_file> is the name of the file containing the LDIF to be imported and <slapd.conf> is the location of your configuration file. You can find a demo LDIF file under <NSHOME>/slapd-<serverID>/ldif. The slapd.conf file is under <NSHOME>/slapd-<serverID>/config. Enter the full path to the slapd.conf file you want to use.
slapd ldif2db -f <slapd.conf> -i <ldif_file> [-d <debug_level> -n <backend_number> -O -s <include_suffix> -x <exclude_suffix>]
ns-slapd ldif2db -f <slapd.conf> -i <ldif_file> [-d <debug_level> -n <backend_number> -O -s <include_suffix> -x <exclude_suffix>]
where <ldif_file> is the name of the file containing the LDIF to be imported and <slapd.conf> is the location of your configuration file. You can find a demo LDIF file under <NSHOME>/slapd-<serverID>/ldif. The slapd.conf file is under <NSHOME>/slapd-<serverID>/config. Enter the full path to the slapd.conf file you want to use.
The following ldif2db parameters are used to complete an LDIF file import:
-d. Optional. Specifies the debug level to use during runtime. Debug levels are defined in "Log Level".
-f. Specifies the slapd.conf file to use for the import process. This parameter is required. For information on where to find directory server configuration files, see "Directory Server Configuration Files".
-i. Specifies the LDIF file to be imported. This parameter is required. You can use multiple -i arguments to import more than one LDIF file at a time. When you import multiple files, the server imports the LDIF files in the order in which you specify them from the command line.
-n. Optional. Specifies the database in your slapd.conf file for which the conversion is performed. If this parameter is not specified, then the server uses the first database defined in the slapd.conf file.
-O. Optional. When you use this argument, no attribute indexes are created for the imported database. If you specify this option and you want to restore the indexes later, you will need to recreate the indexes by hand. See Chapter 7, "Managing Indexes," for more information.
-s. Optional. Specifies the suffix or suffixes you want to import. This option lets you selectively import portions of the LDIF file. You can use multiple -s arguments. If you use both -x and -s with the same suffix, -x takes precedence. Exclusion always takes precedence over inclusion. If you do not specify -x or -s, then all available suffixes will be imported from the LDIF file.
-x. Optional. Allows you to specify suffixes to exclude during the import. Use this option to preserve suffixes such as o=NetscapeRoot that you do not want the import to overwrite. You can use multiple -x arguments. If you use both -x and -s with the same suffix, -x takes precedence. Exclusion always takes precedence over inclusion. If you do not specify -x or -s, then all available suffixes will be imported from the LDIF file.
LDIF to Database Examples
slapd ldif2db -f c:\Netscape\Server4\slapd-dirserver\config\slapd.conf -i c:\Netscape\Server4\slapd-dirserver\ldif\demo.ldif -i c:\Netscape\Server4\slapd-dirserver\ldif\demo2.ldif -s o=Airius.com -x o=NetscapeRoot
ns-slapd ldif2db -f /usr/Netscape/Server4/slapd-dirserver/config/slapd.conf -i /usr/Netscape/Server4/slapd-dirserver/ldif/demo.ldif -i /usr/Netscape/Server4/slapd-dirserver/ldif/demo2.ldif -s o=Airius.com -x o=NetscapeRoot
Deleting LDIF Files
If you want, you can delete LDIF files you have created. The Directory Server Console does not provide functionality to do this. Instead, you need to delete the files from the command line or through your operating system's utilities.
When restoring your database, you must shut down your server. However, you can back up your database while the server is running.
The following sections describe the options available to you:
"Backing Up Your Database From the Server Console"
"Backing Up Your Database From the Command Line"
"Restoring Your Database From the Server Console"
"Restoring Your Database From the Command Line"
"Deleting Database Backups"
"Restoring Databases That Include Replicated Entries"
Backing Up Your Database From the Server Console
When you back up your database from the Directory Server Console, the server copies the entire database and associated index files to a backup location.
To perform an online backup of your database from the server console:
On the Directory Server Console select the Tasks tab.
Click "Back Up the Directory Server". The Backup directory dialog box appears.
Choose a directory name where you want the backup stored in one of two ways: type in the name of the directory in which you want the backup placed in the Directory text box, or click "Use default" and the server provides a name for the backup directory. If you choose to use the default, the backup files will be placed in the following location: <NSHOME>/slapd-<serverID>/bak/<backup_directory> where <backup_directory> is a directory given the name of the backup. By default, the backup directory name identifies the time and date when the backup was created in the format YYYY_MM_DD_HHMMSS.
If you choose to use the default, the backup files will be placed in the following location:
<NSHOME>/slapd-<serverID>/bak/<backup_directory>
where <backup_directory> is a directory given the name of the backup. By default, the backup directory name identifies the time and date when the backup was created in the format YYYY_MM_DD_HHMMSS.
You can back up your database from the command line by using the db2bak command-line script. This script assumes you are using the slapd.conf file located in <NSHOME>/slapd-<ServerID>/config. Where <NSHOME> is the directory where you installed the directory server and <serverID> is the name of your directory server.
To perform an online backup of your directory from the command line:
At the command prompt, change to <NSHOME>/slapd-<serverID>.
Run the db2bak command-line script as follows: db2bak [backup_directory] You can choose to specify a full path or just a directory where you want the server to store the backup. If you only specify a directory, the server creates the directory under <NSHOME>/slapd-<ServerID>/. If you do not specify either a full path or a single directory, the script makes a copy of your database and stores it in <NSHOME>/slapd-<ServerID>/bak/<backup_directory>. Where <backup_directory> is a directory given the name of the backup. By default, the backup directory name identifies the time and date when the backup was created in the format YYYY_MM_DD_HHMMSS.
db2bak [backup_directory]
You can choose to specify a full path or just a directory where you want the server to store the backup. If you only specify a directory, the server creates the directory under <NSHOME>/slapd-<ServerID>/.
If you do not specify either a full path or a single directory, the script makes a copy of your database and stores it in <NSHOME>/slapd-<ServerID>/bak/<backup_directory>. Where <backup_directory> is a directory given the name of the backup. By default, the backup directory name identifies the time and date when the backup was created in the format YYYY_MM_DD_HHMMSS.
If your database becomes corrupted, you can restore from a previously generated backup using the Directory Server Console. This process consists of copying the database and associated index files from the backup location to the database directory. See "Backing Up Your Database From the Server Console" for more information.
WARNING! Restoring your database overwrites your existing database files, if any.
To restore your database from a previously created backup:
Make sure your directory server is shut down. For specific instructions, see "Starting and Stopping the Directory Server".
For specific instructions, see "Starting and Stopping the Directory Server".
Click "Restore Directory Server". The Restore Directory dialog box displays.
The Console lists all backups in the default directory (<NSHOME>/slapd-<serverID>/bak/<backup_name>) in the Available Backups list box. You can either select the backup from this list or enter the full pathname to a location containing a valid backup in the Directory text box.
You can either select the backup from this list or enter the full pathname to a location containing a valid backup in the Directory text box.
You can restore your database from the command line by using the bak2db command-line script. This script assumes you are using the slapd.conf file located in <NSHOME>/slapd-<ServerID>/config. Where <NSHOME> is the directory where you installed the directory server and <serverID> is the name of your directory server.
To restore your directory from the command line:
Run the bak2db command-line script as follows: bak2db [backup_directory]
bak2db [backup_directory]
By default, the server console places backup files that it creates in a directory under <NSHOME>/slapd-<serverID>/bak. You need to delete the files from this directory using the command line or through your operating system's utilities.
Restoring Databases That Include Replicated Entries
If you are restoring a database that is supplying entries to other servers, then you must reinitialize all of your consumer servers. A message will be logged to the consumer servers' log files indicating that reinitialization is required. If you want reinitialization to occur automatically, you can modify the ORCauto parameter. See Chapter 16, "Configuration Parameters," for information.
If you are restoring a database containing data received from a supplier server, then one of two situations can occur:
Change log entries have not yet expired on the supplier server. If change log entries have not expired on the supplier server since the local database backup was taken, then you can simply restore the local consumer and continue with normal operations. This situation is likely to occur only if the backup was taken within a period of time that is shorter than the value you have set for the Max Changelog Age parameter in slapd.conf.
Change log entries have expired on the supplier server since the time of the local backup. In this case, the consumer server will automatically be reinitialized.
"Placing a Database in Read-Only Mode"
"Setting Suffixes for Your Database"
You must put a database in read-only mode if you are manually initializing a consumer. For information on manually initializing a consumer, see "Initializing Consumers".
When a database is in read-only mode you cannot create, modify, or delete any entries.
If your directory server manages multiple databases, you can place all of them into read-only mode at the same time by placing your entire server in read-only mode. For instructions on how to do this, see "Placing the Entire Directory Server in Read-only Mode".
If you want to place a database into read-only mode from the command line, set the slapd.conf Read-only parameter to on. Otherwise, you can place a database into read-only mode from the server console.
To place a database into read-only mode:
Select the Database icon in the navigation tree in the left pane.
Select the Settings tab in the right pane.
Select the "Make Database Read-Only" checkbox.
Click Save.
Your directory server can simultaneously manage many different directories. Each directory is represented by a suffix, and each suffix corresponds to the root (or topmost) entry in the directory. When the directory server receives a request, the server checks its list of suffixes against the request to see if the server is managing the directory that the client wants to access. If the directory request does not match the directories that the server is managing, then the server sends the client a referral, if one has been configured. If a referral has not been configured, the server returns an error.
Your Netscape Directory Server always uses multiple suffixes. However, most of these are used only for internal purposes, and only one corresponds to the primary directory that you are using the server to manage (such as o=Airius.com). Other suffixes correspond to directory trees used internally by the server (such as o=NetscapeRoot, or the change log).
You can add, modify, and delete suffixes for your database. If you delete an existing suffix, then LDAP clients will not be able to access the entries represented by that suffix.
For information on the Suffix parameter, see "Suffix".
To manage suffixes for your server:
Select the Database icon in the navigation tree. This displays the database settings in the right pane.
Select the Settings tab. This tab contains a list of all the current suffixes in your directory.
To add a new suffix, click Add and enter the new suffix in the field that appears. If the suffix value contains a comma, you must precede the comma with a backslash (\). For example, to add Airius Bolivia, S.A. as a suffix, you would enter Airius Bolivia\, S.A. in the Suffix field.
If the suffix value contains a comma, you must precede the comma with a backslash (\). For example, to add Airius Bolivia, S.A. as a suffix, you would enter Airius Bolivia\, S.A. in the Suffix field.
To delete a suffix, select it in the list and click Delete. WARNING! Do not delete the suffix o=NetscapeRoot. The Netscape Administration Server uses this suffix to store information about installed Netscape Servers. Deleting this suffix could force you to reinstall all of your Netscape 4.x servers, including the directory server.
WARNING! Do not delete the suffix o=NetscapeRoot. The Netscape Administration Server uses this suffix to store information about installed Netscape Servers. Deleting this suffix could force you to reinstall all of your Netscape 4.x servers, including the directory server.
To modify an existing suffix, double-click the suffix in the list and make your changes.
On the Directory Server Console, select the Configuration tab.
Double-click the Plugins folder in the navigation tree.
Select the plug-in in the plug-ins list.
To disable the plug-in, clear the "Enabled" checkbox. To enable the plug-in, select this checkbox.
Restart the directory server.
For example, if a user's entry is removed from the directory and referential integrity is enabled, the server also removes the user from any groups of which the user is a member. If referential integrity is not enabled, the user remains a member of the group until manually removed by the administrator. This is an important feature if you are integrating the directory server with other Netscape products that rely on the directory for user and group management.
Whenever you delete or rename a user or group entry in the directory, the operation is logged to the referential integrity log file (<NSHOME>/slapd-<serverID>/logs/referint). After a specified time, known as the update interval, the server searches the directory for all attributes that have been set for integrity updates that have a DN equal to the value of the deleted or modified entries. If the log file shows that the entry was deleted, the corresponding attribute is deleted. If the log file shows that the entry was changed, the corresponding attribute value is modified accordingly.
By default, the referential integrity plug-in is enabled and set to perform integrity updates on the member, uniquemember, owner, and seeAlso attributes immediately after a delete or rename operation. You can; however, disable the plug-in if you do not need this feature, change the update interval, and choose the attributes you want the plug-in to update. The rest of this section explains how in the following sections:
"Managing Referential Integrity From the Server Console"
"Managing Referential Integrity From the Command Line"
"Changing the Integrity Update Interval"
"Modifying Which Attributes to Update"
You can enable or disable the Referential Integrity Postoperation plug-in from the Directory Server Console as described in "Enabling and Disabling Plug-Ins From the Server Console".
Managing Referential Integrity From the Command Line
You can enable or disable the referential integrity plug-in from the command line by editing the plugin postoperation parameter in the slapd.ldbm.conf file (for information on the location of the configuration files, see "Directory Server Configuration Files"). To enable or disable the plug-in:
Stop the server. See "Starting and Stopping the Directory Server" for information.
Open the slapd.ldbm.conf file and locate the line that begins: On Windows NT: plugin postoperation on "referential integrity postoperation" "<NSHOME>/lib/referint-plugin.dll" referint_postop_init On Unix: plugin postoperation on "referential integrity postoperation" <NSHOME>/lib/referint-plugin.so referint_postop_init
plugin postoperation on "referential integrity postoperation" "<NSHOME>/lib/referint-plugin.dll" referint_postop_init
plugin postoperation on "referential integrity postoperation" <NSHOME>/lib/referint-plugin.so referint_postop_init
To disable the plug-in, change the integer value immediately after referint_postop_init to -1. For example: plugin postoperation "<NSHOME>/lib/referint-plugin.dll" referint_postop_init "-1" "<NSHOME>/slapd-<serverID>/logs/referint" "0" member uniquemember owner seeAlso To enable the plug-in, change the -1 back to zero (0).
plugin postoperation "<NSHOME>/lib/referint-plugin.dll" referint_postop_init "-1" "<NSHOME>/slapd-<serverID>/logs/referint" "0" member uniquemember owner seeAlso
To enable the plug-in, change the -1 back to zero (0).
Save the file.
Start the server. See "Starting and Stopping the Directory Server" for information.
See "Starting and Stopping the Directory Server" for information.
By default, the referential integrity plug-in searches the database and updates related entries immediately after a delete or rename operation. If you want to reduce the impact this operation has on your system, you may want to increase the amount of time between updates. Although there is no maximum update interval, the following intervals are commonly used:
Update immediately
90 seconds (updates occur every 90 seconds)
3600 seconds (updates occur every hour)
10,800 seconds (updates occur every 3 hours)
28,800 seconds (updates occur every 8 hours)
86,400 seconds (updates occur once a day)
604,800 seconds (updates occur once a week)
Stop the server.
Open the slapd.conf file and locate the line that begins plugin postoperation <NSHOME>/lib/referint-plugin.dll referint_postop_init
plugin postoperation <NSHOME>/lib/referint-plugin.dll referint_postop_init
Change the integer value that immediately follows referint_postop_init to the number of seconds between updates. For example, if you want to change the update interval so that updates occur once a day (every 86,400 seconds), you edit the line as follows: plugin postoperation "<NSHOME>/lib/referint-plugin.dll" referint_postop_init 86400 "<NSHOME>/slapd-<serverID>/logs/referint" "0" member uniquemember owner seeAlso
For example, if you want to change the update interval so that updates occur once a day (every 86,400 seconds), you edit the line as follows:
plugin postoperation "<NSHOME>/lib/referint-plugin.dll" referint_postop_init 86400 "<NSHOME>/slapd-<serverID>/logs/referint" "0" member uniquemember owner seeAlso
By default, the referential integrity is set up to update the member, uniquemember, owner, and seeAlso attributes. You can either add or delete attributes to be updated by editing the slapd.ldbm.conf file (for information on the location of configuration files, see "Directory Server Configuration Files"). For best performance, the attributes set for updating should also be indexed. For information on indexing, see Chapter 7, "Managing Indexes."
To modify which attributes should be updated:
Open the slapd.ldbm.conf file and locate the line that begins plugin postoperation "<NSHOME>/lib/referint-plugin.dll" referint_postop_init
plugin postoperation "<NSHOME>/lib/referint-plugin.dll" referint_postop_init
Add or delete attribute names from the end of the line that begins plugin postoperation "<NSHOME>/lib/referint-plugin.dll" referint_postop_init For example, to modify the plug-in to perform integrity updates on the manager attribute, add manager to the end of the plug-in postoperation line as follows: plugin postoperation "<NSHOME>/lib/referint-plugin.dll" referint_postop_init 0 "<NSHOME>/slapd-<serverID> /logs/referint" "0" member uniquemember owner seeAlso manager
For example, to modify the plug-in to perform integrity updates on the manager attribute, add manager to the end of the plug-in postoperation line as follows:
plugin postoperation "<NSHOME>/lib/referint-plugin.dll" referint_postop_init 0 "<NSHOME>/slapd-<serverID> /logs/referint" "0" member uniquemember owner seeAlso manager
Restart the server.
Although database transaction logging and database recovery are automatic processes that require no intervention, you may want to tune some of the database transaction logging parameters for best performance.
The following sections describe the parameters:
"Changing the Location of the Database Transaction Log"
"Changing the Database Checkpoint Interval"
"Disabling Durable Transactions"
By default, the database transaction log file is stored in the <NSHOME>/slapd-<serverID>/db directory along with the directory files themselves. Because the purpose of the transaction log is to aid in the recovery of a directory database that was shut down abnormally, it is a good idea to store the database transaction log on a different disk from the one containing the directory database. Storing the database transaction log on a separate physical disk may also improve directory server performance.
You can move the location of the database transaction log file by adding the db_logdirectory parameter to the end of the slapd.conf file.
For information on the location of the configuration files, see "Directory Server Configuration Files". For information on the db_logdirectory parameter syntax, see "Database Transaction Log Directory".
Changing the Database Checkpoint Interval
Whenever a directory database operation such as a write or modify is performed, the operation is logged to the directory server database transaction log. For best performance, the results of the operation itself may not be written to disk immediately. Instead they are stored in a temporary memory cache on the directory server. At specific intervals, the directory server writes the previously cached data out to the disk and logs a checkpoint entry in the database transaction log. By indicating which changes have already been written to the directory, checkpoint entries tell the directory server where in the database transaction log to begin recovery, thus speeding up the recovery process.
By default, the directory server is set up to send a checkpoint entry to the database transaction log every 60 seconds. Increasing the checkpoint interval may increase the performance of directory server write operations. Increasing the checkpoint interval may also significantly increase the amount of time required to recover the directory database after a disorderly shutdown and may waste disk space due to overly large database transaction log files. Therefore, you should only modify this parameter if you are familiar with database optimization and can fully assess the impact of the change.
To modify the checkpoint interval, you must add the db_checkpoint_interval parameter to the end of the slapd.conf file.
For information on the location of the configuration files, see "Directory Server Configuration Files". For information on the db_checkpoint_interval parameter syntax, see "Database Checkpoint Interval".
Disabling Durable Transactions
By default, durable database transaction logging is enabled. This means that every time a directory database operation such as a read or write is performed on the directory, a corresponding entry is physically written to the database transaction log disk. To improve performance, you can disable durable transaction logging. When you do so, every directory database operation is logically written to the database transaction log file, but it may not be physically written to disk immediately. That means that if a directory change was written to the logical database transaction log file but not physically written to disk at the time of a system crash, you cannot recover the change. When durable transactions are disabled, the recovered database is consistent, but does not reflect the results of any LDAP write operations that completed just before the system crash.
You can disable durable transactions by adding the db_durable_transactions parameter to the end of the slapd.conf file and set its value to off.
For information on the location of the configuration files, see "Directory Server Configuration Files". For information on the db_durable_transactions parameter syntax, see "Database Durable Transactions".