The Synchronization process, sometimes referred to as the Skulker process, keeps the information in multiple replicas of the DS database current on all servers. The process is event driven, meaning it is kicked off after an object has been modified. Listing 6.2 shows a sample of the Sync process in the DSTrace screen.

Listing 6.2 demonstrates a failed synchronization condition. The local server is attempting to contact the server named CN=Rigel.OU=West.O=XYZCorp but is unable to complete the Synchronization process. The error -625 indicates a transport failure—also known as a communications failure. To correct this problem, the easiest way to proceed is to verify that the target server is up and that the communications links between the two servers are working properly.

A successful synchronization cycle of the [Root] partition between the two servers is shown in Listing 6.3.

This time the servers are talking to each other, and there are a few updates that need to be sent from one server to the other.

The frequency at which the Sync process runs depends on the object attribute being changed. Each attribute has a flag called that determines whether it is “high convergence.” This flag has one of two possible values:

A Per Replica (DS_PER_REPLICA) flag also exists and can be defined for attributes. When an attribute is defined as Per Replica, the information of the attribute is not synchronized with other servers in the replica ring. Most of the DirXML-related attributes are defined with this flag.

Nontransitive Synchronization in NetWare 4

In NetWare 4.x any server that holds a replica of an NDS partition has to communicate with all the other servers that hold a replica of that partition. Figure 6.3 shows the type of communication that has to take place in order for synchronization to be completely successful on all NetWare 4.x servers.

FIGURE 6.3 Nontransitive replica synchronization between four NetWare 4.x servers.

As you can guess, the number of synchronization processes (or vectors, as they are sometimes called) that must complete grows exponentially as replicas are added. The amount of traffic generated can be tremendous. In fact, the number of communications vectors is n × (n–1), where n represents the number of replicas in the replica ring. Thus, at 27 replicas, a total of 27 × 26, or 702, communications vectors exist.

Transitive Synchronization in NetWare 5 and Higher

In NetWare 5 Novell introduced the idea of transitive synchronization. Transitive synchronization is a synchronization methodology wherein a server doesn’t have to contact every other server in the replica list. It can enable other servers to ensure that synchronization is complete, as demonstrated in Figure 6.4.

FIGURE 6.4 Transitive replica synchronization between four NetWare 5 and higher servers.

The reduction in traffic in a transitive synchronization environment is very significant, and the completion of the entire synchronization cycle is reduced. Ideally, this would create a scenario in which the vector count would simply equal n–1, so with 27 replicas, only 26 communications vectors would be needed. Table 6.3 shows the difference in vectors between transitive and nontransitive synchronization.

TABLE 6.3 The Number of Communications Vectors with Transitive and Nontransitive Synchronization

This discussion represents the ideal number of synchronization vectors when using transitive synchronization. As you can see in Table 6.3, the number of communications vectors with transitive synchronization is significantly smaller than the number with nontransitive synchronization, although it is possible that the number of vectors could increase, depending on the network design and availability of services. The actual number of synchronization vectors with transitive synchronization could be larger but will always be smaller than without transitive synchronization.

NOTE

In a way, you can consider transitive synchronization a feature of NDS 7 and higher. Therefore, you do not need to have NetWare servers to take advantage of it because the non-NetWare DS servers will be running eDirectory, which supports transitive synchronization.

Transitive synchronization also addresses mixed transport protocols used on different DS servers. Consider the example presented in Figure 6.4. Without transitive synchronization support, the servers Rigel and Orion will not be able to synchronize with the server Vega because they do not share a common transport protocol. With transitive synchronization, however, there is no problem because the server Betelgeuse acts as a gateway or a mediator.

WARNING

One side effect of replica rings with mixed transport protocols is that the servers Rigel and Orion in this example will attempt to talk directly to Vega (and vice versa). They will report “Unable to communicate with server x” errors. However, this does not indicate a problem with your DS. It’s just that DS has detected a situation that is really not a problem.

To understand how transitive synchronization works, you must first be familiar with transitive vectors. NDS uses a time vector—also called a time array—to keep track of changes to a given partition. This time vector holds timestamps for all the replicas in the replica ring from a given server’s perspective. (For instance, if there are two replicas for this partition, two timestamps will be found in the time vector, as illustrated in Figure 6.5.) Each server holds a copy of its own time vector as well as copies of time vectors from the other servers in the ring. This group of time vectors is collectively known as the transitive vector. The Transitive Vector attribute is multivalued and associated with the partition root object, so NDS/eDirectory can manage the synchronization process and determine what needs to be sent to other replicas. Each replica has its own transitive vector; there is only one transitive vector for each replica, and it is synchronized between all servers within the replica ring.

