Multiple Tektronix XP/NC Terminal configuration

Francesco Prelz, Stefania Alborghetti, Mauro Campanella, Luca Carbone, Giuseppe Lo Biondo, Marcello Meroni
I.N.F.N. Milano, Computing Services
January 20th, 1998

Abstract:

A fully redundant configuration of two boot nodes to serve a large number of Tektronix XP/NC Series X-terminals via the NCBridge boot software is described here. Separate X standard fontservers provide font access and distribution on both boot nodes.

Introduction

About 70 XP-series and 10 NC-series Tektronix X-terminals are currently active at the I.N.F.N. Milano site. These have historically been booting from a single host with a hardwired configuration. The terminals become unusable when access to the single boot node is lost, since neither the application executables that the terminal needs nor the font directories can be accessed. The X-terminal configuration that is presented here provides for a fallback boot host and a fallback file access host. The following goals are achieved:

Dual (primary and fallback) boot host configuration, with a method to keep the primary and fallback distributions synchronous.
Dual (primary and fallback) file access host configuration, so that any Xterminal can keep retrieving its service applications after a failure of the primary server.
Dual font repository, so that running applications can keep accessing fonts as needed after a disruption of the primary font service.
Provision for a "first boot" configuration tree, that can be used to set and save a common configuration after the local (NVRAM) configuration in the terminal has been erased.

In addition to the above, a virtual key binding configuration that corrects a "Delete" key mapping problem for certain Motif 1.1 based applications (notably Netscape) will be described, as well as an appropriate font collection to meet the needs of an environment where the X-terminals offer service for VAX/VMS, Unix, and NT based applications, as well as Desktop Common Environment (DCE) sessions.

General Information

The main configuration file for a Tektronix boot host, xp.cnf, sits in the software distribution tree that is supplied with the terminals, namely in the following directories:

UNIX boot nodes: /(...)/tekxp/boot/xp.cnf

VMS boot nodes: TEK$XP_BOOT:XP.CNF

The only other Tektronix-supplied configuration file that needs to be edited in order to set up the configuration described in this document is the list of the font paths available to the X server. This can be found in:

UNIX boot nodes: /(...)/tekxp/boot/config/fonts.tbl
VMS boot nodes: TEK$XP_CONFIG:FONTS.TBL

These configuration files are always read from the boot host when the Xterminal boots. They do not override, however, the non-volatile RAM settings that may be stored in the terminal. New settings can be optionally saved back into NVRAM by asserting the save_current_settings directive in xp.cnf.

Dual boot host

The following section of the xp.cnf file must be configured and saved into NVRAM in order to support a secondary boot host that is contacted when the primary host cannot be reached. The terminal will try to access the primary server upon boot, then give up after about a minute and attempt accessing the secondary server (primary.domain and secondary.domain should obviously be replaced with the correct node names). The last section of this document describes a set of shell scripts that automate the configuration of xp.cnf.

##***** Boot Configuration *****
##
##  Note that boot_host_name only accepts TCP/IP names and addresses.
##       When boot_method is MOP, the MOP broadcast protocol is used
##       to determine the host.
##
boot_method             TFTP            #[TFTP | NFS [rsize] | MOP | ROM]
#                                       # rsize in the range 128 to 8192
boot_host_name  "primary.domain"           #[ |  |
 | ]
select FAMILY=XP200 boot_path   "(...)/tekxp/boot/os.350" #[  ]
select FAMILY=XP300 boot_path   "(...)/tekxp/boot/os.350" #[  ]
select FAMILY=XP350 boot_path   "(...)/tekxp/boot/os.350" #[  ]
select FAMILY=NC200 boot_path   "(...)/tekxp/boot/os.500" #[  ]
#
boot_method_2           TFTP            #[TFTP | NFS [rsize] | MOP | ROM]
#                                       # rsize in the range 128 to 8192
boot_host_name_2 "secondary.domain"     #[ |  |  | ]
select FAMILY=XP200 boot_path_2   "(...)/tekxp/boot/os.350" #[  ]
select FAMILY=XP300 boot_path_2   "(...)/tekxp/boot/os.350" #[  ]
select FAMILY=XP350 boot_path_2   "(...)/tekxp/boot/os.350" #[  ]
select FAMILY=NC200 boot_path_2   "(...)/tekxp/boot/os.500" #[  ]
#
determine_address_from  NVRAM           #[NETWORK | NVRAM]
boot_delay              DISABLED        #[DISABLED | RANDOM | ]
#                                       # seconds in the range 1 to 3600
#
# verbose_boot_msg      ENABLED         #[ENABLED | DISABLED]
#

