Configuring Desktop Clients and Servers

This section covers network configuration requirements that are specific to the desktop—that is, these capabilities are provided by the desktop rather than by the base operating system.

The section is divided into two parts:

Configuring login and session services.
Configuring services required by applications and their data. This includes application, database, icon, file, and help servers and their clients.

Configuring Login and Session Services

A login/session server is a system that supplies desktop services (Login Manager, Session Manager, File Manager, Window Manager, etc.) to a display and X server.

Typically, a session server supplies services to X terminals. However, a network configuration can be set up that concentrates session services on one or more servers that are accessed by both X terminals and workstations.

The Login Manager is the desktop component responsible for supplying login services to other displays. Once the user has logged in, the Session Manager is started for the user.

For information about configuring login/session servers and X terminals, see “Displaying a Login Screen on a Network Display”.

Configuring Input Method Servers

An Input Method Server (IMS) is launched by the dtimsstart command. dtimsstart is normally invoked automatically at Xsession startup (user login) by the script /usr/dt/config/Xsession.d/0020.dtims.

Depending on the currently selected locale, environment variables, configuration files, and command-line options, dtimsstart displays a selection window from which the user can select the IMS to use. From the selection window, the user can also request to start an IMS on a remote system. In this case, dtimsstart:

Executes the DtImsGetRemoteConf action to retrieve information about IMSs registered on the specified remote system
Lists the registered IMSs in the selection window
Executes the DtImsRunRemoteIms action to start the user-selected IMS on the remote system

When searching for IMSs on a remote system, dtimsstart retrieves only registered IMSs. To be registered on a system (local or remote), an IMS must:

Be defined in the entry file for the current locale. Each locale has its own entry file that lists the IMSs that support that locale. The location of the locale entry file is /usr/dt/config/ims/<locale_name>.
Have its own entry file on the system. The IMS entry file describes the attributes of an IMS. The attributes include the supported protocols, the name of the server on which the IMS runs, the command line options for the IMS, and an indication whether the IMS allows remote execution or not. The location of the IMS entry files is /usr/dt/config/ims/<ims_name>.

For descriptions of the file formats, with examples, refer to the dtimsstart man page.

To define the hosts on which an IMS can be found, you can configure the imServerHosts application resource. This resource (which is used by the Style Manager when identifying IMSs for user selection) contains a comma-separated list of host names. For example:

*imServerHosts: xylo,expo

Configuring Other Application-Related Services

This section covers networking requirements common to the desktop:

Application servers
Database servers
Icon servers
Help servers

To Configure Desktop Clients and Servers

Provide the operating system network configurations required by the desktop.
See “Configuring Base Operating System Networking for the Desktop”.
Install the desktop or the minimum set of files:
You must install:
- The entire Common Desktop Environment runtime file sets
- Or, these sets of files: CDE-MIN and CDE-TT
NOTE: Installation and file sets may differ among vendors.
Configure the system for the ToolTalk filename database server daemon rpc.ttdbserver.
This should happen automatically when the desktop is installed. For more information, see “Configuring the ToolTalk Database Server”.
Install and configure the subprocess control daemon (dtspcd).
This should happen automatically when the desktop is installed. For more information, see “Configuring the Subprocess Control Daemon”.
Mount all required remote data.
Data is considered "remote" when it is located on a system other than the system on which the application using the data is running.
For example:
- If an application uses data located on a file server, it must mount those files.
- If File Manager icons are located on an icon server, the session server must mount those files.
- If the network uses a help server for desktop help files, the session server and all application servers must mount the help data.
  For more information about mount points, see the next section, “Configuring the Mount Point for Remote File Systems”.

Configuring the Mount Point for Remote File Systems

When the desktop passes file names from one system to another, it must transform, or map, those file names to names that make sense to the destinition system. This mapping is necessary because a file may be mounted in different locations on the different systems, and therefore must be accessed using different names. For example the file /projects/big on sysA may be accessed as /net/sysA/projects/big on sysB.

Requirements for File-Name Mapping

To correctly perform this file-name mapping, one of the following must be true:

The mount command is used to statically mount file systems. These types of static mounts are typically configured in a file such as /etc/checklist, /etc/mnttab, or /etc/filesystems.
For file-name mapping to work correctly between systems, file system mounts must use consistent host names. If a host is known by several names (for example, aliases, or if the host has more than one LAN address that are known by different names), you must use the same name and form of the name for all mounts.
Or, the automounter is used to mount file systems at the default /net mount point.
Or, the automounter is used to mount file systems at a location other than /net and the DTMOUNTPOINT environment variable is set to indicate the mount point. See the next section, “Setting a Value forDTMOUNTPOINT”.

