5 — Managing the PC-DCE Cell and Servers

[Previous] [Next] [Contents] [Index]

This chapter describes how to manage PC-DCE server replicas and how to backup PC-DCE server and configuration data. This chapter contains the following sections:

5.1 Definitions
5.2 Server Locations and Requirements
5.3 Managing Cells
5.4 Incorporating Replicas into a Cell
5.5 Managing CDS Replicas
5.6 Managing Security Service Replicas
5.7 Removing and Reconfiguring a PC-DCE Server
5.8 Backing Up and Restoring a PC-DCE Server
5.9 Using Locksmith Mode to Repair Registry Damage
5.10 Handling Security Replica IP Address Changes
5.11 Using the Name Service Interface Gateway

5.1 Definitions

Because DCE terminology regarding replicas differs somewhat as it applies to CDS versus the Security Service, it can sometimes lead to confusion. The following definitions clarify DCE replica terminology.

Replica - For CDS, a replica is a copy of a CDS directory.

For the Security Service, a replica is a complete copy of the security registry database.

Master - For CDS, a master is a writeable copy of a CDS directory. There can be only one master copy of a directory.

For the Security Service, the master is the writeable copy of the security registry. There can be only one master.

Slave - Read-only copy of the security registry database.

Primary Server - PC-DCE's term for a CDS server that contains, by default, a clearinghouse that contains master copies of all CDS directories. Although it is possible for master directories to be distributed among multiple clearinghouses, the default (and typical) scenario is for one clearinghouse to contain all the master directories.

Replica Server - For CDS, replica server is PC-DCE's term for a CDS server that contains readonly copies of CDS directories. By default, a PC-DCE replica server contains a clearinghouse that contains a readonly copy of the root directory (/.:) but copies of no other directories. A default CDS replica server is not a backup server.

For the Security Service, a replica server is a server that maintains a slave copy of the registry.

Backup Server - For CDS, a backup server is a replica server that contains readonly copies of all CDS directories.

For the Security Service, a backup server is a replica server.

5.2 Server Locations and Requirements

This section describes location, hardware, and security requirements for primary and replica servers.

5.2.1 Locating Servers

As part of your topology design you must decide where to locate your CDS and security servers.

5.2.1.1 For Performance

Because certain full client requests can only be fulfilled by the CDS server that owns the clearinghouse containing the master hosts directory replica, you should locate the master replica for this directory as close as possible to the majority of your users. Then locate additional replicas in remote locations to improve performance in those locations.

You can further tune your CDS database by locating the master directory for each host (/.:/hosts/hostname) in a clearinghouse that is local to that host. When you initially configure a client system, the PC-DCE configuration program creates the host's master directory in the clearinghouse that contains the master hosts directory, even if that clearinghouse is not local. So, to perform this bit of fine-tuning, you may need to re-assign mastership for many host replicas.

Situate servers in the network topology so as to avoid any bottlenecks due to slow network links.

5.2.1.2 For Fault-Tolerance

If your cell serves more than a focused geographic area such as a building or small campus, you should locate your primary and backup servers in different locations. In case of primary server downtime due to power outage or other local catastrophe, the backup server will not be affected.

5.2.1.3 For Security

Make sure that all primary and replica servers, especially the master security server, are located in a physically secure area with controlled physical and login access.

5.3 Managing Cells

This section describes how to obtain information about a cell, such as the cell's DCE servers and hosts, and whether the cell's services and clients are working.

NOTE: You cannot use the cell backup command to back up PC-DCE servers. For instructions on backing up PC-DCE servers, refer to Section 5.8 on page 82.

5.3.1 Showing All Configured DCE Servers and DCE Hosts

To show configured DCE servers and hosts in a cell, enter the dcecp cell show command. This command returns a list of servers grouped by type, along with a list of DCE hosts, as follows:

• secservers - Each value is the name of a security server.

• cdsservers - Each value is the name of a machine running a CDS server. The name is the simple name found under /.:/hosts. A clearinghouse must be configured on that machine.

• dtsservers - Each value is the name of a DTS server in the cell.

• hosts - Each value is the name of a host in the cell, including machines mentioned previously as servers.

The following example shows the names of all the configured DCE servers and hosts in the local cell:

dcecp> cell show
{secservers
 /.../mycell.goodco.com/subsys/dce/sec/master}
{cdsservers
 /.../mycell.goodco.com/hosts/darwin}
{dtsservers
 /.../mycell.goodco.com/hosts/banks}
{hosts
 /.../mycell.goodco.com/hosts/banks
 /.../mycell.goodco.com/hosts/cook
 /.../mycell.goodco.com/hosts/darwin
 /.../mycell.goodco.com/hosts/wilson}

If you have the necessary permission, you can show the configured DCE servers and hosts in another cell by including that cell's name as an argument as shown in the following example:

dcecp> cell show /.../othercell.goodco.com
{secservers
 /.../othercell.goodco.com/subsys/dce/sec/master}
{cdsservers
 /.../othercell.goodco.com/hosts/magpie}
{dtsservers
 /.../othercell.goodco.com/hosts/bluejay}
{hosts
 /.../othercell.goodco.com/hosts/bluejay
 /.../othercell.goodco.com/hosts/finch
 /.../othercell.goodco.com/hosts/magpie
 /.../othercell.goodco.com/hosts/redpoll}

You can use the server ping command to test whether a server process is running. The server ping command returns a 1 if it the server is accessible and a 0 if it is not accessible.

The following example tests whether the master security server is accessible on the network:

dcecp> server ping /.:/subsys/dce/sec/master
1

Use the cell show command to obtain a list of servers to input into the server ping command.

5.3.3 Testing Whether a DCE Host is Running

Because DCE communications often involve several steps before clients communicate with their servers, communication failures can be difficult to diagnose. For instance, a server may not be running on a host or the DCE services may not be currently running, even though the host has been configured into the cell.

You can use a server ping command to test whether a server process is running but, if this fails, you can use the host ping command to test whether a host's DCE services are accessible on the network. This command returns a 1 if it is accessible and a 0 if it is not. The host ping operation tests for the presence of the remote host's DCE daemon (dced).

The following example tests whether dced on host cook is accessible on the network:

