Configuration Options

This appendix explains the various methods you can use to configure your X station. Topics include:

See also Remote Configuration Parameter Reference for a complete listing of all remote configuration parameters with explanations, defaults, and valid values.

Local versus Remote Configuration

You can configure your HP X stations remotely (from the host) or locally (from each X station's configuration screens).

For most customers, the best way to make users productive quickly is to configure the X stations from the host using either BOOTP or DHCP, and remote configuration.

However, other customers find that the flexibility to change configuration values from the X station's configuration screens is an important feature. The benefits of configuring remotely and locally are listed below:

Configuring from the Host

There are two important advantages to configuring from the host:

Users can operate X stations without needing to configure their units
You can set the configuration lock function to disable access to the configuration screens ("Securing The Configuration Screens" has details).

For more information about using DHCP/BOOTP and remote configuration, refer to Configuring X Stations from the Host.

Configuring from the X Station

There are two advantages to configuring locally using the configuration screens:

The configuration screens provide quick and easy access to the X station configuration parameters. For example, you can quickly reset a parameter, such as bell volume, and click on [OK] to activate the new setting.
An advanced user can change the X station's configuration immediately, without interrupting the system administrator. (However, if the user enters improper configuration values, network operation could be disrupted.)

For details on the configuration screens, refer to Configuring X Stations from the Configuration Screens.

Configuring X Stations from the Host

The administration script (xtadm) helps you to configure your X stations remotely from the host. It automatically sets up a BOOTP file which then configures your X stations with the necessary network configuration data. For many users, this is all the configuration information that the X stations require.

In addition, the administration script creates a remote configuration file that contains any configuration information that is not supplied by BOOTP. This file is automatically downloaded to an X station when the X station is switched on.

When used together, BOOTP and remote configuration can configure the X station completely.

Note: If you are using an Aptrex X terminal, you can configure the X terminal remotely from the host using RARP.

The following sections provide more detail about BOOTP/DHCP and remote configuration:

Using BOOTP and DHCP

BOOTP (boot protocol) and the related DHCP (dynamic host configuration protocol) are standard protocols that can download network configuration data to an X station. The network configuration data enables the X station to communicate directly with devices on the network. This data includes the IP addresses of the X station and the computers it accesses.

Note: You can make use of DHCP if it is provided with your host software. However, a DHCP daemon is not provided with the HP ENWARE X station software. DHCP is not supported for Token Ring networks.

You can also give an X station its network configuration data by typing the network data in the configuration screens and rebooting the X station. However, using BOOTP or DHCP to download the data has two major benefits:

The network configuration data for the entire network is in one place (in bootptab) and is easy to maintain.
Once the bootptab file has been set up, the user of a new X station does not have to configure it before using it. Configuration data downloads automatically when the X station is switched on.

Caution: If the General Network configuration screen is set to "Network Parameters Download From Host [BOOTP]" or "Network Parameters Download From Host [DHCP]", DHCP or BOOTP overwrites the network parameters in the configuration screens with parameters stored in the bootptab file every time the X station is switched on. To prevent this from happening, change the configuration to "Network Parameters [from Fields Below]".

How BOOTP and DHCP Work...

If the X station is configured to use BOOTP or DHCP, switching the X station on causes it to broadcast a boot request on its subnet.

Factory default configuration methods are as follows:

X Station: Factory Default
HP 700/RX: BOOTP
ENTRIA/Aptrex: DHCP
ENVIZEX `a', `i' series: BOOTP
ENVIZEX `p' series: DHCP

All HP X stations that default to DHCP continue to boot from hosts that run BOOTP. When the X station sends a boot request, that request contains the X station's Ethernet address. What happens next depends on which process--BOOTP or DHCP--is running on the host.

If BOOTP Is Running on the Host:

If BOOTP is running, any boot request causes bootpd to look through bootptab for the Ethernet address of the X station.

If a match is found, the network configuration data for the requesting X station is extracted from bootptab and sent as a packet over the network.

If no match is found, the X station fails to boot.

If DHCP Is Running on the Host:

If DHCP is running, you need to be aware of whether the X terminal is configured to use DHCP or BOOTP:

If DHCP is running and the X station is configured to use BOOTP, dhcpd operates just as bootpd does.
If DHCP is running and the X station is configured to use DHCP, dhcpd looks through bootptab for the Ethernet address of the X station.
If no match is found, dhcpd searches for a resource file that contains IP addresses and terminal names you have made available. If dhcpd can find an available IP address and terminal name, it assigns them to the X terminal, which allows the X terminal to boot. Otherwise the X terminal fails to boot.
If a match is found, dhcpd operates as bootpd does.

Modifying the Remote Configuration File

If you need to set all of your X stations to a non-standard configuration, (as would be the case if all of your users had non-USASCII PS/2 keyboards, for example), before you use xtadm (or an equivalent process) you should edit sample.cfg so that each remote configuration file created from this master file specifies the proper parameter value. These changes may include:

"Changing The Default Font Path"
"Setting Up A Non-Standard Keyboard"
"Speeding Up The Boot Process"
"Securing The Configuration Screens"
"Access Control"
"Client Authorization"
"Using Remote Configuration."

To get a list of all remote configuration parameters and their corresponding options, issue the command:
remsh terminal_name get config

On Sun systems, the command is rsh instead of remsh.

Note: All configuration parameters are listed in Remote Configuration Parameter Reference with explanations, defaults, and valid values.

Changing the Default Font Path

If you chose not to install the HP X station fonts, you need to change the X station's font path to use the workstation's fonts. To change the default font path:

As superuser, edit:
basepath/config/sample.cfg
Find the line that has the Font Path keyword and remove the comment character (#).

Change the font path to access the workstation fonts. For example:

Font Path=/usr/lib/X11/fonts/hp_roman8/75dpi/,/usr/lib/X11/fonts/misc/,

Note: The font path cannot contain remote-configuration style variables (such as $(BasePath)).

Setting Up a Non-Standard Keyboard

To change the master remote configuration file so that it sets X stations to have a new keyboard language:

As superuser, edit:
basepath/config/sample.cfg
Find the line that has the PS/2 Keyboard Language keyword and remove the comment character (#).

Change the line:

PS/2 Keyboard Language   =  USASCII

to the appropriate keyboard language. For example:

PS/2 Keyboard Language   =  Deutsch

Change the line that has the Save Config keyword to remove the comment character (#) in column 1, if present. Make the line similar to the following:
```
Save Config
```
Save the changed file.

After the X station downloads the remote configuration file, the keyboard will be fully functional.

Speeding Up the Boot Process

Lines in the remote configuration file direct the X station to load files specified by the following parameters: SNMPFile and XpointerkeysFile.

If your X stations do not require these files, define these parameters to "" as follows. Change:

XpointerkeysFile  = $(SearchPath)/config/$(Personality)Xpointerkeys

to:

XpointerkeysFile  = ""

Securing the Configuration Screens

If you need to restrict users from accessing specific configuration screens, you can set the configuration access parameter in the remote configuration file. There are four levels of configuration lock:

Unlocked: (Default). The configuration screens are completely accessible, unless the configuration Password has been set. When a user specifies a configuration password, only people who know the password can view or change the X station's significant configuration parameters.
Pref+Stats+Log: Users can access only the [Preferences] screen and the screens available through the [Diagnostics] configuration menu.
Stats + Log: Users can access only the screens available through the [Diagnostics] configuration menu.
Locked: There is no configuration screen access and the mouse and keyboard are disabled during bootup. However, you can use a local terminal emulator to display error messages that would otherwise go to the Log screen. For details about using a local terminal emulator for this purpose, refer to Why Use Local Clients?.

When configuration access is locked, remote configuration and BOOTP are automatically enabled.

Securing X Windows Access

The X server that runs on HP X stations supports two types of security: access control and client authorization. Refer to:

The X server uses these security features when an X client is negotiating a connection with the X server. These two forms of security restrict which clients may connect but not what these clients may do once connected. Changes in access control and client authorization will not have any effect on clients which are already connected.

Access Control

Access control allows the X server to discriminate between X clients on the basis of which host they are running on. The X server manages the "access control list" which consists of a list of IP addresses. Only clients running on any of these machines will be allowed to connect.

The access control list is managed locally on the X station. Initially, the access control list contains only the IP address(es) of the X terminal itself, including localhost. When the user logs in with an XDM or telnet session, that host will also be added.

Additionally, the file pointed to by the configuration variable Xhosts File may contain host names or IP addresses which will also be added automatically to the access control list. The X station reads this file when it boots up.

Client Authorization

Client authorization allows the X server to restrict access to those clients that produce an acceptable 128-bit magic cookie or key. This method of authorization is also referred to as MIT-MAGIC-COOKIE-1 authorization.

When a user logs in via a display manager such as XDM, dtlogin, or vuelogin, some things happen automatically and transparently. The display manager generates a random 128-bit key which it passes to the X server via the XDMCP protocol. The display manager also adds this key to the user's .Xauthority file. If a file other than $HOME/.Xauthority is being used, the display manager will set the environment variable XAUTHORITY to point to it.

The .Xauthority file is essentially a database. Each record consists of a display name, the authorization protocol to use, and the actual key. This file is not in a readable format - use the 'xauth' utility described below to view or manipulate it. The permissions on the .Xauthority file normally allow reading and writing only by the user, since this is how the key is protected.

When you run an X client, it looks for the display name in the authority file pointed to by the XAUTHORITY environment variable (and defaults to $HOME/.Xauthority). If a key is found for the display it wants to connect to, the client will use that key as part of the connection negotiation. If a client cannot read the authority file, it does not have the user's permission to access the display.

Note: Some X clients that were compiled with pre-X11R4 libraries may not be aware of the client authorization security scheme, will not search for the key, and will therefore be denied access. Client authorization cannot be enabled if these clients are used.

Additionally, when the terminal boots up, it reads the file pointed to by the configuration variable "Xauthority File". Any magic cookies in this file will allow a client to access the X server. This file is inherently a public file (readable by tftp), so the use of this feature should be restricted to testing or public X terminals. General users should also be prevented from writing or creating these files. The format of this file is the same as the .Xauthority which is created in the user's home directory.

The X11 distribution includes a utility called "xauth" which allows you to modify the contents of the authorization database. For example, "xauth l" lists the contents of the .Xauthority file in human-readable form. See "man xauth" for a complete description of this utility.

How Access Control and Client Authorization Work Together

If more than one user may be running clients on a given host and you wish to limit access to a display to a particular user, use client authorization rather than the access control list. The following examples describe how client authorization and the access control list work together.

If you enable Client authorization, the X client must produce the correct key to be allowed to connect, regardless of which host it is running on and whether or not access control is enabled.
If you disable Client authorization and enable access control, the client will be allowed to connect if it is running on one of the hosts in the access control list OR the client produces an acceptable key. This configuration is useful, for example, if the access control list contains only the X terminal itself, thereby allowing local clients to run which do not have access to the user's home directory.
If you disable both client authorization and access control, all clients are allowed to connect.

If an X client cannot connect to an X server because of security reasons, the client will likely print a message like the following:

Xlib:  connection to "terminal:0.0" refused by server
        Xlib:  Client is not authorized to connect to Server
        Error: Can't open display: terminal:0

In addition, the X terminal log will contain a message similar to the following:

AUDIT: Tue May  9 13:41:54 1995: Xserver: client 17 rejected
        from IP 15.4.2.41 port 14090

Modifying the Access Control List

To allow a new host to access your X station for this X session, use xhost on the login server as follows:
xhost +ipaddress
A hostname can be used in ipaddress.
To allow a new host "permanent" access to your X station, add it to your terminalname.hosts file.
To deny a host access to your X station for this X session, use:
xhost -ipaddress
To deny a host access to your X station "permanently," remove it from your terminalname.hosts file.

Sharing Windows when Client Authorize Is Enabled

If you want to permit another user to send a window to your display, you need access to the user's .Xauthority file. Here is one way to permit such access for the duration of a session:

You (the receiver) type from your home directory:
chmod 644 .Xauthority
The sender types from the home directory:
xauth merge receiver_home_dir/.Xauthority
You (the receiver) should then restore the original read/write permissions on the .Xauthority file by typing:
chmod 0600 .Xauthority

Because the X session manager sets a new magic cookie for the X server each time a user starts a new X session, users wishing to share windows need either to repeat the sharing of .Xauthority files or not use Client Authorization.

Using Remote Configuration

You can use BOOTP/DHCP and remote configuration to configure the X station completely, and automatically. By default, at start up the X station requests that BOOTP or DHCP send the X station its network configuration information. After this has been received, the X station searches for its remote configuration file, which you can use to change any of the X station's configuration parameters.

The remote configuration file is created automatically when you install X stations using the administration script (xtadm). It copies the remote configuration file basepath/config/sample.cfg to terminalname.cfg for each X station you install. If you need to customize the remote configuration file, you should do so before the master file gets copied for each X station.

For more information, refer to Modifying the Remote Configuration File. For specific values and syntax of remote configuration parameters, refer to Remote Configuration Parameter Reference.

Caution: If remote configuration is enabled, any configuration parameters set in the X station's terminalname.cfg file overwrite the X station's configuration at every power on. If you change the X station's configuration from the configuration screens, you may need to disable Remote Configuration. To do so:

Press and hold [F12] to access the configuration screens.
Select [Network]
Select [General]
Set the Network Parameters field to: From Fields Below
Select the [Terminal] configuration screen
Click beside the Remote Config field to disable the download
Click on [OK].

By default, remote configuration is re-enabled by BOOTP or DHCP each time you power up the X station.

Using the Variables in the Remote Configuration File

The default remote configuration file contains variables of the form $(variablename). Variables can include other variables--the server expands each variable until it derives a unique parameter. Alternative values for variables are specified as comma-separated lists.

The X server supports the following variables:

$(BasePath): All downloadable X station files have this path in common. Normally it is: /usr/lib/X11/700X. For HP-UX 10.x systems, this path is: /opt/hpxt/enware/xthome.
$(FileServerList): This is the list of potential file servers and their access mechanisms. Elements are separated by commas. For example: /nfs/fileserver1,/tftp/fileserver2
$(SearchPath): This is a variable that allows you to search for files on the current host and on other hosts you specify. Thus, for example, setting $(SearchPath) to $(BasePath), $(FileServerList)$(BasePath) could cause it to expand to /usr/lib/X11/700X and /nfs/fileserver/usr/lib/X11/700X.
$(LANG): This is the language of the X station.
$(TerminalName): This is the variable form of the Terminal Name parameter.
$(NodeNameList): This is a list of the terminal names and IP addresses for each of the X terminal's network interfaces. Entries are separated by commas.
$(Personality): By default, this is the $(NodeNameList) variable followed by a period and by nothing: $(NodeNameList).,, In the case of $(Personality)snmpdrc for an X terminal that has an IP address of 125.4.5.6 and a terminal name of xterm1, this expands to xterm1.snmpdrc, 125.4.5.6.snmpdrc, and snmpdrc
$(RGBClass): This names a version of the rgb.txt file that has been customized to work with 98xxx or A10xx monitors. The X server determines the correct value automatically.

Example: How the X Server Reads a Parameter's Variables

Assume that your X terminal is configured as follows:

The X terminal's terminal name is xterm16
The X terminal's IP address is 125.4.5.6
The primary file server is fileserver1 and its access mechanism is nfs
The first alternative file server is fileserver2 and its access mechanism is tftp
The SearchPath and Personality variables are set as shown above and the remote configuration file contains the following parameter:
```
ModulesFile  = $(SearchPath)/bin/$(Personality)modules.ld
```

The X terminal loads the first available modules.ld file from the following list:

/usr/lib/X11/700X/bin/xterm16.modules.ld
/usr/lib/X11/700X/bin/125.4.5.6.modules.ld
/usr/lib/X11/700X/bin/modules.ld
/nfs/fileserver1/usr/lib/X11/700X/bin/xterm16.modules.ld
/nfs/fileserver1/usr/lib/X11/700X/bin/125.4.5.6.modules.ld
/nfs/fileserver1/usr/lib/X11/700X/bin/modules.ld
/tftp/fileserver2/usr/lib/X11/700X/bin/xterm16.modules.ld
/tftp/fileserver2/usr/lib/X11/700X/bin/125.4.5.6.modules.ld
/tftp/fileserver2/usr/lib/X11/700X/bin/modules.ld

For HP-UX 10.x, all occurrences of /usr/lib/X11/700X should be replaced by /opt/hpxt/enware/xthome.

Configuring X Stations from the Configuration Screens

To configure an X station locally, you can enter all the X station's network configuration data on the configuration screens and then re-boot the X station. You can also use the configuration screens with BOOTP/DHCP and remote configuration to make configuration adjustments.

Using the Configuration Screens

To access the configuration screens, press and hold [F12]. (If a login screen is being displayed, you need to log in before you can access the configuration screens.)

To learn how to prevent access to the configuration screens, see "securing The Configuration Screens."

Note: On 46021A HP-HIL keyboards, the notation [F12] refers to the fourth unlabeled key above the numeric keypad. On the LK201-layout keyboard, the notation [F12] refers to the key labeled [F3].

To select a screen button or field, click the left mouse button on it.

If you need information on a configuration parameter, move the cursor to that field and click the right mouse button to make a help window appear. Click a mouse button to make the window disappear. (This feature requires that [Click for Help] is enabled on the [Preferences] configuration screen.)

Note that the online help is available only after the X station has downloaded the server file from the host.

Saving and Recalling Configuration Values

[OK] saves the choices displayed on the configuration screens.
[Cancel] removes the configuration screens without saving any changes.
[Factory Defaults] sets all parameters on all configuration screens to their factory defaults.

Note: In addition to the changes you make to the configuration screens, there are two configuration processes that can set or reset values:

DHCP and BOOTP, if enabled by setting "Network Parameters" to [Download from Host (BOOTP)], or [Download from Host (DHCP)], will overwrite your X station's network configuration parameters and enable remote configuration. See Using BOOTP and DHCP.
Remote configuration, if enabled, can overwrite any of your X station's configuration parameters. See Using Remote Configuration.

You can also use the configuration screens to monitor performance and diagnose some types of problems. Refer to Diagnosing Problems from the Configuration Screens for details.

Remsh Reference

HP X stations can provide you with remsh access (on Sun systems, rsh access) to their configuration, current status, and operation.

If this capability presents a security risk in your system, you can control remsh access by setting a remote configuration parameter. See Controlling remsh Access for details.

Supported remsh Commands describes the supported remsh commands.

Controlling remsh Access

Remsh commands require that a user have access privileges set for a particular X station. You can set the following levels of privileges by remote configuration:

x: The user can start, query, or kill processes on the X station.
w: The user can write configuration changes to the X station.
r: The user can read configuration and statistics information from the X station.
*: Equivalent to rwx.
blank: The user has no access to the X station's remsh services.

To control remsh access, use the remote configuration parameter Remsh Access. The syntax is:

Remsh Access  = <host name>:<user name>:<r|w|x|*| >, ...

where the definition is a comma-separated list. The default is Remsh Access = *:*:rx

Supported remsh Commands

HP X stations support remsh commands using the following syntax:
remsh terminalname command [parameters]

For example, if your X station has the terminal name hpxterm1, the command to list the processes running on your X station is:

remsh hpxterm1 ps

For a listing of all commands that get information from the terminal, type:
remsh terminalname get help

Commands Requiring x Privileges:

local_client client_parameters: executes the specified local client. For example:
remsh xterm1 get log
ps: lists the processes running on the X station.
kill pid: terminates the specified local client.

Commands Requiring wx Privileges:

reset: resets the X server, terminating the current session.
reboot: reboots the X station.

Commands Requiring w Privileges:

putlog string: writes string to the X station's log screen.
reconfig: forces the X station to re-read its remote configuration file.

Commands Requiring r Privileges:

ls

lists the X station's devices.

cat file

prints the specified file (or device).

get parameter

prints the specified information:

config gives the X station's current configuration
eeprom gives the X station's stored configuration
log gives the contents of the log screen
stats gets memory and network statistics
installed gets the installed configuration screen

adShow

lists the modules.ld file loaded by the X station.

env

lists the X station's environment variables.

Commands Requiring No Privileges:

ping hostname: "pings" the specified device.