The boot_delay parameter can be set to RANDOM when it is expected that a very large number of terminals may reboot at the same time.

Dual file access host

Here is the xp.cnf configuration that should ensure that the X-terminals can access their applications as needed if either server disappears from the network. Font access (and consequently application startup) is slightly slower when the primary server is not reachable. (primary.domain and secondary.domain should obviously be replaced with the correct node names). The last section of this document (reference) describes a set of scripts that automate the configuration of xp.cnf:

##***** File Host Configuration *****
##
## Note: When file_access is set to NFS the file_host_name command is used
##       to set the server mount point and the file_path command is used to
##       set the local (client) mount path. When file_access is set to SXp
##       the file_host_name has no meaning.
##
file_access_1           TFTP                    #[OFF | NFS | TFTP | DAP | SXp]
file_host_name_1        "primary.domain"        #[ |  |
#                                               #  |
#                                               # TDEnet nodename>]
file_path_1           "(...)/tekxp/boot/config"# 
#
file_access_2           TFTP                    #[OFF | NFS | TFTP | DAP | SXp]
file_host_name_2        "secondary.domain"      #[ | ]
#                                               #  |
#                                               # TDEnet nodename>]
file_path_2           "(...)/tekxp/boot/config"# 
#

Dual fontserver

In order for the X terminals to fully redundantly access fonts as needed, a pair of separate, standard X fontservers has to be set up. Each fontserver has to be configured with the other fontserver in its "alternate fontserver" list. The reason for this is that once the X terminals gain access to a given font, either via an accessible directory or a fontserver, they always try to access that particular font in the same location, even if that location becomes unaccessible due to a host or network failure.

Here's an example fonts.tbl configuration file. Once again, we assume that primary.domain and secondary.domain are the fully qualified names for the hosts where the font servers reside, and 7100 is the TCP port where the font server is listening for connections:

# Installed fonts
resident/
tcp/primary.domain:7100
tcp/secondary.domain:7100

The resident entry will make Tektronix native application startup somewhat quicker, since these applications always need to access the native Tektronix fonts, that are permanently loaded in the terminal.

Here is an example configuration file for the primary fontserver:

# font server configuration file
# $XConsortium: config.cpp,v 1.7 91/08/22 11:39:59 rws Exp $

clone-self = on
use-syslog = off
alternate-servers = secondary.domain:7100,primary.domain:7100
catalogue = /(...)/tekxp/boot,/(...)/tekxp/boot/fonts/decwin/75dpi,/(...)/tekxp/boot/f
onts/decwin/100dpi,/(...)/tekxp/boot/fonts/cde,/(...)/tekxp/boot/fonts/cde/75dpi,/vt
x/tekxp/boot/fonts/cde/100dpi,/(...)/tekxp/boot/fonts/75dpi,/(...)/tekxp/boot/fonts/
100dpi,/(...)/tekxp/boot/fonts/cursor16,/(...)/tekxp/boot/fonts/cursor32,/(...)/tekxp/
boot/fonts/common,/(...)/tekxp/boot/fonts/misc,/(...)/tekxp/boot/fonts/tek100dpi,/vt
x/tekxp/boot/fonts/Speedo,/(...)/tekxp/boot/fonts/Type1,/(...)/tekxp/boot/fonts/japa
nese
#
error-file = /(...)/tekxp/boot/config/fs_errors.log
# in decipoints
default-point-size = 120
default-resolutions = 75,75,100,100
renderers = libfr_Type1.so;Type1RegisterFontFileFunctions,libfr_Speedo.so;Speedo
RegisterFontFileFunctions

