7

X Terminals

Only a few years ago, the average UNIX site was equipped with a few expensive computers, connected to ASCII terminals on every desk. The X terminal is a newcomer in the market of UNIX hardware. Today, the rapidly-growing market of X terminals demonstrates how X11 has changed the landscape of UNIX sites.

An X terminal is as “dumb” as an ASCII terminal, in that without a host computer to connect to, it's nothing but a blank screen with a setup menu. But when properly configured, the X terminal gives the user all the functionality of a workstation without all of its cost and administrative worries.

7.1 Buying an X Terminal: What's What

Today, there are more than two dozen vendors of X terminals. X terminals are sold with a variety of screen sizes, screen depth and resolution, memory configurations, and software. If you are buying an X terminal, you'll probably want to examine recent trade magazines for evaluations of current products. (The market changes so quickly that X terminals tested for this book will undoubtedly be outdated by the time you read this.) But for background of what you're getting into, this section describes some of the areas where X terminals differ and how they should factor in your decision.^*

7.1.1 Monitors

The monitor is arguably the single most important part of the X terminal. The size, resolution, and depth of the monitor have a bigger impact on the perceived quality of the terminal than anything else. Accordingly, the type of monitor also has the biggest impact on the price of the X terminal as well.

The short story is that, when choosing the monitor for an X terminal, you will end up weighing the user's needs against how much money you have to burn. A user who spends the day in data-entry applications might be satisfied with a monochrome 15-inch monitor, but users who do desktop publishing will probably require a 19-inch grayscale or color monitor for viewing a two-page spread.

7.1.1.1 Screen Size

Common screen sizes for X terminals range from 14 inches to 20 inches, measuring the diagonal. Some users may be made happy with a 14- or 16-inch screen, but real estate will be cramped; if you can afford a 19-inch monitor, go for it. (Beware that the actual image area will be smaller than the screen dimensions imply; that is, a 19-inch screen with approximate dimensions of 15x12 inches may have an image area closer to 13.25x11 inches.)

Some X terminals support a “virtual screen,” whereby the screen image is actually larger than the screen itself. The portion of the screen that is obscured can be exposed by moving the mouse onto that area. This may be a good compromise for some users, or it may drive them crazy when the screen shifts every time they move the mouse a bit too far.

7.1.1.2 Resolution

The resolution of a screen is usually given with its dimensions in pixels. X terminal displays range from 640x480 pixels to 1280x1024 pixels. A pixel is the smallest element of the display that can be addressed. The number of pixels effectively determines how much information can be shown on your screen.

So what does the number of pixels really tell you? If you're a purist, then you're primarily interested in knowing how many dots per inch (dpi) there are. The best way of finding out the dpi is to ask the X terminal manufacturer. You can try to get a reasonable approximation by comparing the number of pixels to the dimensions of the screen image, but you'll have to measure the actual dimensions of the image (since the actual image is smaller than the screen size).

To get an idea of what sort of resolutions should be expected, our monochrome 19-inch NCD terminals have 1280x1024 pixels for approximately 100x100 dots per inch. Our monochrome 14-inch NCD terminals have 1024x1024 pixels for 106x106 dots per inch. The xdpyinfo client can be used to learn the dimensions and dots per inch for any server you have network access to. Since xdpyinfo requests this information from the server itself, the numbers it reports are only as accurate as the numbers advertised by the vendor.

Beware that for color terminals, you should concern yourself with, the dot pitch of the monitor as well as the resolution. The dot pitch is the distance between the dots projected by the color guns. If the resolution of the monitor tries to display more pixels than you have dots on the screen, the picture will be fuzzy and cause eye-strain.

Note that the higher the resolution, the more traffic over the network (since higher resolution means more pixels being drawn over the network) and the more memory you'll need for reasonable performance. Low-end color and grayscale displays tend to have lower resolution than monochrome displays, to cut down on required memory (and thus cost).

7.1.1.3 Depth

The depth of an X terminal is determined by the number of bits per pixel it supports for color information. A monochrome (a.k.a. static gray) monitor has one bit per pixel: each pixel is either black or white, with no shades of gray. Most grayscale and color monitors have 8 bits per pixel, although some may have as few as 2 or 4, and others may have as many as 12 or 24. A color monitor with 8 bits per pixel can support as many as 2⁸ = 256 simultaneous colors; likewise, a grayscale monitor with 8 bits per pixel can support 256 shades of gray.

If you choose to buy an X terminal with a depth of only 2 or 4 bits per pixel, beware that some X clients are dumber than others. Some of the less robust applications assume that if you have a depth greater than 1, then you must have 8 bits per pixel. (These clients can also cause problems on displays with 12 or 24 bits per pixel.)

Another possible complication is that, if you buy a grayscale monitor, you may find that some applications think you have color. For example, on a 2-bit grayscale display, FrameMaker will try to display windows using its color default of a blue background. The best way to deal with this complication is to set up your application resources to use only black and white; see Section 3.5.6 for an example of using xdm and display classes to set up different defaults according to the display type.

Although you might be concerned that an X terminal with 8 bits per pixel may produce 8 times as much traffic as one with a monochrome display, this is seldom an issue in practice. Most clients address only 1 bit per pixel, regardless of the depth of the display.

7.1.1.4 Refresh Rate

The refresh rate of a monitor is the frequency that the screen is redrawn. If the screen is refreshed too slowly, it may be noticeable to users and quickly cause eye-strain. In general, a refresh rate of less than 70 Hz is considered to be too slow for daily use.

7.1.2 Keyboard and Mouse

There are several different types of keyboards available for X terminals. Since there are few things more frustrating to users than having to use a keyboard they are unaccustomed to, choose the keyboard carefully. DEC users are used to different key configurations than both Sun users and PC users. Users have different ideas of what a “UNIX” keyboard is—some users think it's a Sun3 keyboard, others think it's a Sun4 keyboard, and some think it's a DEC keyboard. (What NCD calls a UNIX keyboard is actually a DEC keyboard.)

