VMS Help
DCE_RPC, rpccp, Name Service Interface
*Conan The Librarian (sorry for the slow response - running on an old VAX)
|
|
The remainder of this description contains information to help you use
commands that call the name service interface to access name service
entries (NSI commands).
The DCE RPC name service interface (NSI) is independent of any
particular name service. CDS, however, is the only name service
available for DCE RPC Version 1.0 applications. For more details
on the name service interface, see the OSF DCE Application
Development Guide-Core Components. For a description of the DCE
Cell Directory Service, see the OSF DCE Administration Guide-Core
Components.
To store information about RPC servers, interfaces, and objects, the
NSI defines the following name service entries:
server entry
Stores binding information, interface identifiers, and
object UUIDs for an RPC server.
group Corresponds to one or more RPC servers that offer a common
RPC interface, type of RPC object, or both.
profile Defines search paths for looking in a name service database
for a server that offers a particular RPC interface and
object.
Note that when the NSI is used with the Cell Directory Service, the
name service entries are CDS object entries.
|
2 - Structure of Entry Names
|
Each entry in a name service database is identified by a unique
global name made up of a cell name and a cell-relative name.
A cell is a group of users, systems, and resources that share common
DCE services. A cell configuration includes at least one cell
directory server, one security server, and one time server. A cell's
size can range from one system to thousands of systems. For
information on cells, see the CDS portion of this book.
The following is an example of a global name:
/.../C=US/O=uw/OU=MadCity/LandS/anthro/Stats_host_2
The parts of a global name are as follows:
Cell name (using X.500 name syntax)
For example:
/.../C=US/O=uw/OU=MadCity
The symbol /... begins a cell name. The letters before the
equal signs (=) are abbreviations for country (C),
organization (O), and organization unit (OU).
For entries in the local cell, the cell name can be
represented by a /.: prefix, in place of the actual cell
name; for example,
/.:/LandS/anthro/Stats_host_2
For NSI operations on entries in the local cell you can omit
the cell name.
Cell-relative name
Each name service entry requires a cell-relative name,
which contains a directory pathname and a leaf name.
directory pathname
Follows the cell name and indicates the
hierarchical relationship of the entry to the
cell root. The directory pathname is the middle
portion of the global name. The cell name is to
the left of the directory pathname, and the leaf
name is to the right, as follows:
cell-name + directory-pathname + leaf-name
The directory pathname contains the names of any
subdirectories in the path; each subdirectory
name begins with a slash (/), as follows:
/sub-dir-a-name/sub-dir-b-name/sub-dir-c-name
Directory paths are created by name service
administrators. If an appropriate directory path
does not exist, ask your name service
administrator to extend an existing path or
create a new path. In a directory path, the
name of a subdirectory should reflect its
relationship to its parent directory (the
directory that contains the subdirectory).
leaf name Identifies the specific entry. The leaf name is
the right-hand part of global name beginning with
the rightmost slash.
In the following example, /.../C=US/O=uw/OU=MadCity is the cell name,
/LandS/anthro is the directory pathname, and /Cal_host_4 is the leaf
name.
/.../C=US/O=uw/OU=MadCity/LandS/anthro/Cal_host_4,
If a name service entry is located at the cell root, the leaf name
directly follows the cell name; for example, /.:/cell-profile.
Note that when the NSI is used with CDS, the cell-relative name is a
CDS name.
|
3 - Guidelines for Constructing Names of Name Service Entries
|
A global name includes both a cell name and a cell-relative name
composed of a directory pathname and a leaf name. The cell name is
assigned to a cell root at its creation. When you specify only a
cell-relative name to an NSI command, the NSI automatically expands
the name into a global name by inserting the local cell name. When
returning the name of a name service entry, a group member, or member
in a profile element, NSI operations return global names.
The directory pathname and leaf name uniquely identify a name service
entry. The leaf name should somehow describe the entry; for example,
by identifying its owner or its contents. The remainder of this
section contains guidelines for choosing leaf names. Note that
directory pathnames and leaf names are case sensitive.
Naming a Server Entry
For a server entry that advertises an RPC interface or service
offered by a server, the leaf name must distinguish the entry
from the equivalent entries of other servers. When a single
server instance runs on a host, you can ensure a unique name by
combining the name of the service, interface (from the interface
definition), or the system name for the server's host system.
For example, consider two servers, one offering a calendar ser-
vice on host JULES and one, on host VERNE.
The server on JULES uses the following leaf name:
calendar_JULES
The server on VERNE uses the following leaf name:
calendar_VERNE
For servers that perform tasks on or for a specific system, an
alternative approach is to create server entries in a system-
specific host directory within the name service database. Each
host directory takes the name of the host to which it
corresponds. Because the directory name identifies the system,
the leaf name of the server entry name need not include the
host name, for example:
/.:/LandS/host_1/Process_control
To construct names for the server entries used by distinctive
server instances on a single host, you can construct unique
server entry names by combining the following information: the
name of the server's service, interface, or object; the system
name of the server's host system, and a reusable instance iden-
tifier, such as an integer.
For example, the following leaf names distinguish two instances
of a calendar service on the JULES system:
calendar_JULES_01
calendar_JULES_02
Avoid automatically generating entry names for the server
entries of server instances, for example, by using unique
data such as a time stamp (calendar_verne_15OCT91_21:25:32)
or a process identifier (calendar_jules_208004D6). When a
server incorporates such unique data into its server entry
names, each server instance creates a separate server entry,
causing many server entries. When a server instance stops
running, it leaves an obsolete server entry that is not
reused. The creation of a new entry whenever a server
instance starts may impair performance. A server can use
multiple server entries to advertise different combinations
of interfaces and objects. For example, a server can create
a separate server entry for a specific object (and the
associated interfaces). The name of such a server entry should
correspond to a well-known name for the object. For example,
consider a server that offers a horticulture bulletin board
known to users as horticulture_bb. The server exports the
horticulture_bb object, binding information, and the
associated bulletin-board interface to a server entry whose
leaf name identifies the object, as follows:
horticulture_bb
Note that an RPC server that uses RPC authentication can choose
identical names for its principal name and its server entry.
Use of identical names permits a client that calls the
rpc_binding_set_auth_info routine to automatically determine a
server's principal name (the client will assume the principal
name to be the same as the server's entry name). If a server
uses different principal and server entry names, users must
explicitly supply the principal name. For an explanation of
principal names, see the DCE Security Service part of the DCE
Application Development Guide.
Naming a Group
The leaf name of a group should indicate the interface, service,
or object that determines membership in the group. For example,
for a group whose members are selected because they advertise an
interface named Statistics, the following is an effective leaf
name:
Statistics
For a group whose members advertise laser-printer print queues
as objects, the following is an effective leaf name:
laser-printer
Naming a Profile
The leaf name of a profile should indicate the profile users;
for example, for a profile that serves the members of an
accounting department, the following is an effective leaf name:
accounting_profile
To use the NSI commands to access entries in a CDS database, you
need access control list (ACL) permissions. Depending on the NSI
operation, you need ACL permissions to the parent directory or the
CDS object entry (the name service entry) or both. The ACL
permissions are as follows:
+ To create an entry, you need insert permission to the parent
directory.
+ To read an entry, you need read permission to the CDS object
entry.
+ To write to an entry, you need write permission to the CDS
object entry.
+ To delete an entry, you need delete permission either to the
CDS object entry or to the parent directory.
Note that write permission does not imply read permission.
ACL permissions for the NSI commands of the control program are
described in the reference pages.
[legal]
[privacy]
[GNU]
[policy]
[netiquette]
[sponsors]
[FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.