The catalogue directive points to an appropriate list of fonts that's able to serve the needs the user community. See the "Standard fonts" section below for more details. The alternate-servers directive instructs the fontserver to redirect font service requests to the secondary server, and to revert to the primary server in case the primary server recovers after a failure and the secondary server fails.

The secondary fontserver configuration file is quite similar, except for the actual font directory paths. Moreover, the primary and secondary entries need to be swapped in the alternate-servers directive. The setup scripts described in the "Reference" section below also help maintaining the fontserver config files.

Other `xp.cnf` configuration directives

Here is a list of miscellaneous directives that typically need to be changed from the default values in xp.cnf:

clear_table "GATEWAY"
clear_table "IP_HOST"
ip_host_table "aaa.bbb.ccc.ddd" "primary.domain"
ip_host_table "eee.fff.ggg.hhh" "secondary.domain"
gateway_table "0.0.0.0" "iii.jjj.kkk.lll"

In order to preserve basic terminal services when no access to the Domain Name Server is available, the dotted-quad IP addresses of the boot servers should be included in the local resolver table, stored in NVRAM. This is done with the ip_host_table directives above. Also, the default route configuration has to be included with the gateway_table directive, where iii.jjj.kkk.lll is the numeric IP address of the default gateway for the network.

xdmcp_connect    BROADCAST
broadcast_address aaa.bbb.ccc.255
enable_broadcasts YES

It's useful to enable the terminal to broadcast-poll the local network for hosts willing to negotiate an XDMCP connection, rather than hardwire a single XDMCP host. aaa.bbb.ccc.255 should be set to the broadcast address of the network where the terminal is physically sitting. It turns out, however, that the Xterminal software does issue the XDMCP broadcast to both this address and 255.255.255.255, thus extending the XDM negotiation to the entire local broadcast domain.

name_server_1         "dns1.domain"
name_server_2         "dns2.domain"
enable_name_service   YES
default_domain_suffix "domain"

Here a primary and a secondary Domain Name Server are chosen. The internal host table (see above) is also used in the name resolution process. The domain name that is appended by default to unqualified host names is also set here. It was found useful to gather these parameters into a single configuration file and use a set of simple shell scripts to insert them into xp.cnf (see the last section of this document).

keyboard_language NORTH_AMERICAN

This directive determines where certain application default and configuration files are read within the boot directory tree. With this configuration, such files are read from the /(...)/tekxp/boot/usascii directory.

snmp_trap_list "snmp.access.host.domain" 0x0
snmp_comm_list "0.0.0.0" public R
snmp_comm_list "snmp.access.host.domain" community RW

The above directive cause a Simple Network Management Protocol agent to be started on the X-terminal. This is useful to gain remote access to the terminal configuration and be able to remotely trigger a terminal reboot. The Management Information Base (MIB) structure is specific for the Tektronix X-terminals, and can be found in the configuration directory tree as /(...)/tekxp/mgmt/mib.txt.

start MWM  YES

This directive will start the Motif window manager upon terminal startup (there needs to be a Motif license authorization key on the terminal).