Keyboards differ in things like the position of the tilde and escape keys, the position of the Alt key(s), and the positions of the CTRL and CAPS LOCK keys (which are sometimes reversed, to the great frustration of the user). Most X terminal manufacturers also have international keyboards available.

Almost all X terminals come with a 3-button mouse. The only deviations between the mouse distributed with X terminals is whether it's a mechanical mouse or an optical mouse. Optical mice cost a bit more, but many people consider them to be more reliable. Trackballs are also available from many manufacturers at an extra cost.

7.1.3 X Server Software

The X server is essentially the operating system for the X terminal. X terminals differ, however, in where the server program resides, and even where it is run.

• Many older X terminals have the X server built directly into ROM. However, these X terminals tend to be much more expensive, and furthermore they require replacing the ROM at every upgrade.
• Most X terminals are designed to read the X server program from a host on the network at boot time. Upgrades involve replacing a single file on the host. The downside to having the X server software loaded over the network, however, is if you intend to run X over a serial connection—downloading a megabyte of software can take some time over a modem line.
• Some X terminals give you the option of both—they have X server software built in, but can then override it by downloading another server from the network. This method is currently being replaced by another method using FLASH ROM. FLASH ROM is a type of ROM that is updated by being downloaded from a host only once. This means that you don't have to download the entire server image every time you boot the X terminal, but you also don't have to deal with the messiness of opening up each X terminal every time an upgrade comes in. FLASH ROM is expensive, but it's clearly the most efficient way of dealing with X terminal software.
• There are a few low-cost X terminals designed to run over serial lines exclusively.^* These X terminals do not actually run the X server, but rely on the host to run the X server as well as the clients. The advantage is that all the traffic between client and server can take place over TCP/IP or IPC, so that the communication over the serial connection can be restricted to keystroke and mouse events and to screen updates. Another great advantage is that, since they need very little memory to run, these serial X terminals tend to be very inexpensive. The disadvantage is that they are still very slow (although faster than many other methods of running X over serial connections).

We strongly recommend that you buy an X terminal with an XDMCP-compliant server (R4 or higher). (Almost all X terminals sold today support XDMCP; see Section 3.1 for more information on XDMCP.) If you run R5 on a host, we also recommend getting an X terminal that supports the R5 font server and (if the X terminal supports color) one that supplies color characterization data for Xcms. (At this printing, X terminals supporting the R5 font server and Xcms are just coming to the market.)

For the purposes of this book, we emphasize setting up X terminals running over TCP/IP with the X server software downloaded over TFTP.

7.1.4 Special Features

As the X terminal market has grown, X terminal capabilities have expanded as well.

Local Clients

Some X terminals can run X clients locally. Window managers are the most popular clients to run locally, and can make quite an impact on performance. Note, however, that the more you want your X terminal to do, the more memory you'll need. And remember that the whole idea of X and the X terminal in particular is to have cheap desktop access to remote computing—so don't go wild on local clients unless you have real reasons for keeping network traffic at a minimum. For example, if you're running the X terminal over serial lines, you may want to have a local window manager. In any event, the local window manager will be more responsive, but you have to live with the X terminal vendor's choice of a window manager.

Backing Store

Almost all X terminals are capable of backing store. Backing store allows an X server to keep an image of obscured windows in memory so they can be redrawn quickly and without network overhead when exposed. To use this feature, however, terminals need to have some extra memory installed, or they may produce an error message (or crash). Some terminals give the option of using backing store only when there is enough memory available; enable this option if it is provided with your terminal, since it might help performance. Beware, however, that when the X terminal later needs more memory, it may not consider the memory set aside for backing store to be fair game.

Remote Configuration

All X terminals can be configured using a local setup menu. Some X terminals, however, also provide the ability to read their configuration parameters from a file on a remote host at boot time. This becomes a great advantage when you have many X terminals to maintain—it's always easier to edit files on-line than to visit every office on your site after hours. See Section 7.6 for more information on remote configuration.

Peripheral Support

Many X terminals allow you to hang printers off their serial port. In addition, some X terminals made by IBM have a port for connecting a hard drive directly to the X terminal. The hard drive is used for “swapping” large images, reducing memory requirements.

7.1.5 Memory Configuration

X terminals range from 512K of memory to 72MB. As usual, what you should get depends on what you plan to use it for. If you plan to run graphics-intensive applications, you'll want more memory for a reasonable display. Remember that the more pixels on the screen and the greater the depth of your terminal, the more memory you'll need.

In addition, many of the fancier features available for X terminals can be memory-intensive. X terminals that can run clients locally will need more memory to support them. If you want your X terminals to do backing store, that will also require more memory.

Although many X terminals are smart enough to cut down on backing store when memory gets low, beware that some X terminals might crash if they run out of memory. If this happens, it's a good idea to disable backing store completely, if you can.

Some X terminal manufacturers use their own proprietary memory. If you think this may turn into an issue when it becomes time to upgrade the memory, you might prefer to stick to a manufacturer that uses industry-standard SIMMs.

7.1.6 Network Interface

Most X terminals come with built-in Ethernet and TCP/IP support, and most also provide a serial interface. Some X terminals support the IBM Token Ring beneath TCP/IP. DECnet is supported by some X terminals as well.

Most X terminals support SLIP for running X over a modem line. X terminals supporting PPP for modem lines are just now coming to the market. In addition, some X terminal manufacturers have their own serial line protocols that are more efficient than SLIP, such as NCD's Xremote and Serial Xpress by Tektronix.

7.2 X Terminal Setup

Assuming you now have an X terminal, you probably want to make sure it works before you do any serious configuration. For an X terminal running over TCP/IP, this means you have to perform the following steps. These steps are described in more detail later in this chapter. Please note that X terminals may have different procedures where noted.

