1 — Gradient DCE for Tru64 UNIX

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

1.1 Overview of the Software

Distributed computing services, as implemented in the Distributed Computing Environment (DCE), provide an important enabling software technology for the development of distributed applications. DCE makes the underlying network architecture transparent to application developers. It consists of a software layer between the operating system and network interface and the distributed application. It provides a variety of common services needed to develop distributed applications, such as name, time, and security services, and a standard remote procedure call interface.

Gradient® DCE for Tru64™ UNIX® provides a means for application developers to design, develop, and deploy distributed applications. Gradient DCE for Tru64 UNIX is based upon OSF® DCE Release 1.2.2.

1.2 Kit Contents

Gradient DCE for Tru64 UNIX consists of the following distributed computing technologies:

The Gradient DCE for Tru64 UNIX product consists of twelve subsets:

The rest of this chapter describes the subsets, additional support, and restrictions for this product.

1.2.1 Runtime Services (RTS) Subset

You must install the DCE Runtime Services subset on all systems on which you want to run DCE applications. This subset includes the DCE client software necessary to run DCE distributed applications and the administrative tools required to configure and maintain the DCE environment. This subset is a prerequisite for all the other subsets. For DCE server configurations, you must install the appropriate subsets described in the following sections. .

Specifically, this subset includes the following components:

1.2.2 Cell Directory Server Subset

The Cell Directory Service (CDS) Server subset provides a consistent mechanism for naming and locating users, applications, files, and systems within a DCE cell. The CDS Server subset requires the Security Server subset to be installed. The CDS Server subset includes the following components:

The Global Directory Agent (GDA) allows you to link multiple CDS or LDAP namespaces using the Internet Domain Name System (DNS) or X.500. To link multiple CDS namespaces using X.500, you must install the DIGITAL X.500 Base kit and the DIGITAL X.500 API kit on your CDS server. Optionally, you can install the DIGITAL X.500 Administration Facility kit for debugging and general administrative support. LDAP directory services using X.500 can be enabled during configuration.

The XDS library allows applications to access the CDS and X.500 directory services. The XDS routine library reference pages are provided in the Gradient DCE for Tru64 UNIX Reference Guide.

1.2.3 Security Server Subset

The Security Server (SEC) subset provides secure communications and controlled access to resources in a DCE environment. DCE Security includes authentication, secure communication, and authorization. The Security Server subset includes these components:

1.2.4 Application Developer's Kit Subset

The Application Developer's Kit (ADK) subset provides the files necessary to develop DCE client and server applications using RPC, CDS, DTS, and Security application programming interfaces. Specifically, this subset includes these components:

1.2.5 Online Manual Pages Subset

Product Name provides two sets of online reference (manual) pages: administrative commands for managing DCE, and application development routines for programming distributed applications. To use the online reference pages on Tru64 UNIX systems, specify the command or routine name with the man command. For example, this command displays the reference page for uuidgen:

% man uuidgen

If more than one reference page exists for a topic (for example, intro), you must specify the section number. For example, this command displays the introduction reference page for security:

% man 3sec intro

For multiple-word commands, use underscore characters to connect the words in the command. For example, this command displays the reference page for rpccp show entry:

% man rpccp_show_entry

1.2.6 Distributed File Service Runtime Services Subset

You must install the Distributed File Service (DFS) Runtime Services subset on all systems on which you want to run DCE DFS. This subset provides runtime services, including the DCE DFS client software necessary to run DCE DFS, and the administrative tools required to configure and maintain the DCE DFS environment.

Specifically, this subset includes the following components:

1.2.7 DFS Kernel Binary Subset

This subset contains the kernel binary files.

1.2.8 DFS Utilities Subset

This subset contains DCE DFS utilities:

1.2.9 DFS Online Manual Pages

This subset contains the online reference (manual) pages for the administrative commands for managing DCE DFS. See Section 1.2.5 on page 18 for information on displaying the online manual pages.

1.2.10 NFS-DFS Secure Gateway Server

This subset contains the NFS-DFS Secure Gateway server components. It includes the gateway authentication daemon and the local authentication registration utility.

See the Gradient DFS for Tru64 UNIX Configuration Guide for more information on configuring DFS.

1.3 Platforms and Networks Supported by Gradient DCE for Tru64 UNIX

1.3.1 Interoperating with PCs