## NO   - means do not preload client.
## TEMP - means preload client but when client is through remove from system
##        memory.
## PERM - means preload client and always leave in system memory even after
##        exiting.
#
 preload  CDE           NO          # [NO|TEMP|PERM] default if authorized.
 preload  MWM           PERM        # [NO|TEMP|PERM] default if authorized.
 preload  OLWM          NO          # [NO|TEMP|PERM] default if authorized.
 preload  XPWM          NO          # [NO|TEMP|PERM]
 preload  XLOCK         NO          # [NO|TEMP|PERM]
 preload  TEKHOSTMENU   TEMP        # [NO|TEMP|PERM]
 preload  SETUP         NO          # [NO|TEMP|PERM]
 preload  LAUNCHER      TEMP        # [NO|TEMP|PERM]
 preload  AUDIO_SERVER  NO          # [NO|TEMP|PERM] default if audio present.
 preload  AUDIO_MIXER   NO          # [NO|TEMP|PERM]
 preload  AUDIO_PLAYER  NO          # [NO|TEMP|PERM]
 preload  DIGITAL_VIDEO NO          # [NO|TEMP|PERM]
 preload  ANALOG_VIDEO  NO          # [NO|TEMP|PERM]
 preload  XIEVIEW       NO          # [NO|TEMP|PERM]
 preload  TEK220        TEMP        # [NO|TEMP|PERM]
 preload  TEK340        NO          # [NO|TEMP|PERM]
 preload  TELNET        PERM        # [NO|TEMP|PERM]
 preload  CTERM         NO          # [NO|TEMP|PERM]
 preload  LLOGIN        NO          # [NO|TEMP|PERM]
 preload  TIP           NO          # [NO|TEMP|PERM]
 preload  WINDD         NO          # [NO|TEMP|PERM]

This determines what elements of the X-terminal specific software are loaded into the terminal, and whether they are permanently left in the terminal memory. The configuration above assumes that the most frequently requested services on the terminal are independent VT-220 based TELNET sessions.

vms_menu_entry        "TCPIP"    "host1.domain"     "PREF"
vms_menu_entry        "TCPIP"    "host2.domain"     "PREF"

The above entries will determine which hosts are listed in the "TCP connection to VMS hosts" window.

select IPADDR=aaa.bbb.ccc.ddd netstation_name "name"

One of these entries in the configuration file for each available terminal prevents errors in the manual assignment of terminal names. A simple program that generates these directives from Domain Name Server information was written and is described in the last section of this document.

disable_lpd_authhost    YES

No LPD server is running on the X-terminel.

telnet_exit_on_logout   NO

The TELNET window will automatically disappear after a connection is closed (this is often the expected behaviour).

restricted_setup ON
setup_password   #######
save_current_settings