dcecp> host ping /.:/hosts/cook
1

You can test whether a cell's DCE services are running by entering the cell ping command.

If called with no option, the cell ping command performs a server ping operation on the master security server, on the CDS server that has a master clearinghouse, and all the DTS servers in the cell. Use the -replicas option to test CDS and security service replicas as well as the masters. The -clients option tests every DCE host in the cell by looping though the /.:/hosts directory in CDS and performing a host ping, with each host name as an argument.

In case of failure, the operation generates an error and returns a list of servers or hosts that could not be contacted. For any successes, the operation returns the message DCE services available. For successes with the -clients option, the message is DCE clients available.

The following example pings the names of all the configured master DCE servers in the local cell:

dcecp> cell ping
DCE services available

The following example pings the names of all the configured DCE hosts in the local cell. Depending on the size of a cell and timeout values set, this command can take a long time (from several to many minutes) to complete.

dcecp> cell ping -clients
DCE clients available

If you have the necessary permission, you can ping the configured DCE servers and hosts in another cell by including that cell's name as an argument as shown in the following example:

dcecp> cell ping /.../othercell.goodco.com
DCE services available

Because your users all rely on the CDS and the security registry, you should take steps to ensure that if a primary server becomes unavailable, an adequate backup is available. DCE replica functionality lets you create backup servers that continue to provide cell directory and security services if the primary servers are unavailable.

5.4.1 Choosing the Number of Replicas

Your cell should contain, in addition to the primary server for CDS, at least one backup server. A backup server is a replica server that contains read-only replicas of all CDS directories, rather than just the root, which is the default configuration for a CDS replica server. It should be standard operating procedure to keep the CDS directories maintained on backup servers complete and up-to-date.

Your cell should also contain, in addition to the master security server, at least one slave server. A security server slave may also be referred to as a replica server or a backup security server.

In environments that cannot tolerate downtime, it is prudent to maintain at least two full CDS replica servers and two security slaves. Then if a primary server becomes unavailable, you can configure one backup as the new primary server and still have a backup already in place.

5.5 Managing CDS Replicas

This section describes how to manage CDS replicas:

5.5.1 Understanding the PC-DCE Default CDS Replica Configuration
5.5.2 Why Modify the Default PC-DCE CDS Replica Configuration?
5.5.3 Basic CDS Replica Management Tasks
5.5.4 CDS Replica Management Procedures

5.5.1 Understanding the PC-DCE Default CDS Replica Configuration

When you configure a cell using PC-DCE servers, you configure the CDS server to either be a primary server or a replica server. The primary server maintains a clearinghouse that contains the master replicas of all CDS directories. A replica server, by default, maintains a clearinghouse that contains a readonly replica of the root directory (/.:) only.

5.5.2 Why Modify the Default PC-DCE CDS Replica Configuration?

You can use DCE command line tools to create replicas of additional directories in the clearinghouse maintained by a replica server. You can also change the mastership of specific directories.

Why would you want to do any of this? Here are several possible reasons:

• You want to increase the ability of replica servers to perform load sharing. In this case you would want to replicate additional directories on replica servers so they can serve information from these directories.

• You want to assign a replica server mastership of certain directories in order to enhance performance in geographically-dispersed cell. For example, when a full DCE client initializes it exports objects to the master directory for its host (/.:/hosts/hostname). You may wish to move the mastership of certain hosts subdirectories to the replica server closest to the corresponding hosts.

• You want to convert an existing replica server to be the primary server. You may want to do this for performance reasons or if the primary server has experienced a hardware failure.

• You want to ensure that clients will be able to "failover" if the master is down (see Appendix B on page 123).

The following sections describe how to make these modifications to the default CDS replica structure.

5.5.3 Basic CDS Replica Management Tasks

This section describes basic CDS replica management tasks. A later section describes how to apply these basic tasks to more complex management procedures.

5.5.3.1 Determining the Structure of the CDS Directory Tree

The first thing you should do if you are planning to add or delete replicas or change replica mastership is to familiarize yourself with the structure of the current CDS directory tree. To do so, you explore the tree using the following dcecp command:

directory list -directories directory

This command lists all of the directories subordinate to directory. By starting at the root directory (/.:) and working your way downward, you can discover all of the directories. For example:

C:\> dce_login cell_admin -dce-
C:\> dcecp
dcecp> directory list -directories /.:
/.../longwood/hosts /.../longwood/subsys /.../longwood/users

This shows the three directories under the root. Now we will explore each of these subdirectories:

dcecp> directory list -directories /.:/hosts
/.../longwood/hosts/banks.explorers.com
/.../longwood/hosts/darwin.explorers.com

dcecp> directory list -directories /.:/hosts/banks.explorers.com
dcecp> directory list -directories /.:/hosts/darwin.explorers.com
dcecp> 

There are no directories under host directories.

dcecp> directory list -directories /.:/subsys
/.../longwood/subsys/dce
dcecp> directory list -directories /.:/subsys/dce
/.../longwood/subsys/dce/sec
dcecp> directory list -directories /.:/subsys/dce/sec
dcecp> 

There are no directories under subsys/dce/sec.

dcecp> directory list -directories /.:/users
/.../longwood/users/joseph /.../longwood/users/charles

dcecp> directory list -directories /.:/users/bob
dcecp> directory list -directories /.:/users/charles
dcecp> 

There are no directories under user directories.

The structure of this CDS directory tree is therefore:

/.:

/.:/hosts
/.:/hosts/banks.explorers.com
/.:/hosts/darwin.explorers.com

/.:/subsys
/.:/subsys/dce
/.:/subsys/dce/sec

/.:/users
/.:/users/joseph
/.:/users/charles

To create replicas of CDS directories, use the following dcecp command:

directory create directory -replica -clearinghouse clearinghouse

For example, if you want to create a replica of /.:/hosts in a clearinghouse darwin_ch, you would enter:

C:\> dce_login cell_admin -dce-
C:\> dcecp
dcecp> directory create /.:/hosts -replica -clearinghouse /.:/darwin_ch

After you create the directory replica, you synchronize its contents with the contents of the corresponding master directory (Section 5.5.3.3).

NOTE: To create replicas of all directories below (and including) the root directory, use the Full Replica option on the Custom tab of the PC-DCE Configuration Panel.

