NetWare 5.1 Advanced Administration

Chapter 8: Maintaining Novell Directory Services

 

Objectives:

The topics begun in this chapter will be continued in the Design class next term. This chapter discusses the NDS database, dividing it into sections and making automatic copies of it. The objectives important to this chapter are on page 8-1:

  1. Identify the Benefits of NDS eDirectory
  2. Define NDS Replication and Synchronization
  3. Identify Basic Administration Procedures for the NDS Database
  4. Troubleshoot NDS Database Inconsistencies
  5. Identify NDS Repair Procedures
  6. Recovering from a Crashed SYS Volume
Concepts:
Identify the Benefits of NDS eDirectory

The chapter opens with a discussion of a new name for a Novell product: eDirectory appears to be a new name for NDS. A list of its benefits is given:

  • World’s leading directory service
  • Cross-platform
  • Proven secure
  • Scalable
  • Integrates various directories
  • Central or distributed administration
  • Simplified network administration.

NDS is what it always has been. It is improved in each version, as you would expect. NDS eDirectory is based on a standard called X.500. It supports LDAP, HTTP, and Java, so you can access it via several methods.

Define NDS Replication and Synchronization

The next new topic in the chapter is the Directory Partition. A Directory can be a large database. It may be too large to put on any one server. It is more secure and more practical to divide it into segments, called partitions, that are saved in several places. (This use of the word "partition" is completely different from the way it is used to describe a section of a hard drive. An NDS partition is not a hard drive partition.)

A partition is defined as a subsection of the Directory. We divide the Directory Tree into partitions by using containers as markers of where partitions start. A partition must have a container at the top, and may contain other containers as well. The partition is referred to by the name of the highest container in it. In the diagram below, the first partition we see is the [Root] partition. It is drawn so that it contains the [Root], the highest container object in the Tree. (This is not the only way to partition a Tree, just an example. The [Root] object need not be in partition by itself.)

Any partition also contains all objects inside the containers it contains, unless another partition is made as a child of the first one. For example, the [Root] partition is the default partition in an NDS Tree. If it had been left alone, the [Root] partition below would have contained all objects in the Tree. However, a child partition was created: the EMA partition. We refer to the EMA partition as the child of the [Root] partition, since the EMA partition branched from the [Root] partition. This also makes the [Root] partition the parent partition of the EMA partition. In this example, the EMA partition also has two child partitions: the NYC partition and the Tokyo partition.

The topmost container in a partition is called the partition root. This is true for any partition. In the diagram above, we see that there are four partitions. The first is the [Root] partition, which contains [Root] only. The other three partitions are named for their partition root objects, the three containers at the top of each one. Note the naming standard:

  • All partitions are named for the topmost container in them, the partition root.
  • Only one partition may be called the [Root] partition, the one with [Root] at its highest point.

It may be clearer if you think of the phrase "partition root" as really meaning the "partition's root", the place where we drew a line in the Tree and said it begins a new partition.

Now for the concept of Replicas. A Directory partition contains a lot of information, and it would be a shame to lose it, so Novell invented four kinds of replicas, most of which are copies of a given partition.

  • Master replica - a complete copy of a partition. The original copy is a master copy. Another copy may be promoted to master status, if the original master is damaged. You may only have one master replica of any partition at any given time. Changes made elsewhere are passed here during NDS synchronization, and reconciled. This replica can be used to make changes to the partition and to objects in it.
  • Read/Write replicas - also a complete copy of the partition. There can be several of these copies, and two are created by default (if you have enough servers). This replica can be used to make changes to objects in it. Any partition changes attempted in it are passed to the master replica as requests. Object changes made here are passed to the master replica during NDS synchronization, and reconciled there. This replica can become a master replica if the master is damaged. It can also become a Read-Only replica.
  • Read-only replica - also a complete copy of the partition. Multiples are allowed. All changes requested here are not made here, but passed to the nearest Master or Read/Write replica. Login to a Read-only partition is possible, but not directly supported, as the request is passed on as above. This replica may become a Master replica or a Read/Write replica. This replica receives changes made in other replicas during synchronization. Novell does not recommend making this kind of replica.
  • Subordinate Reference - this is not a complete copy. It is not really a copy at all, just a pointer to a copy of one of the above types. Subordinate References are created automatically. Any server that has a replica of a parent partition, and no replica of the parent's child, will be given a Subordinate Reference to the child. This replica does not support any changes, but forwards any request to a Master or Read/Write replica.

Changes to data come in two types: simple changes and complex changes. A simple change could be a change that affects the data in one object. This change needs to be replicated to all copies of the NDS partition that the object exists in. A simple change is replicated easily, and the replicas synchronize quickly. A complex change would affect multiple objects, such as creating a new partition from two smaller ones. Much data has to be replicated so synchronization may take much longer.

Three utilities are used for maintenance of NDS:

  • NDS Manager - use this from the Tools menu of NetWare Administrator
  • DSREPAIR - an NLM to be run on the server
  • SET NDS TRACE - this is a command run on the server

The text informs us that it focuses on actions using NDS Manager, but you should know that the other two utilities exist as well.

