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.
1 – Name Service Entries
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
service 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
identifier, 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 th horticulture_bb object, binding informa-
tion, 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
4 – Permissions Required
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.