Your DCE server can interoperate with a PC client that has Microsoft RPC software installed on it. To use RPC from a PC, you need not make any changes to the DCE server system.

1.3.2 Network Support

Gradient DCE for Tru64 UNIX supports Tru64 UNIX Version 5.0a. Gradient DCE for Tru64 UNIX provides RPC communications over UDP/IP, TCP/IP, and the DECnet/OSI (Phase V) network protocol family. This network family includes both NSP and OSI transport protocols.

DECnet/OSI support provides upward compatibility for applications on OpenVMS™ nodes running DECnet™ Phase IV. Client applications that run over DECnet Phase IV on OpenVMS can use DECnet Phase IV addressing semantics to communicate with server applications running over the DECnet/OSI Phase V protocol families on Tru64 UNIX.

Application writers can establish a relationship between a client and server by specifying a protocol sequence in one of three ways: in an explicit string binding, in an interface definition, or by registering in the Cell Directory Service. (See the OSF DCE Application Development Reference, intro(3rpc), for a list of valid DCE protocol sequences.) A server that prints addresses as part of its runtime operation prints network addresses and endpoint semantics as string bindings. (For a complete description of the format of string representations of binding information, see the OSF DCE Application Development Guide)

The following string bindings are examples for each protocol supported on Tru64 UNIX platforms. In any DCE implementation that supports the OSI protocol stack, whether from Entegrity Solutions® or another vendor, string bindings such as these are printed when an application fully implements all supported protocols.

String Bindings for the IP protocol:


String Bindings for the DECnet Phase IV protocol:


String Bindings for the DECnet/OSI (Phase V) protocols:


1.4 Threads

The Pthreads interface is an important part of the architecture for DCE, and the DCE services rely on it. DCE uses the Pthreads interface from POSIX 1003.4a/d4. DECthreads is provided as part of the Tru64 UNIX operating system. Refer to the Guide to DEC Threads in the operating system's documentation set for information about threads.

1.5 Enhancements to OSF DCE

The Gradient DCE for Tru64 UNIX kit provides the following added-value features, which are not included in the OSF offering, to help users develop and deploy DCE applications:

1.5.1 CDS Enhanced Browser

The CDS Enhanced Browser contains additional functions beyond those contained in the OSF DCE Version 1.1 Browser. See Chapter 5 for more information.

1.5.2 IDL Compiler Enhancements

The Gradient DCE for Tru64 UNIX IDL compiler in this kit includes important enhancements, which are Entegrity value-added functionality available only with Gradient DCE for Tru64 UNIX:

See Chapter 10 for more information about IDL.

1.5.3 The RPC Event Logger Utility

Entegrity provides the RPC Event Logger, which records information about operations relating to the execution of an application interface.

1.5.4 Name Service Interface Daemon for Microsoft RPC

Entegrity provides the name service interface daemon (nsid), also known as the PC Nameserver Proxy Agent, to allow RPC communication with personal computers running the DCE-compatible Microsoft RPC. The nsid enables an RPC application on MS-DOS, DOS Windows, and Windows NT to perform name-service operations that are available through RPC, as if the RPC applications on the PC were directly involved in the full CDS namespace.

1.5.5 Security Integration Architecture

Security Integration Architecture (SIA) lets users of Gradient DCE for Tru64 UNIX use both BSD security and DCE security by using the same system commands and routines for both.

1.5.6 RPC Support of DECnet/OSI (Phase V)

This version of Gradient DCE for Tru64 UNIX supports Entegrity's DECnet/OSI implementation. See Section 1.3 on page 19 for more information.

1.5.7 DTS Support of DECnet/OSI (Phase V)

This version of the Gradient DCE for Tru64 UNIX supports full functionality of DECnet/OSI implementation.

1.5.8 CDS Cache Clerk Enhanced Memory Management

The CDS enhanced command, dcecp cdscache discard, lets an administrator release specified structures from the cache without any need to stop and restart DCE.

1.5.9 CDS Preferencing

This enhancement improves performance at CDS clients by providing a ranking to the order in which clearinghouses are contacted by the client for CDS information. This can be accomplished automatically through the use of defaults associated with the location of CDS clients with respect to CDS servers or by manual overrides made by cell administrators. For more information, see Section 5.4 on page 69.

1.5.10 DTS Support for DLI (Data Link Interface) and RPC

