NetWare 5 Advanced Administration

Chapter 10: 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 10-1:

  1. Understanding partitioning and replication.
  2. Explain preventive maintenance procedures for the NDS database.
  3. Troubleshoot NDS database inconsistencies.
  4. Explain NDS database repair procedures that use NDS Manager, including creating a new master replica, repairing a local database, sending and receiving updates, repairing network addresses, and repairing server IDs.
  5. Explain the procedure for recovering NDS from a failed server or volume.

 

Key Concepts:

The chapter opens with a summary of NDS Directory features on page 10-2:

  • The Directory is a database of objects. Earlier versions of NetWare used a Bindery for this purpose.
  • The Directory contains data on object properties and their values, and the rights other objects have to them.
  • The Directory is checked to determine whether any object has the rights required to carry out an action or request. This is called access control.
  • The Directory is checked to authenticate users. This means checking their credentials, their rights, their passwords, etc.
  • The Directory is not part of the File System. The Server and Volume objects are the only common areas.

The first 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 on page 10-2. We divide the Directory Tree into partitions using containers. 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 do it, just an example.) 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 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. Other copies may be made into master replicas, if the original 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.
  • 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.

Page 10-4 describes two concepts: 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.

Preventative Maintenance

  • 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.
    • 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 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 on pages 10-10 and 10-11.
  • 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 appear on page 10-12:
    • Set Minimum Space Requirements - to make the system warn you before it runs out of space
    • 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.
    • Do not turn off TTS on servers with active replicas. This will cause the disaster.
  • Prepare the Server for Shutdown - If bringing a server down, remember that someone is depending on it. Consult the chart on page 10-13 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.

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 like those on page 10-15, that start with the word SYNC.
      • In NDS Manager, follow the procedure on page 10-16. 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 on page 10-17, Checking Partition Continuity. Any icon that appears with an exclamation point (illustrated on page 10-18) 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.
  • Correct the Problem - Repairs to NDS. There is a set of guidelines on page 10-20 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 on page 10-21 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 (on pages 10-22 and 10-23) 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.

On page 10-24, the text begins discussing 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.