Repairing eDirectory with DSRepair Every database needs a tool for repairing inconsistencies when they occur. DSRepair has been serving in this capacity as long as eDirectory has existed. Even though Novell is shifting its focus toward Web-based tools, DSRepair is still essential for working on your eDirectory on a day-to-day basis. DSRepair offers three main groups of features: To load DSRepair on your NetWare 6.5 server, load DSREPAIR.NLM at the server console. Throughout this section, when describing steps for performing a DSRepair operation, it is assumed that you have already loaded the utility. Figure D.3 shows the main menu of DSRepair . Figure D.3. DSRepair main menu.  All DSRepair operations and results can be logged to file for review. The default log file is SYS:SYSTEM\DSREPAIR.LOG . DSRepair on NetWare has a menu for configuring the log file. To access this menu, select the Advanced Options Menu, and then select Log File and Login Configuration. This following three sections describe the features available in each of the three main categories of DSRepair operations: Unattended Full Repair, eDirectory Monitor Operations, and eDirectory Repair Operations. Unattended Full Repair The Unattended Full Repair (UFR) is probably the most-used feature in DSRepair although the huge database sizes now being supported by eDirectory might change that. UFR checks for and repairs most noncritical eDirectory errors in the eDirectory database files of a given server. UFR is activated by selecting Unattended Full Repair from the main DSREPAIR menu. The UFR performs eight primary operations each time it is run, none of which requires any intervention by the administrator. These operations are described in Table D.2. During some of these operations, the local database is locked. UFR builds a temporary set of local database files and runs the repair operations against those files. That way, if a serious problem develops, the original files are still intact. When complete, a UFR log file will be generated that outlines all the activities that have gone on, errors that were encountered , and other useful information in reviewing the state of your eDirectory environment. TIP Rebuilding the operational indexes used by eDirectory is possible only when the local database is locked. Given this, it is good to schedule a locked database repair on a regular basis, even in large eDirectory environments.
Table D.2. Operations Performed by Unattended Full Repair | OPERATION | LOCKED? | DESCRIPTION | | Database structure and index check | Yes | Reviews the structure and format of database records and indexes. This ensures that no structural corruption has been introduced into the eDirectory environment at the database level. | | Rebuild the entire database | Yes | This operation is used to resolve errors found during structure and index checks. It restores proper data structures and re-creates the eDirectory database and index files. | | Perform tree structure check | Yes | Examines the links between database records to make sure that each child record has a valid parent. This helps ensure database consistency. Invalid records are marked so that they can be restored from another partition replica during the eDirectory replica synchronization process. | | Repair all local replicas | Yes | This operation resolves eDirectory database inconsistencies by checking each object and attribute against schema definitions. It also checks the format of all internal data structures. This operation can also resolve inconsistencies found during the tree structure check by removing invalid records from the database. As a result, all child records linked through the invalid record are marked as orphans. These orphan records are not lost, but this process could potentially generate a large number of errors while the database is being rebuilt. Do not be overly alarmed. This is normal and the orphan objects will be reorganized automatically over the course of replica synchronization. | | Check local references | Yes | Local references are pointers to other objects maintained in the eDirectory database on this server. This operation will evaluate the internal database pointers to make sure that they are pointing to the correct eDirectory objects. If invalid references are found, an error is reported in DSREPAIR.LOG. | | Repair network addresses | No | This operation checks server network addresses stored in eDirectory against the values maintained in local SAP or SLP tables to make sure that eDirectory still has accurate information. If a discrepancy is found, eDirectory is updated with the correct information. | | Validate stream syntax files | Yes | Stream syntax files, such as login scripts, are stored in a special area of the eDirectory database. Validate stream syntax files checks to make sure that each stream syntax file is associated with a valid eDirectory object. If not, the stream syntax file is deleted. | | Check volume objects and trustees | No | This operation first makes sure that each volume on the NetWare server is associated with a volume object in eDirectory. If not, it will search the context in which the server resides to see whether a Volume object exists. If no Volume object exists, one will be created. After validating the volume information, the list of trustee IDs is validated . Each object in eDirectory has a unique trustee ID. This ID is used to grant rights to other objects, including NetWare volumes , in the eDirectory tree. This task makes sure that each trustee ID in the volume list is a valid eDirectory object. If not, the trustee ID is removed from the volume list. | WARNING When the local database is locked, no changes are permitted while the operations execute. Some of these operations, when performed on very large eDirectory databases, will take an extended period of time to complete. When working with a large eDirectory database, it is best to schedule these types of operations carefully so as not to disrupt network operations.
DSRepair Monitor Operations DSRepair offers several partition, replica, and server operations that are available to monitor the health of the eDirectory environment. These operations can be performed individually or as groups to help keep eDirectory stable and healthy . Some of the DSRepair operations described in this section are available only when DSRepair is loaded in advanced mode. This is done by typing the following at the server console: DSREPAIR -a The first category of operations can be loosely grouped into monitor operations that are designed to report eDirectory status and health. You will likely perform most of these tasks from iMonitor with NetWare 6.5, but they are still available from DSRepair . Table D.3 describes the monitor operations available with DSRepair . Table D.3. DSRepair Monitor Operations on NetWare | OPERATION | HOW TO ACCESS | DESCRIPTION | | Report sync status | Select Report Synchronization Stat | Reports the sync status for every partition that hosts a replica on this server. | | Report sync status of all servers | Select Advanced Options Menu Select Replica And Partition Operations, and then select a partition Select Report Synchronization Status Of All Servers | Queries each server hosting a replica of the selected partition and reports the sync status of each replica. | | Report sync status on selected server | Select Advanced Options Menu Select Replica and Partition Operations and then select a partition Select View Replica Ring and choose a server Select Report Synchronization Status on Selected Server | Reports the sync status of the replica hosted by this server for the selected partition. | | Time sync | Load DSRepair at the NetWare console and select Time Synchronization | Reports status of time synchronization. | | Perform database structure and index check | Select Advanced Options Menu, and then Repair Local DS Database | Reviews the structure and format of database records and indexes. This ensures that no structural corruption has been introduced into the eDirectory environment at the database level. | | Perform tree structure check | Select Advanced Options menu, and then Repair Local DS Database | Examines the links between database records to make sure that each child record has a valid parent. This helps ensure database consistency. Invalid records are marked so that they can be restored from another partition replica during the eDirectory replica synchronization process. | | Servers known to this database | Select Advanced Options menu, and then select Servers Known to This Database | Queries the local database and compiles a list of servers known to this partition. | | View entire server name | Select Advanced Options menu, and then select Servers Known to This Database Select a server, and then select View Entire Server's Name | Displays the distinguished eDirectory name for this server. | | View replica ring | Select Advanced Options, and then select Replica and Partition Operations Select a partition and then select View Replica Ring | Displays a list of all servers that host a replica of the selected partition. | | View entire partition name | Select Advanced options menu, and then select Replica and Partition Operations; select a partition, and then select View Entire Partition Name | Displays the distinguished eDirectory name for this partition root object. | DSRepair Repair Operations Although monitoring the condition of the eDirectory database is important, it does little good if there are no tools for repairing inconsistencies when they occur. DSRepair offers several eDirectory repair operations. These repair operations can be organized into three categories: Database Repair Operations All database repair options are accessible from the same menu in DSRepair , as shown in Figure D.4. Access these operations by selecting Advanced Options Menu and then choosing Repair Local DS Database. Figure D.4. Database repair options available from DSRepair .  Table D.4 describes the repair operations available from this menu. Table D.4. DSRepair Database Operations on NetWare | OPERATION | DESCRIPTION | | Rebuild entire database | This operation is used to resolve errors found during structure and index checks. It restores proper data structures and re-creates the eDirectory database and index files. | | Repair all local replicas | This operation resolves eDirectory database inconsistencies by checking each object and attribute against schema definitions. It also checks the format of all internal data structures. Repairing all local replicas can also resolve inconsistencies found during the tree structure check by removing invalid records from the database. As a result, all child records linked through the invalid record are marked as orphans. These orphan records are not lost, but this process could potentially generate a large number of errors while the database is being rebuilt. Do not be overly alarmed. This is normal and the orphan objects will be reorganized automatically over the course of replica synchronization. | | Validate mail directories/syntax files | Both of these operations are only used with NetWare. By default, eDirectory creates mail directories in the SYS:Mail directory of NetWare servers in order to support legacy bindery users. Login scripts for bindery users are stored in their mail directory. Validate Mail Directories checks to make sure each mail directory is associated with a valid eDirectory User object. If not, the mail directory is deleted. Stream syntax files, such as login scripts, are stored in a special area of the eDirectory database. Validate Stream Syntax Files checks to make sure that each stream syntax file is associated with a valid eDirectory object. If not, the stream syntax file is deleted. | | Check local references | Local references are pointers to other objects maintained in the eDirectory database on this file server. Check Local References evaluates the internal database pointers to make sure they are pointing to the correct eDirectory objects. If invalid references are found, an error is reported in DSREPAIR.LOG. | | Reclaim database free space | This operation searches for unused database records and deletes them to free up disk space. | | Rebuild operational schema | This operation rebuilds the base schema classes and attributes needed by eDirectory for basic functionality. | Partition and Replica Repair In addition to these database repair options, DSRepair offers a menu of partition and replica operations designed to keep the distributed eDirectory environment functioning properly. This changes the focus from the local database to the partitionand all the replicas of that partition stored on servers across the network. To access these operations, select Advanced Options, Replica and Partition Options, and then select the partition with which you want to work, as shown in Figure D.5. Figure D.5. DSRepair replica and partition options.  Table D.5 describes the various partition and replica operations available. Table D.5. DSRepair Partition and Replica Operations | OPERATION | DESCRIPTION | | Sync replica on all servers | Each server holding a replica of the selected partition is contacted and then a synchronization cycle is initiated. | | Repair all replicas | This operation resolves eDirectory database inconsistencies by checking each object and attribute against schema definitions. It also checks the format of all internal data tructures. | | Repair selected replica | Performs a replica repair on the selected replica only. | | Repair ring selected replica | Performs a replica repair operation on each server that hosts a replica of the selected artition. | | Repair ring all replicas | Performs the replica ring repair operation for each replica ring in which this server participates. | | Schedule immediate sync | Initiates a replica synchronization cycle for each partition with a replica hosted on this server. This is useful for forcing the recognition of recent database changes. | | Designate this server as new master replica | If the master replica of a given partition is lost due to hardware failure, this operation can be used to designate a new master in order for partition operations to function normally. | Three other replica operations are available by doing the following: -
Select Advanced Options Menu, and then select Replica And Partition Operations. -
Select a replica and then choose View Replica Ring. -
Select a server from the list. These three operations are described in Table D.6. Table D.6. DSRepair Replica Ring Operations on NetWare | OPERATION | DESCRIPTION | | Synchronize the replica on the selected | Reports the synchronization status of the server selected partition's replica that is hosted on this server. | | Send all objects to every replica in the ring | The operation rebuilds every replica in the ring according to the objects found in this server's replica. Warning: Any changes made to other replicas that have not yet updated to this server will be lost. | | Receive all objects for this replica | This operation rebuilds the local replica from object information received from the master replica. Warning: Any changes made to this replica that have not yet updated to the master replica will be lost. | Other Repairs Finally, there are four miscellaneous repair operations that are accessible from other areas of the DSREPAIR utility. Table D.7 describes these operations. Table D.7. Other DSRepair Operations | OPERATION | HOW TO ACCESS | DESCRIPTION | | Repair all network addresses | Select Advanced Options Menu, and then Servers Known to This Database. Select a server from the list. | This operation checks server network addresses stored in all Root Partition objects in the tree against the values maintained in local SAP or SLP tables. If a discrepancy is found, eDirectory is updated with the correct information. If no corresponding SAP or SLP entry is found, DSRepair reports an error. | | Repair selected server's network addresses | Select Advanced Options Menu, and then Servers Known to This Database. Select a server, and then select Repair Selected Server's Network Addresses. | Same as above, but only the Root Partition objects on the local server are checked. | | Check volume objects and trustees | Select Advanced Options Menu, and then Check Volume Objects and Trustees. | Check Volume Objects and Trustees first makes sure that each volume on the NetWare server is associated with a Volume object in eDirectory. If not, it searches the context in which the server resides to see whether a Volume object exists. If no Volume object exists, one is created. After validating the volume information, the list of trustee IDs is validated. Each object in eDirectory has a unique trustee ID. This ID is used to grant rights to other objects, including NetWare volumes, in the eDirectory tree. This task makes sure that each trustee ID in the volume list is a valid eDirectory object. If not, the trustee ID is removed from the volume list. | | Check external references | Select Advanced Options Menu, and then Check External References. | External references are to eDirectory objects not stored in partition replicas on this server. Check External References evaluates each reference to an external object to make sure that it is pointing to a valid eDirectory object. The external reference check also verifies the need for all obituaries maintained in the local database. An obituary is used to maintain database consistency while eDirectory is replicating changes such as object moves, deletes, or name changes. If a replica attempts to reference the changed object using old information because it has not received the replica sync yet, the obituary entry permits it to do so without generating an error. Once all replicas have synchronized with the new information, the Janitor process eliminates the obituary. | By using the operations described in this section, you will be able to manage most non-catastrophic problems in your eDirectory environment. DSRepair Command-Line Switches Novell recommends that some DSRepair operations be performed on a regular basis in order to keep the eDirectory tree healthy. To facilitate this, Novell has also made DSRepair functionality available through command-line switches. These switches make it possible to use batch schedulers to perform regular eDirectory tree maintenance automatically without any input from the administrator. Table D.8 describes the various command-line switches that are provided for automating basic DSRepair tasks. Table D.8. Basic Command-Line DSRepair Switches | SWITCH | PARAMETER | DESCRIPTION | | -L | Filename (with path ) | Specify location for DSRepair log file. Appends to existing log file if it exists. Default is SYS:SYSTEM\DSREPAIR.LOG. | | -U | None | Performs Unattended Full Repair and automatically unloads when complete. | | -RC | None | Create an eDirectory dump file. This file is a snapshot of the local eDirectory database that can be used for troubleshooting. The dump file is stored as SYS:SYSTEM\DSR_DIB. | | -RD | None | Repair Local Database. Executes using default database repair options, which includes Structure and Index Check, Rebuild Database, Tree Structure Check, Repair All Local Replicas, Validate Mail/Stream Files, and Check Local References. | | -RN | None | Repair Network Addresses. | | -RV | None | Perform Volume Object Repair. | | -RVT | Volume Name | Perform Volume Object Repair and Trustee Check. | In addition to the numerous functions described in the previous sections, DSRepair also has some advanced features that are hidden from normal use. These advanced features are enabled through switches when loading the DSRepair utility. Table D.9 provides an overview of the advanced functionality available on each platform. WARNING The features described in this section canand willcause irreversible damage to your eDirectory tree if used improperly. We recommend that these features be used only under the guidance of eDirectory professionals, such as the Novell Technical Services team, in order to resolve serious database issues. Always make a full backup of the eDirectory tree before using any of these features on a production tree. If you are going to use these features be sure you understand all the consequences before proceeding.
Table D.9. Advanced DSRepair Features | SWITCH | DESCRIPTION | | -MR | Removes all "move inhibit" obituaries. | | -N | Limits the number of days a User object can be connected to a given server to the number specified as a command-line argument. When this number is reached, the user connection is terminated . The default value is 60 days. | | -RS | Removes the server identified by the Partition Root ID provided as a command-line argument from the replica ring for that partition. This might be necessary if a Read/Write replica becomes corrupt and needs to be eliminated. | | -A | Load DSRepair with advanced options available. This uncovers additional menu options that are not normally visible. Select Advanced Options Menu, and then select Replica and Partition Operations and choose the partition with which you want to work. You will see the following additional menu items: -
Repair timestamps and declare a new epoch -
Destroy the selected replica on this server -
Delete unknown leaf objects This switch also allows the Designate This Server as the New Master Replica option to assign a Subordinate Reference as the new Master replica. Be careful!! If you select the View Replica Ring option and select a replica, you will see an additional option on that menu as well: Remove this server from the replica ring | | -XK2 | Kill all eDirectory objects in this server's eDirectory database. This operation is used only to destroy a corrupt replica that cannot be removed in any other way. | | -XK3 | Kill all external references in this server's eDirectory database. This operation is used to destroy all external references in a nonfunctioning replica. If the references are the source of the problem, eDirectory can then re-create the references in order to get the replica functioning again. | These advanced options are seldom used because they are needed for only the most serious of cases. However, it is nice to know they exist when you get into a jam. It is highly recommended that you work with these switches in a test environment and carefully study the ramifications of these radical operations. Sometimes the cure can be worse than the problem. |