You can verify that all of the replicas have been created by entering the clearinghouse show command and checking the Dir_Name entries. For example:

dcecp> clearinghouse show /.:/shadow
{CDS_CTS 1999-05-11-18:11:21.697000100/00-10-4b-9a-fb-74}
{CDS_UTS 1999-05-11-18:11:25.753000500/00-10-4b-9a-fb-74}
{CDS_ObjectUUID 0065c6b0-72c9-1738-9286-00104b9afb74}
{CDS_AllUpTo 1999-05-11-18:11:24.200000100/00-10-4b-9a-fb-74}
{CDS_DirectoryVersion 4.0}
{CDS_CHName /.../longwood/shadow}
{CDS_CHLastAddress
  {Tower {ncacn_ip_tcp 190.82.110.235}}
  {Tower {ncadg_ip_udp 190.82.110.235}}}
{CDS_CHState on}
{CDS_CHDirectories
{{Dir_UUID 0006ddd1-ff50-16d2-9270-00104b9afb74}
  {Dir_Name /.../longwood}}
{{Dir_UUID 007779f0-ff55-16d2-9270-00104b9afb74}
  {Dir_Name /.../longwood/hosts}}
{{Dir_UUID 00609690-ff55-16d2-9270-00104b9afb74}
  {Dir_Name /.../longwood/subsys}}
{{Dir_UUID 00534690-ff55-16d2-9270-00104b9afb74}
  {Dir_Name /.../longwood/users}}
{{Dir_UUID 00962580-ff9b-16d2-9270-00104b9afb74}
  {Dir_Name /.../longwood/hosts/banks.explorers.com}}
{{Dir_UUID 007f1b10-ff55-16d2-9270-00104b9afb74}
  {Dir_Name /.../longwood/hosts/darwin.explorers.com}}
{{Dir_UUID 006ccb90-ff55-16d2-9270-00104b9afb74}
  {Dir_Name /.../longwood/subsys/dce}}
{{Dir_UUID 0072e610-ff55-16d2-9270-00104b9afb74}
  {Dir_Name /.../longwood/subsys/dce/sec}}
{{Dir_UUID 006ce530-ff55-16d2-9270-00104b9afb74}
  {Dir_Name /.../longwood/users/joseph}}
{{Dir_UUID 00923620-ff55-16d2-9270-00104b9afb74}
  {Dir_Name /.../longwood/users/charles}}
{CDS_ReplicaVersion 4.0}
{CDS_NSCellname /.../longwood}

To synchronize a directory means to update a read-only replica directory with the contents of the corresponding master directory. This normally happens on a periodic basis (default: every hour).

Using the cdsreplica create command to create replicas of all directories below (and including) the root directory automatically synchronizes all replica directories as it creates them.

To synchronize a directory immediately, use the following dcecp command:

directory synchronize directory

For example, to synchronize the contents of a newly created replica of the /.:/hosts directory with the contents of the corresponding master directory:

dcecp> directory synchronize /.:/hosts

If you want to change the mastership of a replica, you use the following cdscp command:

set directory directory to new epoch masternew_clearinghouse readonly old_clearinghouse

This command sets the old master directory to be a read-only replica. You would do this if you want to keep the old primary server on the network as a replica server.

If you want to eliminate the old master directory, use the exclude option:

set directory directory to new epoch masternew_clearinghouse exclude old_clearinghouse

For example, you may want to eliminate directories if you are removing the old master server from the network.

The following command changes the mastership of the directory /.:/hosts/darwin.explorers.com to the darwin_ch clearinghouse. The directory becomes readonly on the old master clearinghouse banks_ch:

C:\> dce_login cell_admin -dce-
C:\> cdscp
cdscp> set directory /.:/hosts/darwin.explorers.com to new epoch master /.:/
darwin_ch readonly /.:/banks_ch

This section describes how to apply basic CDS replica management tasks (Section 5.5.3 on page 71) to more complex replica management procedures.

5.5.4.1 Creating a Backup Server

If you want to create a backup server that provides a full backup of all CDS directories if the primary CDS server experiences data loss, you must determine the structure of the CDS namespace (Section 5.5.3.1 on page 71) and create replicas of all directories on your backup server (Section 5.5.3.2 on page 72).

You must make it standard operating procedure to keep the backup server current. Directories that exist on both master and read-only replicas are automatically synchronized on a periodic basis. However, if someone creates a new directory on the master, the new directory is not automatically replicated.

5.5.4.2 Creating a Backup Server for Failover

If you want to create a backup server that will simply allow clients to start up if the primary server is temporarily unavailable, at a minimum you must replicate the /.:/subsys/dce/sec directory, which stores the locations of security servers. For example:

dcecp> directory create /.:/subsys
dcecp> directory create /.:/subsys/dce
dcecp> directory create /.:/subsys/dce/sec
dcecp> directory synch /.:/subsys/dce/sec
dcecp> directory synch /.:/subsys/dce
dcecp> directory synch /.:/subsys
dcecp> directory synch /.:

The following procedure is a general overview. Details on each step follow the general overview.

1. Determine the structure of the CDS directory tree.

2. If the replica server clearinghouse does not contain a complete set of directory replicas, create new directory replicas.

   NOTE: If the primary server is unavailable, you will need to restore the CDS directories from backups (Section 5.8 on page 82).

3. Change mastership of the directory replicas.

4. Verify changes.

Use the procedure described in Section 5.5.3.1 on page 71.

To create new directory replicas:

Creating new directory replicas is described in Section 5.5.3.2 on page 72. The following is an example of the commands you would issue to create replicas on a replica server whose clearinghouse contains a copy of the root directory only. This example creates the replicas in the clearinghouse/.:/darwin_ch:

C:\> dce_login cell_admin -dce-
C:\> dcecp
dcecp> directory create /.:/hosts -replica -clearinghouse /.:/darwin_ch
dcecp> directory create /.:/hosts/banks.entegrity.com -replica 
-clearinghouse /.:/darwin_ch
dcecp> directory create /.:/hosts/darwin.entegrity.com -replica 
-clearinghouse /.:/darwin_ch
dcecp> directory create /.:/subsys -replica -clearinghouse /.:/darwin_ch
dcecp> directory create /.:/subsys/dce -replica -clearinghouse /.:/darwin_ch
dcecp> directory create /.:/subsys/dce/sec -replica -clearinghouse /.:/
darwin_ch
dcecp> directory create /.:/users -replica -clearinghouse /.:/darwin_ch
dcecp> directory create /.:/users/joseph -replica -clearinghouse /.:/
darwin_ch
dcecp> directory create /.:/users/charles -replica -clearinghouse /.:/
darwin_ch

If the primary server is available, synchronize the directories. Notice that you synchronize starting with the ends of the branches (the leaves) and working up to the root.

dcecp> directory synchronize /.:/users/joseph
dcecp> directory synchronize /.:/users/charles
dcecp> directory synchronize /.:/users
dcecp> directory synchronize /.:/subsys/dce/sec
dcecp> directory synchronize /.:/subsys/dce
dcecp> directory synchronize /.:/subsys
dcecp> directory synchronize /.:/hosts/darwin.entegrity.com
dcecp> directory synchronize /.:/hosts/banks.entegrity.com
dcecp> directory synchronize /.:/hosts
dcecp> directory synchronize /.:

If the old primary server is to be converted to a replica server, issue the dcecp directory modify command with the readonly option. In the following example, the clearinghouse for the old primary server is /.:/banks_ch.

dcecp> directory modify /.: -master /.:/darwin_ch -readonly /.:/banks_ch
dcecp> directory modify /.:/hosts -master /.:/darwin_ch 
-readonly /.:/banks_ch
dcecp> directory modify /.:/hosts/banks.entegrity.com -master /.:/darwin_ch 
-readonly /.:/banks_ch
dcecp> directory modify /.:/hosts/darwin.entegrity.com -master /.:/darwin_ch 
-readonly /.:/banks_ch
dcecp> directory modify /.:/subsys -master /.:/darwin_ch 
-readonly /.:/banks_ch
dcecp> directory modify /.:/subsys/dce -master /.:/darwin_ch 
-readonly /.:/banks_ch
dcecp> directory modify /.:/subsys/dce/sec -master /.:/darwin_ch 
-readonly /.:/banks_ch
dcecp> directory modify /.:/users -master /.:/darwin_ch 
-readonly /.:/banks_ch
dcecp> directory modify /.:/users/joseph -master /.:/darwin_ch 
-readonly /.:/banks_ch
dcecp> directory modify /.:/users/charles -master /.:/darwin_ch 
-readonly /.:/banks_ch

If the old primary server will no longer be in service, issue the above commands using the exclude option in place of the readonly option. For example:

dcecp> directory modify /.: -master /.:/darwin_ch -exclude /.:/banks_ch

NOTE: If you are removing the old primary server from service, you must remove all references to it from the cell as described in Section 5.7 on page 79.

To verify your changes:

To verify that mastership has changed, issue the dcecp command directory show on at least one directory. For example, the following command displays information on the root (/.:) directory. In the example command output, the arrows (<-----) point to the pertinent lines.

dcecp> directory show /.:
{RPC_ClassVersion {01 00}}
{CDS_CTS 2000-04-02-14:53:41.113000100/00-60-08-a1-4e-cf}
{CDS_UTS 2000-04-02-19:13:51.127000700/00-60-08-a1-4e-cf}
{CDS_ObjectUUID 00113e11-a675-1523-ba3f-006008a14ecf}
{CDS_Replicas
 {{CH_UUID 005a06e0-b994-1523-baa9-006008a14ecf}
  {CH_Name /.../longwood/darwin_ch}                          <-----
  {Replica_Type Master}                                      <-----
  {Tower {ncacn_ip_tcp 192.92.110.141}}
  {Tower {ncadg_ip_udp 192.92.110.141}}}
 {{CH_UUID 0004baf0-a72d-1523-9616-00802964ff95}
  {CH_Name /.../longwood/banks_ch}                           <-----
  {Replica_Type ReadOnly}                                    <-----
  {Tower {ncacn_ip_tcp 192.92.110.53}}
  {Tower {ncadg_ip_udp 192.92.110.53}}}}
{CDS_AllUpTo 2000-04-02-19:13:51.497000100/00-60-08-a1-4e-cf}
{CDS_Convergence medium}
{CDS_InCHName new_dir}
{CDS_DirectoryVersion 4.0}
{CDS_ReplicaState on}
{CDS_ReplicaType ReadOnly}
{CDS_LastSkulk 2000-04-02-19:13:51.497000100/00-60-08-a1-4e-cf}
{CDS_LastUpdate 2000-04-02-19:10:43.964000100/00-80-29-64-ff-95}
{CDS_Epoch 001360f0-e36f-1523-baa9-006008a14ecf}
{CDS_ReplicaVersion 4.0}

You use the PC-DCE Configuration Panel to specify whether the security server you are configuring is to be a primary server (master) or a replica server (slave). The first server you create for a cell must be the master, and then it is easy to configure additional slaves.

You use the DCE command line tools to promote a slave to a master or demote a master to a slave. You may need to do this if the master experiences a hardware failure or if you want to run the master on a faster machine.

The following sections describe how to perform these procedures.

5.6.1 Promoting a Slave to Master

This section describes how to promote a slave to a master. In this scenario, the current master is available and will be converted to a slave.

The following procedure is a general overview. Details on each step follow the general overview.

1. List the security servers to obtain the correct names.

2. Designate the new master and slave.

3. Verify that mastership has changed.

4. Verify that the new slave is correctly updating its copy of the registry.

Use the dcecp command registry catalog. For example:

C:\> dce_login cell_admin -dce-
C:\> dcecp
dcecp> registry catalog
/.../longwood/subsys/dce/sec/banks.explorers.com
/.../longwood/subsys/dce/sec/darwin.explorers.com

Use the dcecp command registry designate. The following example designates darwin.explorers.com, currently a slave, to become the master, and banks.explorers.com, currently the master, to become a slave:

dcecp> registry designate /.:/subsys/dce/sec/banks.explorers.com -slave
dcecp> registry designate /.:/subsys/dce/sec/darwin.explorers.com -master

Use the sec_admin command lrep -all to verify that the mastership has changed. In the following example command output, the arrows (<-----) point to the pertinent lines.

dcecp> sec_admin
Default replica:  /.../longwood/subsys/dce/sec/darwin.explorers.com
Default cell:     /.../longwood
sec_admin> lrep -all
Default replica:  /.../longwood/subsys/dce/sec/darwin.explorers.com
Default cell:     /.../longwood

subsys/dce/sec/darwin.explorers.com (master)
          Instance id: 002eff42-b985-1523-b204-006008a14ecf
          Addresses:               ncacn_ip_tcp:191.92.110.141[]
                                   ncadg_ip_udp:191.92.110.141[]
          State:                   in service - master               <----
          Last update received at: Thu Apr 02 14:45:31 2000
          Last update's seqno:     0.235

subsys/dce/sec/banks.explorers.com
          Instance id: 00881bc0-a718-1523-a4f9-00802964ff95
          Addresses:               ncacn_ip_tcp:191.92.110.53[]
                                   ncadg_ip_udp:191.92.110.53[]
          State:                   in service - slave                <----
          Last update received at: Thu Apr 02 14:45:31 2000
          Last update's seqno:     0.235
          Propagation state:       ready for updates
          Last update delivered:   Thu Apr 02 14:45:31 2000
          Last update's seqno:     0.235
          Number of outstanding updates: 0
          Last comm status:        Successful completion (dce / svc)

Change the registry by creating a new user, and then issue another lrep -all command to determine whether the seqno values have changed. In the following example command output, the arrows (<-----) point to the pertinent lines.

dcecp> user create wendy -group none -org none -password wendy -mypwd -dce-
dcecp> sec_admin
Default replica:  /.../longwood/subsys/dce/sec/darwin.explorers.com
Default cell:     /.../longwood
sec_admin> lrep -all
Default replica:  /.../longwood/subsys/dce/sec/darwin.explorers.com
Default cell:     /.../longwood

subsys/dce/sec/darwin.explorers.com (master)
          Instance id: 002eff42-b985-1523-b204-006008a14ecf
          Addresses:               ncacn_ip_tcp:192.92.110.141[]
                                   ncadg_ip_udp:192.92.110.141[]
          State:                   in service - master
          Last update received at: Thu Apr 02 15:07:48 2000
          Last update's seqno:     0.262                             <----

subsys/dce/sec/banks.explorers.com
          Instance id: 00881bc0-a718-1523-a4f9-00802964ff95
          Addresses:               ncacn_ip_tcp:192.92.110.53[]
                                   ncadg_ip_udp:192.92.110.53[]
          State:                   in service - slave
          Last update received at: Thu Apr 02 15:07:48 2000
          Last update's seqno:     0.262                             <----
          Propagation state:       ready for updates
          Last update delivered:   Thu Apr 02 15:07:48 2000
          Last update's seqno:     0.262
          Number of outstanding updates: 0
          Last comm status:        Successful completion (dce / svc)

If the slave's last update's seqno is lower than the master's last update's seqno, then the slave is not updating its copy of the registry. This typically occurs when the slave was the original master and is named /.:/subsys/dce/sec/master. This is a known problem in DCE. If this occurs, you will have to completely remove the slave from the cell and reconfigure it, as described in Section 5.7.

5.7 Removing and Reconfiguring a PC-DCE Server

This procedure describes how to remove and reconfigure a PC-DCE server running both Security and CDS servers.

5.7.1 Removing Cell References to the Server

If you are planning to reconfigure a server, but not reconfigure the cell, you must remove cell references to the server prior to reconfiguring.

If a machine is no longer serving as a replica due either to reconfiguration or system failure, it is necessary to remove references to the replica from the cell registry. Not doing this could cause time delays should the master go down and will cause failure if you try to configure the machine as a replica in the future.

The following procedure is a general overview. Details on each step follow the general overview.

1. Remove the old replica's machine and cds-server principals.

2. Remove the old replica from the /.:/sec rpcgroup.

3. Delete the old replica.

4. Exclude all CDS directories from the old CDS server's clearinghouse.

5. Delete the old clearinghouse object.

6. Delete the old master hosts directory and its remaining contents.

7. Remove the DTS server, if present.

Use the dcecp principal delete command. For example:

C:\> dce_login cell_admin -dce-
dcecp> principal delete hosts/banks.entegrity.com/self
dcecp> principal delete hosts/banks.entegrity.com/cds-server

Use the dcecp command rcpgroup remove. For example:

dcecp> rpcgroup remove /.:/sec -member /.:/subsys/dce/sec/master

Use the dcecp command registry delete command with the -force option to remove the replica. The following example removes a reference to an old master:

dcecp> registry delete subsys/dce/sec/master -force
dcecp>

Use the dcecp command directory modify with the exclude option. For example:

C:\>dcecp
dcecp> directory modify /.: -master /.:/darwin_ch -exclude /.:/banks_ch
dcecp> directory modify /.:/hosts -master /.:/darwin_ch 
-exclude /.:/banks_ch
dcecp> directory modify /.:/hosts/darwin.entegrity.com -master 
/.:/darwin_ch -exclude /.:/banks_ch
dcecp> directory modify /.:/hosts/banks.entegrity.com -master 
/.:/darwin_ch exclude /.:/banks_ch
dcecp> directory modify /.:/subsys -master /.:/darwin_ch 
-exclude /.:/banks_ch
dcecp> directory modify /.:/subsys/dce -master /.:/darwin_ch 
-exclude /.:/banks_ch
dcecp> directory modify /.:/subsys/dce/sec -master /.:/darwin_ch 
-exclude /.:/banks_ch

You may see a message regarding a replica that does not exist at the clearinghouse you are excluding. This is harmless because if the replica is not there you do not have to exclude it.

To delete the old clearinghouse object:

Use the dcecp command obj delete. For example:

dcecp> obj delete /.:/banks_ch

Use the dcecp command dir delete. For example:

dcecp> dir delete /.:/hosts/banks.entegrity.com -tree

1. Use the dcecp command rpcprofile show to obtain the interface UUID of the dts-entity:

   dcecp> rpcprofile show /.:/lan-profile
   {{019ee420-682d-11c9-a607-08002b0dea7a 1.0} /.../longwood/hosts/
   banks.entegrity.com/dts-entity 0 {Time Server entry}}
   

2. Use the dcecp command rpcprofile remove to remove the dts-entity:

   dcecp> rpcprofile remove /.:/lan-profile 
   -member /.:/hosts/banks.entegrity.com/dts-entity 
   -interface {019ee420-682d-11c9-a607-08002b0dea7a 1.0}
   

3. If you are running a global time server, you must remove an additional entry. To find the UUID of the global dts-entity, use the following command. In this example, the UUID is in the last entry.

   dcecp> rpcprofile show /.:/cell-profile
   {{d46113d0-a848-11cb-b863-08001e046aa5 2.0} /.../longwood/sec 0 rs_bind}
   {{0d7c1e50-113a-11ca-b71f-08001e01dc6c 1.0} /.../longwood/sec-v1 0 
   secidmap}
   {{8f73de50-768c-11ca-bffc-08001e039431 1.0} /.../longwood/sec 0 krb5rpc}
   {{b1e338f8-9533-11c9-a34a-08001e019c1e 1.1} /.../longwood/sec 0 rpriv}
   {{b1e338f8-9533-11c9-a34a-08001e019c1e 1.0} /.../longwood/sec 0 rpriv}
   {{6f264242-b9f8-11c9-ad31-08002b0dc035 1.0} /.../longwood/lan-profile 0 
   LAN}
   {{4d37f2dd-ed43-0000-02c0-37cf2e000001 4.0} /.../longwood/fs 0 fs}
   {{eb814e2a-0099-11ca-8678-02608c2ea96e 4.0} /.../longwood/subsys/dce/dfs/
   bak 0 bak}
   {{17579714-82c9-11c9-8a59-08002b0dc035 1.0} /.../longwood/hosts/
   banks.entegrity.com/dts-entity 0 {Global Time Server}}
   

4. To remove the global dts-entity, use the dcecp command rpcprofile remove:

   dcecp> rpcprofile remove /.:/cell-profile 
   -member /.:/hosts/banks.entegrity.com/dts-entity 
   -interface {17579714-82c9-11c9-8a59-08002b0dc035 1.0}
   

If you are reconfiguring the server, perform the following additional procedure. Details on each step follow the general procedure.

1. Delete PC-DCE files that contain references to the server.

2. Clear the endpoint mapper.

3. Reconfigure the old master as a replica.

4. Verify that the new replica is updating its registry.

On the old master, delete the following files:

• PCDCE32\opt\dcelocal\dce_cf.db
  

• PCDCE32\opt\dcelocal\etc\security\pe_site

Reboot the machine to clear the Microsoft endpoint mapper.

To reconfigure an old master as a replica:

Use the PC-DCE Configuration Panel, accessed through the PC-DCE Service Panel (Configure button), to reconfigure the old master:

• On the Custom tab of the PC-DCE Configuration Panel, select replica for each server.

• Change the master server name to the name of the new master server.

If the configuration hangs on Configuring clearinghouse, perform a dce_login as cell_admin from the command line and wait a bit longer — this should fix the problem.

To verify the old master (new replica) is updating its registry:

Create a new user and then use the sec_admin lrep -all command to verify that the sequence numbers match. For details, refer to Section 5.6.1 on page 77.

5.8 Backing Up and Restoring a PC-DCE Server

In addition to having replicas in the cell for automatic failover, you should also back up your PC-DCE data. This section describes how to back up and restore PC-DCE server configuration and database data. These procedures apply to both the CDS and Security Service servers.

5.8.1 Backing Up (With Servers Stopped)

1. Stop PC-DCE on the system to be backed up:
   • Open the Windows control panel and open the PC-DCE Service Panel application.

   • Click the Stop DCE button.

2. Back up the registry key HKEY_LOCAL_MACHINE/Software/Entegrity/DCE/Configuration:
   • Start the registry editor (regedt32.exe).

   • Select the HKEY_LOCAL_MACHINE window, navigate to the Entegrity DCE configuration key, and select it by clicking on it.

   • Use the Registry > Save Key... command to make a file backup of the key.

3. Back up the following directories:
   • install_directory\opt (for example, PCDCE32\opt)
     
     • install_directory\krb5 (for example, PCDCE32\krb5)

4. Restart PC-DCE from the PC-DCE Service Panel.

1. Put the master security server into maintenance mode:

   C:\> dce_login cell_admin -dce-
   C:\> sec_admin
   default replica:  /.../longwood
   Default cell:     /.../longwood
   sec_admin> state -m
   

   NOTE: The state command only works on the master. If sec_admin is not already bound to the master, it attempts to do so when you issue this command.

2. Disassociate the clearinghouse from the master CDS server. In the following example, darwin is the master:

   C:\> dcecp
   dcecp> clearinghouse disable /.:/darwin_ch
   

3. Back up the registry key HKEY_LOCAL_MACHINE/Software/Entegrity/DCE/Configuration:
   • Start the registry editor (regedt32.exe).

   • Select the HKEY_LOCAL_MACHINE window, navigate to the Entegrity DCE configuration key, and select it by clicking on it.

   • Use the Registry > Save Key... command to make a file backup of the key.

4. Back up the following directories:
   • install_directory\opt (for example, PCDCE32\opt)
     
     • install_directory\krb5 (for example, PCDCE32\krb5)

5. Put the master security server into service mode:

   sec_admin> state -s
   

6. Relocate the clearinghouse:

   dcecp> clearinghouse create /.:/darwin_ch
   

1. Stop PC-DCE on the system to be restored:
   • Open the Windows control panel and open the PC-DCE Service Panel application.

   • Click the Stop DCE button.

2. Restore the registry key HKEY_LOCAL_MACHINE/Software/Entegrity/DCE/Configuration:
   • Start the registry editor (regedt32.exe).

   • Select the HKEY_LOCAL_MACHINE window, navigate to the Entegrity DCE configuration key, and select it by clicking on it.

   • Use the Registry > Restore... command to select the backup file and apply it to the registry.

3. Restore the following directories from the backups:
   • install_directory\opt
     
     • install_directory\krb5

4. Restart PC-DCE from the PC-DCE Service Panel.

If you are upgrading from PC-DCE 3.0 or any version before 2.2.1HF1, the master security server may require an upgrade providing an improved method for storing passwords in the security registry's account database.

If a PC-DCE security server is the master security server in your cell, OR if a PC-DCE replica security server has ever been promoted to be the master (even temporarily) AND the account registry database was changed while a PC-DCE security server was the master server, follow these steps:

1. From the PC-DCE Service Panel on the security server machine, click Stop DCE.

2. If there are any replicas configured in the cell, stop them by clicking Stop DCE on the PC-DCE Service Panel from the replica machines.

3. Back up the files located in: install_directory\opt\dcelocal\var\security\rgy_data\

4. Back up the the file: install_directory\opt\dcelocal\var\security\.mkey.

5. From a command line, enter the following:

   C:\> sec_salvage_db.exe -print
   

   C:\> 
   

6. From the command line, enter the following:

   C:\> sec_salvage_db.exe -account
   

   This upgrades the passwords in the account registry database on the PC-DCE master security server. The machine responds:

   Will overwrite data at /opt/dcelocal/var/security/rgy_data/, do you wish to continue (y[es]) or abort sec_salvage_db.exe (n[o])?

7. Choose yes.

8. From the PC-DCE Service Panel on the master security server machine, click Start DCE to bring up the master security server.

9. From the PC-DCE Service Panel on the replica security server machine(s), click Start DCE to restart the replicas if any exist in the cell.

10. Login to DCE as cell_admin.

11. From a command line, run dcecp and perform a "registry sync" for each replica in the cell.

    C:\> dcecp
    

    dcecp> registry sync /.:/subsys/dce/sec/hostname
    

This upgrades the replica's account databases.

5.9 Using Locksmith Mode to Repair Registry Damage

If the security registry is damaged by an intruder or other agent, and you are unable to log in as a cell administrator, you may be able to repair the damage by putting the security server into locksmith mode. Locksmith mode allows a special principal, the locksmith principal, to log in with special access privileges. As the locksmith principal, you can repair registry damage.

When you bring up a security server in locksmith mode, secd automatically creates a locksmith account or, if the locksmith account exists, it lets you supply a new password for that account.

5.9.1 Automatic Changes to the Locksmith Account

If the locksmith account exists when you start the security server in locksmith mode, the security server checks certain account and registry policy information and makes the changes shown in Table 5-1 and Table 5-2. These changes ensure that you will be able to log into the locksmith account even if the account or registry policy was tampered with.

Table 5-1: Locksmith Account Changes Made by the Security Server

If the security server finds the...	It changes the....
Password-Valid Flag is set to no	Password-Valid Flag to yes
Account Expiration Date is set to less than the current time plus 1 hour	Account Expiration Date to the current time plus 1 hour
Client Flag is set to no	Client Flag to yes
Account-Valid Flag is set to no	Account-Valid Flag to yes
Good Since Date is set to greater than the current time	Good Since Date to the current time
Password Expiration Date is set to less than the current time plus 1 hour	Password Expiration Date to the current time plus 1 hour

Table 5-2: Registry Policy Changes Made by the Security Server

If the security server finds the...	It changes the....
Account Lifespan is set to less than the difference between the locksmith account creation date and the current time plus 1 hour	Account Lifespan to the current time plus 1 hour minus the locksmith account creation date
Password Expiration Date is set to greater than the time the password was last changed but less than the current time plus 1 hour	Password Expiration Date to the current time plus 1 hour

5.9.2 Starting the Security Server in Locksmith Mode

You can start only the master security server in locksmith mode. You start the security server locally, and from the command line rather than the PC-DCE Service Panel. You must shut down PC-DCE before starting the security server from the command line.

Use the following form of the secd command to start a security server in locksmith mode:

secd [-locksm[ith] pname [-lockpw]]

where:

-locksm[ith] - Starts a security server in locksmith mode.

pname - Specifies the name of the locksmith principal. If no registry account exists for this principal, secd creates one.

-lockpw - Prompts for a new locksmith password. This option allows you to specify a new password for the locksmith account when the old one is unknown.

To start the master security server in locksmith mode:

1. From the PC-DCE Service Panel, shut down PC-DCE on the master security server machine.

2. Start the security server in locksmith mode. The following example shows the security server started with the locksmith account that was created for the principal named houdini:

   C:\> secd -locksmith houdini
   

   If the locksmith account does not exist, it prompts you to create it. Respond y and supply passwords to create the new account:

   Account for houdini doesn't exist. Should this be created ? [y/n]? <y>y
   Enter password for locksmith account:
   Reenter password to verify:
   

   NOTE: If the account exists but you have lost its password, use the -lockpw option to cause secd to prompt you for a new locksmith password and replace the existing password with the one you enter.

   The security server (secd) remains running in foreground mode. Leave this command prompt window open.

3. Open another command prompt window and log into DCE as the locksmith:

   C:\> dce_login houdini bagoftricks
   

4. Repair the registry damage.

5. Stop the security server:

   C:\> sec_admin
   Default replica: /.../longwood
   Default cell:    /.../longwood
   sec_admin> stop
   sec_admin> exit
   bye.
   

6. Destroy the locksmith credentials:

   C:\> kdestroy
   

7. Close the command prompt windows.

8. Restart PC-DCE from the PC-DCE Service Panel.

If you change the IP address of a master or slave security replica, you must update the pe_site files on all security server systems.

The pe_site file is located in install_directory\opt\dcelocal\etc\security file on that host before restarting PC-DCE. This file lists the IP address of each security replica in the cell. There are two entries for each server.

After you change the IP address of the machine, open the pe_site file for each replica in the cell and update the two entries for the changed replica.

For example, if your cell contains two servers named banks and darwin, and darwin is a slave, the pe_site file on darwin might look like this:

/.../longwood8 00532910-5db6-153f-bf58-00802964ff95@ncadg_ip_udp:
194.90.110.141 subsys/dce/sec/darwin.myco.com
/.../longwood8 00532910-5db6-153f-bf58-00802964ff95@ncacn_ip_tcp:
194.90.110.141 subsys/dce/sec/darwin.myco.com
/.../longwood8 00532910-5db6-153f-bf58-00802964ff95@ncadg_ip_udp:
194.90.110.53 subsys/dce/sec/master
/.../longwood8 00532910-5db6-153f-bf58-00802964ff95@ncacn_ip_tcp:
194.90.110.53 subsys/dce/sec/master

Suppose you change darwin's IP address to 194.90.110.80. You would change the pe_site file as follows:

/.../longwood8 00532910-5db6-153f-bf58-00802964ff95@ncadg_ip_udp:
194.90.110.80 subsys/dce/sec/darwin.myco.com
/.../longwood8 00532910-5db6-153f-bf58-00802964ff95@ncacn_ip_tcp:
194.90.110.80 subsys/dce/sec/darwin.myco.com
/.../longwood8 00532910-5db6-153f-bf58-00802964ff95@ncadg_ip_udp:
194.90.110.53 subsys/dce/sec/master
/.../longwood8 00532910-5db6-153f-bf58-00802964ff95@ncacn_ip_tcp:
194.90.110.53 subsys/dce/sec/master

The Name Service Interface Gateway (nsid), allows remote systems that only have RPC services to use the DCE CDS name service. The nsid runs on one or more DCE systems in the cell and acts on behalf of the remote system to execute the RPC name service API calls. Through a hidden level of indirection, the nsid allows the PC to appear as if it is directly involved in the broader cell namespace.

5.11.1 Configuring the nsid

To configure nsid, your system must also be a CDS client or a CDS server. For procedural information about configuring, starting, or stopping nsid, see the online help system that accompanies the PC-DCE Configuration Panel.

During configuration, the appropriate nsid settings are defined in the Windows registry. Once configured, the nsid is added to your DCE configuration and is started along with all other DCE components.

5.11.2 Security Considerations

RPC communication between the client system (using the services of the nsid) and the system running the nsid uses unauthenticated Microsoft RPC. The nsid runs under the fixed principal, pc-user. Communication between the system running the nsid and the DCE Cell Directory Service is authenticated under this principal.

In order for the nsid to access entries in the DCE namespace on behalf of the client system, you must modify the access control lists (ACLs) on the namespace entries to authorize access by the nsid principal. However, if the namespace entry .:/subsys/DEC/pc is used by the client system, you do not need to modify the ACLs.

The ACLs are preset with authorized access for the nsid principal pc-user. For example, a MSRPC server can export an interface named "foo" with the cds entry name ".:/subsys/DEC/pc/foo", without modifying the ACLs. A MSRPC client can then import a binding to that interface using the same cds entry name.

For Windows NT and Windows 2000, nsid does use DCE security. A security Principle and Account must be created on the CDS Server with rgy_edit (or rgyedit for a Windows NT or Windows 2000 Server):

hosts/your_PC_name/pc-user

Then, on the client side, you must create a security key with rgyedit:

ktadd -p hosts/<your PC name/pc-user -pw <principle password>

5.11.3 The Microsoft Locator and the nsid

The Locator is Microsoft's simple, flat-namespace directory service. The Locator exports the Microsoft version of the RPC name service interface (NSI) and makes an association between entry-name strings and string bindings.

The Locator exports the identical interface as the nsid. The caller of the Microsoft NSI makes a remote procedure call to either the Locator or the nsid based entirely on the string-binding components defined at the time in the Registry.

5.11.4 The Microsoft Registry and the nsid

The Registry defines the name server that will be queried when any of the rpc_ns_* procedures is called. The name server can be either the Microsoft Locator or the nsid; after installation of Windows NT or Windows 2000, the default setting is the Locator. The following section describes how to modify your Regisry to employ a remote nsid.

5.11.5 Modifying the Windows NT Registry for Using the nsid

On Windows NT and Windows 2000, the Registry is an integral component of the operating system. There are two methods for modifying the Registry to define settings for nsid.

• The Network applet in the Control Panel
  
• The Registry Editor
  

The RPC Name Service Provider is usually changed through the Network applet in the Control Panel.

To perform this task, do the following:

1. Start the Network applet from the Windows Control Panel.

2. Under the Services tab, select RPC Configuration then click Properties.

3. Under Name Service Provider, select DCE Cell Directory Service.

4. Supply the IP address (or the DECnet address) in the Network Address box.

5. Click OK to change the configuration, then click close to exit the applet.

The machine must be rebooted for the changes to take effect.

5.11.5.2 To Modify the Registry by Using the Registry Editor:

Another way to modify the Registry is to use the registry editor (regedt32.exe). You must use this method to add the default name_service entry.

To set up the Registry on Windows NT or Windows 2000 to use the nsid, do the following:

1. From a command window, enter regedt32 to display the Registry Editor window.

2. Place the focus in the HKEY_LOCAL_MACHINE subwindow by clicking it.

3. Double-click successively on SOFTWARE, Microsoft, Rpc, and NameService. The right half of the HKEY_LOCAL_MACHINE subwindow will now list the parameters for the RPC Name Service Provider.

4. Change the settings as follows:

   NOTE: You change the values by double-clicking them; a window appears that allows you to change the value.

   Setting	New Value
   DefaultSyntax	Either 0 or 3
   Endpoint	No value
   NetworkAddress	Network address of the system where the nsid will be running
   Protocol	One of the protocol sequences that the Windows NT system will use to communicate with the nsid (ncacn_ip_tcp or ncadg_ip_udp
   ServerNetworkAddress	Network address of the system where the nsid will be running

After the task is completed, the right half of the HKEY_LOCAL_MACHINE subwindow displays parameter information similar to the following:

DefaultSyntax:REG_SZ:3
Endpoint:REG_SZ:
NetworkAddress:REG_SZ:16.64.0.79
Protocol:REG_SZ:ncacn_ip_tcp
ServerNetworkAddress:REG_SZ:16.64.0.79

To finish setting up the Registry, pull down the Registry item on the menu bar and choose Exit.

[Previous] [Next] [Contents] [Index]

To make comments or ask for help, contact support@entegrity.com.

Portions of this document were derived from materials provided by Compaq Computer Corporation. Copyright © 1998-2003 Compaq Computer Corporation.

Copyright © 2003 Entegrity Solutions Corporation & its subsidiaries.

All rights reserved.