For information about the automounter, see the automount(1m) man page.

Setting a Value forDTMOUNTPOINT

You must set the DTMOUNTPOINT environment variable if both of the following conditions are true:

The automounter is used to mount file systems.
And, remote file systems are mounted at a location other than /net.

DTMOUNTPOINT must be set for processes, including:

The user's desktop processes that are automatically started when the user logs in, such as the Workspace Manager (dtwm) and File Manager (dtfile)
System processes such as rpc.ttdbserver and dtspcd that are started by mechanisms such as inetd
Applications that are started by the desktop on local or remote systems
Applications that are started by the user from a shell command line

To set DTMOUNTPOINT for all of these processes"

Edit the file /etc/inetd.conf:

Find the dtspcd entry and add:
-mount_point mount_point

Find the rpc.ttdbserver entry and add:

-m mount_point

For example if the automounter is being used with a mount point of /nfs, the entries in /etc/inetd.conf are:

dtspc stream tcp nowait root /usr/dt/bin/dtspcd /usr/dt/bin/dtspcd -mount_point /nfs
rpc stream tcp wait root /usr/dt/bin/rpc.ttdbserver 100083 1 rpc.ttdbserver -m /nfs

Perform the procedure on your system that rereads /etc/inetd.conf. For more information, see the inetd(1m) man page.
Set DTMOUNTPOINT such that its value is inherited by user logins.
This can be done by setting the variable in /etc/dt/config/Xsession.d. For more information on setting environment variables, see “To Set Environment Variables”.

Configuring the Subprocess Control Daemon

The desktop subprocess control (SPC) service provides client/server command execution.

The desktop subprocess control daemon (dtspcd) is used by the desktop to launch remote applications. It is an inet daemon that accepts requests from remote clients to execute commands. For more information on how to configure inet daemons, see the inetd.conf(1m) man page.

The desktop action invocation library uses the SPC service to invoke remote actions.

To Configure dtspcd

Confirm that dtspc is properly registered in both /etc/services and /etc/inetd.conf. See the dtspcd(1m) man page.
HP-UX only: Ensure that /usr/adm/inetd.sec is properly configured. See the inetd.sec(4) man page.

SPC Security

Authentication for the subprocess control service is based on file system authentication. The dtspcd must have access to an authentication directory that is also mounted by all SPC client systems.

By default the dtspcd authentication directory is the user's home directory. However, you can configure the dtspcd to use a different location by setting the -auth_dir option in the /etc/inetd.conf directory. See the dtspcd(1m) man page for more information.

Because SPC authentication is based on file system authentication, the SPC service is only as secure as your distributed file system. If you are using the desktop in a network where you do not trust the distributed file system, you may wish to disable the dtspcd. To disable the dtspcd, comment out the dtspc entry in /etc/services.

Configuring Environment Variables for Remote Execution

When the desktop uses an action to start an application on a remote system, the user's environment variables are copied to the remote system and placed in the environment of the application.

By default, some of the environment variables are altered before they are copied to the remote system. You can configure both the action invocation component and the subprocess control service of the desktop to perform additional environment variable processing before the variables are placed into the application's environment.

For more information on the default configuration and how to modify it, see the dtactionfile(4) and dtspcdenv(4) man pages.

Configuring the ToolTalk Database Server

One component of ToolTalk is the ToolTalk database server, /usr/dt/bin/rpc.ttdbserver.

The ToolTalk database server is used by the ToolTalk messaging service and for file-name mapping. It is usually registered in /etc/inetd.conf when the desktop is installed and needs no additional configuration.

For more information on the ToolTalk database server and its configuration options, see the rpc.ttdbserver(1m) man page.

Configuring the ToolTalk Message Server

The ToolTalk message server is ttsession. By default, it does not require any configuration; it is started by the Xession script during login.

See the ttsession man page for more information on the ToolTalk message server and its configuration options.

Configuring theCalendar Daemon

One component of the Calendar application is the Calendar daemon rpc.cmsd. It is usually registered in /etc/inetd.conf when the desktop is installed and needs no additional configuration.

For more information on the Calendar daemon and its configuration options, see the rpc.cmsd(1) man page.