7 — Managing Intercell Naming

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

7.1 Overview of Intercell Naming

To find names outside of the local cell, CDS clerks must have a way to locate directory servers in other cells. The Global Directory Agent (GDA) enables intercell communications by serving as a connection to other cells through the global naming environment. This chapter describes how the GDA works and how to manage it. The chapter also describes how to define the local cell in either of the global naming environments (DNS, X.500, or LDAP), where a step is necessary to make the local cell accessible to other cells.

NOTE: If the cell name is an X.500 formal name, then either GDS or an LDAP server may be used as the global name server.

7.2 How the Global Directory Agent Works

The GDA is an intermediary between CDS clerks in the local cell and CDS servers in other cells. A CDS clerk treats the GDA like any other name server, passing it name lookup requests. However, the GDA provides the clerk with only one specific service; it looks up a cell name in the X.500, LDAP, or DNS namespace and returns the results to the clerk. The clerk then uses those results to contact a CDS server in the foreign cell.

A GDA must exist inside any cell that wants to communicate with other cells. It can be on the same system as a CDS server, or it can exist independently on another system. You can configure more than one GDA in a cell for increased availability and reliability. Like a CDS server, a GDA is a principal and must authenticate itself to clerks.

CDS finds a GDA by reading address information that is stored in the CDS_GDAPointers attribute associated with the cell root directory. Whenever a GDA process starts, it creates a new entry or updates an existing entry in the CDS_GDAPointers attribute. The entry contains the address of the host on which the GDA is currently running. If multiple GDAs exist in a cell, they each create and maintain their own address information in the CDS_GDAPointers attribute.

When a CDS server receives a request for a name that is not in the local cell, the server examines the CDS_GDAPointers attribute of the cell root directory to find the location of one or more GDAs. The next figure shows how a CDS clerk and CDS server interact to find a GDA.

Figure 7-1: How the CDS Clerk Finds a GDA

The following steps summarize the GDA search that is illustrated in the preceding figure:

1. On Node A, a client application passes a global name, beginning with the/... prefix, to the CDS clerk.

2. The clerk passes the lookup request to a CDS server that it knows about on Node B.

3. The server's clearinghouse contains a replica of the cell root directory, so the server reads the CDS_GDAPointers attribute and returns the address of Node C, where a GDA is running.

4. The clerk passes the lookup request to the GDA.

The next figure shows how CDS and a GDA interact to find a name in a foreign cell that is defined in DNS. Suppose the name is /.../widget.com/printsrv1, which represents a print server in the foreign cell.

Figure 7-2: How the GDA Helps CDS Finds a Name

The following steps summarize the name search that is illustrated in the preceding figure:

1. The client application passes the name /.../widget.com/printsrv1 to the CDS clerk.

2. The clerk passes a lookup request to a CDS server that it knows about on Node B.

3. The server's clearinghouse contains a replica of the cell root directory, so the server looks up the CDS_GDAPointers attribute and returns the address of Node C, where a GDA is running.

4. The clerk passes the lookup request to the GDA.

5. The GDA recognizes that the name is a DNS-style name, so it assumes that the second component is a cell name that is defined in DNS. It passes that portion of the name (widget.com) to DNS. For simplicity, the figure shows only one DNS server; more than one DNS server can actually be involved in resolving a global cell name.

NOTE: Although this example concerns the lookup of a DNS-style name, the sequence and execution of operations is nearly identical for an X.500 name or a hierarchical cell name. If the GDA recognizes that a name is an X.500-style name, it passes the name to either an LDAP client (via LDAP APIs) or a GDS client (via XDS/XOM APIs) rather than to a DNS server. The LDAP client or GDS client then communicates with the appropriate server to obtain the cell bindings (the same information as would be obtained from a DNS server). If the GDA recognizes that a name is a hierarchical cell name, it passes it to the CDS server of the topmost cell in the hierarchy, which is registered in one of the global namespaces. The CDS server in this cell walks down the cell hierarchy to locate the name.

1. DNS looks up and returns to the GDA information that is associated with the widget.com cell entry. The information includes the addresses of servers that maintain replicas of the root directory of the /.../widget.com cell namespace.

2. The GDA passes the information about the foreign cell to the clerk.

3. The clerk contacts the CDS server on Node E in the foreign cell, passing it a lookup request.