FIGURE 6.5 NDS iMonitor showing the time vector values of a transitive vector.

To see the transitive vector values in NDS iMonitor, as shown in Figure 6.5, from Agent Summary, you click the Partition Replica link and then click the Partition link, followed by Attributes. Finally, you click the Transitive Vector link.

NOTE

In NDS 6 and earlier, the single-valued attribute Synchronized Up To is used to determine when the latest changes were made. The value of this attribute is unique for each replica and is not synchronized to the other servers in the replica ring.

When you synchronize the transitive vector values, all the replicas can synchronize without needing to have every replica communicate with every other replica. Each time the replica synchronization process begins its scheduled run, it first checks the entries in the transitive vector to determine which other servers hold replicas that need to be synchronized. The check compares the timestamps of the time vectors of the source server that received the update with those of the destination server. If a timestamp is greater for the source server, replica updates are transferred. The source server updates its own time vector within the transitive vector and sends the updated transitive vector to the target server. At the end of the replica update process, the target server updates its own time vector within the transitive vector and sends that updated transitive vector back to the source server. Now the two servers know they are both up-to-date, and the target server will not try to sync with the source server with the same update.

NOTE

Under the transitive synchronization scenario, the source server does not request the target server’s timestamps because they are already present in the transitive vector that is stored on the source server.

Multithreaded Synchronization

One of the most significant performance-enhancement features in eDirectory is the introduction of multithreaded replica synchronization, starting with eDirectory 8.6. In previous versions of eDirectory and NDS, all inbound and outbound synchronization was performed using a single thread. Partitions were synchronized in a serial manner—changes in one partition could not be synchronized until the previous partition had been completely processed. However, this is not very efficient for trees where there may be many partitions.

Starting with eDirectory 8.6, outbound synchronization is now multithreaded. Partitions stored on one server can be synchronized out in a parallel manner, allowing replicas to be synchronized in a much more efficient manner.

NOTE

Inbound synchronization is still single threaded. An eDirectory server can receive inbound synchronization for only one partition at a time.

Multithreaded synchronization takes place using one of two synchronization methods (see Figure 6.6):

   By partition—This method causes eDirectory to send out one partition to multiple recipient servers at a time.

   By server—This method causes eDirectory to send out multiple partitions to multiple unique servers at one time.

FIGURE 6.6 Multithreaded synchronization methods.

When eDirectory starts up, it analyzes all partitions and corresponding replica rings stored on the server. This analysis procedure results in a list of all servers involved in replica synchronization and all partitions stored on those servers. If the number of partitions stored on the local server is equal to or greater than the number of unique servers minus one (the local server), eDirectory will automatically synchronize using the by-partition method. Otherwise, eDirectory uses the by-server method. By default, the synchronization method is dynamically adjusted (that is, selected by eDirectory upon startup). But you can also manually select a preferred method via NDS iMonitor (see Figure 6.7).

FIGURE 6.7 Use the Agent Synchronization link under Agent Configuration in NDS iMonitor to view and manage multithreaded synchronization.

The number of threads used for synchronization determines how multithreaded synchronization behaves. For example, if only one thread is configured for synchronization, multithreaded synchronization is effectively disabled. By default, eDirectory allows a maximum of eight threads for multithreaded synchronization.

eDirectory automatically determines the number of threads to use in multithreaded synchronization by determining whether the number of partitions is less than or equal to two times the number of unique servers in those partitions’ replica rings. If the number of partitions is less than or equal to two times the number of unique servers in those partitions’ replica rings, eDirectory will set its maximum thread usage to the number of partitions stored on the local server. Otherwise, the number of threads is set to half the number of unique servers in shared replica rings. This allocatable thread count is used only if it does not exceed the configured maximum thread count. If this count is exceeded, the number of allocatable threads will be set to the configured maximum thread count.

Auxiliary Class Object Handling

NDS versions prior to NDS 8 do not understand or know how to handle auxiliary classes. Consequently, NDS 8 and higher servers only send auxiliary class and auxiliary attribute information to servers running NDS 8 and above. When synchronizing to servers running previous versions, eDirectory must send the auxiliary class information in a manner that is compatible with the previous releases. Because an auxiliary class adds attributes to an object that previous versions of NDS consider illegal, NDS 8 and eDirectory servers make the following modifications to the objects with auxiliary classes before they are sent to servers with previous versions of NDS:

   The AuxClass Object Class Backup attribute (of type SYNC_CLASS_NAME) is added to the object, and all the information from the object’s Object Class attribute is stored in the attribute. This attribute is stored only on the pre-NDS 8 servers.

   The object’s class is changed to Unknown.

   The auxClassCompatibility attribute (of type SYNC_CLASS_NAME) is added to the object on all replicas and is used to maintain timestamps for the object.

