Red Hat DIRECTORY SERVER 7.1 SP7 - S Guía para resolver problemas descargar pdf (Pagina 53)

Obituaries 53

Obituaries

There has been a great deal of confusion surrounding obituaries stored in the directory and, as a

result, some people have developed poor business practices to deal with then. Unlike some directory

products, Novell eDirectory ensures referential integrity between objects. For example, if Group A

has a member, User B, and User B is deleted, the directory automatically removes the reference to

User B from Group A. Obituaries exist as operational attributes placed on objects by eDirectory as

another way of ensuring referential integrity during delete, move, rename, restore, and other

operations.

There are three general classifications for obituaries:

 Primary obituaries include the types Dead (0001), Restored (0000), Moved (0002), New RDN

(0005), and Tree New RDN (0008).

 Secondary obituaries are generally associated with a Primary obituary and represent the agents

and partitions that need to be notified of the operation specified in the Primary obituary. They

include the types Back Link (0006), Used By (000C), and Move Tree (000a).

 Tracking obituaries include the types Inhibit Move (0003), Old RDN (0004), and Tree Old RDN

(0007).

Obituaries, with the exception of Tracking obituaries, must move through a set of synchronizing

states:

 Initial State or Issued (0)

 Notified (1)

 OK to Purge (2)

 Purgeable (4)

The states are recorded in the Flags field in the obituary attribute. Before an obituary can move to the

next state, the current state must have been synchronized to all replicas of the real object. In order to

determine whether all replicas in the ring have seen a given obituary state, a vector is computed from

the transitive vector. In eDirectory 8.6 and later, a non-stored Obituary Vector is used. In previous

versions of eDirectory, the Purge Vector is used. If the Modification Timestamp (MTS) on the obituary

is older than the computed vector, the server responsible for that obituary can advance it to the next

state.

For a Secondary obituary of type Back Link, the agent that holds the master replica of the object with

the obituary is responsible for advancing the states. For a Secondary obituary of type Used By, the

replica agent that created it is responsible for advancing the obituary states as long as that replica still

exists. If it does not still exist, the agent holding the master of that partition takes over advancing the

obituary states for the Used By obituary. For a Move Tree obituary, the master of the root partition is

responsible for advancing the states.

Primary obituaries can be advanced in their states only after all Secondary obituaries have advanced

through all of their states. After the Primary obituary reaches its last state, and that state synchronizes

to all servers in the ring, all that remains is the object husk, which is an object without attributes—one

which can subsequently be purged from the system by the Purge Process. Tracking obituaries are

1 2 ... 48 49 50 51 52 53 54 55 56 57 58 ... 119 120

Sin comentarios

Red Hat DIRECTORY SERVER 7.1 SP7 - S Guía para resolver problemas Pagina 53