4. The Node E server's clearinghouse contains a replica of the root directory, so the server looks up the entry for printsrv1 in the root and passes the requested information to the clerk on Node A. For simplicity, this example shows the clerk contacting only one server in the foreign cell. While resolving a full name, the clerk may actually receive referrals to several servers in the foreign cell.

5. The clerk passes the information to the client application that requested it.

Note that both of the previous examples represent initial lookups. The CDS clerk caches the locations of GDAs once it discovers them. The clerk also caches the addresses of servers in foreign cells that it learns about, enabling it to contact the foreign servers directly on subsequent requests for names in the same cell.

Note also that a GDA knows its own cell name and can therefore avoid contacting a global directory service to look up names in its own cell. Furthermore, the GDA can recognize whether a cell name conforms to the X.500 or DNS naming syntax, and it uses that knowledge to route a lookup request to the appropriate global directory service. If the cell name conforms to the X.500 naming syntax, the GDA will first send the request to the LDAP client and then to the GDS client if it is not resolved by the LDAP client/server.

7.3 Managing the Global Directory Agent

Use the DCE configuration program to configure the GDA; the GDA requires little management once it is configured. (See the OSF DCE Administration Guide—Introduction for details on configuring the GDA.)

The GDA is typically started and stopped automatically by scripts that execute as part of normal system startup and shutdown procedures. Sometimes, however, you may want to use commands to stop and restart a GDA. Once you have configured GDA with the DCE configuration program, you can use these steps to start and stop GDA.

The GDA runs as a process called gdad. To start the gdad process, follow these steps:

1. Make sure that a CDS server is already running somewhere within the cell.

2. Log into the system as superuser (root).

3. Enter the following command to see if the dced process is already running:

   # ps
   

   If the dced process appears on the list of active processes, proceed to step 5. If the dced process does not appear on the list of active processes, enter the following command to start the process:

   # dced

4. Enter the following command to start the cdsadv process:

   # cdsadv

5. Enter the following command to start the gdad process:

   # gdad

NOTE: See the OSF DCE Administration Guide—Introduction for the parameters required if gdad is to use LDAP to obtain cell bindings.

To stop the GDA, enter the following command, where pid is the process identifier of the gdad process:

# kill pid

7.4 Enabling Other Cells to Find Your Cell

The GDA is the mechanism that allows CDS clerks in your local cell to find other cells. To make your cell accessible to others, you must create an entry for it in one of the currently supported global naming environments. Before you do this, obtain a unique cell name from the appropriate naming authority. (See the OSF DCE Administration Guide—Introduction for details.)

After you configure a cell, name it, and initialize the cell namespace, you can use the dcecp directory show command to obtain the data you need to create or modify the cell entry in an X.500, LDAP, or DNS server. You can use the ldap_ addcell command to add the appropriate information for the cell to an LDAP server. The data in a cell entry is what the GDA passes to CDS after looking up a cell name. CDS, in turn, uses the information to contact servers in the cell. The following subsections describe how to define and maintain a cell entry in an X.500 server (GDS), an LDAP server, or DNS server. These sections assume a basic familiarity with X.500 and DNS; for details, see the appropriate documentation for each global name service.

You can also define and maintain a cell entry in the CDS namespace of another cell. This type of definition exists in a hierarchical cell configuration.

7.4.1 Defining a Cell in the Domain Name System

Names in DNS are associated with one or more data structures called resource records. The resource records are stored in a data file whose name and location are implementation specific. To create a cell entry, you must edit the data file and create two resource records for each CDS server that maintains a replica of the cell namespace root.

The first resource record, whose type can be AFSDB or MX, contains the host name of the system where the CDS server resides. You can use MX as an alternative to using AFSDB. The second record, of type TXT, contains the following information about the replica of the root directory that the server maintains:

• The UUID of the cell namespace, in hexadecimal notation
  
• The type of the replica (master or read-only)
  
• The global CDS name of the clearinghouse where the replica resides
  
• The UUID of the clearinghouse, in hexadecimal notation
  
• The DNS name of the host where the clearinghouse resides
  

The following example shows a set of AFSDB resource records for a cell that is named cs.tech.edu, in which two replicas of the root directory exist. Note that only the first resource record contains the cell name; the second, third, and fourth records are assumed to be associated with the same cell because they do not contain a cell name. The TTL heading stands for time-to-live, which is a value, in seconds, after which the data is no longer considered valid in a DNS cache. (The value shown specifies a default value of 1 week.) The IN class indicates that the protocol is Internet, and the subtype of 2 indicates that a name server exists on the host named in the record.

