Troubleshooting Novell's eDirectory: The Directory Information Base
This chapter is from the book
This chapter is from the book
This chapter is from the book
Just as you don't really need to know how a combustion engine works in order to drive a car, it is not necessary for you to have an intricate knowledge of the directory services (DS) database file structure in order to use, manage, and troubleshoot eDirectory. On the other hand, knowing that the eDirectory database is made up of a number of files and knowing what components make up the eDirectory database can make troubleshooting easier. Although this chapter is by no means an in-depth technical view of the DS database files, it gives you an idea of what the files are named, where they are located, and what the purpose of each is.
The set of DS database files is officially known as the Directory Information Base (DIB). Oftentimes, these files are simply referred to as NDS files; however, in a number of Novell utilities, such as DSRepair, the term DIB is used.
Because there are still many NetWare 4 and NetWare 5 servers being used around the world, this chapter covers the DIB sets used in NDS 6, 7, and NDS 8/eDirectory.
The NDS 6 DIB
The main DIB set used by NDS 6 is composed of four files:
PARTITIO.NDS
ENTRY.NDS
VALUE.NDS
BLOCK.NDS
Each of these files is examined individually in the sections that follow.
PARTITIO.NDS
The PARTITIO.NDS file contains information specific to partitions that are stored on the file's server. This data is server-centric because it has no correlation with the data in the PARTITIO.NDS file on another server. The file contains the following fields to help DS replicate and synchronize data between servers:
Partition ID—This is the hexadecimal number assigned to a replica (by NetWare) when it is created. This number is used to associate an object with its partition. It is also referred to as the replica ID in DSRepair and the root entry ID in DSBrowse.
Partition root object—This is the hexadecimal object ID number of the object that is the root of the partition. This is also known as the replica root object.
Replica type—This is the type of replica (such as Master or Read/Write).
Replica state—This is the state of the replica (such as On or Split).
Replica flags—The replica flags are used by the NDS synchronization processes. They are also referred to as partition flags.
Next timestamp—This is the minimum value of the next timestamp the server issues to an object in the partition.
You can look up this information by using DSREPAIR.NLM in the following way: From the main menu, select Advanced Options, Replica and Partition Operations. Then you select any one of the partitions from the displayed list and choose Display Replica Information. The resulting log file shows the data from the PARTITIO.NDS file in a readable format, as shown in Figure 3.1. You can obtain similar information by using DSBrowse, as illustrated in Figure 3.2.
)
Figure
3.1 A sample DSREPAIR.NLM log file, showing information about the
SLCDEV partition.
)
Figure
3.2 DSBrowse, showing information about a partition.
ENTRY.NDS
All objects stored on the server are located within the ENTRY.NDS file. Each object has a record entry in the file, and each record contains the following fields:
Object Name—This is the typed relative distinguished name of the object (for example, CN=Tasha).
Partition ID—This is the hexadecimal ID of the partition in which the object exists. This corresponds to the records in the PARTITIO.NDS file.
Base Object Class—This is a pointer to the record within the ENTRY.NDS file that contains the schema definition (such as User), which is used as the object's base object class.
Creation Time—This is the timestamp of when the object was created.
Parent Object—This is a pointer to the record within the ENTRY.NDS file that contains the object that is the parent of the current object. For example, if the current object's full name is CN=Tasha.OU= North_America.O=Testing, this field points to OU=North_America.O=Testing, which is the parent of the CN=Tasha object.
Sibling Object—This is a pointer to the record within the ENTRY.NDS file for the object that is a sibling object.
First Child Object—This is a pointer to the record within the ENTRY.NDS file for the object that is the first child object. If the current object is a leaf object, such as a user, then there is no child object.
Last Child Object—This is a pointer to the record within the ENTRY.NDS file for the object that is the last child object. If the current object is a leaf object, such as a user, then there is no child object.
First NDS Attribute—This is a pointer to the record within the VALUE.NDS file that contains the object's first attribute.
Subordinate Count—This is the number of records that are subordinate to (that is, reference) the current object. In essence, this is the number of child objects the object has. For example, if the current object is a container and has four User objects and two organizational units (OUs), the subordinate count is six.
Object Flags—This is a set of flags that identifies the characteristics of the object. The following are the possible flag values:
-
Alias indicates that the object is an alias to another object.
Backlinked indicates that the object is an external reference that has established a backlink.
Partition or Partition Root indicates that the object is a partition root object.
-
Present indicates that the object is present in the DS tree.
Not Present indicates that the object is no longer considered by DS to exist within the tree, but its record still exists in the DIB because the Janitor process hasn't purged it yet. See the "Delete Object" and "Obituaries" sections in Chapter 6 for more information about the Janitor process.
NOTE
A sibling object is an object that has the same parent object (or name context) as another object. For example, CN=Tasha.OU=North_America.O=Testing is a sibling object to CN=Chelsea.OU=North_America.O=Testing because both objects have the same parent object, OU=North_America.O=Testing.
NOTE
An external reference is a placeholder used to store information about an object that is not contained in a partition held by the server. See Chapter 6, "Understanding Common eDirectory Processes," for more information about external references and backlinks.
Figure 3.3 shows a sample entry record for the User object Tasha, located in OU=North_America.O=Testing.
)
Figure
3.3 Viewing DS entry record information by using DSBrowse.
VALUE.NDS
The VALUE.NDS file contains attribute values associated with records in the ENTRY.NDS file. The structure of the VALUE.NDS file is similar to that of ENTRY.NDS. The following fields are stored in the VALUE.NDS file:
Object Name—This is a pointer to the object record in the ENTRY.NDS file to which this attribute is associated.
Attribute—This is a pointer to the record within the ENTRY.NDS file that contains the schema attribute definition (such as Surname) for this attribute.
Next Value—This is a pointer to the record within the VALUE.NDS file that contains the attribute's next value if the attribute is multivalued.
Next Attribute—This is a pointer to the record within the VALUE.NDS file that contains the next attribute assigned to the object.
First Block—Each VALUE.NDS record can hold up to 16 bytes of data (such as the number of days before a password expires). If the data for an attribute's value doesn't fit in a single VALUE.NDS record, the extra data is stored in a record in the BLOCK.NDS file. The First Block field is a pointer to a record in this file that holds the first block of overflow data.
Modification Time stamp—This field contains the time stamp when the attribute value was created or last modified.
Attribute Value—This is the data associated with the attribute. If the attribute's data type or syntax is stream (SYN_STREAM), the filename containing the stream data is recorded instead.
Attribute Flags—This is a set of flags that identify the characteristics of the attribute. The following are the possible flag values:
Base Object Class indicates that the value in the record is the value used as the base object class for the object that this attribute is associated with.
Naming indicates that the value in the record is used as the relative distinguished name of the object that this attribute is associated with.
Present indicates that the object is present in the DS tree.
Not Present indicates that the object is no longer considered by NDS to exist within the tree, but its record still exists in the DIB because the Janitor process hasn't purged it yet. See the "Delete Object" and "Obituaries" sections in Chapter 6 for more information.
NOTE
All stream data, such as login scripts, is stored in individual files, where the filename is an eight-digit hexadecimal number and the file extension is .000. The hexadecimal number in the filename has no direct relationship to the hexadecimal object ID of the DS object to which the file is associated. For example, the container login script for OU=North_America (whose object ID is 0x01000124) is stored in a stream file named 0004B3C0.000, and the print job configuration information associated with the same container is stored in a stream file called 0031B000.000. You can look up the filenames by using DSBrowse, as illustrated in Figure 3.4. DSBrowse on NetWare does not provide that information. However, you can use MONITOR to see the filename that is opened when you are editing the login script and print job configuration.
)
Figure
3.4 Looking up the name of a stream file for the login script.
BLOCK.NDS
The BLOCK.NDS file is used to store the value of an object's attribute that exceeds 16 bytes in size. Each record in BLOCK.NDS consists of the following fields:
Attribute Name—This is a pointer to the attribute record in the VALUE.NDS file to which this data block is associated.
Value—This is the value or data for the attribute. Each record in BLOCK.NDS can hold up to 108 bytes of data.
Next Block—If the data is larger than 124 bytes (16 bytes in the VALUE.NDS file and 108 bytes in the first block of BLOCK.NDS), additional records in the BLOCK.NDS file are used for the excess data. The next block points to the next record within the BLOCK.NDS file that contains data for the attribute.
NDS and Transaction Tracking System
If you are familiar with database structures, you'll readily recognize that the DIB set is implemented as a set of linked lists. The link generally starts in the ENTRY.NDS file and is then linked to VALUE.NDS and then to BLOCK.NDS. By using linked lists, NDS can easily insert data into the DIB by simply adjusting the pointers accordingly. Any nodes (that is, elements in the list) that are deleted can be easily reused; therefore, there is generally no need to repack the DIB unless you have deleted a large number of objects. Even then, you might not see much of a size reduction of the DIB because only empty nodes at the end of the lists are deleted.
To reduce the chance of pointer corruption and data integrity, DS transactions are protected by NetWare Transaction Tracking System (TTS); therefore, if for some reason the server's TTS mechanism is disabled, DS.NLM automatically shuts down the DIB. Because TTS uses disk space on the SYS: volume to create transaction log files, it is essential that you ensure that the SYS: volume always has sufficient free disk space; otherwise, you risk shutting down NDS.
NOTE
eDirectory does not depend on TTS because it is a cross-platform product and TTS is available only on NetWare. However, eDirectory also keeps its roll-forward log (RFL) files on the same disk on which the DIB is installed. Therefore, it is also essential that you ensure that sufficient free disk space is available; otherwise, you risk eDirectory shutting down unexpectedly.
On NetWare 4 servers, you can easily look up the object and attribute information by using Novell's DSView NetWare Loadable Module (NLM). This NLM is not included with NetWare but can generally be found included with the DS.NLM updates. For NetWare 5 and higher, the corresponding utility is the DSBrowse NLM that is included with NetWare; a DSBrowse module is included for the other platforms that eDirectory runs on. The DSView screen in Figure 3.5shows the information related to the Login Intruder Limit attribute, such as timestamp and syntax.
)
Figure
3.5 Examining the NDS 6 DIB by using DSView on a NetWare 4 server.
NOTE
By default, DSRepair saves the old DIB files after a repair operation. The four files in the main DIB set used by DS 6 are renamed with a .OLD extension. Because of the backup DIB files, you essentially double your DIB size after you run DSRepair. Keep this in mind if you're low on disk space on the SYS: volume.