Table 6.4 demonstrates how eDirectory modifies an object’s Object Class, AuxClass Object Class Backup, and auxClassCompatibility attributes as it synchronizes to an NDS 7 or older server when an auxiliary class is present for the object.

TABLE 6.4 Auxiliary Class and Attribute Information, as Seen on Servers Running Different DS Versions

When an NDS 8/eDirectory server receives an Unknown object, it checks whether the object has an auxClassCompatibility attribute. If there is such an attribute, NDS 8/eDirectory replaces the Unknown class with information from the AuxClass Object Class Backup attribute and restores the object to normal. The auxClassCompatibility attribute is maintained on all servers in the replica ring as long as at least one NDS 7.x or older server is in the ring. When all NDS 7.x and older servers are removed from the replica ring, the attribute is removed from the object. This information is often referred to as the “Aux Class Lie.”

NOTE

Because many existing applications that read NDS/eDirectory class definitions do not necessarily understand auxiliary classes, Novell modified the read class definition APIs to provide backward compatibility. All the new routines do is intercept the client responses and substitute the class information located in the Object Class attribute with the information located in the AuxClass Object Class Backup attribute. As a result, if you look at the object in DSBrowse or NDS iMonitor, the object will still show up with an Unknown class, but NetWare Administrator and ConsoleOne will now show up as known objects. You should be able to administer such objects with NetWare Administrator or ConsoleOne as if they were normal objects. Only applications that have been updated to be compatible with NDS 8 and higher can display auxiliary class definitions with an auxiliary object class flag.

NOTE

You need DS.NLM 6.19/7.62 and higher to take advantage of the updated APIs.

You can modify the NDS schema by adding or deleting attribute definitions and object class definitions. Such changes need to be replicated among all the servers within the same tree that contain replicas. This synchronization is done through the Schema Synchronization process. This process is started within 10 seconds following completion of the schema modification operations; the 10-second delay enables several modifications to be synchronized at the same time.

The updates to the schema are propagated from one server to another; this is similar to the Replica Synchronization process. However, the Schema Synchronization process does not use a replica ring to determine which servers to send the schema updates to. Schema updates are sent to servers that contain either replicas of a given partition or Child partitions of the given partition.

Because schema modifications must occur on the server that is hosting the Master replica of [Root], the modifications flow from the [Root] partition down to the extreme branches of the tree.

The actual Schema Synchronization process is made up of several different processes:

The detailed operation of the Schema Synchronization process is rather involved. The following simple example serves to illustrate how the Schema Synchronization process works from a high-level point of view. Figure 6.8 depicts a small tree with five servers and three partitions.

FIGURE 6.8 A Schema Synchronization process example.

A schema change is made to Betelgeuse because it holds the Master replica of the [Root] partition. After this server has been updated, this server sends the schema changes out to the other servers that hold copies of [Root]: Rigel and Andromeda. After all servers in the [Root] partition have received the updates, DS sends the updates to the other servers in the tree. It does this by looking at the servers that hold copies of [Root] and reading the replica list information to find out what other replicas are out there; then it builds a schema sync list. Each server’s schema sync list may be different, depending on what replicas it hosts.

You can look up a server’s schema sync list by using either DSTrace or NDS iMonitor. It is easiest to use NDS iMonitor, as shown in Figure 6.9; it is found under Service List under the Schema link.

FIGURE 6.9 A server’s schema sync list.

To use DSTrace, you first enable the DSTrace filter with the +SCHEMA flag on NetWare or the +SCMA flag on Unix, and then you use the set dstrace=*ssl DSTrace option. The output looks similar to this:

On Windows, you need to enable DSTrace’s Schema Details from the DSTrace Edit menu and then trigger the Schema Sync process from the Trace tab of the DSA window.

By looking at the replica list on Rigel, for example, DS can determine that there are two child partitions—OU=West.O=XYZCorp and OU=East.O=XYZCorp. The replica list on Rigel also indicates what other servers are in the tree. DS determines that the servers Vega and Orion also need to be updated. During this determination, note that Vega and Rigel are listed twice because of the replication scheme in this tree; even though Rigel receives an update in the first round of schema synchronization, after Vega receives the updates to the schema, Rigel is again checked to see whether its schema is current. If the schema is not current, it is updated.