;First Replica: 
;Name            TTL       Class     Type     Subtype   Host
cs.tech.edu      604800    IN        AFSDB     2        fox.cs.tech.edu 
;Name            TTL       Class     Type     Rdata
                 604800    IN        TXT      (1        ;version
                 fd3328c4-2a4b-11ca-af85-09002b1c89bb   ;ns uuid
                 Master                                 ;Replica1 type
                 /.../cs.tech.edu/cs1_ch                ;ch name
                 fd3328c5-2a4b-11ca-af85-09002b1c89bb   ;ch uuid
                 fox.cs.tech.edu)                       ;host
;Second Replica:
                  604800    IN        AFSDB     2        rox.cs.tech.edu
                 604800    IN        TXT      (1        ;version
                 fd3328c4-2a4b-11ca-af85-09002b1c89bb   ;ns uuid
                 Read-only                              ;Replica2 type
                 /.../cs.tech.edu/cs2_ch                ;ch name
                 fd3429c4-2a4b-11ca-af87-09002b1c89bb   ;ch uuid
                 rox.cs.tech.edu) 
;host

You can use MX as an alternative to using AFSDB. The following example shows a set of MX resource records for the same cell, cs.tech.edu, in which two replicas of the root directory exist.

;First Replica: 
;Name            TTL       Class     Type    Preference   Exchange
cs.tech.edu.     604800    IN        MX      1            fox.cs.tech.edu.
;Name            TTL       Class     Type    Rdata
                 604800    IN        TXT     (1           ;version
                 fd3328c4-2a4b-11ca-af85-09002b1c89bb     ;ns uuid
                 Master                                   ;Replica1 type
                 /.../cs.tech.edu/cs1_ch                  ;ch name
                 fd3328c5-2a4b-11ca-af85-09002b1c89bb     ;ch uuid
                 fox.cs.tech.edu)                         ;host
;Second Replica:
                 604800    IN        MX      2
rox.cs.tech.edu.
                 604800    IN        TXT     (1           ;version
                 fd3328c4-2a4b-11ca-af85-09002b1c89bb     ;ns uuid
                 Read-only                                ;Replica2 type
                 /.../cs.tech.edu/cs2_ch                  ;ch name
                 fd3429c4-2a4b-11ca-af87-09002b1c89bb     ;ch uuid
                 rox.cs.tech.edu) 
;host

After you configure a cell, you can use the dcecp directory show command to display the information that is required to construct resource records like those shown in the previous example. The following is an example directory show command that displays output for a cell named /.../cs.tech.edu.

dcecp> directory show /.../cs.tech.edu

To create a new resource record in the DNS namespace, use the information from the directory show command and place the properly formatted data into the DNS data file.

7.4.2 Defining a Cell in the Global Directory Service

In GDS, cell information is contained in two attributes: CDS-Cell and CDS-Replica. You can cause an existing GDS name to become a cell entry by adding these two attributes to the name. If the name you want to use for the cell does not yet exist, you must create it and then add the attributes. The GDS administration program uses numbered screens called masks to accept user input. Use the object administration masks to create a cell entry. (See the OSF DCE GDS Administration Guide and Reference for details.)

After you configure a cell, you can use the dcecp directory show command to obtain the data that you need to supply when you are creating the CDS-Cell and CDS-Replica attributes. The following is an example directory show command and the resulting GDS-formatted output for a cell that is named /.../C=US/O=ABC/OU=Sales:

dcecp> directory show /.../C=US/O=ABC/OU=Sales
{RPC_ClassVersion {01 00}} 
{CDS_CTS 1996-04-18-20:11:02.385764100/08-00-09-85-01-22}
{CDS_UTS 1996-08-01-18:01:37.408282100/08-00-09-85-01-22}
{CDS_ObjectUUID 68f0755c-9956-11cf-9da3-080009850122}
{CDSReplicas
  {{CH_UUID 59eb61fc-9956-11cf-9da3-080009850122}
   {CH_Name /.../c=us/o=abc/ou=sales/dcegecko_ch}
   {Replica_Type Master}
   {Tower {ncadg_ip_udp 15.22.50.148}}
   {Tower {ncacn_ip_tcp 15.22.50.148}}}}
{CDS_AllUpTo 1996-08-01-14:39:36.404042100/08-00-09-85-01-22} 
{CDS_Convergence medium}
{CDS_ParentPointer
  {{Parent_UUID 5a824f54-9956-11cf-9da3-080009850122}
   {Timeout
    {expiration 1996-08-02-14:01:36.251}
    {extension +1-00:00:00.000I0.000}}
   {myname /.../c=us/o=abc/subsys}}}
{CDS_DirectoryVersion 3.0} 
{CDSReplicaState on} 
{CDS_ReplicaType Master} 
{CDS_LastSkulk 1996-08-01-14:39:36.404042100/08-00-09-85-01-22} 
{CDS_LastUpdate 1996-08-01-18:01:37.408282100/08-00-09-85-01-22} 
{CDS_Epoch 68fdf042-9956-11cf-9da3-080009850122}
{CDS_ReplicaVersion 3.0} 
dcecp>

