Starting and Stopping DCE Host Services

Before starting dced, any underlying network services on which client/server communication depends must be available; on most UNIX systems, for example, network interfaces and routing services must be enabled. Once these transport-layer services are established, you can start dced. After dced starts, RPC-based servers can start.

The endpoint mapper listens on privileged or reserved communication ports (well-known endpoints) for client requests for service. Consequently dced must be started as a privileged user.

Part of dced (the endpoint map) contains information that clients use to locate servers on a host system. The dced program maintains a copy of this information in a database file 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 id's 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, become the superuser 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 in the OSF DCE Command Reference.

If the DCE daemon stops or exits unexpectedly, you can restart it. The restarted dced 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 the 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 do not 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 have 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 hosts without having to log into each host. In Part 1 of this book, we explained how to use dcecp in interactive mode as well as how to write dcecp scripts to manage DCE activities. It will help to understand those basics before performing administrative tasks explained in this topic or elsewhere in this document.