This version of the Gradient DCE for Tru64 UNIX allows the acceptance of messages on both RPC (a new default) and DLI (the old default).

1.5.11 LDAP Directory Service

The Lightweight Directory Access Protocol (LDAP) provides access to the X.500 directory service without the overhead of the full Directory Access Protocol (DAP). LDAP supports the TCP/IP protocol.

1.5.12 New localrpc Protocol Sequence

Gradient DCE for Tru64 UNIX now supports a new protocol sequence. It is implemented with UNIX Domain sockets and can only be used by clients and servers that are on the same node. By using UNIX Domain sockets, the IP layer can be bypassed, providing gains in performance that may vary with the nature of the RPC traffic. The user must explicitly choose to use the localrpc protocol sequence in either a well-known endpoint in the IDL file, or as called out by one of the rpc_server_use_protseq*() functions wherever a protocol sequence string can be used. String bindings can also be used to pass localrpc binding information from server to client.

1.5.13 Kerberos 5-Compliant Utilities

Massachusetts Institute of Technology (MIT) Kerberos Version 5 authentication and key distribution service is supported. The Kerberized secure and encrypting versions of UNIX network utilities are supported: telnet, rlogin, rsh, and ftp.

1.5.14 DCE in a Tru64 UNIX TruCluster Application Server Environment

Compaq TruCluster™ Solutions is a fault-resilient technology that maximizes uptime for mission-critical applications, databases, and operating systems. Gradient DCE for Tru64 UNIX is Compaq TruCluster tolerant.

1.6 Diskless Support Removed from OSF DCE

Support for diskless workstations was removed from OSF DCE Release 1.1. Consequently, Gradient DCE for Tru64 UNIX does not support diskless workstations.

1.7 Restrictions Using Gradient DCE for Tru64 UNIX

This section describes the following restrictions:

1.7.1 DCE DFS Restrictions and Limitations

For this release, Gradient DFS for Tru64 UNIX is based on OSF DCE Release 1.2.2, and has the following restrictions:

1.7.2 Utility Restriction

If SIA is enabled, the registry information change commands, passwd (change password), chsh (change shell) and chfn (change finger information) can alter the information in one of the configured security mechanism registries.

The OSF DCE chpass utility is not supported by Gradient DCE for Tru64 UNIX. The three commands noted previously provide most functions of chpass, which is a platform-dependent tool that was originally intended only as a reference implementation.

1.7.3 DIGITAL X.500 Restrictions

Version 3.1 of the DIGITAL X.500 Directory Service programming interface to the XDS and XOM APIs does not support the Basic Directory Contents Package (BDCP).

The BDCP permits certain X.500 attribute values to be expressed as OM objects. Applications using Compaq's implementation of XDS must instead specify the values of the X.500 attribute supported in the BDCP as ASN.1 BER.

An important instance of this restriction occurs when representing attribute values that are Distinguished Names, for example, when creating an alias entry with the ds_add_entry( ) routine. You can still create aliases, but not as described in the OSF DCE Application Development Guide.

The OSF DCE Application Development Guide states that, to add an alias entry, these two attributes are required in the list of X.500 attributes specified in the Entry argument to ds_add_entry( ):

DS_A_ALIASED_OBJECT_NAME = alias-target-name

When the BDCP is supported, the alias-target-name value is a DS-DN OM object. The syntax of this value in the Attribute-Value OM Attribute is OM_S_OBJECT.

The current DIGITAL X.500 Directory Service product requires that the alias-target-name value be supplied as ASN.1 BER, with a syntax of OM_S_ENCODING_STRING in the Attribute-Value OM Attribute.

To encode the alias-target-name from a DS-DN OM object to ASN.1 BER, complete the following steps:

  1. If the DS-DN OM object is public, make it a OM private object by calling om_create( ) and om_put( ) routines.

  2. Call the om_encode( ) routine to convert the DS-DN OM private object to an Encoding OM object. Specify `OM_BER' as the `Rules' parameter to om_encode( ) routine. The ASN.1 BER value is returned in the Encoding OM private object.

  3. Call the om_get( ) routine to extract the value. This value can be passed as the alias-target-name.

You must do the same thing when supplying member names for groups. In this case, the Entry argument to the ds_add_entry( ) routine requires these attributes.

