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:

• DCE Remote Procedure Call (RPC), which allows you to create and run client/server applications.

• DCE Cell Directory Service (CDS), which provides location-independent naming for servers.

• DCE Distributed Time Service (DTS), which synchronizes time in distributed network environments.

• DCE Security Service, which provides secure communications and controlled access to resources.

• DCE Distributed File Service (DFS), which provides transparent file access to a single namespace in a distributed computing environment.

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

• Runtime Services (RTS) subset
  
• Security Server (SEC) subset
  
• Cell Directory Server (CDS) subset
  
• Six Distributed File Service (DFS) subsets
  
• Application Developer's Kit (ADK) subset
  
• Online Command Reference Manual Pages (MAN) subset
  
• Online Application Developer's Manual Pages (ADKMAN) subset
  

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:

• Remote Procedure Call runtime library

  The RPC runtime library includes routines that manage communications between client and server stubs. The DCE host daemon (dced) maintains the endpoint map (addresses). The RPC Event Logger (rpclm) is also provided in this subset.

• Cell Directory Server (CDS) clerk and CDS advertiser

  The CDS clerk (cdsclerk) runs on the client node and serves as an intermediary between client applications and CDS servers. Clerks learn about CDS servers by listening to messages sent out by the CDS advertiser (cdsadv).

• DIGITAL X.500 XDS Library

  The XDS library provides support for use of XDS with DCE naming.

• Distributed Time Service (DTS) clerk and server

  The DTS clerk and server (dtsd) synchronize time in distributed network environments.

• PC name service interface daemon

  The Runtime Services subset provides the name service interface daemon (nsid), also called the PC Nameserver Proxy Agent, to allow interoperability with machines running Microsoft® RPC on MS-DOS®, Windows®, Windows NT™, or Windows 95™. If the PC is running DCE services, the nsid is not necessary.

• Audit Service daemon

  The Audit Service daemon (auditd) records and logs significant events (such as creating a user, logging in, or obtaining a ticket) in an audit trail file. Application servers can be designed to use the Audit Service for logging purposes.

• Administrative tools

  The administrative tools include the control program dcecp and the enhanced CDS Browser (cdsbrowser). The Browser provides a graphical user interface for viewing the CDS namespace. The dcecp program replaces the earlier control programs rpccp for RPC, cdscp for CDS, and dtscp for DTS. These control programs remain available for special purposes, however.

  The administrative tools also include rgy_edit, passwd_import, passwd_export, acl_edit, getcellname and sec_admin.

• DCE Configuration Program

  The DCE configuration program (dcesetup) allows you to configure your DCE environment.

• DCE Login Facility

  The dce_login command allows you to log in to DCE.

• Other DCE tools

  kinit
  kdestroy
  klist
  UUID Generator (uuidgen)
  

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:

• CDS server (cdsd)
  
• Global Directory Agent (gdad)
  

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:

• Security server (secd)
  
• Tool used to create the security database (sec_create_db)
  
• Tool used to move the security database (sec_salvage_db)
  

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:

• Interface Definition Language (IDL) stub compiler
  
• Required DCE application development include files
  
• Sample time-provider routines
  
• Sample DCE applications
  
• Symbols and message strings (SAMS) compiler for building DCE message files, as described on the sams reference page.
  

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

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:

• User-level commands that include the DCE DFS configuration program (dfssetup), Basic OverSeer (BOS) Server commands (bos, bosserver), Cache Manager commands (cm), user-space services to the Cache Manager or File Exporter (dfsbind), Cache Manager daemon (dfsd), non-DCE LFS partitions exporter (dfsexport), Fileset Location Database Server daemon (flserver), Fileset Server and Fileset Location Server commands (fts), Fileset Server daemon (ftserver), File Exporter daemon (fxd), Update Server daemon for clients (upclient), and Update Server daemon for servers (upserver).

• Error message files

• DFS shared library (libcedfs.so)

This subset contains the kernel binary files.

1.2.8 DFS Utilities Subset

This subset contains DCE DFS utilities:

• scout displays File Exporter statistics.

• dfstrace helps you diagnose problems in the kernel or within server processes that interface with dfstrace.

• udebug displays Ubik status information.

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

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:

ncacn_ip_tcp:16.20.16.155[3924]
ncadg_ip_udp:16.20.16.155[1575]

String Bindings for the DECnet Phase IV protocol:

ncacn_dnet_nsp:12.36[RPC2DD20001]

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

ncacn_osi_dna:%x49000caa000400243021[RPC52DD20001,tpid=cots]
ncacn_osi_dna:%x49000caa000400243020[RPC52DD20001,tpid=nsp]
ncacn_osi_dna:NODENAME[RPC52DD20001,tpid=cots]

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:

• CDS Enhanced Browser
  
• IDL compiler enhancements
  
• RPC Event Logger Utility
  
• NSI daemon (PC Nameserver Proxy Agent)
  
• Security Integration Architecture (SIA)
  
• RPC support of DECnet/OSI (Phase V)
  
• DTS support of DECnet/OSI (Phase V)
  
• CDS Cache Clerk Enhanced Memory Management
  
• CDS Preferencing
  
• DTS Support for RPC and DLI (Data Link Interface)
  
• LDAP Directory Service
  
• New localrpc protocol sequence
  
• Kerberos 5-compliant utilities
  
• DCE in a Tru64 UNIX TruCluster Application Server Environment
  

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:

• Runtime routine templates
  
• DEC Fortran support
  

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:

• Use of DCE DFS
  