As discussed earlier in this chapter, schema changes are synchronized from the root of the DS tree down to its branches. Because a tree can have NDS 8 servers near the root, with NetWare 6 or 4.2 servers in the middle, and an eDirectory 8.7 server below them, eDirectory must be able to send schema information about auxiliary classes in a manner that is compatible with legacy versions of NDS. It must do so with sufficient clues that an eDirectory server can re-create an auxiliary class from the information. To accomplish this, when synchronizing schema with a server running NDS 7 or older, eDirectory makes the following changes to the three auxiliary class characteristics to make them compatible with previous versions of NDS:

The NDS Janitor process is responsible for a number of different tasks, including the following:

The Janitor process has responsibility for some fairly critical tasks. By default, the Janitor process runs every two minutes, although it doesn’t perform every task in its list each time it runs. (For example, it schedules the Flat Cleaner process only once every 60 minutes.)

DS uses synthetic time to manage situations where the current timestamp on an object is later than the current time. The Janitor process checks the timestamps on the objects in the server and when a new timestamp is needed for an object. If an object in the server’s replicas has a timestamp greater than the current server time, the Janitor process notifies the operating system, and a message is generated on NetWare’s system console:

Janitor Process Optimization

One of the Janitor process optimization steps is the rehashing of the database information to enable the server to perform lookups more quickly.

If the Janitor process detects that the name of the partition root object has changed, it notifies all servers holding external references of this object of the new name.

Updating the Inherited ACL attribute values starts with the first partition in the partition database. After the Janitor process has located the partition, it validates that the parent object is not an external reference and looks at the ACL to determine whether any of the attribute values have been modified. If they have, it validates whether the attribute is inheritable, and if it is, it recalculates the Inherited ACL attribute values. The Janitor process performs this process for all the partitions on the server.

REAL WORLD
Inherited ACL Explained

Inherited ACL is an attribute that is assigned to and found only on a partition root object. It is used to identify effective rights that are inherited by trustees on the partition root object and that were assigned at a container higher up in the tree.

The Inherited ACL attribute provides a way for NDS to determine each object’s effective rights, without having to walk past that object’s partition boundary (that is, upward in the tree).

The NDS Janitor process calculates the Inherited ACL attribute by starting at the partition root object of a partition (if there are multiple partitions, beginning with the one closest to [Root]) and performing the following tasks:

1.   The Janitor process searches each of the subordinate containers for rights assignments.

2.   The Janitor process replaces the rights assignment found on a subordinate container with the one found on a superior container object whenever it encounters a duplicate privilege assignment for a trustee.

3.   The Janitor process searches for and applies any inherited rights filter (IRF) found on a subordinate container object to all trustee rights assignments inherited by that subordinate container.

After the NDS Janitor process has reached the lower boundary of the partition, the process adds the Inherited ACL values gathered up to that point to the child partition’s partition root object; the child partitions could be Master, Read/Write, Read-Only, or SubRef partitions. The process then repeats itself, proceeding through the same steps with each child partition until all partitions on the server have been processed and no additional partitions exist.

The Inherited ACL attributes are synchronized to the other servers in each partition’s replica ring. In the process, the servers that hold child partitions—but not the parent partition—are able to calculate the proper rights for objects without having to communicate with other servers.

Updating the Status attribute involves validating that the DS attribute Status of the NCP Server object is set to Up. Because the server that performs the validation is up and running, this server always checks for an Up value. If it is set to Down, the Janitor process updates the attribute. Figure 6.10 shows where in NDS iMonitor you can see the result of this operation. To reach this screen, you select Agent Summary, Known Servers; click the server of interest; and select Status.

FIGURE 6.10 A server status value shown in NDS iMonitor.

When an NCP Server object’s Status attribute is set to Down, the synchronization processes does not attempt to communicate with that server. Sometimes when a server is brought back online, its Status attribute value of Up might not be noticed by the other servers in the replica ring right way. You can manually force the status to Up by using NDS iMonitor as shown in Figure 6.11 by clicking the Agent Configuration link and then selecting the Agent Triggers link.

FIGURE 6.11 Manually forcing server status to Up.

The Janitor process’s role in ensuring that the server can receive schema updates if it holds no replicas is particularly important. Even if a server has no local replicas, it still receives information for external references (such as those used to grant rights in the file system). In order to handle this properly, the server needs to know about all the different class definitions in case an extended class object receives rights to the file system. Equally important is the need for the schema partition to be maintained in case a new replica is added to the server later. If the server does not have current information about the schema and a replica is added to the server, many objects will change to Unknown objects in the local database, which can cause problems with object administration if those copies of the objects are read by the various management tools.