1. Configure the local name server to include a new IP address for the new machine. If you aren't already familiar with this procedure, see Section A.6 for more information.
2. Install the fonts on the host machine.

   The X terminal should have arrived with a font tape. Unless both the X terminal and the host support the R5 font server (and to this date, no X terminals do), you need to install the fonts as documented by the X terminal vendor.

   Where you install your fonts depends on how you intend for them to be read. Some X terminals can read fonts via NFS; all X terminals can read fonts via TFTP. Although it may be preferable to read fonts via NFS, it's a bit harder to set up. For easy setup, therefore, install the fonts in /tftpboot/usr/lib/X11/vendor/fonts. (You can move the fonts elsewhere if and when you switch to NFS.) See Section 7.4 for more information on font management for X terminals. See Section 7.3.3 for more information on TFTP.

   If the X terminal has support for the R5 font server, and you have an R5 machine running the font server, you don't need to install new fonts. You can just set up the X terminal to use the font server, specifying the name of the font server (consisting of transport, host, and port number). Note that some X terminals may use the term “font server” differently—i.e., as the host that the X terminal reads its fonts from, but without actually using the R5 font service protocol.

3. Install the X server.

   If the X server is built into ROM, you can skip this step. Otherwise, the X server software was probably sent on a tape, to be copied onto the host and read by the X terminal at startup via TFTP. Copy the X server program to the proper directory on the host machine (probably /tftpboot) and make sure that the TFTP daemon is running on the host. (See Section 7.3.3 for more information on TFTP.)

   Next, tell the X terminal where to download the server from. At this point, you need to consult your documentation; however, for an example, our NCD X terminals use a command line similar to the following on their boot monitors:

   > bt Xncd16 140.186.65.137 140.186.65.25

   The X terminal will boot using the file /tftpboot/Xncd16 on the host with IP address 140.186.65.25. The X terminal will use IP address 140.186.65.137.

   After the X terminal is initially booted, you can configure its setup menu so that it can automatically boot at power up. Alternatively, if the X terminal uses BOOTP, then you can enter this information into /etc/bootptab; see Section 7.3.2 for more information.

4. Now it's time to connect to a host. If you don't have R4 or R5 xdm already running on a host machine, see Section 3.3 for information on how to start it up.^*

   Once you have xdm running on a host machine, some X terminals arrive pre-configured to do a Broadcast query. Those terminals should receive the login box immediately once the X terminal has been supplied a broadcast address. If there's some complication, you can configure the X terminal to query the host running xdm directly. See your vendor's documentation to learn how to configure the terminal to use XDMCP.

lmui@ruby 26% who am i
ruby!lmui ttyp6Aug 20 18:18  (ncd9.ora.com)
lmui@ruby 27% setenv DISPLAY ncd9.ora.com:0
lmui@ruby 28% xterm &

7.3 Network Setup

Now for the details. To configure the X terminal for the network, you first need to set up the hosts database. If you aren't already familiar with how to do this on your site, see Section A.6 for more information.

The hosts database maps hostnames to IP addresses. The next issue is how the X terminal knows its IP address. Some X terminals can save their IP address in NVRAM (Non-Volatile RAM). Other X terminals, however, have no way of storing their IP addresses. Instead, they have to depend on the host to tell them their IP address at boot time, using RARP (Reverse Address Resolution Protocol) or BOOTP (Bootstrap Protocol).

Another issue, for X terminals that boot over the network, is how the terminal accesses its server binary. The server image for these X terminals resides on a host somewhere on the network, and the X terminal needs to be able to read their boot image using some protocol, generally TFTP (Trivial File Transfer Protocol).

7.3.1 Getting the IP Address Using RARP

The way RARP works is that the host machine keeps a table of Ethernet addresses and the corresponding IP addresses. This table is kept either in /etc/ethers or in the ethers database if the host uses NIS. The rarpd daemon waits for broadcast requests from X terminals and other diskless machines. In its broadcast, the X terminal supplies its Ethernet hardware address (which is built into their Ethernet interface). The rarpd daemon on the host responds with its IP address on that network.

If you don't run NIS, adding a new RARP entry is just a matter of editing /etc/ethers./etc/ethers has a simple syntax similar to /etc/hosts. You can get the Ethernet hardware address of the new X terminal from the monitor at boot time. NCD X terminals, for example, print a message similar to the following:

Boot Prom  V2.1.0
Testing available memory   3.0 Mbytes
Network controller passed  00:00:A7:10:11:BF
Keyboard controller V2.00

To add this terminal as ncd4, add the following line to /etc/ethers (convert the letters in the hex number to lowercase):

00:00:a7:10:11:bf   ncd4

The RARP daemon uses the ethers database along with the hosts database to determine the X terminal's IP address. Note that for RARP to work, you must have an entry for the new X terminal in the hosts database.

If you run NIS, see Section A.7 for information on how to add an entry to the ethers database.

7.3.2 Getting Information Using BOOTP

BOOTP is similar to RARP, but it gives a bit more information. RARP will tell the X terminal only its IP address. BOOTP can be set up to tell the X terminal its subnet mask, name server host, and what machine and pathname to download the X server from.

The BOOTP daemon bootpd uses a file called /etc/bootptab. The BOOTP protocol has changed over the years, as has the syntax for bootptab. Standard BOOTP (RFC951) uses a single-line entry per hardware address, to supply the IP address and the name of the boot file. The first two uncommented lines contain, respectively, the directory in which the boot files reside, and the default boot file. For example:

#
# default boot directory
#

/tftpboot:/

# default bootfile
Xncd19

# bootp clients --
# host htype   haddr         iaddr      bootfile

ncd4 1    00:00:A7:10:11:BF  140.186.65.13   Xncd16

The first field is the hostname of the BOOTP client (in this example, ncd4). The second field is the hardware type, with 1=Ethernet. The third and fourth fields represent the hardware and Internet addresses. The fifth field is the name of the boot file to use in the specified directory. (The “:/” following the default boot directory /tftpboot is needed for systems that run TFTP in restricted mode.)

