# Configuring the Desktop in a Network

The desktop is designed to work well in a highly networked environment. The architecture of the desktop lets system administrators distribute computing resources throughout the network, including:

- Applications.

- Data files for applications.

- Desktop session services (desktop applications such as Login Manager and File Manager).

- Help services. Help data files can be put on a central help server.

  SAG.ClSrv.div.2
  SAG.ClSrv.div.7
  SAG.ClSrv.div.8
  SAG.ClSrv.div.18
  SAG.ClSrv.div.32

## Overview of Desktop Networking

The operating system provides a variety of networking services, including distributed file systems and remote execution. X servers provide additional networking capabilities, including access to remote displays and security services.

The desktop layers a user interface on top of these networking features. The goals of this interface and its underlying architecture are to make networked systems:

- Easier to use. Users can run applications and access data files without worrying about where in the network the applications and data are located.

- Easier to administer. The desktop provides application integration tools and networked search paths that make it easier for systems to locate remote data and applications. In addition the desktop's file-name mapping process makes it easier to administer complex networks containing numerous servers.

- Flexible. While the administration features of the desktop have been designed for certain common network situations, the desktop can accommodate many other customized network configurations.

### Types of Networked Desktop Services

Networking lets a user sitting at a particular display access various computing services distributed among other systems, such as:

- The desktop session and its applications—for example, Workspace Manager and File Manager

- Other applications

- Data files

Networking terminology uses the term
server to describe a system that provides computing services to one or more other systems. When a system receives services from a server, it is called a
client of that server.

In a complex network, a system may use services located on a number of systems throughout the network. Furthermore, a system may act as a particular type of server (for example, a session server) and may also be a client (for example, of an application server).

### Typical Network Situations

From a desktop perspective, a typical network configuration may contain some combination of these major components:

Displays | Where the X server is running
Login/Session servers | Where the desktop applications (Login Manager, Workspace Manager, etc.) run
Application servers | Where other applications run
File servers | Where data used by applications is located

One of the most common network configurations involves systems accessing an application server. SAG.ClSrv.mkr.1 illustrates a workstation that uses an application server. The X server and desktop session are running on the workstation.

#### Application servers provide services to the desktop session

Networks also frequently use
file servers to store large amounts of data. This data may be used by applications running on an application server, or by the desktop applications (for example, File Manager needs access to data files to display them in the File Manager window).

#### Files servers provide data to application servers and session servers

X terminals run the X server and obtain desktop session services from another system.

#### X terminals get session services from a session server

### Other Networking Situations

The desktop is flexible and can support more complex network configurations. This usually involves making various services, in addition to file servers, available to application servers.

#### Services required by a desktop application server can be distributed

### Summary—Types of Servers

Display | The system running the X server.
Login and session server | The system running the desktop session (Login Manager, Session Manager, Window Manager, File Manager, etc.)
Application server | A system on which an application runs. Also called the execution host.
File server | A system on which data files for applications are stored
Help server | A system on which help data files are stored
(Action) database server | A system where files containing action and data type definitions are stored
Icon server | A system on which icon files are stored

The network may include additional servers, such as a password server, mail server, video server, etc.

## General Steps for Configuring Desktop Networking

There are three general steps for configuring desktop networking:

1. Configure base operating system network services.

   These are the networking services provided by your operating system upon which the desktop depends. See SAG.ClSrv.div.8.

2. Install and configure desktop networking software and services.

   These are the services required by the desktop, regardless of the type of client or server system being set up. See SAG.ClSrv.div.18.

3. Configure the particular type of server or client.

   For example, configuring an application server requires different steps than configuring a file server. See SAG.ClSrv.div.32.

## Configuring Base Operating System Networking for the Desktop

The desktop requires the following base networking configuration:

- Users must have a login account on the session server and on each system providing desktop services to the session server. The user must have the same user ID and group ID on all client and server systems.

- Systems must have access to remote file systems containing data used by the session and other applications.

- The `lp` print spooler must be configured to access remote printers.

- `sendmail` must be configured for email services.

- X authorization must be set up.

### Providing Login Accounts to Users

This section describes the login account requirements for desktop networking.

#### Providing Login Accounts

Users must have a login account on:

- All systems providing services to the desktop, including application servers, file servers, and systems providing networked printers.

- All session servers the user may access. Usually, session servers are used with X terminals.

#### Providing Consistent User and Group IDs

UNIX users are identified by a login name and a
numeric user ID (UID). In a desktop network, the user should have the same login name and UID on all client and server systems.

UNIX users are also assigned to one or more login groups. Each group has a group name and a numeric group ID
(GID). In a desktop network, all systems should use consistent group names and group IDs.

For more information, see the `id`(1) or `id`(1m) man page.

### Configuring Distributed File System Access

The desktop uses NFS for sharing files between systems. You must identify all the file systems in your network that contain shared files and ensure that they are correctly mounted on all appropriate systems.

Typically, you must provide the following remote file access:

- The
  user's home directory must be shared by all desktop client and server systems. This is necessary because:

  - The home directory contains data files that must be accessed by applications on remote systems. For example, applications using data files frequently use the home directory as the default data file location.

  - The home directory is the default `dtspcd` authentication directory. For more information about the `dtspcd`, see SAG.ClSrv.div.25.

- If users require access to data files that are not in their home directory, these data files must be shared by all the desktop client and server systems that operate on the data files.

- The desktop installation and configuration directories (`/usr/dt` and `/etc/dt`) must be shared by all the desktop client and server systems so that all of the user's applications access the same desktop configuration files.

#### Providing a Networked Home Directory

A desktop network works most effectively when users have a single home directory that is shared among all client and server systems on the network.

A networked home directory lets users use different systems in the network without losing personal customizations and configurations. This is because personal customizations and the information required to restore the previous session are saved in subdirectories of the home directory.

A common home directory is also required by:

- The default X authorization mechanism. See SAG.ClSrv.div.17.

- The desktop subprocess control daemon, which is involved in launching remote applications, must be able to write to the user's home directory.

#### File-Name Consistency

You should configure the network so that users can access their data files from all systems using the same name. This is known as providing file-name consistency, and is usually accomplished by creating appropriate
symbolic links. For example you can configure every system so that each user's home directory is available as `/users/`login_name by creating a symbolic link to the actual mount location of the directory.

### Configuring Access to Remote Printers

The desktop uses the
`lp` print spooler for accessing local or remote printers. See the `lpadmin`(1m) man page for information on configuring the `lp` spooler.

Before attempting to print using the desktop graphical interface, you should test that you can correctly print to all printers using the
`lp` command.

It is highly recommended that you use consistent printer device names. For example, if a particular printer is known as `Postscript1` on the system to which it is directly connected, all other systems accessing the printer remotely should also use the name `Postscript1`.

### Configuring Electronic Mail

The desktop mailer uses `sendmail` for delivering mail between systems. See the
`sendmail`(1m) man page for more information on how to configure email connectivity.

Before attempting to send or receive mail from the desktop, you should test that you can correctly send and receive mail using the
`mailx` command.

### Configuring X Authorization

The desktop uses the default X mechanism for authorizing remote applications (X clients) to access a local display. The easiest way to configure this is to provide a networked home directory for each user. This ensures that the following requirements are met:

- The user must have read and write permission to the file HomeDirectory`/.Xauthority.`

- The `.Xauthority` file on an application server must contain the “magic cookie” for the display on which the application will run.

For more information, see the `X`(1) or `xauth`(1) man pages.

## 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 SAG.LogMg.mkr.6.

### 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

1. Provide the operating system network configurations required by the desktop.

   See SAG.ClSrv.mkr.6.

2. 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

   Installation and file sets may differ among vendors.

3. 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 SAG.ClSrv.div.29.

4. Install and configure the subprocess control daemon (`
   dtspcd`).

   This should happen automatically when the desktop is installed. For more information, see SAG.ClSrv.div.25.

5. 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, SAG.ClSrv.div.22.

#### 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, SAG.ClSrv.div.24.

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

##### Setting a Value for
DTMOUNTPOINT

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”

1. Edit the file `/etc/inetd.conf`:

   1. Find the `
      dtspcd` entry and add:

          -mount_point mount_point

   2. 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

2. Perform the procedure on your system that rereads `/etc/inetd.conf`. For more information, see the `inetd`(1m) man page.