Finally, the Janitor process is also responsible for updating the Revision attribute of external references when the attribute value on the referenced object is changed.

The Flat Cleaner process is scheduled by the Janitor process and runs
             192every 60 minutes by default. Responsibilities of the Flat Cleaner process include the following:

As described in Chapter 2, the bindery partition is the partition that is used to store information about the bindery user Supervisor. This partition also stores the SAP information that is received from IPX networks connected to the server. If a service is removed from the network, the SAP table in the server needs to be updated; this is one of the tasks the Flat Cleaner process is responsible for.

Obituaries that have reached the Purgeable stage need to be removed from the database, and the Flat Cleaner takes care of this. Essentially, the Flat Cleaner process removes any object or attribute flagged as Non Present.

The Flat Cleaner process is also responsible for validating the Up state of all servers that hold Master replicas. As discussed earlier in this chapter, the Janitor process is responsible for setting the server Status attribute to Up. The Flat Cleaner process is responsible for setting the Status attribute to Down as necessary if it finds that it cannot communicate with the server.

To understand the process better, let’s consider a simple example where there are two servers, Orion and Rigel. Orion holds the Master copy of [Root], the only partition in the tree. If Rigel is offline when Orion’s Flat Cleaner process runs, Orion sets the Status attribute for Rigel to Down. When Rigel is brought back online, it runs its Janitor process, checks the Status attribute, and sees that it is set to Down. Because the server is no longer down, Rigel changes the Status attribute to Up.

The Flat Cleaner process also performs checks to validate all Public Key and CA Public Key attributes for objects the server holds. If it finds an invalid or missing key, it attempts to create new keys for the object. DS uses the Public Key and CA Public Key attribute values during the authentication process; if these keys are not valid on User objects, the user (or an administrator) has to change his or her password to fix the problem. If, however, these keys are corrupted on an NCP Server object, server-to-server authentication is disrupted, and synchronization does not occur.

The Backlink process, or Backlinker process, as it is called in some Novell documentation, checks on the validity of external references by verifying whether the original entry still exists and whether the reason for its existence is still valid. If the external reference is no longer needed or used after a given time period, the Backlink process removes it.

The Backlink process also helps clean up external references. If the server holding the external reference no longer requires it or if the ExRef partition’s life span has expired after not being used for a certain amount of time (the default is 192 hours [that is, 8 days]), the external reference of the object is deleted when the Backlink process has conformed each of the following conditions seven times:

The Backlink process is also responsible for ensuring that every external reference has a copy of the actual object’s GUID attribute. This is necessary for file system rights for NSS volumes in NetWare 6 and higher.

By default, this process runs every 13 hours (that is, 780 minutes). You can modify the default value with via either DSTrace or NDS iMonitor (see Figure 6.12).

FIGURE 6.12 DSA background process settings in NDS iMonitor.

Because the Backlink process works with external references, it is also known as the External Reference Check process.

The last of the automated background processes is the Limber process. Primary responsibilities of the Limber process include the following:

If a server name or address changes, the Limber process is responsible for ensuring that the modifications are made to each replica pointer table in the partition ring. If the changes occur on the server that holds the Master replica, the Limber process changes its local address in the replica pointer table. If the changes occur on a server that holds a non-Master replica, the Limber process tells the Master replica about the changes. The Limber process can initiate the Backlink process, which does part of the checking (on exref objects) for the Limber process.

As mentioned in Chapter 2, some of the information maintained by the Limber process is stored in part in the local System partition. The following tasks are considered to be secondary functions of the Limber process but are nonetheless important:

The Limber process is one of the background processes that cannot have its schedule interval changed. If the Limber process’s primary operations complete successfully, the process reschedules itself to run again in three hours. If the primary operations have not completed successfully, the Limber process reschedules itself to run again in five minutes.

Object creation is a fairly straightforward process. In ConsoleOne, for instance, you select the context where you want the new object to be placed and either click Insert or right-click the container you want to create the object in and then select Create from the menu. ConsoleOne asks you for the object class, and after you select that, you are presented with an appropriate dialog box to enter the mandatory attributes of the object.

From the server’s perspective, object creation is also a simple process. The client API generates the DSA request verb DSV_ADD_ENTRY (decimal value 7) and submits it to the server. Listing 6.4 shows the DSA Add Entry request for User object PKuo.

