OSF DCE Administration Guide--Core Components

Managing DCE Host Services and Host Data
named dcelocal/var/dced/Ep.db so it won’t be lost if you stop and then restart dced for
some reason. Another database file called dcelocal/var/dced/Srvrexec.db maintains
information about servers (such as each server’s process ID) that are currently running on
the host. The information in both of these databases becomes obsolete when a system
reboots because most servers get different endpoints and different process IDs each time
they start.
You can configure dced to start each time a host boots. In some cases, the
dcelocal/etc/rc.dce file is linked to or copied to /etc/rc.dce. This way, dced is invoked
when other daemons are started. The dcelocal/etc/rc.dce file is also responsible for
deleting the Srvrexec.db and Ep.db database files before starting dced. If your system
does not automatically delete these files, you’ll have to manually delete them before
starting dced.
While you normally do not need to start dced in a shell, if you ever need to do so, log in
as root and enter the following command:
# dcelocal/bin/dced
By default, dced listens on one endpoint for each transport that is supported by the host
on which it is running. That is, if a host supports both TCP/IP and UDP/IP transports,
dced will listen on one TCP and one UDP socket for client requests. An optional protseq
argument lets you limit the transports that dced uses to the ones you specify. Intended as
a debugging capability, this feature should be used with care; if you limit transports,
clients will not be able to locate servers over the excluded transports, and servers will not
be able to register themselves in the endpoint map by using the excluded transports. For
information about the optional protseq argument, see the dced(8dce) reference page.
If the DCE daemon stops or exits unexpectedly, you can restart it. The restarted dced
process does not lose any previously registered server bindings. It simply loads the
information from the Ep.db and Srvrexec.db files. As a rule, stopping and restarting
dced is not recommended because it also stops the security validation service.
Although you should run the host services on all hosts where DCE client or server
applications run, there are some situations where you can avoid running them:
• DCE clients that don’t perform authentication
• DCE servers that don’t perform authentication and that don’t use the endpoint
mapper or other active DCE host services
Once you’ve started the DCE host services, you can perform all DCE host and server
administration tasks by using the DCE control program, dcecp. The control program
offers secure, remote access to host and server administrative functions, which means
you can manage all of your DCE Version 1.1 hosts without having to log into each host.
Part 1 of this book explained how to use dcecp in interactive mode as well as how to
write dcecp scripts to manage DCE activities. You should be acquainted with those
basics before performing administrative tasks explained in this chapter or elsewhere in
this document.
124243 Tandem Computers Incorporated 9−3