“Extended” BOOTP (RFC1048 with CMU extensions) has syntax similar to that of /etc/termcap and /etc/printcap. A single BOOTP definition is in two parts, a “global” part used for all machines and a part that is particular to the new machine. The “global” part must appear first, and might resemble the following:

global:
     :sm=255.255.255.0:
     :ht=ethernet:
     :ds=140.186.65.25:
     :ns=140.186.65.25:
     :to=18000:
     :hn:
     :vm=rfc1048:

The client-specific part might then resemble:

ncd4:
     :hd=/tftpboot:
     :bf=Xncd16:
     :tc=global:
     :ha=0000A71011BF:
     :ip=140.186.65.13:

The two-character capabilities have the following meanings:

The hn entry should be set to the hostname of the terminal. For the global entry, hn should be left blank (as shown above).

7.3.3 Trivial File Transfer Protocol (TFTP)

An X terminal needs to use some simple transfer protocol to download its server software. Most X terminals use TFTP as their transfer protocol of choice. Since TFTP does not require a user name or password in order to allow a connection, we strongly recommend running tftpd in “restricted” or “secure” mode. Using restricted TFTP, the server code must be copied to the TFTP home directory—usually /tftpboot—and the X terminal needs to be told which host to boot from. When the X terminal connects to the host via restricted TFTP, the host's TFTP server does a chroot to /tftpboot and reads files relative to the new root.

The TFTP server is usually run from inetd, which is started at boot time from /etc/rc or rc.local. inetd manages several daemons listed in /etc/inetd.conf; requests for those services are routed through inetd, which then starts up the appropriate daemon.

TFTP is often disabled from inetd.conf because it is considered a potential security hole. If you're not sure if TFTP is active, first make sure that inetd is running, and if it is, then look in the configuration file for inetd (either /etc/inetd.conf or /etc/servers) to make sure TFTP is called. In /etc/inetd.conf, the line starting TFTP should look something like the following:

tftp dgram udp wait root /usr/etc/in.tftpd in.tftpd -s /tftpboot

In /etc/servers, it should look like:

tftp udp /usr/etc/in.tftpd -s /tftpboot

(The –s option says to run TFTP in “secure” mode, so that machines connecting via TFTP can read files only in /tftpboot. On some systems this option appears as –r, for “restricted” mode. Since TFTP is such a security hazard, we do not recommend using it except in restricted mode; otherwise, anyone on the network can get any file on your host!)

You can also test if TFTP is running by trying it manually:

lmui@reno % tftp ruby
tftp> status
Connected to ruby.ora.com.
Mode: netascii Verbose: off Tracing: off
Rexmt-interval: 5 seconds, Max-timeout: 25 seconds
tftp> get Xncd16
Received 846244 bytes in 8.4 seconds
tftp>

(After quitting TFTP and confirming that the file was properly retrieved, you probably want to remove it from the directory it was copied to.)

Test if TFTP is running in restricted mode by requesting a file that isn't in /tftpboot:

tftp> get  /etc/motd
Error code 1: File not found
tftp>

Another possible error message on some systems is:

tftp> get /etc/motd
Transfer timed out.
tftp>

If you don't get an error message and TFTP lets you copy /etc/motd to your current directory, then it isn't running in restricted mode, and you should probably be worried about what other files can be transferred (such as /etc/passwd!).

If TFTP is not enabled, edit inetd.conf or /etc/servers as appropriate, and send a SIGHUP to inetd. This will force inetd to reread /etc/inetd.conf.

# vi /etc/inetd.conf
     (restore the TFTP line)
# ps agx | grep  inetd
  188 ? IW    5:06 inetd
 5922 q6 S    0:00 grep inetd
# kill -HUP 188