The request buffer is filled with the information entered in the Create Object dialog box. In the listings in this section, this information is seen on the server processing the client request by enabling the +DSA and +BUFFERS (+CBUF on Unix) flags in DSTrace.

The information shown in the request buffer is in Unicode format, which is a 2-byte character format. For English-language objects, Unicode fills the first byte with 00. In Listings 6.4 and 6.5, you can see the object name starting at offset 19, followed by the mandatory attribute Surname (offset 39) and its value (offset 63). Finally, you can see the Object class attribute and the value USER. This is the minimum information needed to create a User object and is passed directly to the DSA from ConsoleOne.

If the object already exists, the server’s reply is shown right after the request, as shown in Listing 6.5.

The error code -606 is defined as ERR_ENTRY_ALREADY_EXISTS. This makes sense because in this example, the object does in fact already exist in the specified context.

Object creation can take place on any writable replica. When a create request is completed on the server that the workstation contacts, the object is queued up for the next synchronization cycle and sent out to the other servers in the replica ring. As discussed in the section “The Synchronization Process,” this synchronization cycle is either transitive or nontransitive, depending on the version of NetWare and NDS/eDirectory running on the servers in the replica ring.

Renaming an object is a fairly simple process. The request is actually broken into two parts—a Resolve Name request (DSV_RESOLVE_NAME, decimal value 1), as shown in Listing 6.6, and the actual Rename operation, as shown in Listing 6.7. This example renames the object PKuo as JimH. This operation requires that the client be able to contact a server holding a writable copy of the object being renamed.

The reply sent to the Resolve Name request returns the object ID of the object being renamed, starting at offset 4 in reverse-byte order, as shown in bold in Listing 6.6. In this example, the entry being renamed has an entry ID of 0E0002BC. The server responding also includes its network address in the reply buffer. In this example, the (IPX) address is shown starting at offset 20. Unlike the entry ID, the address value is not in reverse-byte order, and it includes the network, the node, and the socket address. In this example, the address is 84123001:000000000001:0451.

When the requested information is returned, the client sends the Rename request (DSV_MODIFY_RDN, decimal value 10) to the server that replied to the Read request. The request buffer for the Rename request does not include the old object name; rather, it uses the object’s ID, retrieved from the Resolve Name request that occurred at the start of the rename operation. This object ID is again put at offset 4, in reverse-byte order. In Listing 6.7, this is 0E0002BC, shown in bold, the same object ID returned by the Resolve Name request. In a rename operation, the object ID in the Rename request always matches the ID read in the initial Resolve Name request. This is how the client knows which object is being renamed.

In a multiserver environment, the rename operation sets in motion a series of events to ensure that the rename operation is synchronized properly. The old object ID has an OLD_RDN obituary issued for it in order to start processing the purge of the old name from the DS database. At the same time, a NEW_RDN obituary is issued for the new object name.

If one of the servers in the replica ring is unavailable, you can see the obituaries that have been issued for the rename operation. By running DSRepair (with the -A command-line parameter), you can view the current obituaries and their states on the server by performing an external reference check. Listing 6.8 shows the information written to the DSREPAIR.LOG file about the two obituaries that have been created by renaming the object PKuo as JimH.

From the section “Obituaries,” you know that a Backlink obituary was created because the server Rigel contains either a real copy or an exref of the object. The obituaries that are issued do not prevent you from performing other operations on the object. In fact, after an object is renamed, it is possible to create a new object by using the original object’s name.

Deleting an object from the tree is similar to renaming an object in the tree. As with the rename operation, the delete operation requires that the client be able to communicate with any server that holds a writable copy of the object.

First, a Resolve Name request is sent; it is similar to the one that appears before the rename operation in Listing 6.6. As with the rename object operation, the reply buffer includes both the object ID of the object being deleted and the network address of the server that responded to the request. When this information is returned, the client requests the actual deletion of the object by using DSA verb DSV_REMOVE_ENTRY (decimal value 8). This request is shown in Listing 6.9.

You again see the object ID passed into the request starting at offset 4, in reverse-byte order. This request is for object ID 010002BA to be deleted. The object ID requested again corresponds to the object ID returned by the Resolve Name request at offset 4.

Object deletion creates an obituary of class Dead. Again, by using DSRepair with the -A switch and checking external references, you can see the obituaries created by deleting the object. Listing 6.10 shows the log file entries that result from this operation.

As with a Rename request, a Backlink obituary is generated in addition to the Dead obituary; a Used By obit is also generated. And as with the rename operation, these obituaries do not cause any delay in creating an object with the same name.