To create a new resource record in GDS, use the information from the directory show command to fill in the fields of Mask 21 (CDS-Cell) and Mask 22 (CDS-Replica) in the GDS administration program.

7.4.3 Defining a Cell in an LDAP Server

The ldap_addcell utility obtains and dynamically adds DCE cell information to an LDAP server. The ldap_addcell command must be run with root authority. The ldap_addcell command can:

• Create a new directory object with cell bindings.
  
• Modify an existing directory object to add the cell bindings.
  
• Change the values of the cell bindings in a directory object that already exists.
  
• Delete the cell bindings from a directory object that already exists.
  

The cell bindings that are added or retrieved from a directory object have the same format used for an X.500 server (GDS) and are stored in 2 attributes:

• CDSCELL
  
• CDSREPLICAS
  

Authentication information such as userid and password are part of the ldap_addcell utility invocation, because it writes to the directory service. The DCE cell information stored in the directory service is the same whether it was written using the X.500 registration utility or the ldap_addcell registration utility.

The ldap_addcell command has the following syntax:

ldap_addcell -h ldap_server -a authentication_DN -p password [-o object_class,object_class...]|[-d]

where:
-h ldap_server	The name of the LDAP server targeted to hold the cell binding.
-a authentication_DN	The distinguished name (DN) specified in LDAP name syntax that will be authenticated and used to add cell binding.
-p password	The password that is used to authenticate the distinguished name (DN).
-o object_class	Value(s) of the attribute object_class for the entry (the registration) being created or modified. Note that, if you are listing more than one object_class value, you must separate them with commas.
-d	Deletes the DCE cell information attributes from the entry in the directory. It does not remove the entire directory entry.

The command must be run with root authority and prints a message to stderr.

The following ldap_addcell examples assume the following:

• mymachine.mycity.mycompany.com is the LDAP server machine name.
  
• gdatest is a user that has write access to the LDAP server.
  
• gdatest is also the password of the user gdatest.
  
• An organizationalUnit is allowed to contain the auxiliary object, dceCellInfo.
  
• The LDAP server does schema checking.
  

This example shows the normal creation of the cell bindings in the LDAP server.

ldap_addcell -h mymachine.mycity.mycompany.com -a 
"cn=gdatest,ou=houston,o=compaq,c=us" -p "gdatest"        -o 
organizationalUnit,dceCellInfo

This example shows the deletion of the CDSCELL and CDSREPLICAS attributes.

ldap_addcell -h mymachine.mycity.mycompany.com -a 
"cn=gdatest,ou=houston,o=compaq,c=us" -p "gdatest" -d 

This example shows the changing of the CDSCELL and CDSREPLICAS attributes in an object that already exists.

ldap_addcell -h mymachine.mycity.mycompany.com -a 
"cn=gdatest,ou=houston,o=compaq,c=us" -p "gdatest

Most parameters of the ldap_addcell command have a corresponding environment variable which is used when the corresponding parameter is not present on the ldap_addcell command invocation. Table 7-1 lists environment variables.

.

Table 7-1: ldap_addcell Parameters and Environment Variables

ldap_addcell Parameter	Environment Variable
-h	LDAP_SERVER
-a	LDAP_AUTH_DN
-p	LDAP_AUTH_DN_PW
-o	LDAP_OBJECT_CLASS

NOTE: The -d parameter does not have a corresponding environment variable.

If the cell entry is already registered, the CDSCELL and CDSREPLICAS attributes are replaced with new values for this cell unless the -d parameter is specified.

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

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

Copyright © 2001 Entegrity Solutions Corporation & its subsidiaries.

Copyright © 1998-2001 Compaq Computer Corporation.

All rights reserved.