3. 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 SAG.SesMg.mkr.9.

#### 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

1. Confirm that `dtspc` is properly registered in both `/etc/services` and `/etc/inetd.conf`. See the `dtspcd`(1m) man page.

2. 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 the
Calendar 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.

## Administering Application Services

This section covers specific configuration requirements for:

- Application servers and their clients

- Desktop servers that provide special services—database servers, icon servers, and help servers

It also covers networking requirements for two special configurations for networked applications:

- Remote execution hosts

- Applications running across file system mounts

### Search Path Environment Variables

The desktop uses a set of environment variables to specify the search path used to find application desktop configuration files such as the actions and data types database, help files, and icon files.

For information on how to use the search path environment variables, see SAG.Datab.div.1,'' or the `dtenvvar(5)` man page.

### Configuring an Application Server and Its Clients

In the standard application server configuration, the application server contains all the binary and configuration files associated with the application, including:

- The application executable(s)

- Standard application configuration files such as app-defaults, message catalogs, and shared libraries for that application.

- Desktop configuration files:

  - Action and data type definition files

  - Icon image files

  - Desktop help data files

#### Standard application server configuration

#### To Configure an Application Server

1. Provide the operating system network configurations required by the desktop.

   See SAG.ClSrv.mkr.6.

2. Provide the general desktop configuration required for servers.

   See SAG.ClSrv.mkr.10.

3. Install the application(s).

4. If an application does not automatically register itself, you must perform the registration procedure.

   See SAG.RegAp.mkr.1.

#### To Configure the Client of an Application Server

1. Provide the operating system network configurations required by the desktop.

   See SAG.ClSrv.mkr.6.

2. Provide the general desktop configuration required for clients.

   See SAG.ClSrv.mkr.10.

3. Add the application server to the application search path on a system-wide or personal basis:

   System-wide | Set the DTSPSYSAPPHOSTS variable in `/etc/dt/config/Xsession.d/0010.dtpaths`
   Personal | Set the DTSPUSERAPPHOSTS variable in HomeDirectory`/.dtprofile`

For example, the following line in /`etc/dt/config/Xsession.d/0010.dtpaths` adds a system with hostname `SysAAA` and `SysBBB` to the application search path:

    DTSPSYSAPPHOSTS=SysAAA:,SysBBB:

For more information about setting the application search path, see:

- SAG.Datab.div.7

- SAG.Datab.div.3

### Configuring Database, Icon, and Help Services

Usually, the action and data type definitions, icons, and help data files associated with an application are installed onto the same system as the application.

For example, consider the typical configuration of help data files:

- The help files for File Manager are usually located on the session server. The desktop finds them because the help search path automatically searches the proper locations on the session server.

- The help files for other applications are usually located on the same application server as the application. The session server finds them because modifying the application search path automatically modifies the help search path.

There may be situations in which you want to place database (actions and data types), help, or icon data elsewhere on the network. For example, if your network uses multiple session servers, you might want to create a help server on which all the help data files for desktop applications (File Manager, Style Manager, etc.) are stored. This conserves disk space because the help files do not need to be duplicated on each session server.

#### To Create a Database, Help, or Icon Server

1. Provide the operating system network configurations required by the desktop.

   See SAG.ClSrv.mkr.6.

2. Provide the general desktop configuration required for clients.

   See SAG.ClSrv.mkr.10.

3. Install the database, help, or icon files.

   The files can be located anywhere on the system. However, it may be easier to use the following locations, since these are the directories automatically searched when a system has been designated an application server.

   - Database files: `/etc/dt/appconfig/types/`language

   - Help files: `/etc/dt/appconfig/help/`language

   - Icon files: `/etc/dt/appconfig/icons/`language

   If you are setting up a database server, the actions must be written to specify where their commands (`EXEC_STRING`s) will run. See SAG.ClSrv.div.41.

#### To Configure the Session Server to Find a Database, Icon, or Help Server

1. Provide the operating system network configurations required by the desktop.

   See SAG.ClSrv.mkr.6.

2. Provide the general desktop configuration required for clients.

   See SAG.ClSrv.mkr.10.