Identify Basic Administration Procedures for the NDS Database
  • Planning Replica Placement - Follow the pattern of the default partition: have at least three copies of each partition. Minimize traffic by limiting yourself to seven or less copies of each partition.
  • Rights for Partition Managers
    • Changes to partitions take time to propagate. If you have several container administrators, only allow a few of them to manage partitions. To manage a partition, they need the Supervisor object right to the partition root. To manage that container, they need only CBRD rights to it (not enough to manage the partition).
    • Also, only make partition changes from one workstation, never from two at once. One manager at a time. A dead lock on the system is possible otherwise.
  • NDS Backups - This is done separately from a data backup. It is done in case your replicas are all bad after a disaster. Do not try to restore NDS from a tape before trying to recreate a bad replica from a good one.
  • Use ONE Version of NDS - NDS versions are controlled by the DS.NLM module. When sent a patch from Novell, apply that patch to all appropriate servers. The patch will only apply to a specific version of NetWare, so do not put a NetWare 5.1 patch on a 4.11 server, should you have both kinds of servers.
  • Procedures for using NDS Manager to check and update DS.NLM versions are described in the chapter.
  • Do NOT Fill SYS: Volumes - Time for deep dark secrets, friends. Your NDS replicas are stored in hidden directories in SYS: volumes. TTS (Transaction Tracking System) watches for change requests coming in to the replica. If you run out of room on the SYS: volume, TTS shuts down, and you can't make NDS changes. This means no one can even log in, much less do any work. Six guidelines to avoid this state are offered:
    • Set Minimum Space Requirements - to make the system warn you before it runs out of space. The default setting is 256 blocks. Try more. The range of acceptable values is from zero to one million.
    • Do not put print queues (the Queues directory) on the SYS: volume.
    • Do not let users store their files on SYS:
    • Do not add replicas to a server unless it has several megabytes of free space.
    • A CD-ROM on a server requires space for index files. Watch out for this. Index files of this sort average 8 MB in size.
    • Do not turn off TTS on servers with active replicas. This will cause a disaster.
  • Prepare the Server for Shutdown - If bringing a server down, remember that someone is depending on it. Consult the chart in this section for precautions. Do not turn off a server with the only copy of a replica on it. Move the replica, or make a new one first.

Troubleshoot NDS Database Inconsistencies

Troubleshooting and Repairing NDS has three major steps:

  1. Identify the problem. - The text refers to NDS problems as database inconsistencies.
  2. Get help from documentation.
  3. Correct the problem.

Each major step is discussed.

  • Identify the Problem. - Three Types:
    • Client Symptoms - these symptoms indicate replicas out of synch
      • User is prompted for a password when they have none.
      • Logging in takes an unusually long time.
      • NDS changes disappear.
      • NDS rights that were granted disappear.
      • Errors continue, but are erratic in appearance.
    • Unknown Client Objects - This may indicate a synchronization error, or it may indicate that partitions are being merged or created.
    • NDS Error Messages
      • You can watch for error messages with the command line utility mentioned above. At the server type in:
        SET NDS TRACE TO SCREEN=ON

        Watch for errors that start with the word SYNC.
      • In NDS Manager, follow the procedure on the text. Look for a value greater than 0 for the All Processed = No line. Note that this method does not check all servers with replicas. Use the next method for better data.
      • The second method using NDS Manager is Checking Partition Continuity. Any icon that appears with an exclamation point shows a synch error.
  • Get Help from Documentation
    • When checking for Partition Continuity, if you get an icon with an exclamation point, double click it. You will get an error code. Double click that, and click the Help button near it. Actions will be recommended.
    • If you already have an error code (perhaps from the TRACE command) just go into NDS Manager, open the Help menu and select Contents. Drill down to Reference, NDS Server Codes, and List of Codes. Select the error code you have obtained.
Identify NDS Repair Procedures
  • Correct the Problem - Repairs to NDS. There is a set of guidelines which you should know:
    • First, leave it alone for a few hours. It might correct itself.
    • Do not bring down the server. It cannot correct itself if you do.
    • Perform corrections only when the documentation says to do so.
    • Do not try to make ordinary changes to a partition that already has errors. It may get worse.
  • To make corrections, consult the chart about NDS Manager in your text. It explains what each action does. Note the Synchronize Immediately, Repair Replica, and Assign New Master actions.
  • The last section under Repairs is the list of eight steps to remove NDS from a server. This is done when you want to take a server out of the net for replacement, major repairs, etc.

Recovering from a Crashed SYS Volume

The text discusses the procedure to recover from a crashed SYS: volume. As noted above, NDS replicas are stored in a hidden directory in this volume. If it goes bad, NDS goes bad. Review the procedure, and take note of the three dingbats (trouble spots) included here.

  1. Document what replicas of what partitions are located on each server before the server goes down. Yes, this means ongoing documentation. If you do not, you will have to do it all anyway as soon as one fails. It will be harder then.
  2. Watch for -625 errors. They may require you to remove the down server from all replica lists that where it is included.
  3. Do not remove a functioning server from a replica list. This will corrupt the list.