The final object-level operation to examine is the move object operation. This operation is more complex than the other object-level operations and differs slightly from them because of the added complexity.

The first difference between moving an object and performing any other object-level operation is that a Move request requires communication with the server that holds the Master replica of the object. If an object is moved across a partition boundary, communication with the servers that hold the Master replicas of both partitions is required. In addition, those servers must be able to communicate with each other in order for an object’s data to be moved from one partition to the other.

For simplicity, let’s examine an object move within a partition (User object PKuo from East.XYZCorp to West.XYZCorp) because this operation does not vary much between a single server operation and a multiserver operation.

In Listing 6.11, you start by reading object information, using DS verb DSV_READ_ENTRY_INFO (decimal value 2), for the source organizational unit (OU) and destination OU. The request made for the objects is by ID, and the reply buffers contain information about the object: the container class and the full DN of the container in question.

These requests validate that the source and target containers are known to the client, and they ensure that the client is communicating with the server that holds the Master copy of the object and the server that will hold the Master copy of the object. Next, you see a Read request to obtain information about the actual object being moved. This is shown in Listing 6.12.

The next step in the move process is to issue a start move operation (DS verb DSV_BEGIN_MOVE_ENTRY, decimal value 42). This request, shown in Listing 6.13, involves the name of the object and the server involved in the communications. Starting at offset 16, you can see the object name, and at offset 32, the FQDN of the server.

At this point, the obituaries are issued for the moved object as well as for the object in its new location. Listing 6.14 shows the DSRepair log after an exref check is performed.

Now you see more differences between the move operation and the previously described object operations. The Inhibit Move obituary issued for the new object (Obit 4 in Listing 6.14) blocks further operations (except modify) on the object, including renames, deletions, and moves until the move operation is completed. It is possible to change the attributes of the object, but all other requests receive a -637 error “previous move in progress”). This is one of the most common error messages received while performing administrative tasks. If you understand how the move process operates, you can understand what a -637 error means and know what needs to be done to resolve the situation.

As with the previous object operations, with this operation, you also have a Backlink obituary created.

When the move is complete, DS requests that the move be finished by issuing DS verb DSV_FINISH_MOVE_ENTRY (decimal value 43). This initiates the purge process for the Move Inhibit and Moved obituaries. Listing 6.15 shows this request.

The finish move operation completes, and the obituary purge process begins. When the obituaries are purged, you can proceed with other move operations, and you can rename the object or delete it. However, if you try to delete an object that was just moved without waiting for its associated obits to be purged, you will get a response similar to that shown in Listing 6.16.

The error message in the reply buffer is expected in this case: -637 error (“previous move in progress”). This error occurs because the obituaries created for the Move request have not yet purged, even though the finish move operation has executed successfully. You can retry in a short while and succeed. However, if the error is not cleared after some time (say, 10 minutes), you should check server-to-server communications and determine why the obits are not being purged.

When working with partitions and replicas, you need to be familiar with the various states they can be in. Table 6.5 lists the possible states that a partition or replica can go through and their values (in both hexadecimal and decimal).

TABLE 6.5 Replica States

The values that appear in some DSRepair log files and DSTrace screens can provide insight into the current state of operations. A detailed explanation of some of the states follows:

NetWare 4.1 and higher enable you to abort a partition operation that is in progress. A pending partitioning or replication operation can be aborted through DSRepair, as shown in Figure 6.15.

FIGURE 6.15 Using DSRepair to abort an in-progress partition operation.

Now that you have a good grounding in the replica states, the following sections examine the various partitioning/replication operations, starting with the Split Partition operation.

The Split Partition operation is the process that is used to create a new (child) partition. When you install the first DS server in a tree, the [Root] partition is created automatically; any other partitions created are split off the [Root] partition.

The information reported by the DSTrace screen is fairly minimal. Watching the operation entails enabling the Partition DSTrace flag (+PART in NetWare and Unix). This enables the trace information for all partitioning operations. Listing 6.17 shows the information presented during a Split Partition operation.

While a Split Partition operation is being performed, further partitioning and replication operations for that partition are suspended. Further operations will result in an error -654 (ERR_PARTITION_BUSY) until the replicas are turned on (that is, become usable). This operation is indicated in the last line of Listing 6.17.

Notice that lines 7 and 8 in Listing 6.17 (which appear in boldface) indicate that the server the trace was done on became the Master replica for the new partition. This is to be expected because this server holds the Master replica of the parent partition. When you perform a Split Partition operation, the servers that end up with replicas are the same as the ones that hold replicas of the parent partition. After the replicas are turned on, you can further manipulate the replicas by adding, removing, or changing the replica types.