DS_A_MEMBER = member-name

The member-name value must be supplied as an ASN.1 BER value.

This encoding requirement applies whenever a Distinguished Name is input as either an attribute value to the ds_compare( ) routine, or as a value to be added to or removed from the ds_modify_entry( ) routine.

Whenever a Distinguished Name is returned as an attribute value from ds_read( ), the application must do the following:

  1. Create an Encoding OM private object containing the value to be decoded by calling om_create( ) and om_put( ) routines.

  2. Call the om_decode( ) routine to convert the Encoding OM private object to a DS-DN OM private object.

Entegrity's implementation of the XDS API om_encode( ) and om_decode( ) routines supports only DS-DN OM objects. Other types of OM objects are not supported.

The following example shows how to create an alias without the BDCP. The example illustrates the steps for performing a synchronous Add Entry operation.

NOTE: The Invoke_id argument is not needed and is set to NULL. The workspace and bound session arguments are assumed to have been set up previously.

The entry adds the following string as an alias entry in the CDS namespace:

/C=US/O="Compaq Computer Corporation"/OU=Research/Projects/CDS

This entry, in turn points to the entry

/C=US/O="Compaq Computer Corporation"/OU=Research/Projects/DECdns

This example shows the additional steps required to supply the attribute value for the DS_A_ALIASED_OBJECT_NAME attribute if the Basic Directory Contents Package (BDCP) optional XDS package is not supported.