• Use of the chpass utility
  
• Use of some features of the XDS Directory Interface
  

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

• Supports the UNIX® File System (UFS) and POLYCENTER™ Advanced File System (AdvFS) only. Enhanced DFS server capabilities (for example, fileset cloning) are not supported on the server side.

• DFS built-in backup is not supported. Instead, use the Tru64 UNIX native file system backup facility.

• The NFS-DFS Secure Gateway server does not support remote DFS login / logout capabilities. For authenticated access to DFS, users of DCE-unaware NFS clients must authenticate to DCE from the Gateway Server machine using a dfsgw add operation. Refer to the OSF DCE DFS Administration Guide and Reference for information about authenticating from a Gateway Server machine.

• Gradient DFS for Tru64 UNIX uses Tru64 UNIX ACLs. These lack some of the features of DCE ACLs. Chapter 8 discusses how Gradient DCE for Tru64 UNIX compensates for some ACL limitations.

• DCE DFS uses DCE credentials to authorize access to objects in the DCE DFS namespace. Background daemons lacking DCE Security credentials may not be able to use the DCE DFS namespace. Processes started by system daemons (that is, cron(8), inetd(8), rdistd(8)) may be denied access to files in the DCE DFS namespace if they do not have DCE credentials. For example, attempts to use the commands at(1) or rdist(1) when the remote files are in the DCE DFS namespace may fail. This is an important security feature of DCE and DFS. See Section 8.5 on page 100 for information on obtaining DCE credentials by using the -k flag with dce_login.

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_OBJECT_CLASS = DS_O_ALIAS
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_OBJECT_CLASS = DS_O_GROUP_OF_NAMES
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_ATTR_TYPE_DESC( cpub_ava0[1], DS_ATTRIBUTE_TYPE,
                                      DSX_TYPELESS_RDN);
    OMX_ZSTRING_DESC(   cpub_ava0[2], OM_S_PRINTABLE_STRING,
                                      DS_ATTRIBUTE_VALUES,
                                      "CDS");
    OMX_OM_NULL_DESC(   cpub_ava0[3]);

    OMX_CLASS_DESC(     cpub_ava1[0], DS_C_AVA);
    OMX_ATTR_TYPE_DESC( cpub_ava1[1], DS_ATTRIBUTE_TYPE,
                                      DSX_TYPELESS_RDN);
    OMX_ZSTRING_DESC(   cpub_ava1[2], OM_S_PRINTABLE_STRING,
                                      DS_ATTRIBUTE_VALUES,
                                      "Projects");
    OMX_OM_NULL_DESC(   cpub_ava1[3]);

    OMX_CLASS_DESC(     cpub_ava2[0], DS_C_AVA);
    OMX_ATTR_TYPE_DESC( cpub_ava2[1], DS_ATTRIBUTE_TYPE,
                                      DS_A_ORG_UNIT_NAME);
    OMX_ZSTRING_DESC(   cpub_ava2[2], OM_S_PRINTABLE_STRING,
                                      DS_ATTRIBUTE_VALUES,
                                      "Research");
    OMX_OM_NULL_DESC(   cpub_ava2[3]);

    OMX_CLASS_DESC(     cpub_ava3[0], DS_C_AVA);
    OMX_ATTR_TYPE_DESC( cpub_ava3[1], DS_ATTRIBUTE_TYPE,
                                      DS_A_ORG_NAME);
    OMX_ZSTRING_DESC(   cpub_ava3[2], OM_S_PRINTABLE_STRING,
                                      DS_ATTRIBUTE_VALUES,
                                      "Compaq Computer Corporation");
    OMX_OM_NULL_DESC(   cpub_ava3[3]);

    OMX_CLASS_DESC(     cpub_ava4[0], DS_C_AVA);
    OMX_ATTR_TYPE_DESC( cpub_ava4[1], DS_ATTRIBUTE_TYPE,
                                      DS_A_COUNTRY_NAME);
    OMX_ZSTRING_DESC(   cpub_ava4[2], OM_S_PRINTABLE_STRING,
                                      DS_ATTRIBUTE_VALUES,
                                      "US");
    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_ATTR_TYPE_DESC( cpub_attr1[1], DS_ATTRIBUTE_TYPE,
                                       DS_A_OBJECT_CLASS);
    OMX_ATTR_TYPE_DESC( cpub_attr1[2], DS_ATTRIBUTE_VALUES,
                                       DS_O_ALIAS);
    OMX_OM_NULL_DESC(   cpub_attr1[3]);

    /* define the second entry attribute descriptor */

    OMX_CLASS_DESC(     cpub_attr2[0], DS_C_ATTRIBUTE);
    OMX_ATTR_TYPE_DESC( cpub_attr2[1], DS_ATTRIBUTE_TYPE,
                                       DS_A_ALIASED_OBJECT_NAME);
    OMX_STRING_DESC(    cpub_attr2[2], OM_S_ENCODING_STRING,
                                       DS_ATTRIBUTE_VALUES,
                                       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. */

    OMX_ZSTRING_DESC(   cpub_ava0[2], OM_S_PRINTABLE_STRING,
                                      DS_ATTRIBUTE_VALUES,
                                      "DECdns");

    /* 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,
                           &entry);

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

    OMX_STRING_DESC(cpub_attr2[2], OM_S_ENCODING_STRING,
                                   DS_ATTRIBUTE_VALUES,
                               alias_enc_string->value.string.elements,
                               alias_enc_string->value.string</ul>ngth);

    /* 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");
    }
    else
    {
        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.