Merging a partition—also referred to as joining a partition—is the reverse of splitting a partition. The Merge Partition operation merges parent and child partitions into a single partition. As Listing 6.18 shows, two operations actually take place during a join—a join up operation and a join down operation. The join up operation is the process of joining of the child partition with the parent; the join down operation is the process of the parent joining with the child partition.

The Merge Partition operation results in a single partition where there were two; however, the replicas for each of the old partitions have to be dealt with in such a way that bindery services on all servers are not disrupted. When you’re merging partitions together, it is very important to determine where the new partition’s replicas are going to be. For example, if you have eight servers involved in the Merge Partition operation, you will end up with eight replicas of the new partition. This might not be desirable, so you will want to examine where these new replicas will be and what services would be affected on each server if you were to remove the replica from this server.

Moving a partition is similar to moving an object—in fact, the operation uses the same code within the DS module to perform the operation. The biggest difference is that the Move Partition operation also generates Create Replica operations, which in turn result in object Synchronization operations. The Move Partition operation is a fairly complex operation—more so than the other operations discussed in this chapter. Before you commence, you must make sure you have no synchronization problems in the partitions involved.

There are two rules to remember when moving partitions:

Figure 6.16 shows an example of a violation of the first rule. This Move Partition operation is invalid because containment rules are violated: O=XYZCorp cannot be moved to under O=DIV1 because an organization cannot contain another organization.

FIGURE 6.16 Illegal partition moves.

By extension of the second rule, it is not possible to move a partition so that it becomes subordinate to a child partition. As Figure 6.16 shows, it is also not permissible to move the East.XYZCorp partition under the OU=West.O=XYZCorp partition because there exists a child partition, OU=IT.OU=East.O=XYZCorp, under OU=East.O=XYZCorp.

The following sections focus on some things you need to watch out for when moving a partition.

The Rename Partition operation is very similar to the Rename Object operation, except that the obituaries issued are different—rather than the OLD_RDN and NEW_RDN obituaries being issued, the obituaries issued are Tree_OLD_RDN and Tree_NEW_RDN. Renaming a partition is really a special case of the Object Rename operation because the only object directly affected is the partition root object.

The Rename Partition operation is one operation that can hold up any other type of partition or replication operation. NDS/eDirectory checks for this condition before attempting the Add Replica, Delete Replica, Split Partition, Join Partition, and Change Partition Type operations.

Creating a replica, also known as an Add Replica request, requires communication with each server in the replica ring for the partition being affected. An inability to communicate with a server in the replica ring results in a -625 error (ERR_TRANSPORT_FAILURE) or a -636 error (ERR_UNREACHABLE_SERVER).

Creating a replica of a partition involves making changes to the local partition database and then performing a synchronization of all objects in the partition to the server receiving the new replica. Problems can occur for two reasons:

The Delete Replica operation is similar in requirements to the Create Replica operation. The Delete Replica operation requires all servers in the replica ring be reachable. The server holding the Master replica of the partition processes the request.

The verification routines ensure that the replica being removed is a Read/Write or Read-Only replica. If the replica in question is the Master replica, a -656 error (ERR_CRUCIAL_REPLICA) is returned.

A lock is placed on the partition during the operation. Unlike in other operations, this lock is left in place for a number of steps, including an immediate synchronization that is scheduled to ensure that all objects in the replica being moved have been synchronized. This ensures that information in the objects stored in the replica being deleted does not get lost if it is newer than the information in other replicas.

Compared to the other operations we have looked at in this chapter, the Change Replica Type operation is relatively simple. This operation is easiest to perform from the ConsoleOne utility. Figure 6.17 shows the ConsoleOne dialog box, Change Replica Type, that is used during this operation.

FIGURE 6.17 The Change Replica Type dialog box.

In Figure 6.17 you can see the replica types available for changing the selected server’s replica type. Because the selected server currently holds a Read/Write replica of the partition, you have a number of options to choose from.

Changing a Read/Write or Read-Only replica to a Master replica actually causes two changes to be made. First, the Master replica is changed to a Read/Write replica. Second, the Read/Write or Read-Only replica becomes the Master replica; this is done because there cannot be two Master replicas for a given partition—and it is done for you automatically.

The Change Replica Type operation generally occurs very quickly because no replicas need to be created or deleted in order to change the replica. The replica ring is updated on all servers that hold replicas (including SubRef replicas), and the server or servers affected have a change made in their partition entry tables to reflect the change in replica type.