Troubleshooting guide

9
Obituaries 53
9
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