OSF DCE Administration Guide--Core Components
Overview of DCE Security
memory database and its log file. Each update in a propagation queue is identified by a
sequence number and a timestamp. The sequence number is used internally to track the
propagation of updates to slave replicas. The timestamp is provided to show users the
date and time of updates.
When a master or slave replica restarts, it initializes its database in virtual memory and
then applies any outstanding updates in the log file to its database. If the replica is the
master replica, it also recreates the propagation queue from the log file so that any
outstanding slave updates can be propagated. This mechanism ensures that no updates
are lost when a server is shut down.
27.6.3 Propagating Database Changes
To propagate updates to the slave replicas, the master replica first updates its copy of the
database by using the process described in Section 27.6.2. Then, the master replica
attempts to propagate the update to each slave replica on its replica list. The replica list
contains each slave replica’s ID and network address. It also contains the sequence
number of the last update that was made to the slave. The master replica always
propagates in sequenced numerical order. By examining the sequence number that is
associated with a replica in its replica list, and the sequence numbers of the updates that
are in its propagation queue, the master can determine which of the updates on its
propagation queue must be propagated to which slave. This mechanism helps ensure that
the unavailability of a single slave replica does not interfere with updates to the rest of
the slave replicas.
If the propagation of an update does not succeed on the first attempt, the master replica
tries periodically until it succeeds. When the update succeeds, the master updates the
sequence number that is associated with the updated replica on its replica list. When an
update is propagated to all the slave replicas, the master removes the update from its
propagation queue.
27.6.4 Master/Slave Authentication
Like all DCE objects, the master and slave replicas must authenticate to each other. To
do this, the master carries the identity of dce-rgy, one of the principals that is created
when the database is created. Slaves carry the identity of the host machine on which they
exist. Note that this identity must have the rights to the /.:/sec/replist object described in
Chapter 41.
27.7 The /etc/passwd and /etc/group Files and the Registry
124243 Tandem Computers Incorporated 27−7