3. Add the database, icon, or help server to the appropriate search path.

   - If you placed the data files in the locations specified in SAG.ClSrv.mkr.18 of SAG.ClSrv.mkr.17, you can modify the application search path.

   - If you placed the data files in other locations, you must modify the specific search path.

     For example, if you placed the help files in directory `/etc/dt/help` on system `SysCCC`, you would add the following line to /`etc/dt/config/Xsession.d/0010.dtpaths`:

         DTSPSYSHELP=/net/SysCCC/etc/dt/help

   For more information about setting search paths, see:

   - SAG.Datab.div.14

   - SAG.Datab.div.20

   - SAG.Datab.div.26

   - SAG.Datab.div.3

### Special Networked Application Configurations

This section describes how to configure systems to run applications:

- Elsewhere than on the system containing the action—on a remote execution host

- Locally across file system mounts

#### Specifying a Remote Execution Host

In the typical application server configuration, the action definition is located on the same system as the application executable. However,
actions can be written to execute commands on other systems. In this configuration, the system containing the application is called the
execution host.

The action definition may be located on the session server or on a system that provides action and data type services to the session server—called a
database server or database host.

Action definitions use the `EXEC_HOST` field to specify where their commands (`EXEC_STRING`s) should be run. For example, the following action definition specifies that an `xload` client be run on a system with host name `SysDDD`:

    ACTION XloadSysDDD
    { TYPE        COMMAND
     EXEC_HOST    SysDDD
     EXEC_STRING  /usr/bin/X11/xload -label SysDDD
    }

If the `
EXEC_HOST` field specifies more than one host name, then the desktop tries to execute the `EXEC_STRING` on each host in order until it finds one that can run the action. For example, the following `EXEC_HOST` field specifies that the action should first attempt to run the `EXEC_STRING` on `SysDDD`, and, failing this, try `SysEEE`.

    EXEC_HOST  SysDDD,SysEEE

If the `
EXEC_HOST` field is not set for an action, it defaults to the value `%DatabaseHost%`. The value of `%DatabaseHost%` is obtained from the database search path.

For example, suppose the database search path has been modified by adding the following line to `/etc/dt/config/Xsession.d/0010.dtpaths`:

    DTSPSYSDATABASEHOSTS=SysAAA:,/net/SysBBB/etc/dt/appconfig/types/C

`SysAAA` is specified using the host-qualified syntax—`SysAAA:`. An action definition found using this element of the search path sets the database host to `SysAAA`. However, an action found using the `/net/SysBBB`… portion of the search path sets the database host to the local system because the syntax does not include the host qualifier.

##### To Configure the Remote Execution Host

1. Provide the operating system network configurations required by the desktop.

   See SAG.ClSrv.mkr.6.

2. Provide the general desktop configuration required for servers.

   See SAG.ClSrv.mkr.10.

3. Ensure that the applications are properly installed and configured for local execution.

##### To Configure the System Containing the Action Definition

1. Provide the operating system network configurations required by the desktop.

   See SAG.ClSrv.mkr.6.

2. Provide the general desktop configuration required for servers.

   See SAG.ClSrv.mkr.10.

3. Create and install the action definitions and application groups.

   See SAG.CrAct.div.49 and SAG.CnfAM.mkr.10.

##### To Configure the Session Server

1. Provide the operating system network configurations required by the desktop.

   See SAG.ClSrv.mkr.6.

2. Provide the general desktop configuration required for clients.

   See SAG.ClSrv.mkr.10.

3. Modify the actions search path to include the database host.

   See SAG.Datab.div.14.

4. Modify the application search path to include the execution host.

   See SAG.Datab.div.7.

#### Running Applications Locally

The standard application server configuration runs applications on the application server. Sometimes it is desirable to have the application installed on a remote system but executed locally on the session server.

##### Execution across mount points

##### To Configure the Application Server

No special configuration is required.

##### To Configure the Session Server

1. Modify the application search path. Use the local absolute path to the application.

For example, you might use the following variable definition to find an application registered on `sysAAA`:

    DTSPSYSAPPHOSTS=/net/SysAAA/etc/dt/appconfig/appmanager/C

The session server must be able to access the application's configuration files, such as app-defaults, message catalogs, and shared libraries.