These three directives finally instruct the terminal to protect the settings that were listed so far with a password (it should be entered in place of the ####### only when the terminals are first set up, see the "First boot" section below). Everything is then saved into NVRAM

Standard Fonts

The following table summarizes the font collection that was assembled in order to satisfy the needs of a user community which needs primarily to access VAX/VMS, Unix, and NT based applications, as well as run Desktop Common Environment (DCE). This collection is not meant to be exhaustive, but provides a tested common set of fonts to build on:

Font root directory	Origin	Remarks
`fonts/misc`	NCBridge distribution
`fonts/100dpi`	NCBridge distribution
`fonts/75dpi`	NCBridge distribution
`fonts/cursor16`	NCBridge distribution
`fonts/cursor32`	NCBridge distribution
`fonts/common`	NCBridge distribution
`fonts/tek100dpi`	NCBridge distribution	Lucida fonts
`fonts/Speedo`	NCBridge distribution	Bitstream Speedo fonts
`fonts/Type1`	NCBridge distribution	IBM Courier fonts
`fonts/decwin/75dpi`	Digital Equipment
`fonts/decwin/100dpi`	Digital Equipment
`fonts/decwin/vax`	Digital Equipment (VMS)	Only Terminal14/Dectech/Bold fonts
`fonts/cde`	CDE distribution	Aliases only
`fonts/cde/75dpi`	CDE distribution	Aliases only
`fonts/cde/100dpi`	CDE distribution	Aliases only
`fonts/hp_roman8`	Hewlett Packard	Needed by HP system applications

MOTIF Virtual bindings

The default MOTIF virtual bindings, as supplied by Tektronix, do not correctly map the "Backspace" key, so that it doesn't work as expected when editing text entry fields from inside MOTIF-based applications (most notably Netscape). In order to correct the problem, a .motifbind configuration file had to be added to the "national" configuration directory (typically (...)/tekxp/boot/usascii The contents of the file are the following:

       osfBackSpace   :    Delete
       osfDelete      :    BackSpace
       osfAddMode     :    Shift F8
       osfBeginLine   :    Home
       osfClear       :    Clear
       osfDown        :    Down
       osfEndLine     :    End
       osfCancel      :    Escape
       osfHelp        :    F1
       osfInsert      :    Insert
       osfLeft        :    Left
       osfMenu        :    F4
       osfMenuBar     :    F10
       osfPageDown    :    Next
       osfPageUp      :    Prior
       osfRight       :    Right
       osfSelect      :    Select
       osfUndo        :    Undo
       osfUp          :    Up

These represent the default key mappings, where the Backspace and Delete key mappings have been swapped.

Note: The .motifbind file is only read by the Motif "1.1" version, as distributed and licensed by Tektronix. According to Tektronix there appears to be no provision to change the Motif virtual bindings under Motif version 2 and later.

Terminal name assignments

The configuration file stored on the Terminal boot server(s) has to include the name to be assigned to all configured terminals. In order to avoid manual and error-prone updates of the configuration file, a procedure was developed in order to retrieve the listing of the nodename/IP address mapping for all configured X terminals from the Domain name Server. The appropriate records are selected on the base of the contents of the HINFO record in the Domain Name Server. See the "Reference" section below for more details.

Synchronous boot node distribution

In order to assure that the boot distributions on the primary and alternate X-terminal boot node are kept synchronous, a modified version of the standard UNIX rdist utility was used. The modification was required by security concerns (given the potential security holes opened by many standard vendor "r" service daemons), and involved having rdist use ssh instead of rsh.

"First boot" directory

Many settings need to be written into the X-terminal non-volatile RAM only once, upon system installation or reset to factory settings. For this reason, it is handy to have a distribution tree which is an exact mirror of the original boot tree, except for the xp.cnf file. A simple procedure which creates a symbolic link "copy" of an entire directory tree was written. This way the entire (...)/tekxp/boot tree was duplicated into a (...)/tekxp/first_boot tree, where the only real file is (...)/tekxp/first_boot/config/xp.cnf. The NVRAM host tables, the boot configuration, the setup access password (restricted_setup and setup_password directives) can thus be set in the first_boot configuration only, which will include a save_current_settings directive as the last line.

Reference section: configuration and tools in use at the INFN Milano site

A package with all of the UNIX distribution maintenance software in use at the INFN Milano site is available as http://www.mi.infn.it/xterm/nc_maint.tar.gz.

These are the build and configure instructions:

Unwind the tar file somewhere under the Tektronix software distribution tree. The tar file contains a maint directory. A good location for it is (...)/ncbridge/maint.
First of all the binary utilities need to be built. This includes the rdist utility modified to use ssh, a utility to get a list of X-terminals from the Domain Nameserver (get_xp_list) and a utility to make symbolic link copies of entire directory trees (r_ln). Make sure the secure shell (ssh) package is installed on the host, or install it if necessary (the package is available at Sunsite or its mirrors).
Make sure that the location of the ssh executable is correctly specified in the (...)maint/rdist/config/config.h include file (_PATH_REMSH macro). The default is /usr/local/bin/ssh.
Change directory to the maint directory and issue a make command. Disregard the warnings about the redefinition of _PATH_REMSH.
Edit make_xp_cnf.sh. The subnet (or subnets) that need to be scanned for xterminals have to be inserted in place of the ?.?.?. The get_xp_list program will then list all hosts in the specified subnets which have a name which starts with xt, or whose HINFO record in the Nameserver contains the substrings (case-insensitive) "X-term", "X_term", "NC" or "Network Computer". The name list obtained this way will be inserted into the xp.cnf file.
Edit defines.sh and insert the location of the primary boot host, secondary boot host, of the boot paths and fontserver hosts, as specified in the file.
Install the fonts found in the addtl_fonts directory into the (...)/tekxp/boot/fonts directory. See the appropriate section above for a brief description of these fonts. If the required font collection is different from the one listed above, the fs_conf file will need to be edited as well.
Edit and modify as needed the xp_tail.cnf and xp_head.cnf files, which are two sections of the standard xp.cnf configuration file, adapted to the dual_boot configuration. Don't change any of the "@@" macros found, since they will be replaced by the appropriate information from defines.sh.
Issue an install_xp.cnf command. This will synchronize the primary and secondary server software distribution (will create the secondary server distribution if it's not there already), and copy the final xp.cnf file into the appropriate config directory. You may want to check the final xp.cnf file by hand to make sure everything went straight.
Remember to start or restart the X font servers on the primary and secondary fontserver hosts (do a fs -config (...)/tekxp/boot/config/fs.pri & on the primary fontserver and a fs -config (...)/tekxp/boot/config/fs.sec & on the secondary fontserver.

When a change to the xp.cnf file is needed, just cd to the (...)/ncbridge/maint directory, edit the xp_head.cnf and xp_tail.cnf files, and issue a quick_xp_cnf.sh command. This will take care of building and copying the new xp.cnf on both boot hosts, keeping them synchronous. Ssh will prompt for a passphrase or password if necessary and depending on the ssh configuration. Once again, the "@@" macros should not be removed from the xp_head.cnf or xp_tail.cnf files: modify the defines.sh configuration file if necessary.

Use of `get_xp_list`

Usage: get_xp_list -[nscjb] [-f <first> -l <last>]|[-h <host>]|[3-octet subnets]

This program retrieves a list of the X-terminals in the specified subnets, using information from the hostname and the HINFO record in the Domain Nameserver. A DNS entry will be recognized as belonging to an X-terminal in the following two cases:

The hostname begins with xt.
The DNS HINFO record matches one of the following (case insensitive) strings: "x-term","x_term","NC","network computer".

There is also an option to open a remote "setup" window for each listed terminal (-s). In order to use this option, the TEK_BIN environment variable must point to the location of the Tektronix "xpsh" executable.

Here's the meanings of the individual flags:

-n Don't number each printed entry.

-s Start a remote "Setup" window for each found terminal. In order for this option to work, TEK_BIN must point to the location of the Tektronix xpsh executable.

-c Format output list so that it can be included into xp.cnf.

-j Just list the terminal hostnames.

-b Brief (TRUE or FALSE) output. Only affects the output when the -h flag is also used (see below).

-f <first> List only terminals starting with the first found.

-l <last> List only terminals up to the last found. This can be used to just display a range of terminals, using the list numbers returned by get_xp_list itself.

-h <host> Just determine whether hostname host is an X-terminal or not. This flag can also be useful as a simpler way to start a remote setup window (get_xp_list -s -h <host>)

Examples:

> get_xp_list 202.103.224 202.103.225
> get_xp_list -s xttest

Use of `r_ln`

Usage: r_ln [source tree] [destination tree]

r_ln has basically the same usage as cp -r, but it creates a tree of symbolic links instead of copying a directory tree. It is useful in order to create a "First boot" directory where those configuration options that are only necessary the first time a terminal is booted can be inserted.

Example:

> r_ln /usr/local/tekxp/boot /usr/local/tekxp/first_boot

UNIX boot nodes:	`/(...)/tekxp/boot/xp.cnf`
VMS boot nodes:	`TEK$XP_BOOT:XP.CNF`

UNIX boot nodes:	`/(...)/tekxp/boot/config/fonts.tbl`
VMS boot nodes:	`TEK$XP_CONFIG:FONTS.TBL`

`-n`	Don't number each printed entry.
`-s`	Start a remote "Setup" window for each found terminal. In order for this option to work, `TEK_BIN` must point to the location of the Tektronix `xpsh` executable.
`-c`	Format output list so that it can be included into `xp.cnf`.
`-j`	Just list the terminal hostnames.
`-b`	Brief (TRUE or FALSE) output. Only affects the output when the `-h` flag is also used (see below).
`-f <first>`	List only terminals starting with the first found.
`-l <last>`	List only terminals up to the last found. This can be used to just display a range of terminals, using the list numbers returned by `get_xp_list` itself.
`-h <host>`	Just determine whether hostname host is an X-terminal or not. This flag can also be useful as a simpler way to start a remote setup window (`get_xp_list -s -h <host>`)