NAME
dce_tools_intro - Introduction to the general DCE administration
tools
DESCRIPTION
This section describes publicly accessible DCE administration commands
that are general to DCE rather than specific to a particular component.
These commands are as follows:
csrc
The csrc utility is the code set registry compiler, which builds
a DCE character and code set registry on a host from a source
file supplied by a cell administrator. Administrators run the
csrc utility when they are building an "internationalized" DCE
cell.
dce_config
The dce_config shell command invokes a menu-driven interface that
installs, configures, and starts up DCE. The dce_config command
displays a hierarchy of menus and invokes individual installation
and configuration routines, according to users' menu selections.
dcecp
The dcecp control program is the primary DCE administration
interface, providing remote access to routine DCE administrative
functions.
dced
The DCE host daemon is a process that provides services for the
local host, and is also the server used by remote applications to
access these host services.
getcellname
Returns the name of the local cell.
RELATED INFORMATION
See each command's reference page for further information.
1 – csrc
NAME
csrc - Builds a DCE character and code set registry on a host
SYNOPSIS
csrc [argument] ...
ARGUMENTS
-i source_filename
Reads code set values from the source file you specify rather
than from the default code set registry source file
dce$common:[etc]code_set_registry.txt
-m intermediate_cs_name
Indicates the code set to be used as an intermediate code set
-o destination_filename
Places the generated code set registry file in the location
you specify rather than in the default location
dce$common:[etc]code_set_registry.db
DESCRIPTION
The Code Set Registry Compiler csrc creates a character and code set
registry file from the information supplied in a character and code
set registry source file.
A code set registry source file is composed of a series of code set
records. Each record describes, in human-readable form, the mapping
between an OSF-registered or (optionally) a user-defined unique code
set value and the character string that a given operating system uses
when referring to that code set (called the "local code set name").
A code set registry file is the binary version of the source file; the
DCE RPC routines for character and code set interoperability use the
file to obtain a client's or a server's supported code sets and to
translate between operating system-dependent names for code sets and
the unique identifiers assigned to them. A code set registry file must
exist on each host in an "internationalized" DCE cell (a DCE cell that
supports applications that use the DCE RPC character and code set
interoperability features).
CREATING THE SOURCE FILE
Code set registry source files are created for input to csrc in two
instances:
+ By DCE licensees, when they are porting DCE to a specific
operating system platform and plan for their DCE product to
support internationalized DCE applications. In this instance,
DCE licensees modify a template code set registry source file
supplied on the DCE source tape to contain, for each code set
that their platform supports, the local code set names for
those supported code sets. Licensees can also add to this file
any vendor-specific, non-OSF registered code set names and
values that their platform supports.
+ By cell administrators, when they are configuring machines that
are part of an internationalized DCE cell. In this instance,
the cell administrator adds the local code set names of any
additional code sets that the site supports to the licensee-
generated code set registry source file for each different
operating system platform that exists in the cell. The cell
administrator can also add to each platform-specific source
file any site-specific, non-OSF registered code set names and
values.
Each code set record specifies one code set, and has the following
form:
start
field_list
end
where field_list consists of the following keyword-value or keyword-
text pairs:
description text
A comment string that briefly describes the code set.
The text field can contain multiple lines; use the
backslash character (\) to continue the line. Use this
field to give a detailed description of the code set
and character set(s).
loc_name text
A maximum 32-byte string (31 character data bytes plus a
terminating NULL) that contains the operating system-
specific name of a code set or the keyword NONE. Use
this field to specify the name that your site uses to
refer to this code set and the code set converters
associated with it. For example, on UNIX platforms, code
set converters are usually implemented under the iconv
scheme. Check the iconv converter directory to determine
the code set names.
rgy_value value
A 32-bit hexadecimal value that uniquely identifies this
code set. A registry value can be one that OSF has
assigned or one that a DCE licensee or cell administrator
has assigned. Licensee or cell administrator-defined
values must be in the range 0xf5000000 through 0xfffffff.
char_values value[:value]
One or more 16-bit hexadecimal values that uniquely
identify each character set that this code set encodes.
A character value can be one that OSF has assigned or
one that a DCE licensee or a cell administrator has
assigned. Use the colon character (:) to separate
multiple character set values.
max_bytes value
A 16-bit value that specifies the maximum number of
bytes this code set uses to encode one character. The
count should include any single-shift control characters,
if used.
In the source file, braces({}) can be used as synonyms for the
start and end keywords. Use one or more spaces or tabs to separate
field names and values. An unquoted # (number sign) introduces a
comment; in this case, the csrc utility ignores everything between
the comment character and the end of the line.
The OSF DCE source tape provides a partial version of a code set
registry source file in the file /usr/lib/nls/csr/code_set_registry.txt.
This source file contains records for all OSF-registered code sets,
and assigns the text string NONE to loc_name fields intended for
modification to a local code set name.
DCE licensees who port DCE to their operating system platform and
who plan to support internationalized DCE RPC applications must
replace the NONE text string with their local name for the code set,
for each code set that their operating system platform supports.
If their platform does not support a given code set, they must leave
the NONE keyword in the code set record.
Cell administrators of internationalized DCE cells carry out the
same procedure on the licensee-supplied, platform-specific source
files that exist at their site. For each platform-specific source
file, they replace the NONE keyword with the local code set names
for any site-specific supported code sets.
DCE licensees and cell administrators can also add vendor-specific
or site-specific code set values that have not been registered with
OSF. These vendor or user-defined values must be in the range
0xf5000000 through 0xfffffff.
Here is an excerpt from the OSF-supplied code set registry source file:
start
description ISO 8859:1987; Latin Alphabet No. 1
loc_name NONE
rgy_value 0x00010001
char_values 0x0011
max_bytes 1
end
start
description ISO 8859-2:1987; Latin Alphabet No. 2
loc_name NONE
code_value 0x00010002
char_values 0x0012
max_bytes 1
end
start
description ISO 8859-3:1988; Latin Alphabet No. 3
loc_name NONE
code_value 0x00010003
char_values 0x0013
max_bytes 1
end
start
description ISO 8859-6:1987; Latin-Arabic Alphabet
loc_name NONE
code_value 0x00010006
char_values 0x0016
max_bytes 1
end
[...]
start
description ISO/IEC 10646-1:1993; UCS-2 Level 1
loc_name NONE
code_value 0x00010100
char_values 0x1000
max_bytes 2
end
[...]
start
description JIS eucJP:1993; Japanese EUC
loc_name NONE
code_value 0x00030010
char_values 0x0011:0x0080:0x0081:0x0082
max_bytes 3
end
GENERATING THE CODE SET REGISTRY FILE
DCE licensees use csrc to create licensee-supplied code set
registry files for their internationalized DCE product. Cell
administrators of internationalized DCE cells use the csrc
utility to create site-specific code set registry files for
each host in the cell. The cell administrator runs the csrc
program on each host in the cell.
When invoked without options, csrc uses the default source file
dce$common:[etc]code_set_registry.txt and creates the default
output file dce$common:[etc]code_set_registry.db. Use the -i
and -o options to redirect csrc to use a specific source file or
generate a specific output file. The csrc utility also generates
a log file named CSRC_LOG in the current directory.
ADDING INTERMEDIATE CODE SETS
Use the -m option to add a maximum of five intermediate code set
names to the code set registry file's intermediate code set priority
list. The order in which you specify intermediate code sets
determines their order of precedence in the list; that is, the first
intermediate code set you specify with -m becomes the first
intermediate code set in the priority list, and thus will be the
first code set used should an intermediate code set be required for
client-server communication. If you do not specify intermediate
code sets with -m, the Universal code set ISO 10646 will be used as
the default intermediate code set.
RESTRICTIONS
You need write permission to the dce$common:[etc] directory, which
usually requires privileges.
FILES
dce$common:[etc]code_set_registry.txt
Default pathname for code set registry source file.
dce$common:[etc]code_set_registry.db
Default pathname for code set registry object file
EXAMPLES
% csrc -i dia0:[test.i18n_app]code_set_registry.txt -
-o code_set_registry.db s
In the previous example, the log file CSRC_LOG is created in the current
working directory, testi18n_app.
RELATED INFORMATION
FUNCTIONS: dce_cf_get_csrgy_filename
dce_cs_loc_to_rgy
dce_cs_rgy_to_loc
rpc_rgy_get_codesets
BOOKS: OSF DCE Administration Guide
OSF DCE Application Development Guide-Core Components
2 – dce_config
NAME The dce$setup.com command file replaces the dce_config command. See the dce$setup.com help for more information.
3 – dcecp
NAME
dcecp - An administrative interface for performing DCE management
tasks. The interface accepts interactive commands and
scripts written with the dcecp language.
SYNOPSIS
dcecp
dcecp script_name
dcecp -c command
ARGUMENTS
script_name
The script_name is the filename of a user-defined script containing
dcecp commands.
-c command
The command is a valid dcecp command. For a description of the dcecp
command format, see "Administration Objects," below.
DESCRIPTION
The dcecp control program is the primary DCE administration interface,
providing remote access to routine DCE administrative functions from
any DCE Version 1.1 platform.
The dcecp control program is built on a portable command language
called the Tool Command Language (Tcl). Tcl allows the use of
variables, if statements, list processing functions, loop functions
and many other features commonly found in command languages. The
control program extends these features providing a set of commands
for manipulating specific DCE objects. The control program also
includes task scripts to help administrators perform some routine
DCE management functions. Refer to the DCE Administration Guide
Core Volume for information about the basic concepts and features
of dcecp. All of TCL is included in the dcecp language.
INVOKING AND TERMINATING DCECP
The dcecp control program allows you to invoke dcecp commands in
the following modes:
+ Interactive mode
+ Command line mode
Interactive Mode
Activate interactive mode by entering the dcecp command
without any arguments . At the dcecp prompt enter a dcecp
command. The dcecp program executes the command,
displays the result, and is ready to accept another
command.
$ dcecp
dcecp> directory list /.: -directories
/.:/hosts /.:/subsys
dcecp>
Command Line Mode
Activate command line mode from the system prompt using
one of the following methods:
+ Enter the dcecp command with a filename of a script
containing dcecp commands (and/or other valid Tcl
commands) as follows:
$ dcecp myown.Tcl
+ Enter the dcecp command with the -c option followed
by a dcecp command.
$ dcecp -c directory create /.:/admin/printers
Enter multiple dcecp commands by separating them
with a semicolon (;) and enclosing the commands in
double quotes (""). Remember to enclose case sensitive
characters double quotes. Multiple commands must be on
a single line as follows:
$ dcecp -c "directory create /.:/admin/printers;directory show"
Terminate an interactive dcecp session using the exit and quit commands.
Use the following command syntax:
exit n
quit
Use the n argument to specify the exit value returned to DCL. If no
value is specified, exit passes the return value of the most recent
command to DCL. The following example terminates a session and
returns an exit value of 56 to the DCL:
dcecp> exit 56
By default, dcecp returns 1 on success and %X00038008 if a command
fails.
STARTUP SCRIPTS
When you invoke dcecp the following script files are executed in the
order shown:
tcl$library:init.tcl
contains the standard Tcl initialization scripts with
definitions for the unknown command and the auto_load
facility
"$dcecp_library/init.dcecp"
contains the initialization scripts implementing the dcecp
commands and tasks. The implementation sets the Tcl variable
dcecp_library to dceshared/dcecp by default.
$HOME/.dcecprc
contains user customizations.
ADMINISTRATION OBJECTS
A dcecp command has the following syntax:
object operation [argument] [-option [value]] ...
where:
object Specifies the name of a dcecp administration object.
Examples of administration objects are CDS directories,
access control lists (ACLs), DTS servers, server control
objects, and so on. Each administration object is briefly
described below.
operation Specifies the name of an action such as create, show, or
remove, that is to be performed on an administration
object. For complete descriptions of operations supported
by each dcecp object, refer to individual object reference
pages. Common operations are briefly described below.
argument Specifies the name of one or more specific objects to
operate on. Most, but not all, dcecp objects take an
argument. Refer to the individual reference pages for
descriptions of the arguments supported by various objects.
-option Specifies a qualifier that controls the precise behavior of
a dcecp command. Most, but not all, dcecp commands take
options. Specify options by preceeding the option name
with a hyphen as in -replica. Some options take an argument
that can be a name or a value. The following example shows
a -clearinghouse option and its argument which is the name
of a CDS clearinghouse.
directory create /.:/admin -clearinghouse /.:/boston_ch
The dcecp program supports the following dcecp administration objects.
For complete descriptions of the administration objects, refer to the
individual object reference pages.
account Manages an account in the DCE Security Service registry.
acl Creates, modifies, and removes access control lists.
attrlist Manipulates attribute lists.
aud Manages the audit daemon (auditd) on a DCE host.
audevents Manages audit event classification on a DCE host.
audfilter Manages audit event filters on a DCE host.
audtrail Controls the output format for audit events captured
on a DCE host.
cdsalias Manages cell names known to CDS.
cdscache Manages the CDS clerk cache on a DCE host.
cell Manages cell configuration information.
cellalias Manages cell names across all of DCE.
clearinghouse Manages CDS clearinghouse operations in a DCE cell.
clock Manages the clock on a local DCE host.
directory Manages directories in the DCE Cell Directory Service.
dts Manages Distributed Time Service servers and clerks.
endpoint Manages endpoint information in a DCE host's endpoint
map.
group Manages groups in the DCE Security Service registry.
host Manages hosts within a cell.
hostdata Manages a DCE host's principal name and cell affiliation
information on the host.
keytab Manages server passwords on DCE hosts.
link Manages softlinks in the DCE Cell Directory Service.
log Manages routing for DCE serviceability messages.
name Manipulates names in the DCE namespace.
object Manages object entries in the DCE Cell Directory Service.
organization Manages organizations in the DCE Security Service regis-
try.
principal Manages principals in the DCE Security Service registry.
registry Manages the database of a DCE Security Service registry.
rpcentry Manages a server entry stored in the DCE Cell Directory
Service.
rpcgroup Manages a group entry stored in the DCE Cell Directory
Service.
rpcprofile Manages a profile entry stored in the DCE Cell Directory
Service.
schema Manages the schema information for extended registry
attributes.
secval Manages the security validation service in dced.
server Manages servers and their configuration information on
DCE hosts.
user Manages a DCE user.
utc Manipulates UTC timestamps.
uuid Manipulates (generate or compare) UUID's.
COMMON OPERATIONS
This section gives a description of operations that are common to
more than one object. Some operations presented here are implemented
in all objects, some in only a few, and some only for specific types
of objects such as containers (for instance, CDS directories).
The descriptions in the sections on individual objects may override
some of the information presented here. Usually this is only in the
form of an operation accepting more options, but other changes are
possible.
add Adds an object to a container. It is implemented for all
objects that represent containers. Returns an empty string
on success. The argument is a list of names of containers.
The required -member option is used to specify the name of
the member to be added to the containers. It's value is a
list of members to be added. If lists are specified for
both the -member option and as the argument, then each
member name is added to each container. For example it is
used to add a member to an RPC group, and is used to add an
element to an RPC profile.
catalog Returns the names of all instances of an object. It usually
takes no argument. In some cases, though, an argument
specifying a scope, such as a cellname, is optional. For
example, the principal catalog command returns a list of
all principals in the registry. Only implemented by those
objects for which this is possible. By default, fullnames
are returned. Some objects will support a -simplename
option which will return names in a shorter form (either
relative or not fully qualified). The order of the returned
list depends on the object.
create Creates a new instance of an object. Takes one argument
which a list of names of instances to be created. Returns
an empty string on success. Returns an error if the object
already exists. For some objects this command takes a
-attribute option or a set of attribute options to create
attributes on the new object.
delete Destroys an instance of the object. Takes one argument which
a list of names of instances to be deleted. Returns an empty
string on success. If the object does not exist, an error is
returned.
help Returns help information on the object as described in the
Help System section. Takes an argument which may be an
operation supported by the object or the -verbose option
to return more information.
list Returns a list of the names of all the members of a
container. This operation returns names of members, never
any other (e.g., attribute) information about the members.
It is implemented on all objects that represent containers.
The argument is a list of names of containers to return the
children of. The order of the returned list is dependent
on the object. If more than one container name is given as
an argument, all the member names are returned in one list.
modify This operation is used to modify attributes, policies,
counters, or any other information in an object. This fact
means that all attributes, policies, counters, etc. in any
one object must have unique names. It will not be available
to all objects. Returns an empty string on success. The
argument is a list of names of objects to modify. All
objects are modified in the same way. The specific
modification is described by the use of one or more of the
-add, -remove, or -change options. If more than one is used,
then the whole modify operation is treated atomically in
that either it all will work, or none of it will. The order
of the options does not matter. Each option may only be used
once per command invocation. If more then one attribute is
to be added, then the value of that option should be an
attribute list.
-add Used to add an attribute to an object or merely to
add values to an existing attribute. The value of
this option is an attribute list.
-remove Used to remove an entire attribute or merely some
values from an object. The value of this option
is an attribute list.
-change Used to change one attribute value to another.
The value of this option is an attribute list.
operations
Returns a list of the operations supported by the object.
It takes no arguments, and always returns a Tcl list
suitable for use in a foreach statement. The order of the
elements is alphabetical with the exception that help and
operations are listed last. If the user wants them sorted
they should use:
lsort [object operations]
remove Removes an object from a container. It is implemented for
all objects that represent containers. The argument is a
list of names of containers. The remove command requires
one option, -member, which is used to specify the name of
the member to be removed from the container. The value is
a list of names of members of the containers. If the value
of this option and the argument to the command are both
lists, then each listed member is removed from each
specified container. If the members do not exist an error
is returned.
rename This operation changes the name of a specified object. The
argument is a single name of an object to be renamed, i.e.,
it cannot be a list. Takes a required -to option with a
value of the new name. The value may not be a list.
Returns an empty string on success.
show Returns information about an object instance. Objects can
have various types of information such as attributes,
counters, policies, etc. The show command is used to return
any of this information. Options are passed to the command
to specify what information is to be returned. Most of the
options used for this purpose are in the plural form such as
-all, -attributes, -counters, and -members. Unlike the list
command which returns information about the members of a
container, the show command only looks at the named object
instance. If it is a container, it does not return
information about the members, only the container itself.
This command takes one argument which is a list of names of
instances to be shown.
synchronize
Tells the instance to synchronize with any replicas of
itself. In CDS terminology this will perform a skulk on
a directory, in DTS it will cause a server to synchronize.
It is to be implemented for all objects that support
replication. Returns an empty string on success. The
argument is a list of instance names to synchronize. If
more than one instance name is given then each instance
synchronizes, there is no relationship such as synchronize
with each other, as this doesn't make sense for many
objects.
MISCELLANEOUS COMMANDS
The dcecp program includes a set of commands you can use for
performing miscellaneous operations.
dcecp_initInterp
This command will initialize a base Tcl interpreter with
all the dcecp commands.
errtext Takes a DCE status code as an argument and returns the text
of the associated message as found in the message catalogs.
The argument can be in decimal, octal (leading 0), or
hexadecimal (leading 0x) notation.
expand Takes a DCE name as an argument and returns the canonical
form of the name.
login Creates a new login context to be used for the rest of the
dcecp session. Sets convenience variables _c and _u to the
cell name and principal name of the principal that issued
the login command. Convenience variables are discussed in
a separate section of this reference page. Login contexts
are stacked. Takes an account name as an argument. The
password is prompted for and not echoed to the screen.
Also takes the -password option to enter a password.
logout Logs you out of the current login context as established
with a previous login command. Only contexts created with
dcecp's login can be logged out of. Trying to logout of
an inherited context results in an error. Leaving dcecp
will do a logout for all contexts created in the session.
quit Exits from dcecp. A synonym of the Tcl builtin command
exit.
resolve Takes a partial string binding and returns a fully bound
string binding. Takes a require -interface option and an
optional -object option with an interface identifier as an
argument to provide enough information for the mapping to
occur.
shell Spawns a subprocess to execute an OpenVMS command for the
user. When the command terminates, control is returned to
dcecp. If called with arguments, they are passed to the
subprocess and executed. Control is returned upon
completion. Always returns an emptry string, though an
error exception is generated if the subprocess exits
abnormally.
COMMAND PROCESSING
The dcecp control program supports the Tcl built-in commands as well
as its own commands. If a command name is unknown to dcecp, it is
passed to the unknown command and dcecp evaluates it using the
following algorithm:
+ If the command is found in a dcecp script file, dcecp executes
the command
+ If the command exists as an executable OpenVMS program, dcecp
executes the command. Therefore, you can invoke any OpenVMS
command from the dcecp prompt (for example, DIRECTORY).
Because you don't leave dcecp, you don't lose any context you
have established.
+ If you have invoked the command at the top level of the dcecp
shell and the command is a unique abbreviation for another
command, dcecp invokes the command.
ABBREVIATIONS
dcecp makes use of two mechanisms to allow all object names, operation
names, and options to be abbreviated to the shortest unique string in
interactive commands.
The first mechanism relies on the unknown command whose behavior is
described previously in the Command Processing section of this reference
page.
The second mechanism used for abbreviations is built-in to the
individual dcecp commands themselves. This allows the operation name
to be abbreviated to the shortest unique operation supported for an
object, and the options to be abbreviated to the shortest unique
string representing an option supported by an object and operation.
For example, consider the directory create operation:
directory create /.:/admin/printers/ascii -replica -clearinghouse SFO_CH
In the abbreviated form, the same operation can be entered as:
dir cre /.:/admin/printers/ascii -r -c SFO_CH
Although abbreviating commands is a good way to save typing in
interactive commands, abbreviations are not recommended for use in
scripts. New procedures in scripts can cause abbreviations to become
ambiguous. Furthermore, abbreviations aren't always portable. When
scripts move to other machines, some definitions may be left behind
so scripts won't work correctly. Always spell out complete names in
scripts.
SYNTAX
The dcecp commands have a default word order which is object operation.
This order facilitates adding new objects because new objects can
simply be added along with their operations.
You can configure dcecp to accept commands ordered as operation object
by loading a script called verb-object.dcecp. Users who have access to
the operation object order continue to have access to the object
operation order. You can load the script for all users on a host by
including the following line in the system's init.dcecp file:
source verb-object.dcecp
You can configure operation object for individual users by including
the line in that user's .dcecprc file.
ATTRIBUTE LISTS
Many of the commands need to specify attributes to operate upon. For
example, the modify command allows attributes to be changed and the
create command often allows attributes to be created along with the
object. In all cases, you can use an attribute list to specify the
attributes and their values. This makes passing information from one
command to another very easy. For example, an ACL copy operation could
be written as follows:
# copy acl name1 to acl name2
# no error checking
proc acl_copy {name1 name2} {
acl replace $name2 -acl [acl show $name1]
}
ATTRIBUTE OPTIONS
While attribute lists are useful for writing scripts, they are often
not user-friendly. For those objects that have a fixed list of
attributes (for instance, principal and dts, but not object),
wherever an attribute list is allowed, options for each attribute
that are named the same as the attribute are allowed followed by
their values. For example, the following are equivalent:
principal create melman -attribute {{quota 5} {uid 123}}
principal create melman -quota 5 -uid 123
LISTS OF LISTS
The dcecp control program intrepreter relies on list structures as a
way to parse command input and return command output. For instance,
the -remove option in the following example uses a list to group the
attribute and value parts of the option argument together. The
example is a command that removes some ACL's from an object called
/.:/foo:
acl modify /.:/foo -remove {user melman}
The argument to the -remove option is an ACL Entry. The ACL Entry
happens to be a list where the first element describes the ACL Type,
in this case user, and the second is the key for which user, in this
case melman. However, the -remove option may take a list of ACL
Entries, so the following is valid as well:
acl modify /.:/foo -remove {{user melman} {user salamone}}
Lists of one value that do not contain spaces, do not need braces.
The string syntax of an ACL Entry allows the type and key to be
separated by a colon (:), so the following are valid:
acl modify /.:/foo -remove user:melman
acl modify /.:/foo -remove {user:melman user:salamone}
If there is only one ACL Entry given, that is, the -remove option's
value has only one element (and that element does not contain spaces),
then braces are not needed to delimit the list. The following are all
valid, but all are examples with unnecessary braces:
acl modify /.:/foo -remove {{user melman}}
acl modify /.:/foo -remove {{{user melman}}}
acl modify /.:/foo -remove {user:melman}
acl modify /.:/foo -remove {{user:melman} {user:salamone}}
CONVENIENCE VARIABLES
All dcecp commands will set several variables on execution. The
variables will contain the name of the object operated on, the return
value of the last command, the cell name of the last object operated
on, and so on. You can substitute the value of these variables into
the next command to save typing.
Convenience variables behave just like other variables in dcecp. Thus
you can trigger variable substitution by prepending a dollar sign ($)
before the name of the variable. Alternatively, you can trigger
substitution using the set. The dcecp program ensures that the
convenience variables are set only by the program; it prevents users
from changing these variables.
The dcecp program defines the following variables:
_b Holds the name of the server bound to for the last command.
This is actually a Tcl array where the indexes are used to
identify the service. Currently there is only one defined
index: sec. The value specifies the name of a server in
whatever manner the service finds useful. This could be the
name of an RPC server entry in the namespace, or a string
binding, or the name of a cell. This variable may not be
set by the user.
_c Holds the cellname of the current principal. The login
commmand sets the cell name (_c) and principal name (_u)
convenience variables at login (see the login command).
Users can set this variable to change the current login
context. command.
_n Holds a list of the names entered to the last command.
These names are the names that the command operated on,
typically entered as the third argument. Examples follow:
dcecp> dir list /.: -simplename
hosts subsys absolut_ch cell-profile fs lan-profile sec \
sec-v1
dcecp> echo $_n
/.:
dcecp> dir create {/.:/x /.:/y}
dcecp> echo $_n
/.:/x /.:/y
_o Holds the object used in the last operation. For example,
if the last command was dir show /.:, then _o is directory.
_p Holds the parent of _n. If _n is a list, then this is a
list of the same length, where each element is the parent
of the corresponding element in _n.
_r Holds the return value of the last executed command.
_s Holds the name of the server bound to for the last command.
This is actually a Tcl array where the indexes are used to
identify the service. The currently defined indexes are:
sec, cds, dts, and aud.
The value specifies the name of a server in whatever manner
the service finds useful. This could be the name of an RPC
server entry in the namespace, or a string binding, or the
name of a cell. Users can set this variable by issuing the
set command. This lets users select which server is used.
The values of this variable (array) are treated differently
by each service. For example, the security service uses
this variable to display the registry bound to for the last
command, and is used as a default for the next registry
operation. If bound to a read-only replica and an update
is requested, dcecp will try to bind to the master registry
to perform the change. The CDS service only attempts to
communicate with the CDS server named by the variable. If
the named CDS server cannot satisfy a request for any reason,
the request fails. The auditing service and DTS uses its
variable in a similar manner to the CDS server. To contact
an audit daemon or DTS server on another host, set this
variable to identify that server.
For information about an object's use of this variable, see
the object's reference page or use the object's help -verbose
operation.
_u Holds the current principal name. The login commmand sets
the cell name (_c) and principal name (_u) convenience
variables at login (see the login command). Users can set
this variable to change the current login context. command.
ERROR HANDLING
All commands in dcecp return either a list of some information or an
empty string on success. If an error occurs, dcecp returns an error
message. The dcecp program also provides a catch command to help
scripts catch errors and invoke error handlers.
The dcecp program provides two global variables that store error
information returned from commands. The errorInfo variable contains
the stacktrace of the error messages. When errors occur dcecp
commands return one line error messages by default. If the variable
dcecp_verbose_errors is set to 1, then a stack trace as it would
appear in errorInfo is output as well.
When a dcecp command argument is a list of objects, the command
operates on multiple objects. These operations are usually performed
iteratively. If an error occurs, the command aborts at the time of
error producing an exception. Some operations will have finished
and others will not have. The operations are always performed in
the order listed, and the error message should make it clear on which
object the command failed.
HELP
The dcecp program provides several kinds of help. All return help
strings obtained from appropriate message catalogs.
To see which operations an object supports, enter an object operations
command. All dcecp objects support the operations command. An example
is:
dcecp> principal operations
catalog create delete modify rename show help operations
dcecp>
This provides simple help similar to usage messages found on many
systems. Users unsure of an operation name or if an operation is
supported by an object can use this command to find the answer. The
output is a dcecp list that could be used by other dcecp commands.
To see other information about an object, use an object's help command.
All dcecp objects have a help command which offers three kinds of
information.
+ View brief information about an object's operations using help
without arguments or options. Operations are listed in
alphabetical order, with the operations and help commands
listed last because all objects support these commands. An
example is:
dcecp> principal help
catalog Returns all the names of principals in the registry.
create Creates a DCE principal.
delete Deletes a principal from the registry.
modify Changes the information about a principal.
rename Renames the specified principal.
show Returns the attributes of a principal.
help Prints a summary of command-line options.
operations Returns a list of the valid operations for this
command.
dcecp>
+ View brief information about options supported by an operation
using help with one argument-the name of the operation. This
command returns attribute options in alphabetic order followed
by other options also in alphabetic order as well. If no
options are supported, an empty string is returned. An example
is:
dcecp> principal help create
-alias Indicates the principal name is an alias of
the uid.
-attribute Specify principal attributes in an attribute
list format.
-fullname Fullname of the principal.
-quota How many registry objects can the principal
create.
-uid User Identifier of the new principal.
-uuid Orphaned UUID to be adopted by the principal.
dcecp>
+ View a short description of a dcecp object using the help command
with the -verbose option. This command returns text explaining
what the object represents and how to use it. An example is:
dcecp> principal help -verbose
This object allows manipulation of principal information stored
in the DCE registry. The argument is a list of either relative
or fully-qualified principal names. Specify fixed attributes
using attribute options or an attribute list. Specify any
extended attributes using an attribute list. Principal operations
connect to a registry that can service the request. Specify a
particular registry by setting the _s(sec) convenience variable
to be a cell-relative or global replica name, or the binding of
the host where the replica exists. The completed operation sets
_b(sec) convenience variable to the name of the registry
contacted.
dcecp>
COMMAND LINE EDITING
You can edit a line before it is sent to dcecp by using standard OpenVMS
command line editing.
COMMAND HISTORY AND COMMAND LINE RECALL
The dcecp program includes a history facility that stores previously
entered commands. View the stored commands using the history command.
By default, the history facility stores the 20 most recent commands but
you can use a history keep command to change this as in:
dcecp> history keep 50
dcecp>
Each stored command is numbered so you can recall it using an exclamation
point (!) followed by the event number.
dcecp> !7
WHATEVER EVENT 7 WAS...
dcecp>
Recall a specific command using an exclamation point (!) followed by the
first unique characters of a previously entered command
dcecp> !dir
WHATEVER EVENT dir WAS...
dcecp>
You can also recall and revise the most recent command using the
uparrow and command line editing familiar to OpenVMS users.
dcecp> directory vreate /.:/admin/printers
<error message>
dcecp> ^vreate
dcecp> create
[ COMMAND OUTPUT ]
EXAMPLES
INVOCATIONS
The following examples show some ways to issue dcecp commands.
+ Invoke dcecp for interactive use.
$ dcecp
dcecp>
+ Invoke dcecp for a single command.
$ dcecp -c clock show
1994-04-21-19:12:42.203+00:00I-----
$
+ Invoke dcecp and run a script.
$ dcecp get_users.Tcl
$
SIMPLE OBJECT COMMANDS
dcecp> acl show -ic /.:
{unauthenticated r--t---}
{group subsys/dce/cds-admin rwdtcia}
{group subsys/dce/cds-server rwdtcia}
{any_other r--t---}
dcecp>
$ dcecp -c directory show /.:/subsys
{RPC_ClassVersion 0100}
{CDS_CTS 1994-04-14-19:26:22.539+00:00I0.000/00-00-c0-8a-df-56}
{CDS_UTS 1994-04-18-16:39:58.199+00:00I0.000/00-00-c0-8a-df-56}
{CDS_ObjectUUID 00524676-98de-1dad-9263-0000c08adf56}
{CDS_Replicas
{Clearinghouse_Uuid 000ad28c-98c2-1dad-9263-0000c08adf56}
{Clearinghouse_Name /.../brain_cell.osf.org/pmin17_ch}
{Replica_Type Master}
{Tower ncacn_ip_tcp:130.105.1.227[]}
{Tower ncadg_ip_udp:130.105.1.227[]}}
{CDS_AllUpTo 1994-04-18-22:40:35.326+00:00I0.000/00-00-c0-8a-df-56}
{CDS_Convergence medium}
{CDS_ParentPointer
{Parent_UUID 00972ee5-98c4-1dad-9263-0000c08adf56}
{Timeout
{expiration 1994-04-19-16:39:58.049}
{extension +1-00:00:00.000I0.000}}
{myname /.../brain_cell.osf.org/subsys}}
{CDS_DirectoryVersion 3.0}
{CDS_ReplicaState on}
{CDS_ReplicaType Master}
{CDS_LastSkulk 1994-04-18-22:40:35.326+00:00I0.000/00-00-c0-8a-df-56}
{CDS_LastUpdate 1994-04-18-16:39:58.199+00:00I0.000/00-00-c0-8a-df-56}
{CDS_RingPointer 000ad28c-98c2-1dad-9263-0000c08adf56}
{CDS_Epoch 0059e778-98df-1dad-9263-0000c08adf56}
{CDS_ReplicaVersion 3.0}
$
THE FOREACH LOOP
dcecp> foreach i [group list temps] {
> account modify $i temps research -expdate 6/30/95 }
ABBREVIATIONS
dcecp> clearin sh /.../brain_cell.osf.org/pmin17_ch
{CDS_CTS 1994-04-14-19:25:54.051+00:00I0.000/00-00-c0-8a-df-56}
{CDS_UTS 1994-04-14-19:31:46.020+00:00I0.000/00-00-c0-8a-df-56}
{CDS_ObjectUUID 000ad28c-98c2-1dad-9263-0000c08adf56}
{CDS_AllUpTo 1994-04-18-19:40:15.501+00:00I0.000/00-00-c0-8a-df-56}
{CDS_DirectoryVersion 3.0}
{CDS_CHName /.../brain_cell.osf.org/pmin17_ch}
{CDS_CHLastAddress
{Tower ncacn_ip_tcp:130.105.1.227[]}}
{CDS_CHLastAddress
{Tower ncadg_ip_udp:130.105.1.227[]}}
{CDS_CHState on}
{CDS_CHDirectories
{dir_uuid 00972ee5-98c4-1dad-9263-0000c08adf56}
{directory /.../brain_cell.osf.org}}
{CDS_CHDirectories
{dir_uuid 00524676-98de-1dad-9263-0000c08adf56}
{directory /.../brain_cell.osf.org/subsys}}
{CDS_CHDirectories
{dir_uuid 0013b6b8-98e0-1dad-9263-0000c08adf56}
{directory /.../brain_cell.osf.org/subsys/HP}}
{CDS_CHDirectories
{dir_uuid 00216e3e-98e1-1dad-9263-0000c08adf56}
{directory /.../brain_cell.osf.org/subsys/HP/sample-apps}}
{CDS_CHDirectories
{dir_uuid 002a91da-98e2-1dad-9263-0000c08adf56}
{directory /.../brain_cell.osf.org/subsys/dce}}
{CDS_CHDirectories
{dir_uuid 008f45f8-98e3-1dad-9263-0000c08adf56}
{directory /.../brain_cell.osf.org/subsys/dce/sec}}
{CDS_CHDirectories
{dir_uuid 008dbc60-98e4-1dad-9263-0000c08adf56}
{directory /.../brain_cell.osf.org/subsys/dce/dfs}}
{CDS_CHDirectories
{dir_uuid 00986692-98e5-1dad-9263-0000c08adf56}
{directory /.../brain_cell.osf.org/hosts}}
{CDS_CHDirectories
{dir_uuid 00152a98-98e7-1dad-9263-0000c08adf56}
{directory /.../brain_cell.osf.org/hosts/pmin17}}
{CDS_ReplicaVersion 3.0}
{CDS_NSCellname /.../brain_cell.osf.org}
dcecp>
4 – dced
NAME
dced - DCE Host daemon
SYNOPSIS
dced [-ifh] [-w route] [-b|-p|-s] [-e|prot_seq...]
OPTIONS
-h Prints the dced usage and exits.
-i Initializes the dced databases and ACLs and exits. If the
databases exist, this option displays an error. See the
list of databases in the FILES section.
-b Starts dced in bootstrap mode with the endpoint mapper
service and ACLs. This mode means it may need to wait
for other daemons such as secd and cdsd before it can
perform its own initialization.
-c Starts dced so it does not require DCE privacy encryption
for remote key table management. The default is to use
DCE privacy encryption.
-e Starts dced without the endpoint mapper service. No
protocol sequences are valid for this option.
-f Starts the dced process in the foreground. The default is
for dced to run in the background.
-p Purges the existing machine context and removes the bindings
file before starting.
-s Starts dced without the security validation service.
-w Sets the routing for serviceability.
ARGUMENTS
Establishes the serviceability routing for dced's messages.
Starts dced by using the specified RPC protocol sequence
string or strings. Possible values include ncadg_ip_udp
(for a datagram protocol) and ncacn_ip_tcp (for a
connection-based protocol). A complete list of the protocol
sequences recognized can be found in dce/ep.idl.
DESCRIPTION
The DCE Host daemon is a process that provides services for the local
host, and is also the server used by remote applications to access
these host services. The DCE Host daemon services include the
following:
Endpoint Mapper
The endpoint mapper service maintains a database called the
local endpoint map which allows DCE clients to find servers,
individual services provided by servers, and objects managed
by services on the host. The endpoint mapper service maps
interfaces, object UUIDs, and protocol sequence
registrations to server ports (endpoints). Servers register
their bindings with the local endpoint mapper, and the end-
point mapper service on each host uses the local endpoint
map to locate a compatible server for clients that do not
already know the endpoint of a compatible server.
Host Data Management
The host data management service maintains local files of
host data that include (among others) the host_name,
cell_name, cell_aliases, and a post_processors file. The
post_processors file contains program names matched with
the other host data items (UUIDs). The dced runs the program
if the corresponding host data item is changed. There may
also be host-specific data files.
Server Management
The server management service maintains data that describes
the startup configuration (srvrconf) and execution state
(srvrexec) for each server. It also has the functionality
to start or stop particular servers, and enable or disable
specific services of servers.
Security Validation
The security validation service acts as the client side of
the security server by assuring applications that the DCE
Security daemon (secd) that the host is using is legitimate.
In addition, this service logs into the local machine when
dced is invoked and automatically updates the local machine
principal's keys.
Key Table Management
The key table management service allows for remote
maintenance of server's key tables (keytab files).
The DCE Host daemon must be running before any other DCE-based servers
are started. Each DCE host must run only a single dced, and it must run
with privileges since it typically listens on privileged or reserved
network ports. Typically, dced starts each time a host boots. (A file
called SYS$MANAGER:DCE$RPC_STARTUP.COM is responsible for configuration
issues such as deleting the endpoint map database and starting dced.)
By default, the DCE Host daemon listens on one well-known port for each
RPC protocol sequence (that is, each combination of an RPC protocol and
a transport protocol) supported by the host on which it is running. A
prot_seq argument lets you limit the protocol sequences on which dced
listens.
FILES
dce$local:[var.dced]Ep.db dce$local:[var.dced]cell_aliases
dce$local:[var.dced]Hostdata.db dce$local:[var.dced]cell_name
dce$local:[var.dced]Srvrconf.db dce$local:[var.dced]host_name
dce$local:[var.dced]Srvrexec.db dce$local:[var.dced]Acl.db
dce$local:[var.dced]Keytab.db dce$local:[krb5]v5srvtab
dce$local:[var.dced]Xattrschema.db dce$local:[000000]dce_cf.db
dce$local:[var.dced]post_processors
RELATED INFORMATION
COMMANDS: hostdata, endpoint, server, secval, keytab, attribute
LIBRARY CALLS: dce_server*, dced_*, rpc_mgmt_ep*
BOOKS: OSF DCE Application Development Guide.
5 – getcellname
NAME
getcellname - Gets the primary name of the cell
SYNOPSIS
getcellname
DESCRIPTION
The getcellname command prints the primary name of the local cell to
standard output. If the command fails, it prints an error message to
standard error.
FILES
dce$local[000000]dce_cf.db
The local DCE configuration database.
RELATED INFORMATION
FUNCTIONS: dce_cf_get_cell_name