OM_private_object bound_session;   /* Assumed to be externally set up */
OM_workspace      workspace;							   /* Assumed to be externally set up */

    OM_private_object name, alias, alias_enc_obj;
    OM_public_object  alias_enc_string;
    OM_value_position desc_count;

    OM_descriptor     cpub_dn[7];
    OM_descriptor     cpub_rdn0[3];
    OM_descriptor     cpub_rdn1[3];
    OM_descriptor     cpub_rdn2[3];
    OM_descriptor     cpub_rdn3[3];
    OM_descriptor     cpub_rdn4[3];
    OM_descriptor     cpub_ava0[4];
    OM_descriptor     cpub_ava1[4];
    OM_descriptor     cpub_ava2[4];
    OM_descriptor     cpub_ava3[4];
    OM_descriptor     cpub_ava4[4];

    OM_descriptor     cpub_attr_list[4];
    OM_descriptor     cpub_attr1[4];
    OM_descriptor     cpub_attr2[4];
    OM_descriptor     cpub_context[3];

    OM_return_code    ds_status = DS_SUCCESS;
    OM_return_code    om_status = OM_SUCCESS;

    /* Define the name AVA descriptors */

    OMX_CLASS_DESC(     cpub_ava0[0], DS_C_AVA);
    OMX_OM_NULL_DESC(   cpub_ava0[3]);

    OMX_CLASS_DESC(     cpub_ava1[0], DS_C_AVA);
    OMX_OM_NULL_DESC(   cpub_ava1[3]);

    OMX_CLASS_DESC(     cpub_ava2[0], DS_C_AVA);
    OMX_OM_NULL_DESC(   cpub_ava2[3]);

    OMX_CLASS_DESC(     cpub_ava3[0], DS_C_AVA);
                                      "Compaq Computer Corporation");
    OMX_OM_NULL_DESC(   cpub_ava3[3]);

    OMX_CLASS_DESC(     cpub_ava4[0], DS_C_AVA);
    OMX_OM_NULL_DESC(   cpub_ava4[3]);

    /* Define the name RDN descriptors */

    OMX_CLASS_DESC(     cpub_rdn0[0],       DS_C_DS_RDN);
    OMX_OBJECT_DESC(    cpub_rdn0[1],       DS_AVAS, cpub_ava0);
    OMX_OM_NULL_DESC(   cpub_rdn0[2]);

    OMX_CLASS_DESC(     cpub_rdn1[0],       DS_C_DS_RDN);
    OMX_OBJECT_DESC(    cpub_rdn1[1],       DS_AVAS, cpub_ava1);
    OMX_OM_NULL_DESC(   cpub_rdn1[2]);

    OMX_CLASS_DESC(     cpub_rdn2[0],       DS_C_DS_RDN);
    OMX_OBJECT_DESC(    cpub_rdn2[1],       DS_AVAS, cpub_ava2);
    OMX_OM_NULL_DESC(   cpub_rdn2[2]);

    OMX_CLASS_DESC(     cpub_rdn3[0],       DS_C_DS_RDN);
    OMX_OBJECT_DESC(    cpub_rdn3[1],       DS_AVAS, cpub_ava3);
    OMX_OM_NULL_DESC(   cpub_rdn3[2]);

    OMX_CLASS_DESC(     cpub_rdn4[0],       DS_C_DS_RDN);
    OMX_OBJECT_DESC(    cpub_rdn4[1],       DS_AVAS, cpub_ava4);
    OMX_OM_NULL_DESC(   cpub_rdn4[2]);

    /* And now the Distinguish Name descriptor list */

    OMX_CLASS_DESC(     cpub_dn[0],         DS_C_DS_DN);
    OMX_OBJECT_DESC(    cpub_dn[1],         DS_RDNS, cpub_rdn4);
    OMX_OBJECT_DESC(    cpub_dn[2],         DS_RDNS, cpub_rdn3);
    OMX_OBJECT_DESC(    cpub_dn[3],         DS_RDNS, cpub_rdn2);
    OMX_OBJECT_DESC(    cpub_dn[4],         DS_RDNS, cpub_rdn1);
    OMX_OBJECT_DESC(    cpub_dn[5],         DS_RDNS, cpub_rdn0);
    OMX_OM_NULL_DESC(   cpub_dn[6]);

    /* define the first entry attribute descriptor */

    OMX_CLASS_DESC(     cpub_attr1[0], DS_C_ATTRIBUTE);
    OMX_OM_NULL_DESC(   cpub_attr1[3]);

    /* define the second entry attribute descriptor */

    OMX_CLASS_DESC(     cpub_attr2[0], DS_C_ATTRIBUTE);
    OMX_STRING_DESC(    cpub_attr2[2], OM_S_ENCODING_STRING,
                                       NULL, 0); /*Do dynamic fix later*/
    OMX_OM_NULL_DESC(   cpub_attr2[3]);

    /* and now the attribute descriptor list */

    OMX_CLASS_DESC(     cpub_attr_list[0],   DS_C_ATTRIBUTE_LIST);
    OMX_OBJECT_DESC(    cpub_attr_list[1],   DS_ATTRIBUTES, cpub_attr1);
    OMX_OBJECT_DESC(    cpub_attr_list[2],   DS_ATTRIBUTES, cpub_attr2);
    OMX_OM_NULL_DESC(   cpub_attr_list[3]);

    /* create the OM private object: name */

    om_status = om_create(DS_C_DS_DN, OM_FALSE, workspace, &name);

    /* Copy the attribute list from the cpub_dn public object into  */
    /* the name private object */

    om_status = om_put(name, OM_REPLACE_ALL, cpub_dn, 0,0,0);

    /* create the OM private object: alias */

    om_status = om_create(DS_C_DS_DN, OM_FALSE, workspace, &alias);

    /* For brevity in this example we reuse the cpub_dn public object */
    /* for the alias target name by fixing up one of its descriptors. */


    /* Copy the attribute list from the cpub_dn public object into    */
    /* the alias private object. */

    om_status = om_put(alias, OM_REPLACE_ALL, cpub_dn, 0,0,0);

    /* Additionally encode the alias private object */

    om_status = om_encode(alias, OM_BER, &alias_enc_obj);

    /* Extract the actual encoding string from the encoded object     */

    om_status = om_get(alias_enc_obj, OM_NO_EXCLUSIONS, 0, OM_FALSE,
                        0, 0, &alias_enc_string, &desc_count);

    /* create the OM private object: entry */

    om_status = om_create(DS_C_ATTRIBUTE_LIST, OM_FALSE, workspace,

    /* Fixup the cpub_attr_list to hold the encoding string */


    /* Copy the attribute list from the cpub_attr_list public */
    /* object into the entry private object */

    om_status = om_put(entry, OM_REPLACE_ALL, cpub_attr_list,
                        0, 0, 0);

    /* Call the Add Entry function using entry as a parameter */

    ds_status = ds_add_entry(bound_session, DS_DEFAULT_CONTEXT, name, 
                                                          entry, NULL); 
    if (ds_status == DS_SUCCESS)
        printf("ADD ENTRY request was successful\n");
        printf("ADD ENTRY request failed\n");

[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.