For more information on inetd, see the Nutshell Handbook, TCP/IP Network Administration, by Craig Hunt (O'Reilly & Associates, 1992).

7.3.4 Setting Up the Network on the X Terminal

If you're using BOOTP, you don't need to do anything on the X terminal end to get the terminal to connect properly to the host with the right IP address and download its boot file. Otherwise, however, you need to do some fiddling on the setup menu.

As far as TCP/IP is concerned, the things you need to tell the X terminal are:

• The X terminal's IP address
• The subnet mask on the network
• The name server address
• The IP address of the host to boot from
• The broadcast address

Each X terminal vendor has its own way of specifying this information in a setup menu. See your vendor's documentation for more information.

One bit of advice about configuring X terminals: remember that many X terminals need to be explicitly told to save current settings in NVRAM, or changes will not take effect after the X terminal is booted.

7.3.5 Debugging Hints

If you think you've done everything right, but the X terminal still can't seem to boot, here are some hints.

7.3.5.1 Error Messages

The X terminal itself may have a diagnostic window for reporting error messages. The diagnostic window is the first place to look for errors. If all the “interesting” information scrolls off the screen too quickly, you may be able to limit the level of diagnostic information by setting a lower error message level via the setup menu; see your vendor's documentation for details.

If the X terminal appears to know its name but is not able to download the boot file, you may also want to look for an error message on the boot host. Errors from tftpd, bootpd, or inetd should be recorded by syslog on the host machine. Look in /etc/syslog.conf. to determine where daemon error messages are being copied to; for example, on our system, /etc/syslog.conf contains the line:

*.err;kern. debug; daemon,auth.notice;mail.crit;user.none /var/adm/messages

All daemon error messages on our system are therefore being copied to /var/adm/messages.

7.3.5.2 Updating the arp Table

The arp table on the boot host has a listing of all hostnames, Ethernet addresses, and IP addresses that the host knows about. You can access this table using the command arp -a:

% arp  -a
ncd4.ora.com (140.186.65.14) at 0:0:a7:10:12:bf
rubble.ora.com (140.186.65.11) at 8:0:20:2:fc:90
rock.west.ora.com (140.186.66.10) at 0:0:c:0:63:4a
cca.camb.com (140.186.64.12) at aa:0:4:0:e2:4
harry.ora.com (140.186.65.17) at 8:0:20:7:c4:d4
 ...

Keep in mind that if you replace an X terminal with a new one, you may have to manually delete the cached arp entry with the arp -d command before the new terminal can be recognized:

# arp -d ncd4

If you have an old arp entry or have made a mistake in the /etc/ethers file, you may get the following error:

duplicate IP address! ! sent from ethernet address: ...

7.3.5.3 Name Server Problems

If the X server is running properly but you can't seem to get any clients to open the new display, there may be a problem in the name server. The name server is primarily responsible for looking up a hostname and returning the IP address for that host. You can therefore isolate the problem to the name server by supplying the IP address directly to the client program. For example:

lmui@reno % xterm -display 140.186.65.13:0

If this command is successful but “hostname:0” was not, then the problem could be with the name server configuration, with the NIS configuration, or with the resolver configuration file (/etc/resolv.conf).

7.4 Fonts on X Terminals

Many X terminals have some fonts built into the server, but you usually need to read fonts from the host machine as well. Most X terminal manufacturers supply a “font tape” with their product, with fonts that need to be read on your host system. At minimum, the font tape that comes with the X terminal contains vendor-specific .snf or .pcf versions of the BDF fonts supplied by the MIT source distribution of X11. Many vendors also supply some additional fonts.

We said earlier that for easy set up, just put the fonts in /tftpboot. But for real setup, you probably want to think a little harder about where to put the fonts and how they should be read.

7.4.1 Font Formats

Every X server vendor supplies its own font tree for that server. Each font tree takes approximately three to four megabytes of disk space. If you have X terminals manufactured by three different vendors, therefore, you're using up 9 to 12 megabytes just to hold their fonts—not to mention the fonts for running X on the local display of the host machine.

Luckily, you can often get away without keeping multiple fonts on line. For .snf fonts, there are four ways that fonts for different servers might deviate: the byte order, the bit order, the scanline unit padding, and the glyph padding. In most cases, the scanline and glyph padding for a server is 1 (the default), so you seldom have to consider those variables for incompatibilities (although if you find that your characters are drawing over one another, you're probably using fonts compiled with a different padding). The byte order and bit order generally go hand-in-hand. So for most cases, you really need to keep at most only two sets of .snf fonts on line: one for X terminals that number bytes starting at the high end (big endian), and one for X terminals that number bytes starting at the low end (little endian).

PCF fonts don't have byte-order incompatibilities, so if all your X terminals support PCF fonts, you might be able to get away with a single set of fonts.

For example, NCD X terminals are big endian, so if they are reading fonts from a Sun workstation (a big endian machine), chances are that they can read and display the .snf fonts compiled for the local server without a hitch. The bdftosnf font compiler defaults to the byte order on the host machine, so there should be no problem in font compatibility between Sun and NCD X servers. In this situation, you would not have to keep the NCD fonts on line, but could have the X terminals read the Sun-compiled .snf fonts. The easiest way to do this is by linking the standard X11 font directory to the server-specific font directory. For example:

# mkdir /usr/lib/X11/ncd
# In -s /usr/lib/X11/fonts /usr/lib/X11/ncd/fonts

(You may still want to use the fonts supplied with the X terminal, since they may be more sophisticated than those on the core MIT distribution, but that's up to you.)

HDS X terminals are little endian. This means that the fonts on a Sun are not compatible with those supplied by HDS (although fonts on a VAX are).

There is another hitch. Although each of the factors for font compatibility can be overridden on the bdftosnf command line, the options for a different bit or byte order will apply only to the glyph section of the font—the header section will still be in the bit and byte order of the host. So HDS supplies its own font compiler, bdftohds, since they cannot rely on the fonts compiled by bdftosnf on a big endian machine. Many X terminal manufacturers supply their own compiler to convert .bdf fonts to their own format.

Some X terminals (e.g., those made by Visual) can read fonts in either byte order. Furthermore, X terminals are beginning to support the .pcf font format, which does not have byte-order incompatibilities. Tektronix is one vendor that currently sells X terminals supporting both .pcf and .snf formats.

7.4.2 The Font Server (R5)

With Release 5 of X11, a lot of the font confusion is cleared up with the font server. R5-compatible X terminals (of which there are currently none) supply a field in the setup menu for the address of the font server. If your X terminal provides this functionality, and you have an R5 host available to run a font server, run (do not walk) to Section 5.5 to learn how to enable the font server on the host. You have been spared a giant headache.

Some X terminal vendors, such as Visual Technology, have their own proprietary font server mechanism. Although they are unlikely to be compatible with the R5 font server, these proprietary font servers are worth looking into if running the R5 font server is not an option.

7.4.3 Choosing TFTP or NFS for Font Access

Assuming that your X terminal does not support the font server introduced with X11R5, you are stuck with either TFTP or NFS. (Some X terminals also support using FTP, but you're probably better off not opening that can of worms.)

7.4.3.1 Reading Fonts Using TFTP

It's easy to install fonts to be transferred with TFTP. But since TFTP doesn't provide any user authentication, you need to decide whether you want to run it in restricted mode or not, and either option has its downside.

If you run TFTP in restricted mode, you have to put the font files in the TFTP home directory tree (usually /tftpboot). When the X terminal connects to the host using TFTP, it will do a chroot to /tftpboot and then look for the fonts relative to that directory—so, for example, an NCD X terminal will effectively look for its fonts in /tftpboot/usr/lib/X11/ncd/fonts.

The problem with running TFTP in restricted mode is that it gives you no choice but to install all your fonts in the TFTP home directory. This may mean some creative shuffling, just to put /tftpboot on a disk large enough to hold all those fonts. Note that the solution that you would like, which is keeping the fonts in /usr/lib/X11/fonts but creating symbolic links to /tftpboot, isn't an option—restricted TFTP cannot follow links outside of /tftpboot.

If you run TFTP in unrestricted mode, you can put the NCD font files where you really want them, in /usr/lib/X11/ncd/fonts. But you probably don't want to run TFTP in unrestricted mode—after all, do you want anyone over the Internet to be able to read your /etc/passwd file?

A possibility is to use NFS to mount the fonts from the same machine. That is, you might set up the host ruby to export /usr read-only to itself. On newer NFS implementations, the /etc/exports would look like:

/usr -ro,access=ruby

Then have ruby mount /usr/lib/X11/vendor/fonts as /tftpboot/usr/lib/X11/vendor/fonts. In /etc/fstab on the same host:

ruby:/usr/lib/X11/ncd/fonts /tftpboot/usr/lib/X11/ncd/fonts nfs ro,bg 0 0

This provides you the convenience of TFTP without many of the hassles.

7.4.3.2 Reading Fonts Using NFS

If you are using NFS directly to download fonts, check the /etc/exports file on the host to confirm that the X terminal has permission to read its font directory, and make sure that directory is exported with the exportfs command. See Section A.5 for more information on exporting directories under NFS.

Netgroups are particularly useful for grouping several X terminals together that need the same fonts. See the Nutshell Handbook, Managing NFS and NIS, by Hal Stern (O'Reilly & Associates, 1991), for more information.

Using NFS to mount the fonts locally on the X terminal can cause some confusion. The cryptic error message “X Error of failed request: BadValue” means the font can't be read because the specified path doesn't exist. This may happen because the pathname was mistyped; however, it could also be the result of some NFS confusion—the font directory may not be properly exported, or it may be mounted on the local machine under another name. For example, you may mount /export/usr/lib/X11/ncd/fonts on a fileserver as /usr/lib/X11/ncd/fonts on the local X terminal. The pathname you specify to xset must reflect its pathname on the local machine, i.e., the one running the X server.

Another possible source of confusion is that NFS will not extend permission to any path that is not explicitly exported. That is, if /usr/lib/X11/ncd/fonts is a symbolic link to /export/usr/lib/X11/ncd/fonts, exporting /usr will not grant access to the files that are linked to /export.

7.5 Configuring for the X Display Manager

If you're using X terminals, you probably want to control them using the X Display Manager (xdm). There are other ways of starting sessions, such as logging on via telnet and starting clients manually, or using the rexec (remote execution) capabilities supported by some X terminals. But if both the host system and the X server support the XDM Control Protocol (R4 or later), then you should definitely use xdm.

If you aren't running xdm at all, read Section 3.3 for more information to get it started. See Section 3.1 for some background information on XDMCP.

7.5.1 Configuring the X Terminal for xdm

X terminals generally supply three different ways of running XDMCP:

Direct

Calling XDMCP “directly” requires that the name or IP address of the host running xdm be supplied. The X terminal will request an xdm login box from that host and from that host only.

Indirect

Calling XDMCP “indirectly” requires that the name or IP address of the host be supplied. The host is then expected to pass the XDMCP request to another host or group of hosts. For a host running vanilla X11R4, an “Indirect” query is treated the same as a “Direct” one. For a host running X11R5, it can be configured to respond to an “Indirect” query by forwarding the request to another host or by offering a list of hosts for the user to choose from. See Section 3.5.3 for information on how to configure how “Indirect” queries are treated on an R5 host.

Broadcast

Calling XDMCP in “broadcast” mode does not require a hostname or address, but means that the X terminal sends out a general request for an xdm login box across the subnet. For most X terminals, the first host that responds is the one that is used. For some smarter X terminals, the X server gathers responses from all hosts on the local network and allows the user to choose one to start up on.

If an X terminal doesn't connect to any host running xdm under a Broadcast query, but can connect to hosts via a Direct or Indirect query, then there is probably something wrong with the Broadcast address that you have configured the X terminal to use. See your vendor's documentation for information on how to set the Broadcast address.

Note that Broadcast queries are restricted to the local network or subnet. Unlike Direct and Indirect queries, you cannot use a Broadcast query to access a host through a gateway.

7.5.2 Configuring an R5 Host

If the host is using X11R5, then you need to make sure that the new X terminal is given permission to connect to xdm on the host. The /usr/lib/X11/xdm/Xaccess file controls which X servers can connect to the host. The Xaccess file also controls how Indirect queries are dealt with on that host.

For example, to add ncd4 to the list of X servers that can connect to the host, you can simply add the line:

ncd4.ora.com

Note that the Xaccess file accepts wildcards. So ncd4 would already have permission to connect to the host if there were a line such as:

*.ora.com

See Section 3.5.3 for more information on how to configure the Xaccess file.

7.5.3 Configuring an R4 Host

If the host is using X11R4, you don't need to make any changes on the host for a XDMCP-compatible X server to use xdm—you just need to configure the X terminal to use XDMCP.

7.5.4 Configuring xdm Without XDMCP

If either the X server or the host is not XDMCP-compatible (R3 or earlier), then you need to make an entry in the /usr/lib/X11/xdm/Xservers file in order to manage the X terminal using xdm. For example, you can add the line:

ncd4.ora.com:0   foreign xxx

(The “xxx” is required because although R3 xdm ignores the third field in a foreign entry, the field cannot be left empty.)

See Section 3.5.2 for more information on how to configure the Xservers file.

The problem with using pre-XDMCP xdm is that, should the X terminal be turned off for any reason, xdm needs to be restarted before it will know to reconnect to the terminal. If you have no choice but to use an R3 host system, you might be interested in X terminals that offer their own proprietary protocol for controlling xdm. X terminals made by Visual, for example, provide XDSXDM for controlling Release 3 xdm for their XDS terminals.

7.5.5 Setting Up Server Access Control

As described in Chapter 4, there are two current mechanisms for restricting clients from accessing a particular server: host-based access control and user-based access control.

Host-based access control is controlled entirely by the server. Some X terminals allow you to keep a list of hosts that you want to allow access from, using the setup menu on the X terminal. However, it's better to use user-based access control if you can.

User-based access control is controlled both by the server and by the X Display Manager. Check your X terminal documentation to see if user-based access control is supported. If it is, then check if xdm is set up to use user-based access control on X terminals. You can determine this by examining the configuration file for xdm, usually /usr/lib/X11/xdm/xdm-config. The following line:

DisplayManager*authorize:   true

specifies that authorization is being used for all X servers managed by xdm on that host.

Host-based access control overrides user-based access control. This can cause complications when your X terminal supports both types of server access control. Contrary to what your instincts might be, to enable user-based access control you should make sure that host-based access control is also enabled—disabling host-based access control may effectively result in all hosts having access to the server, regardless of any user-based access control in effect. If you want to use user-based access control exclusively, you should make sure host-based access control is enabled but the list of hosts that are allowed access is empty. See Section 4.2.4 for more information.

See Chapter 4 for more information on security issues and X11.

7.6 Remote Configuration of X Terminals

Many X terminals provide a facility called remote configuration. Our experience with remote configuration has been very positive, so we recommend that if you have more than one of a single type of terminal, you should consider using remote configuration.

With remote configuration, the parameters in the setup menu can be defined in a file to be downloaded by the X terminal when it boots. What this does for the administrator is that it makes it easy to change a given field—the administrator no longer needs to visit each X terminal on the site after hours and change their setup menus manually, but can simply edit the remote configuration files for each terminal. The next time the terminal is booted, the new values will be read.

Another advantage of remote configuration is ease in troubleshooting. The danger of user-accessible setup menus is that a user might unknowingly change something that disables their terminal. Many terminal manufacturers provide a mechanism for “locking” the current setup menu settings with a password—so that only administrators with the password will be able to make further changes to the X terminal configuration. Using remote configuration, however, the X terminal is configured at boot time from a file residing on a host. If a terminal's set up is corrupted, therefore, the user can restore its settings just by rebooting the X terminal.

Another advantage of using remote configuration is that it can help you get out of a jam if for some reason your current configuration is so corrupted that you cannot even access the setup menu. If you are using remote configuration, you can just edit the file and then reboot the terminal.

Each X terminal vendor has its own syntax for remote configuration. To give you an idea of what they do, here's a description of how remote configuration is handled by various X terminal vendors.

7.6.1 Remote Configuration on NCD Terminals

On NCD X terminals with remote configuration turned on, each X terminal at boot time looks for a configuration file whose name is derived from its IP address, in hexadecimal. For example, an NCD X terminal with IP address 140.186.65.13 would look for a configuration file called 8CBA410D in the directory /usr/lib/X11/ncd/configs. (See Section A.9 for information on how to get the hexadecimal equivalent of an IP address.)

If the configuration file for its specific IP address doesn't exist, the X terminal then looks for a configuration file called ncd_std in the same directory.

If you are using NFS to read the remote configuration file, the X terminal needs to have read access for the /usr/lib/X11/ncd/configs directory on the host. If you are using restricted TFTP to read the remote configuration file, the configuration files need to be installed in the /tftpboot/usr/lib/X11/ncd/configs directory.

The following is a portion of the remote configuration file used by our NCD X terminals:

background = white
backing-store = by-request
baud-1 = 9600
boot-at-reset = yes
boot-server = 140.186.65.25
broadcast-address = 140.186.0.0
data-bits-1 = 8
default-cterm-host = 0.0
default-domain = ora.com
    ...
virtual-terminal-at-reset = xdm
xdm-access = direct
    ...
xdm-server = 140.186.65.25

Now for the good news: NCD doesn't require you to write it all in by hand. Instead, you can set up a single terminal, make sure it works to your liking, and then download its parameters to a file using the Utilities menu.

The next problem is how to tell the terminal to read the remote configuration file the first time. There's a logistical problem involved: NCD X terminals support NFS only if they're using remote configuration, so if you want to read the actual configuration file over NFS, you need to upload the configuration file initially using TFTP, and then save current values before rebooting.

7.6.2 Remote Configuration on Visual Terminals

On Visual X terminals with remote configuration turned on, the X terminal uses a list of hostnames and optional pathnames to determine which configuration file to use. This list is supplied in the Remote Configuration Menu. The X terminal will search for the configuration files in the order that they are listed. When a specific pathname isn't listed for a given host, the X terminal looks for a configuration file named for its IP address in the /usr/lib/X11/Visual directory on that host. For example, a Visual X terminal with IP address 140.186.65.13 looks for a configuration file called /usr/lib/X11/Visual/140.186.65.13. If that file doesn't exist, it then looks for a configuration file called xds-config in the same directory.

If you are using NFS to read the remote configuration file, the X terminal needs to have read access for whatever directory the configuration files live in. If you are using restricted TFTP to read the remote configuration file, the files need to be in a subdirectory of /tftpboot, and the pathname needs to be relative to /tftpboot.

Visual X terminals use resource syntax for their configuration files. They follow the form:

Visual.model.parameter:   value

where model is the particular model of Visual X terminal, such as X19, X19TURBO, X15, etc. As with standard resource syntax, you can use an asterisk for the model field to have a resource apply for all models. The following is a portion of a sample configuration file for Visual X terminals:

! -------------------------------
! Ethernet Menu
! -------------------------------
Visual*IpNetworkMask:      255.255.255.0
Visual*IpBroadcastAddress: 140.186.0.0
      ...
! -------------------------------
! X Server Features Menu
! -------------------------------
      ...
Visual*DefaultTextFont:     9x15
Visual.X15.DefaultTextFont: 12x20

Note that we've set things up so that the Visual X15 terminal uses the 12x20 font for text, but all other Visual terminals will use the 9x15 font.

7.6.3 Remote Configuration on Tektronix Terminals

For Tektronix X terminals, the syntax for remote configuration files consists of commands followed directly by parameters. Lines starting with “#” are taken as comments. The remote configuration file is read using the same file access method that is used for downloading the server image (i.e., TFTP), so remote configuration is not available for terminals that boot from ROM.

Tektronix remote configuration files need to be thought of somewhat differently, since the terminal executes each line as a command and doesn't just store it as a variable definition. This means that you have to be careful about the sequence of commands. For example, you need to declare a host's address using the ip_host_table command before you can use its hostname for the file_host_name_1 command.

The sample is a portion from a configuration file for Tektronix X terminals:

ip_host_table         140.186.65.25 ruby
ip_host_table         140.186.65.35 opal
file_host_name_1      ruby
file_access_1         TFTP
     ...

7.7 Reconfiguring the Host

When you replace an ASCII terminal with an X terminal, you're giving a user a whole new world of functionality. You are also allowing that user to use five to ten times the resources he or she used previously. Whereas a user on an ASCII terminal might run maybe one or two processes in the background (which usually exit on their own), a user on an X terminal can go hog wild, running an xclock, xbiff, multiple xterms, a mail reader, a news reader, etc.—all this before starting actual “work.” In addition, xdm forks a copy of itself for every display it manages.

In this section, we include an example of how to configure a SunOS system to support more users, processes, pseudo-ttys, and swap space. Refer to your vendor's manual for information on how to reconfigure the kernel on your system.

7.7.1 Increasing the Number of Processes

When you set up a site for running multiple X terminals, you probably want to increase the number of processes that the host can handle at once. If the system runs out of processes, it may give an error:

% ls
No more processes
%

or commands may fail silently.

To increase the number of processes on SunOS 4.x, edit the kernel configuration file. The name of this file follows the form /sys/arch/conf/kernel_name. For our Sun4, this file is /sys/sun4m/conf/RUBY. Edit the maxusers line as appropriate. For example, change:

maxusers    8

to:

maxusers    48

Then rebuild the kernel and reboot:

# /etc/config RUBY
# cd ../RUBY
# make
# cp /vmunix /ovmunix
# cp vmunix /
# sync;reboot

Be careful to follow the guidelines in vendor OS manuals in increasing maxusers. If you increase it beyond the specified upper limit, you run the risk of wasting resources.

7.7.2 Increasing the Number of Pseudo-ttys

Another consideration is the number of pseudo-ttys, or ptys, a host can handle. A typical symptom of running out of ptys is an immediate logout when trying to open a new connection:

% rlogin rock
Password:
SunOS Release 4.1.2 (ORAWEST) #3: Wed Jul 29 12:50:14 PDT 1992
TERM=(xterm)
Connection closed.

On SunOS, edit the same kernel config file /sys/arch/conf/kernel_name. Find the line for pty devices.

pseudo-device   pty          # pseudo-tty's, also needed for SunView

The default entry is for 48 ptys. Appending a number suffix changes it accordingly:

pseudo-device   pty128       # pseudo-tty's, also needed for SunView

We have now set up the system to support 128 ptys. (See your documentation to learn what the maximum number of ptys on your system is. SunOS 4.1.2 can handle up to 256 ptys.)

Next, make more ptys in /dev for each bank of 16 ptys. Since we have expanded to 128 ptys, this would be 128 ÷ 16 = 8 banks of ptys in total. The pty banks are numbered from 0, so you'd remake banks 0 through 7:

# cd /dev
# MAKEDEV pty0 pty1 pty2 pty3 pty4 pty5 pty6 pty7
# ls pty?? | wc -l
  128

Then rebuild the kernel and reboot as shown above.

# /etc/config kernel name
# cd ../kernel name
# make
# cp /vmunix  /ovmunix
# cp vmunix /
# sync;reboot

There is often a script in /dev for creating new pseudo-ttys. See your vendor's documentation for details.

7.7.3 Increasing the Amount of Swap Space

You may need to increase the amount of swap space when you start to get the dreaded error message:

Sorry, pid 3924 (eap) was killed due to lack of swap space

There are two ways to deal with swap space under SunOS: either swap to a file or swap to disk partition.^*

7.7.3.1 Swapping to a File

To swap to a file, fist create the swap file:

# mkfile  -v 64m /work/moreswap
/work/moreswap 67108864 bytes

Then add an entry in /etc/fstab as follows:

/work/moreswap swap swap rw 0 0

Finally, enable swapping on the new area:

# swapon -a
Adding /work/moreswap as swap device

7.7.3.2 Swapping to a Disk

To swap to a disk, add an entry in /etc/fstab to define the new swap partition (in this example, /dev/sd2b):

/dev/sd2b  swap      swap rw 0 0

Then, before running swapon, check the current size of the swap space:

# /etc/pstat  -T
163/2758 files
829/1223 inodes
74/778 processes
14488/63972 swap

This shows approximately 64 MB of available swap space (with 14 MB already used).

Finally, run swapon and then check the size of the swap space again:

# swapon  -a
Adding /dev/sd2b as swap device
# /etc/pstat  -T
163/2758 files
829/1223 inodes
74/778 processes
14488/127944 swap

The swap space has doubled to approximately 128 MB.

7.8 Related Documentation

Articles on X terminals appear frequently in periodicals serving the X and UNIX community. Advertisements (in periodicals that accept them) are also very helpful for keeping track of the latest and greatest X terminal technology.

In addition, a list of X terminal manufacturers is posted quarterly to the comp.windows.x newsgroup.

The following Nutshell Handbooks might come in handy: Managing NFS and NIS by Hal Stern; Essential System Administration by AEleen Frisch; TCP/IP Network Administration by Craig Hunt; and DNS and BIND by Cricket Liu and Paul Albitz.