The main DIB set used by NDS 6 is composed of four files:

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.

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.

   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.

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.

   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.

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.

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.

   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.

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.5 shows 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.

The names of the four core NDS files are changed in NetWare 5 (because of NDS 7), but their functions remain the same as their cousins in NetWare 4. Also, two new DS-related files are also included with NetWare 5. The NDS 7 DIB is composed of the following files:

In NetWare 4, DSRepair renames old DIB files with the .OLD extension. Under NetWare 5, however, DSRepair renames the old DIB .DSD files to files with the .DOD extension, and it renames the 0.DSB file 0.DOB.

Versions of NDS prior to NDS 8 use a database engine called Recman, which, as the name suggests, is a record-based database management engine. NDS 8 and eDirectory uses a database engine called FLAIM, which stands for Flexible and Adaptable Information Manager. It is a database engine that is optimized for search and retrieval for a large number of small interrelated objects. (Novell’s GroupWise email system also uses the FLAIM engine for its database.)

A FLAIM database file is divided into logical files called containers. A FLAIM database can have multiple containers, including custom containers. Each FLAIM database must have at least a Default Data, a Local Dictionary, and a Tracker container. Data in one container can reference data in another container, by using the data record number (DRN) of the data being referenced. Table 3.1 lists the containers used in DS 8 and eDirectory databases.

TABLE 3.1 FLAIM Container Descriptions

These logical files may be stored in one or more physical files. eDirectory’s implementation is that each physical file can grow to 2GB in size for NDS 8/eDirectory 8.5 and to 4GB in size for eDirectory 8.6 and higher; then the content is “spilled” over to another file. Therefore, depending on the size of your DS database, you will at least have a file called NDS.01, and when it reaches the maximum allowed size, an NDS.02 file is created, and when that file reaches the maximum allowed size, an NDS.03 file is created, and so on.

TIP

The FLAIM database can be compressed to remove blank or deleted records. Therefore, one of the options in DSRepair for DS 8 and eDirectory is to reclaim unused space. In Figure 3.6 later in this section, you can see the option about halfway down the list.

FIGURE 3.6 Select Use Temporary NDS Database During Repair? if you do not want to work on a live database.

The following is a list of files employed by eDirectory 8.5 and higher:

When you’re running DSRepair to repair the local database, one option (see Figure 3.6) is to use a temporary DS database during the repair. This allows the repair operation to be done on a copy of the database (using the NDT.* files) and not the live database.

Table 3.2 gives the names of the database files used by the various versions of NDS/eDirectory and summarizes their purposes. It also shows the location of each of these files.

TABLE 3.2 Summary of DS File Functions

You can find the DIB files in the following locations on Windows and Unix systems:

However, many administrators often wonder where NetWare stores the DIB files. NetWare hides its DIB files in the SYS:_NETWARE directory. This is a system-protected directory that can’t be accessed using standard utilities such as FILER. However, you can easily view the contents of this directory by using RConsole (which requires the Internet Packet Exchange [IPX] protocol to be enabled at the server and your workstation) as follows:

1.   Use RConsole to connect to your server.

2.   Press Alt+F1 to bring up the Available Options menu.

3.   Select Directory Scan and enter SYS:_NETWARE as the name for the directory to scan. A list of DIB and stream files is displayed.

Figure 3.4 shows the contents of the SYS:_NETWARE directory on a NetWare 5 server running NDS 7. On a NetWare 5 server running eDirectory or a NetWare 4 server running NDS 6, the output is similar, but the filenames are different, as noted earlier in this chapter.

FIGURE 3.7 A sample directory list of SYS:_NETWARE from a NetWare 5 server running NDS 7.

In a single-server environment, it is possible to back up your DS by making a copy of the DIB files. This is analogous to backing up the bindery in the old NetWare 2 and NetWare 3 environments because all the data is located on a single server. It is not a good idea at all, however, to consider backing up your DS by simply copying the DIB files if you have a multiserver environment. Because the DS database is often in a loosely synchronized, loosely consistent state, you can’t guarantee that the DIB on a given server has full data integrity at the time you make a copy of the files.

In a multiserver configuration, it is best to use a Storage Management Service (SMS)–compliant backup application to back up the DS via proper application programming interface calls. eDirectory 8.7 introduced a new backup and restore utility called eDirectory Backup eMTool to back up the eDirectory database on individual servers. You can learn more about SMS, eDirectory Backup eMTool, and other tools that back up and restore DS in Chapter 8, “eDirectory Data Recovery Tools.”

This chapter presents a high-level look at the file structure of NDS/eDirectory databases. It identifies the filename differences between the NDS and eDirectory and shows you how you can view—using DSRepair, DSBrowse, and DSView—some of the information recorded and used by DS that is not displayed by conventional utilities such as NetWare Administrator and ConsoleOne.