A
System Management
This appendix discusses various tasks involved in X Window System management, mostly from the UNIX point of view.
In This Chapter:
Including X in Your Search Path
Starting X with the Display Manager, xdm (Release 4)
Getting Started with xdm on a Single Display
Setting Up the Configuration File and Other Special Files
The Xsession File and .xsession Scripts
The xdm-pid File (Release 4 Only)
Security and the authorize Resource (Release 4 Only)
X Terminals and the XDM Control Protocol (Release 4)
Release 3 Special Files and the Config File
Managing Multiple Displays: the Release 3 Xservers File
An Older Method of Starting X: /etc/ttys
Host-based Access and the xhost Client
A
System Management
X exists in so many incarnations and runs on so many different versions of UNIX (not to mention other operating systems) that it is difficult to be definitive about system management. This appendix discusses several topics relevant to setting up the standard version of X (with UNIX) and keeping it running smoothly. The range of subjects discussed is somewhat broad. Here’s an overview.
This appendix primarily focuses on ways in which you can set up X to run automatically:
• xdm, the display manager.
• xinit.
• By an older (and now obsolete) method, running xterm from /etc/ttys.
In addition to information relating to starting X, we’ve also included brief discussions of other topics relevant to X system management:
• Including X in your search path.
• Setting the terminal type for xterm.
• Managing fonts.
• Addressing security issues and access control.
• Redirecting console messages.
• Maintaining log files.
• Changing the color name database.
Given the various incarnations of X and UNIX, you should be sure to check your system’s documentation for additional (or contrary) details.
Including X in Your Search Path
The various X clients are normally stored in the directory /usr/bin/X11. In order to invoke them by name like any other UNIX program, you need to make this directory part of your search path.*
This is normally done from your .cshrc (C shell) or .profile (Bourne shell) file, using a command similar to the following:
Bourne Shell:
PATH=.:/usr/ucb:/bin :/usr/bin:/usr/bin/X11: Other directories;
export PATH
C Shell:
set path=(. /usr/ucb /bin /usr/bin /usr/bin/X11 Other directories)
The exact list of directories will differ from system to system. You should be aware that directories are searched in order from left to right, so a command with the same name in an earlier directory will be found and used before one in a later directory. Many users take advantage of this fact to run customized versions of programs by putting “.” (the current directory) or a local tools directory first in their search path. This works fine, but you should be aware that this provides a security loophole that can be taken advantage of by an experienced system cracker. It’s much safer to put “.” at the end of your path, or eliminate it entirely.
If you have already logged in before adding the above line to your .profile or .cshrc file, you should log out and log in again, or type in the path-setting command at your prompt, so that it takes effect for your current session.
Setting the Terminal Type
Several termcap entries work with xterm, including “xterm,” “vt102,” “vt100,” and “ansi.” The xterm program automatically searches the termcap file for these entries (in this order) and sets the TERM and TERMCAP environment variables according to the entry it finds.
We’ve found that the termcap entry called “xterm,” which comes with the standard X distribution, provides very reliable emulation. We suggest you copy this entry from the xterm source directory (the file is called termcap) and add it as the first entry in the /etc/termcap file on your system. This will allow you to set your terminal type to xterm.
A Startup Shell Script
It’s a basic principle of UNIX to “let the computer do the work.” Accordingly, you’d no doubt like to run various X clients automatically whenever you log in.
The best way to do this is to create a script that runs the clients you want. Depending on how X is set up on your system, you can execute this script in one of two ways:*
• If xdm is running X, name the script .xsession and put it in your home directory. When you log in, xdm will automatically execute your .xsession script.
• If you are starting X with xinit, name the script .xinitrc and put it in your home directory. Then put the command xinit at the end of your .login file. xinit normally starts the server and runs a single xterm as a client, but if a file called .xinitrc exists in your home directory, xinit starts the server and executes .xinitrc.
Methods of starting X automatically with xinit or xdm are discussed later in this appendix.
What Should Go in the Script
With some variation depending on the specific environment, in most cases your startup script should:
• Set the DISPLAY environment variable.
• Load your resources file with xrdb.
• Start the window manager.
• Start other clients you want on your default display, such as xterm, oclock, xload, etc.
• Run a console xterm process in the foreground; terminating this process will terminate the login session.
The script can be either a C shell or Bourne shell script. We’ve included a sample script in Bourne shell syntax.†
In writing a script, keep in mind this limitation: running xterm from inside a shell script only works if the script executes quickly—or does not terminate at all.
The problem involves the way that xterm sets up its controlling terminal (/dev/tty). If the xterm’s parent process has died by the time the xterm gets around to doing this, then /dev/tty is redefined properly. If the parent has not died, however, xterm uses the parent’s controlling terminal as its own. If the parent dies at any time after that, /dev/tty will become undefined for that xterm (and all processes spawned by it).
A C shell script that starts up a few xterms and then exits will probably work because the xterm’s parent process (the script) has exited by the time the xterms start defining their /dev/tty. If, however, there is a sleep or another command that takes a long time in the script after the line invoking the xterm, the parent may still be around when the xterm defines /dev/tty. Then, when the script finally exits, /dev/tty becomes undefined for those xterms.
If you want to use a C shell script, this problem can be avoided by enclosing commands in parentheses. This causes the shell to fork an extra time before executing the command, and thus disassociates the process from the controlling terminal before the process begins.
Whether you are using a C shell or Bourne shell script, you should make the last command in the script be one that opens a window, and run that command in the foreground. Then the script will not terminate until that final foreground command terminates—that is, when you kill the window. In this case, all the xterms will have the script’s controlling tty, but since the script is guaranteed to hang around, this causes no problem.
Regardless of how and in what environment you’re starting X, it is advisable to set the DISPLAY variable inside the script, since otherwise the clients won’t know which display to connect to. (Normally, xterm sets the DISPLAY variable. Since you are invoking the other clients not from a shell in an xterm window, but from a standard shell, it will not automatically be set.)
Though without explicit settings, both xdm and xinit will automatically set DISPLAY to unix:0.0 (or some variation thereof), this default setting limits the remote hosts that can connect to the local system. (If every system has the same DISPLAY variable, it becomes rather difficult to run programs on a remote host!) We suggest you set the DISPLAY explicitly, determining the appropriate host name with the hostname command, as shown in the script below.
Note that the hostname command is a BSD command. For a System V equivalent, see your UNIX documentation. Note also that in this script, sed is used to strip domained-based hostnames such as isla.ora.com back to their initial term, the actual system name. If you are running in a standalone environment, this is not necessary.
Example A-1 shows a startup Bourne shell script, which would open windows on the display, as shown in Figure A-1. You can use this script even if you normally use the C shell for interactive use. Note that the comments should probably not be present in the working script. While they are ignored, they do slow down execution, and on a loaded system can cause X to start up improperly.
Example A-1. Startup Bourne shell script
#!/bin/sh
# Get hostname, strip the domain name if there is one
cpu='hostname | sed -e 's/\..*//''
# If no DISPLAY is set, set one.
if [ -z $DISPLAY ]
then
DISPLAY=$cpu: 0
fi
# Special-case the "bogus" non-network display names and
# make sure we can always execute remote clients
case $DISPLAY in
unix:0.0|unix:0|:0.0|:0)DISPLAY="$cpu:0";;
esac
export DISPLAY
# Load resource definitions from .Xresources
xrdb -Dhostname=$cpu $HOME/.Xresources
# Set keyclick off and invoke the screen saver after
# seven minutes of idleness
xset c off s 420
# Start the twm window manager
twm &
# Now start up some xterms
# Start an xterm in bottom left corner
xterm -geometry 80x35+0-0 -display $DISPLAY &
# xterm next to it across the bottom
xterm -geometry 80x35+500-0 -display $DISPLAY &
# remote xterm in regular size just above, but below console xterm
# at top
rsh ora xterm -geometry -0-0 -display $DISPLAY &
# Now start up other clients
# digital xclock in upper right corner
xclock -digital -update 1 -geometry -0+0 &
# xcalc just below it; xclock 30 pixels high on sun, so offset by 30
xcalc -geometry -0+30 &
#xload 235 pixels below that, at bottom of xcalc
xload -geometry -0+265 &
#xbiff down another 120 pixels
xbiff -geometry -0+385 &
# Start a console xterm window.
# This is the only xterm that should be run in the foreground.
# Killing this window will shut down X.
# Use the following line with xinit; comment out if you use xdm
exec xterm -C -display $DISPLAY -geometry 80x5+0+0
# Uncomment this line if you use xdm
# exec xterm -C -ls -display $DISPLAY -geometry 80x5+0+0
Figure A-1. Display after running sample script
Note that all programs that create windows (and hence don’t run quickly and then go away) are run in the background, with the exception of the final xterm window. This will cause the script to simulate the behavior of the console xterm normally started by xinit or xdm.
The -C option specified with the console xterm window redirects messages sent to /dev/console to that xterm window. This option is only supported in some implementations of X; see your documentation. For additional information, see the section “Console Messages” later in this appendix.
You may want to start the console xterm window as an icon, using the -iconic option, so you’re less likely to terminate the window inadvertently and end the session. If you do this, you should specify the position of the icon in your resource file. The following resource entry would place the icon at coordinates 50,50:
xterm*iconGeometry: +50+50
In the example, though, we simply make the window only five lines high, so that we can still see console messages, but won’t be tempted to use it for most purposes.
Note that if you are using xdm, you want to run the final xterm with the -ls option, to make that window be your login shell. If you are using xinit, you should definitely not use this option! Since xinit is invoked from the end of the .login file (instead of directly by xdm before login), you will end up in an infinite loop.
Note that windows are actually arranged in a “tiled” fashion, with two large xterms side by side on the bottom of the screen, a smaller one (connected to a remote system) above, and the “desk accessories” lined up in the upper left corner. This leaves some room free for new windows or for invoking the Twm menu on the root window. This is ideal for our purposes, which are mainly editing, formatting, and testing examples for books. Depending on what you do, another arrangement might be better.*
Starting X
In Chapter 2 Getting Started, we described how to start X manually. However, on a singleuser workstation (or perhaps on several connected displays), it is likely that you might want X to come up automatically. In many commercial X ports, this may already have been done for you.
This section describes three ways to run X automatically. The first method involves the display manager, xdm, which can run X on a single display or several connected displays. Since the display manager is the recommended method of running X and is extremely flexible, we’re including a fairly detailed discussion of it. The second method is to use xinit, which was introduced in Chapter 2. For those who are still running Release 3, we’ve included a discussion of a third method that runs X from /etc/ttys (on BSD 4.3 systems only). This method has been phased out in Release 4.
Starting X with the Display Manager, xdm (Release 4)
Introduced in Release 3, the display manager, xdm, offers an alternative to running X with xinit (or by the obsolete method, from /etc/ttys). xdm is designed to run the X server from the /etc/rc system startup file. In its most basic implementation, the display manager emulates a login or getty on a standard terminal, keeping the server running, prompting for a user’s name and password, and managing a standard login session.
However, xdm has far more powerful and versatile capabilities. Users can design their own login sessions, using .xsession files. You can also customize special xdm files to manage several connected displays (both local and remote), and to set system-wide and user-specific X resources.
A not so obvious limitation of xdm is that it does not work well if you are using other window systems (in addition to X). If you want to use multiple window systems on the same hardware, you should continue to use xinit for the time being. Future releases of xdm should overcome these limitations.
The functionality of xdm has been expanded in Release 4, though many features have not changed since Release 3. The following sections describe the Release 4 version of xdm. Release 4 specific features are noted. If you are running Release 3, also read the section “Release 3 xdm” later in this appendix.
First, we’ll give you the basics of using xdm to run X on a single display and then give you some tips on how to design your own user session and manage multiple displays.
Getting Started with xdm on a Single Display
To have xdm run X on a single display, the system administrator should perform three simple tasks:
1. Set up the xdm configuration file and other special files, as described in the next section.
2. Put the line /usr/bin/X11/xdm at the end of /etc/rc or other similar system startup file.
3. It’s also a good idea to turn off the “console” in /etc/ttys on a single-user workstation, although this is discretionary. (As we’ll see, the display manager provides its own login window. Turning off the console prevents the standard UNIX prompt from being simultaneously displayed on the full screen when xdm is started. Keep in mind this will also prevent system messages from being sent to the console but they should still be saved in /usr/adm/messages.) How you’d turn off the “console” depends on the version of UNIX you are running. The procedure and the system file you edit may differ from system to system. See the getty(8) and init(8) reference pages in your UNIX documentation for details.
Once you perform these steps, as long as UNIX is running, xdm should keep the X server running, allow users to log on and off, and manage a simple login session.
The following sections describe the steps you need to get started with xdm in greater detail.
Setting Up the Configuration File and Other Special Files
In order to run X, xdm uses a configuration file and several special files that specify such things as the server, basic login session, and an error log file.
Be aware that xdm should be able to work in a very rudimentary fashion without any special files. However, a problem with Release 4 may require that at least two of the special files be present (namely, xdm-config and Xservers). These limitations should be removed by patches to the release. If this bug has been patched and xdm finds no special files, it will still start the server and a login xterm window. This default action can be very helpful, because it allows you to log in even if the special files have been inadvertently removed or corrupted.
Despite the potential to work in a rudimentary fashion without special files, xdm was not intended to be run in this way. For most purposes, system administrators will want to use and very likely customize the special files to have xdm run X in a manner more suitable for the particular system.
The configuration file and some prototypical special files can be found in the config directory under the xdm source directory. (Starting from the top of the X11 source tree, the directory is mit/clients/xdm/config.) Table A-1 lists some of the more commonly used special files for Release 4:
As you can see, the file xdm-pid has been added in Release 4; it represents new functionality. The Xstartup and Xreset files can still be used to affect xdm in Release 4, but there are no default files. We’ll discuss these and some of the other special files in greater detail later in this appendix.
Each of the special files can be specified by an xdm command line option. However, it’s more efficient to specify the files—other than the single xdm configuration file—as resources and put those resources in the configuration file itself. The configuration file shipped with the standard version of X is called xdm-config. The Release 4 version of this file is shown in Figure A-2:
Figure A-2. Default xdm-config file, Release 4
The following three xdm-config file entries have been added in Release 4:
DisplayManager.pidFile: /usr/lib/X11/xdm/xdm-pid
DisplayManager._0.authorize: true
DisplayManager*authorize: false
These entries represent new xdm functionality, which will be discussed later in this appendix. If you are using Release 3, these entries are not applicable. (See “Release 3 xdm” for the appropriate xdm-config file.)
In effect, most of the entries in the default configuration file are just pointers to the other special files xdm uses. Notice also that, in most cases, the configuration file has the same syntax as any resource file. Release 4 introduces a variation from traditional resource syntax, which appears in the following line:
DisplayManager._0.authorize: true
when you specify a display name on the command line). This is because dots and colons have special meaning for the resource manager. (Dots separate resource variable components; a colon signals the end of the variable and the beginning of the value field. See Chapter 9, Command Line Options for more information.) Underscores allow a display name to be treated as a single resource variable component. This syntax variance is applicable only to Release 4. The Release 3 version of xdm compensates for resource syntax anomalies—display name components are separated by dots.
In addition to the variables set in the default xdm-config file, you can specify several other display manager resources in the configuration file. See the xdm reference page in Part Three of this guide for a complete list of resource variables.
To get started using xdm, the system administrator should make a directory (/usr/lib/X11/xdm is suggested) and copy these default special files into it:
• xdm-config.
• Xresources.
• Xsession.
As we’ll see later, each of the standard files can be customized but in many cases the defaults will be sufficient to run X on a single display.*
Next, the system administrator should create an Xservers file containing an entry for the local display. As we’ve said, if the Release 4 xdm has been updated with all relevant patches, the Xservers file is not necessary for xdm to run X on a single display. However, if you are running Release 4 without the relevant patches, xdm has a bug that requires you to set up an Xservers file before xdm can work properly. (The bug also requires an xdm-config file be present) Since setting up an Xservers file is fairly simple to do and a good way to avoid potential problems, we recommend that you do so before placing the xdm command in one of the system startup files.
Most workstations can be run using an Xservers file made up of this line:
:0 local /usr/bin/X11/X
This Xservers file is probably adequate for most workstations. However, if X does not run properly on your single display, you should edit the Xservers file. See “The Xservers File” later in this appendix and the xdm reference page in Part Three of this guide for more information about file syntax.
The Standard Login Session
Once you copy the special files to /usr/lib/X11/xdm and create a single-entry Xservers file, if you want xdm simply to run the X server on the local display, prompt for username and password, and run a simple login session, you should be able simply to add this line to the end of the /etc/rc file:
/usr/bin/X11/xdm
(Depending on your version of UNIX, you may want to add this line to /etc/rc.local, /etc/rc2 or some other file. Consult your operating system documentation. Regardless of the file to which it is added, the display manager should be the last process run.)
After this simple modification, when UNIX is put into multi-user mode, xdm automatically starts the X server and keeps it running.
xdm also takes over the login procedure for displays specified in the Xservers file, supplying username and password prompts normally provided by the getty and login programs. Without modification, xdm provides the login window pictured in Figure 2-2 of Chapter 2, Getting Started.
This login procedure is controlled by the authentication widget (part of the xdm program), which in effect “authenticates” the user and password. You can customize the login window by setting resources for the authentication widget in the Xresources file. (These resources must be set in the Xresources file in the directory /usr/lib/X1/xdm to take effect. They cannot be set in a resources file in a user’s home directory, since that file is not loaded into the resource manager until after the login procedure.) Among the customizable features are the login greeting (by default, Welcome to the X Window System), the size and position of the window, and colors and fonts of the text displayed or typed in the window. See the xdm reference page in Part Three of this guide for a complete list of resources.
Each time a user successfully logs on, xdm looks for a file called .xsession in the user’s home directory. If that file exists and is an executable script, xdm runs it as the user’s login session. The .xsession file should follow the general guidelines for startup scripts described earlier in this appendix.
If you’ve just set up xdm, users may not have written .xsession scripts. If xdm finds no .xsession file in a user’s home directory, it provides a default session, consisting of the following commands (excerpted from the standard Xsession file):
resources=$HOME/.Xresources
xrdb -load $resources
twm &
exec xterm -geometry 80x24+10+10 -ls
This default session has three elements: First, xdm checks the user’s home directory for a file called .Xresources. If that file exists, it is loaded into the resource manager with xrdb. Second, the window manager, twm, is started. Third, the console xterm window is started with a login shell (-ls) in the foreground.
After this basic session has been started, the screen looks something like Figure 2-3 and the user is ready to work.
Customizing xdm
The display manager can do far more than run the simple session described above. Any of the special files can be edited to customize the display manager for your site. For example, by editing the Xservers file, you can set up xdm to run multiple displays, such as X terminals.*
Remember that, if xdm has been modified with the proper Release 4 patches, none of the special files (not even the xdm-config file) is absolutely necessary to run X on a single display. In a worst case scenario—if all the special files are removed or corrupted—xdm has reasonable defaults that will allow you to log in and work. Depending on your system configuration, you may elect not to use some of the special files. For example, the Release 4 xdm works well without Xstartup and Xreset files in many environments. As we’ve said, if no Xsession is specified, xterm is executed, etc. (If you decide not to use one of the special files listed in the default xdm-config file, remember to remove the pointer to it from the file!)
What the special files provide is the flexibility to configure xdm for your site, perhaps running X on several displays, each possibly with a different default session, different resources for the authentication widget, etc.
If you examine the default configuration file, you’ll notice most of the resources are specified with loose bindings. This means that the specified resource (for example, Xsession) will apply to all displays being run by xdm. By using tight bindings in the configuration file, you can also specify resources that only take effect on a specific display. To specify a resource for a particular display, just insert the name of the display between DisplayManager and the final resource variable. For example, say xdm is running X on a workstation (named : 0) and a connected X terminal (visual:0). You could specify two different default sessions by using resource definitions (in the configuration file) similar to the following:
DisplayManager._0.session: /usr/lib/X11/xdm/Xsession. ws
DisplayManager.visual_0.session : /usr/lib/X11/xdm/Xsession.visual
Note that an xdm resource specification uses an underscore in place of the colon in a display name. (As discussed earlier, the use of underscores has been introduced in Release 4. The Release 3 syntax is discussed in the section “Release 3 xdm” later in this appendix.) You should match the display name syntax for resources intended to be used on the same display. For example, you might have the following resources variable settings to match the session resource specifications above:
DisplayManager._0.resources: /usr/lib/X11/xdm/Xresources.ws
DisplayManager.visual_0.resources: /usr/lib/X11/xdm/Xresources.visual
The following sections discuss some possible customizations of the default special files. With the vast number of possible system configurations and user preferences, you should consult the xdm reference page in Part Three of this guide for more information.
The Xservers File
The Release 4 xdm source directory contains two sample Xservers files, Xservers.ws and Xservers.fs, which illustrate file entries for workstations and file servers (such as X terminals), respectively. To run xdm on a single workstation, you should create an Xservers file using the Xservers.ws file as a guide. As we’ll see later, in most circumstances, you must edit the Xservers file to specify additional displays for xdm to manage.
Each entry in the Xservers file usually has three or four elements: the display name, an optional display class, the display type, and the server program name (and its arguments, typically the display number). (Since an X terminal runs its own server, the final argument can be a comment, such as “Joe’s X terminal.”) Possible display types are described on the xdm reference page in Part Three of this guide.
Most workstations have a single display numbered 0 of the type local, as illustrated by the typical Xservers file entry for a workstation:
:0 local /usr/bin/X11/X
The display class part of the Xservers entry is new as of Release 4. The sample entry above does not contain a display class, but it would normally be the second part, between the display name and type, as in the following:
:0 display_class local /usr/bin/X11/X
The display class is determined by the machine you are using and should be provided by the hardware vendor. The use of the display class is related to an underlying feature of the Release 4 xdm, the X Display Manager Control Protocol (XDMCP), which is described later in this appendix. For now, suffice it to say that, in most circumstances, you do not have to supply a class name within an Xservers file entry.
For xdm to run sessions on most X terminals, you must add specifications for these displays to the Xservers file, using the sample file Xservers.fs from the xdm source directory as a template. For instance, say you have two X terminals hooked up to a workstation. (As of Release 4, most X terminals are of the display type foreign. In Release 3, most X terminals are of the display type transient.) Your Xservers file might look like this:
:0local /usr/bin/X11/X
visual:0 foreign Lucy's Visual
ncd:0 foreign Ricky's NCD16
Notice that the final element of each X terminal entry is a comment. Using this Xservers file, xdm provides login windows on the two X terminals, as well as the workstation, and runs a session for any user who logs on.
If you edit the Xservers file while the server is running, xdm will not be aware of the changes. You can make xdm reread the Xservers file (or another file specified by the resource DisplayManager.servers) by sending the xdm parent process a SIGHUP. Use the UNIX kill command with the -HUP option (for SIGHUP) and the process ID number of xdm.
It’s likely there will be multiple xdm processes, since the program forks a child process for every display it’s managing. As of Release 4, the ID of the parent process is stored in the file specified by the resource DisplayManager.pidFile—usually /usr/lib/X11/xdm/xdm-pid.
% kill -HUP process-ID
If a new entry has been added, the display manager starts a session on that display. If an entry has been removed, the display manager terminates any session on that display without notice and no new sessions will be started.
Once you edit the Xservers file to reflect the different displays you want to manage, you can enter other display-specific resources in the configuration file.
Be aware that communication problems can arise between the display manager and many autonomous displays (primarily X terminals). If the main display is powered off or reset, xdm may not detect that the server has been stopped and restarted, and thus may not send new login windows to connected displays. In the spring of 1989, the X Consortium proposed a standard protocol between displays and display managers that would avert these problems. The X Display Manager Control Protocol (XDMCP) has been adopted and is implemented by the Release 4 xdm, but not all X terminals implement it yet. We’ll discuss the goals of this protocol at greater length in “X Terminals and the XDM Control Protocol” later in this appendix. For now, be aware that the XDMCP will eventually eliminate the need for Xservers file entries for X terminals. Currently, however, chances are that your X terminal does not understand the XDMCP and requires an Xservers file entry.
The Xsession File and .xsession Scripts
Depending on the needs of your site, you can edit the Xsession file to make the default session anything you want. You can specify an alternative window manager, perhaps even use another program to load resources, and execute any combination of clients.
Another strength of xdm is that it provides for each user to design his own .xsession file. See “A Startup Shell Script” earlier in this appendix for more information on writing a .xsession file.
Be aware that if you’re testing a .xsession script and it doesn’t work, by default xdm will not let you log in (using the normal method) to fix it. However, xdm does provide an escape hatch for these situations, which is explained in “The Xresources File” below.
The Xresources File
The Xresources file is where you should specify resources for the authentication widget. See the xdm reference page in Part Three of this guide for a complete list of resource variables.
As of Release 4, the default Xresources file contains the following event translations, which allow users to log in if a .xsession script doesn’t work:
xlogin*login.translations: #override\
<Key>F1: set-session-argument(failsafe) finish-field()\n\
<Key>Return: set-session-argument() finish-field()
This translation table specifies that if you type the F1 key (rather than Return) after your password when logging in, a “failsafe” session, consisting of a simple login xterm window, will be executed. This will enable you to edit the non-functioning .xsession file. See the xdm reference page in Part Three of this guide for more information. (See Chapter 9, Setting Resources, and Appendix H, Translation Table Syntax, for a discussion of event translations.)
The Error Log File
xdm errors are normally printed to the console. It’s wise to redirect them to a file. The default configuration file sets the resource DisplayManager.errorLogFile to /usr/lib/X11/xdm/xdm-errors. The xdm-errors file can be very helpful if you are testing various xdm configurations.
The xdm-pid File (Release 4 Only)
Added to xdm as of Release 4, the xdm-pid file stores the ID number of the xdm parent process. If you edit the Xservers file while the server is running, xdm will not be aware of the changes. You can make xdm reread the xdm-config file and the Xservers file (or another file specified by the resource DisplayManager.servers) by sending the xdm parent process a SIGHUP.
To make xdm aware of changes to the Xservers file, use the UNIX kill command with the -HUP option (for SIGHUP) and the process ID number of xdm stored in the xdm-pid file. (See “The Xservers File” earlier in this appendix for an example.)
Xstartup and Xreset
As stated previously, the Xstartup and Xreset files mentioned in Table A-1 can still be used to affect xdm in Release 4, but there are no default files; thus, they are not specified in the default configuration file.
The Xstartup file is intended to be a script that is run as root before starting the user session. You might want to write a script containing commands to make fake entries in /etc/utmp, mount users’ home directories from file servers, display a message of the day, or abort the session if logins are not currently allowed.
The Xreset file is intended to be a script that is run as root after a user session has been ended. You might want to write a script to undo the effects of commands in Xstartup, perhaps removing fake entries from /etc/utmp, or unmounting directories from file servers.
See the xdm reference page for more information about the Xstartup and Xreset files.
Security and the authorize Resource (Release 4 Only)
In addition to pointers to several special files, the xdm-config file contains the following resource specifications:
DisplayManager._0.authorize: true
DisplayManager*authorize: false
Available as of Release 4, the authorize resource represents a new method of security for X, which xdm can be set up to provide. The first resource specification above sets a user-based server access scheme to work on the local display. The second one turns the scheme off on all other displays. These defaults should be compatible with running X on the local display and most X terminals that might be connected to it. See “User-based Access: xdm and the .Xauthority File” later in this appendix and the xdm reference page in Part Three of this guide for more about authorization.
Stopping xdm and the Server
By default, xdm automatically restarts the server if the server is killed. If you don’t want this boomerang effect, set the following resource in the xdm-config file:
DisplayManager.DISPLAY.terminateServer: true
Then if you kill the server and all xdm processes, X will exit.
X Terminals and the XDM Control Protocol (Release 4)
The X Display Manager Control Protocol (XDMCP), introduced at Release 4, facilitates the connection of X terminals to remote hosts via xdm. From a user’s standpoint, the main advantage of XDMCP is that it allows you to turn an X terminal off and on again, while maintaining the connection to the remote host. When you turn on an X terminal, xdm should automatically display a login window. The exchange of information between the X terminal and the remote host is invisible to the user. In fact, XDMCP and xdm are intended to make X terminals as easy to use as traditional character terminals. Under the X Display Manager Control Protocol, an X terminal basically requests a connection to a remote host, is recognized by the host, and is sent a login prompt by xdm.
Prior to the adoption of this protocol, xdm was not equipped to reconnect to X terminals that had been turned off and on again. In most cases, X terminals had to be left on at all times. If a terminal was turned off, it was often necessary to kill the associated xdm process; xdm would then restart itself and reestablish the connection, again displaying the login window.
XDMCP is intended to solve problems like this. Be aware, however, that the X terminals in question must be programmed to interpret XDMCP or modified to do so. At the time of Release 4, virtually no X terminals in the market supported XDMCP. Protocol-compatible X terminals should become available in increasing numbers by the fall of 1990. If you’re using an older X terminal, chances are that the programs controlling it must be upgraded to communicate via XDMCP.
If you are using X terminals at your site, the way you set up xdm partially depends on whether the terminals can communicate via the XDMCP. If a terminal can’t communicate in this way, the Xservers file must include an entry for it and the terminal must be left on at all times to maintain the connection to the host via xdm. If a terminal can communicate via the protocol, no Xservers file entry is necessary and the terminal can be turned on and off, while still maintaining the connection to the host Refer your X terminal documentation to find out whether it’s XDMCP compatible.
The XDMCP helps clarify the actual purpose of the Xservers file. The file is actually a list of displays to which xdm must perpetually maintain a connection. By contrast, the XDMCP is a dynamic mechanism whereby connections are made when requested by a display, such as a workstation or a newer X terminal, that can communicate via the protocol.
XDMCP also affects the Xservers file entry for the host. If you are running Release 4, it is recommended that the Xservers file entry for the host include a display class name, which should be provided by the hardware manufacturer. You can use this name in the xdm-config file to specify resources by display class, rather than by individual display.
Release 3 xdm
The Release 3 version of xdm is somewhat simpler to get started with, albeit somewhat less powerful, than the Release 4 version. This section highlights the Release 3 specifics. We assume you have already read the preceding sections describing the Release 4 version.
The Release 3 xdm provides sample files that are probably adequate to run X on most workstations. (A sample Xservers file intended for use on a workstation is included in the Release 3 xdm source directory.) In order to have xdm run X on a single display, simply perform the following three steps:
1. Create a directory called /usr/lib/X11/xdm. Copy the default versions of the files from the config directory under the xdm source directory into the new directory.
2. Put the line /usr/bin/X11/xdm at the end of /etc/rc or other similar system startup file.
3. It’s also a good idea to turn off the “console” in /etc/ttys on a single-user workstation, although this is discretionary. (Since the display manager provides its own login window, turning off the “console” prevents the standard UNIX prompt from being simultaneously displayed on the full screen when xdm is started. Keep in mind this will also prevent system messages from being sent to the console, but they should still be saved in /usr/adm/messages.) How you’d turn off the “console” depends on the version of UNIX you are running. The procedure and the system file you edit may differ from system to system. See the getty(8) and init(8) reference pages in your UNIX documentation for details.
Once you perform these steps, so long as UNIX is running, xdm should keep the X server running, allow users to log on and off, and manage a simple login session.
The Release 3 xdm should be able to run X on a single workstation without any special files, though it was not intended to be used in this manner. If xdm finds no special files, it will still start the server and a login xterm window. This default action can be very helpful, because it allows you to log in even if the special files have been inadvertently removed or corrupted. For most purposes, however, system administrators will want to use and very likely customize the special files to have xdm run X in a manner more suitable for the particular system.
Release 3 Special Files and the Config File
The Release 3 xdm recognizes most of the same special files and resources as the Release 4 version (see Table A-1), with the following exceptions: the xdm-pid file and the authorization resource setting are available in Release 4 only.
The Release 3 version of the xdm-config file is shown in Figure A-3:
Figure A-3. Default xdm-config file, Release 3
The Release 3 default Xservers file, in Figure A-4, is probably adequate for most workstations.
Figure A-4. Typical Xservers file for a workstation, Release 3
However, if X does not run properly on your single display, you should edit the Xservers file to reflect the local display name. You must also edit the Xservers file to specify additional displays for xdm to manage. See “Managing Multiple Displays: the Release 3 Xservers File” later in this appendix.
Customizing the Release 3 xdm
Like the Release 4 version, the Release 3 version special files provide the flexibility to configure xdm for your site, perhaps running X on several displays, each possibly with a different default session, different resources for the authentication widget, etc. (If you decide not to use one of the special files listed in the default xdm-config file, remember to remove the pointer to it from the file!)
Most of the resources specified in the default configuration file have loose bindings, indicating that the resource applies to all displays being run by xdm. By using tight bindings in the configuration file, you can also specify resources that only take effect on a particular display. To specify a resource for a particular display, just insert the name of the display between DisplayManager and the final resource variable. For example, say xdm is running X on a workstation (:0) and a connected X terminal (visual:0). You could specify two different default sessions by using resource definitions (in the configuration file) similar to the following:
DisplayManager..0.session: /usr/lib/X11/xdm/Xsession.ws
DisplayManager.visual.0.session: /usr/lib/X11/xdm/Xsession.visual
Note that an xdm resource specification uses a dot in place of the colon in a display name. (This is different from the syntax expected by Release 4, in which underscores are used between the parts of a display name.) You should match the display name syntax for resources intended to be used on the same display. For example, you might have the following resources variable settings to match the session resource specifications above:
DisplayManager..0.resources: /usr/lib/X11/xdm/Xresources.ws
DisplayManager.visual.0.resources: /usr/lib/X11/xdm/Xresources.visual
The following sections describe Release 3 specific features that may affect customization and discuss possible customization of some of the default special files. You should first have read the sections on customizing the Release 4 version of xdm earlier in this appendix. With the vast number of possible system configurations and user preferences, you should also consult the xdm reference page in Part Three of this guide for more information.
Managing Multiple Displays: the Release 3 Xservers File
If you are running Release 3, you must edit the Xservers file to specify additional displays for xdm to manage.
In Release 3, each entry in the Xservers file has three elements: the display name, the display type, and the server program name (and its arguments, in most cases the display number). (Since an X terminal uses a remote server, the third argument can be a comment, such as “Ethel’s X terminal.”)
Most workstations have a display numbered 0 of the type local, so the Xservers file should look like this:
:0 local /usr/bin/X11/X :0
You can also add specifications for additional displays, such as X terminals. In Release 3, X terminals have the display type transient. (In Release 4, this has been changed to foreign.) To add a single X terminal, you might create a file similar to the following:
:0 local /usr/bin/X11/X :0
visual:0 transient Andy's Visual
Notice that the third element of the X terminal entry is a comment. Using this Xservers file, xdm provides login windows on the workstation and the X terminal, and runs login sessions for any users who log in.
Be aware that communication problems can arise between the display manager and many displays. If the main display is powered off or reset, xdm may not detect that the server has been stopped and restarted, and thus may not send new login windows to connected displays. The X Display Manager Control Protocol, introduced in Release 4, is designed to avert these problems. (See “X Terminals and the XDM Control Protocol (Release 4)” earlier in this appendix for more information.) However, if you are still running Release 3, the safest way to keep xdm running X on an X terminal is to leave the terminal on.
If you edit the Xservers file while the server is running, xdm will not be aware of the changes. You can make xdm reread the Xservers file (or another file specified by the resource DisplayManager.servers) by sending the xdm parent process a SIGHUP. Use the UNIX kill command with the -HUP option (for SIGHUP) and the ID number of xdm’s parent process, as in the following example:
% kill -HOP process-ID
It’s likely there will be multiple xdm processes, since the program forks a child process for every display it’s managing. As a general rule, send the signal to the lowest numbered xdm process. (As we’ve seen, in Release 4, the xdm-pid special file contains the relevant process ID number.)
If a new entry has been added, the display manager starts a session on that display. If an entry has been removed, the display manager terminates any session on that display without notice and no new sessions will be started.
If the xdm connection to an X terminal is interrupted, you should also be able to reestablish it by sending a SIGHUP to the xdm parent process.
Once you edit the Xservers file to reflect the different displays you want to manage, you can enter other display-specific resources in the configuration file.
Release 3 .xsession Scripts
Be warned that if you’re testing a .xsession script and it doesn’t work, by default xdm will not let you log in (under the same login name) to fix it. While the default Release 4 version of xdm provides an escape hatch for these situation, the Release 3 version does not. We strongly suggest that you set one up using “The Xresources File.”
Release 3 Xresources File
To give users a way to log in if a .xsession script doesn’t work, place the following event translations in the Xresources file:
xlogin*login.translations: #override\
<Key>F1: set-session-argument(failsafe) finish-field()\n\
<Key>Return: set-session-argument() finish-field()
This translation specifies that if you type the F1 key (rather than Return) after your password when logging in, a “failsafe” session, consisting of a simple login xterm window, will be executed. This will enable you to edit the non-functioning .xsession file. [This translation table has been added to the default Xresources file in Release 4.]
The Xresources file is also where you should specify resources for the authentication widget. See the xdm reference page in Part Three of this guide for a complete list of resource variables. (See Chapter 9, Setting Resources, and Appendix H, Translation Table Syntax, for a discussion of event translations.)
Release 3 Xstartup and Xreset
The Release 3 version of xdm includes default Xstartup and Xreset files that contain nothing more than a comment. You can use these files to specify custom startup and reset procedures. See “Xstartup and Xreset” under the discussion of the Release 4 xdm, earlier in this appendix. Also see the xdm reference page in Part Three of this guide for more information about the Xstartup and Xreset files.
Starting X with xinit
The xinit program is used to start the server and a first client program, by default an xterm window. Starting X manually with xinit is described in Chapter 2, Getting Started. You can also use xinit to start X automatically.
The easiest way to do this is to run xinit from your .login or .profile file. (If you are using System V, this may be the only reliable way to run xinit.)
xinit will look in your home directory for a file called .xserverrc to run as a shell script to start up the server. If there is no such script, xinit will start the server X on the display :0.
xinit will also look in your home directory for a file called .xinitrc to run as a login script, such as the one described earlier in this appendix. If no such script is found, it will execute a login xterm window.
With System V only, you might try to run xinit from the terminal initialization file /etc/inittab. This file is analogous to the BSD 4.3 /etc/ttys. The /etc/inittab file normally has an entry for each serial port on a system, plus several entries that are used during the boot process. Note that the concept of pseudo-terminals, or ptys (which X relies on) is foreign to System V. All System V servers will have had to do some system hacking to add support for ptys. How this is done will vary from system to system. As a result, we’re going to beg off on describing inittab in detail, and refer you to your system documentation. Again, it is also possible that there will be problems with the controlling tty.
See the xinit reference page in Part Three of this guide for more information.
An Older Method of Starting X: /etc/ttys
For Release 3, this method was supported only for backwards compatibility with older releases of X. As of Release 4, it is not supported. In either case, system administrators should switch to xinit or xdm.
On BSD 4.3-derived systems, you can start X automatically from the /etc/ttys terminal initialization file.* This file normally contains a list of terminals on which a login prompt should be printed by the getty program. For X, this file can be used instead to start xterm for a pseudo-terminal. A typical line to start X from the /etc/ttys file might have the following format:
BSD 4.3 /etc/ttys
| Field | Function in /etc/ttys |
| devname | The name of the special file in the dev directory that corresponds to the device. For X, the pseudo-terminal with the highest minor device number (e.g. /dev/ttyqf and /dev/ptyqf) is normally renamed /dev/ttyv0 and /dev/ptyv0. For systems with more than one display, the next highest pty is used for the second display, and so on. |
| command | The command to be run by init. This is normally getty, but can be another command, such as the command to start a window system. In this example, xterm is run with the -L option, which causes getty to be run in the xterm window rather than the shell. (The -L option is not supported in Release 4.) The window is placed in the top right corner of the screen. Since spaces and tabs are used to separate fields in /etc/ttys, the entire command must be quoted.Note that some implementations of init have relatively small program name buffer sizes, so you may find you can’t list many xterm options. In addition, because the # character is used as a comment symbol in /etc/ttys, you may have difficulty specifying colors (say for an xterm window background) using the hexadecimal color syntax. If you run into either of these problems, you may want to write a small program that runs xterm with the desired arguments, and have init run that instead. |
| ttytype | The name of the terminal attached to the line. This should be the name as defined in the /etc/termcap terminal database. In the example above, it is specified as xterm. Note that the presence of the terminal type field in the BSD 4.3 ttys replaces the /etc/ttytype file that was used for this purpose in earlier BSD versions. |
| status | The word on if the command is to be executed, or off if it is not. Additional flags may be specified after on or off. The word secure must be present to allow root to log in on a particular terminal. The flag window ="command" specifies a window system command to be executed by init before it starts xterm. This should be the command to start the X server, as shown in the example. |
| comment | Comments can appear anywhere in the file. They are introduced by #, and are terminated by a newline. |
Server Access Control
X runs in a networked environment. Because of X’s design, your workstation is no longer your private preserve, but hypothetically, can be accessed by any other host on the network. This is the true meaning of the server concept: your display can serve clients on any system, and clients on your system can display on any other screen.
The possibilities for abuse are considerable. However, there are two access control mechanisms, one host-based and one user-based. The host-based scheme involves a system file (/etc/Xn.hosts) and can be controlled using the xhost client. The user-based scheme involves authorization capabilities provided by the display manager, xdm, as of Release 4, and depends upon the newly introduced X Display Manager Control Protocol (XDMCP). As we’ll see, since most X terminals cannot interpret the XDMCP at this time, the usefulness of this latter access control mechanism is currently somewhat limited.
These two access control methods are discussed briefly in the following sections. For more information, see the Xserver, xhost, xdm, and xauth reference pages in Part Three of this guide.
Host-based Access and the xhost Client
The /etc/Xn.hosts file (where n is the number of the display) contains a list of systems that are allowed to access the server. By default, this file contains only the name of the local host. Edit this file so that it contains the list of systems you want to have access to your server on a regular basis.
The xhost client can be used to give (or deny) systems access to the server interactively, possibly overriding the contents of /etc/Xn.hosts. (The xhost client can also be run from a startup script.) Note that this is really only sufficient for a single-user workstation environment, however.
Specifying a host name (with an optional leading plus sign) allows the host to access the server, and specifying a host name with a leading minus sign prevents a previously allowed host from accessing the server. Multiple hosts can be specified on the same line. Running xhost without any arguments prints the current hosts allowed to access your display.
For example, to add the hosts jupiter and satum, and remove neptune:
% xhost +jupiter satum -neptune
It is possible to remove the current host from the access list. Be warned that you can’t undo this without logging out.
Note that when a remote system is denied access to your display, it means two things: that a person working on the remote system can’t display on your screen, and that you can’t use that remote system for running clients you want displayed on your screen.
User-based Access: xdm and the .Xauthority File (Release 4)
As of Release 4, the display manager and its control protocol (XDMCP) provide a user-based access control mechanism, which can be used to supplement or replace the host-based access mechanism discussed in the previous section. The Release 4 xdm can be set up to provide user authorization on a particular display (see “Security and the authorize Resource” earlier in this appendix). If authorization is enabled, when you log in, xdm places a machine-readable access code, known as a magic cookie, in a file called .Xauthority in your home directory. xdm also makes this magic cookie available to the server.
The magic cookie defined in a user’s .Xauthority file is basically a secret code shared by the server and a particular user logged in on a particular display. When the user runs a client on the local display, the server checks to see whether the client program has access to the magic cookie. All processes started by the user in question have that access, and thus the server allows the client to be run on the display. Basically, under the magic cookie authorization scheme, a display becomes user-controlled. (Once xdm creates an .Xauthority file for a user, each time the user logs on, xdm merges in authorization codes (magic cookies).)
The access afforded by magic cookies is not as broad as that afforded by the host-based mechanism. When a system relies entirely on host-based access, any machine on the list of approved hosts can connect to the system. Thus, generally, any user logged on to an approved host can access any display connected to the system. This is somewhat feeble security. User-based access control is a little safer.
Be aware, however, that, currently, user-based access control cannot provide security for all X terminal users. This method of access control relies on the X Display Manager Control Protocol and few X terminals in the current market are programmed to understand the protocol. However, user-based access can be used effectively on workstations running Release 4 and on many of the newer X terminals.
The security mechanism provided by the magic cookie is evident in a situation in which another user tries to run a client on your machine. The server requires the client run by the other user to have access to the magic cookie shared exclusively between you and the server. The other user cannot provide the proper authorization code, and thus cannot run a client on your host.
Of course, in many cases, users in a network will want to run clients on several machines (while displaying the client window on their local displays). This can be done if a user supplies authorization information associated with his local machine (or X terminal display) to the remote host. X developers have provided a new client, xauth, to allow users to transfer this information. Basically, xauth is a utility to manipulate .Xauthority files.
The most common use for xauth is to extract a user’s authorization information for the current display, copy it to another machine, and merge it into the server’s authorization records on the remote machine, as in the following:
% xauth extract - $DISPLAY | rsh host2 xauth merge -
The dash (-) arguments indicate that extracted authorization records should be written to the standard output and that the xauth merge function should accept records from standard input. This command supplies the remote server with authorization information, allowing the user to run a remote shell on that host See the xauth reference page in Part Three of this guide for more information.
If an installation is using remote file sharing, such as NFS, then sharing authorization records may not be an issue. If every user has a single home directory that is accessible to all machines, the machines have access to the necessary .Xauthority files at all times. In such an environment, users should be able to run programs on any of the networked machines without using xauth.
When user-based access control fails (for example, when a null or invalid magic cookie is offered to the server), host-based access takes over. To be more specific, say for example a user is logged on at an X terminal that is not XDMCP compatible, and thus the user has no .Xauthority file (i.e., magic cookie). If that user tries to open a window on the remote console display, the client window cannot access a magic cookie. (The host interprets this as a null cookie.) Then host-based access control takes over. If the user in question is working on a system authorized in the /etc/Xn.hosts file, he should be authorized to run a client on the console display.
Font Management
In Release 3, the X Consortium adopted the Bitmap Display Format (BDF) as the (non-exclusive) standard font format. BDF font files must be compiled to produce SNF (Server Natural Format) font files, which can be used by the server. (These font files have a .snf extension.)
The standard fonts shipped with X should already be compiled. If you add BDF font files to the system, the files must be converted to SNF format using the program bdftosnf. The showsnf program displays the SNF font file so you can check that it compiled properly. See the bdftosnf and showsnf reference pages in Part Three of this guide for details.
Once a new font is moved to the directory you want (perhaps /usr/lib/X11/fonts/misc), you must add the font to the font database (fonts.dir file) used by the server. To do this, run mkfontdir with the directory as an argument, as in the following:
% mkfontdir /usr/lib/X11/fonts/misc
An entry for the new font is added to the fonts.dir file. You should also edit the fonts.alias file if you want to add an alias for the new font.
Then the server must be made aware of the new font. The command:
% xset fp rehash
makes the server reread the font databases and alias files in the current font path.
If you are using a server other than the standard release, the server developer should provide a program to convert BDF font files to a format appropriate for the server.
Console Messages
On a single-user workstation, it is likely that the screen used for running X is also used as the system console.
If X is started manually, the console will be the first window to appear on the screen. But if X is started from your .login file, console messages from the kernel may sometimes appear on the screen, overlaying the X windows. They make a nasty mess of the screen, but the display can be refreshed and the console message erased by running the client xrefresh (described in Part Three).
Some implementations of X support a -C option to xterm that redirects messages sent to /dev/console to that xterm window. If this option is supported, you should add the -C option to the console xterm in your startup file. After this window is mapped (displayed on the screen), all such messages are displayed there.
Log Files
The X server creates log files useful in fixing a problem that might occur. These files are located in /usr/adm.
You should make provisions to trim these files periodically. As with all log files, you can do this automatically with an entry in the crontab file.
Changing the Color Name Database
The X Window System comes with a predefined set of colors, listed in the file /usr/lib/X1/rgb.txt. You can use these color names to specify colors either on the command line or in a resources file. If you have the X sources, you can customize the color name database using the following procedure.
1. Edit the rgb.txt source file, which is located in the mit/rgb directory, to change or add colors. The format of a line in the rgb.txt file is:
red green blue color_name
The red, green, and blue values are integers in the range 0 to 255; the color name is case insensitive, but must not include any special symbols. A typical entry in the rgb.txt file is:
127 255 212aguamarine
See Chapter 8, Command Line Options, for more about color specifications.
2. Run the rgb program using the makefile also located in the mit/rgb directory. This program converts the text file (rgb.txt) to a UNIX dbm(1) format file (rgb.dir), which is used as the color database. Just type:
% make
3. Then install the new rgb.dir file in /usr/lib/X11 by typing:
% make install
If the color name database gets corrupted in some way (e.g., written to accidentally), the server may not be able to find any colors with which to display. On a black and white workstation, you may get error messages similar to the following:
X Toolkit Warning: Cannot allocate colormap entry for White
X Toolkit Warning: Cannot allocate colormap entry for Black
X Toolkit Warning: Cannot allocate colormap entry for white
X Toolkit Warning: Cannot allocate colormap entry for black
If you get errors of this sort, perform steps 2 and 3 in the procedure described above. This will overwrite the corrupted rgb.dir file.
*This topic isn’t really part of system management, but since we assume most people know how to do it, we didn’t want to clutter up Chapter 2 with unnecessary discussion. On the other hand, the information is critical for those who don’t already know it, so we wanted to put it somewhere!
*If you are still starting the X server from /etc/ttys file, as described later in this appendix, this will bring up an xterm window with a login prompt. In this case, you can run the script to start other clients from your .login file. Note, however, that this method of starting the X server is not supported in Release 4.
†Thanks to Dave Curry for his help in preparing this sample.
*Note that this file was developed for and run on a Sun workstation. Differences in pixel sizes may make the coordinates and sizes of various windows come out differently on other hardware.
*For our purposes, we are talking about the default special files provided with the standard release of X. Keep in mind that you can rewrite the resource definitions is the xdm-config file to specify files of any name (in any directory) as the so-called special files. (The configuration file also can have any name you like and be stored in any directory.) If you use a filename other than xdm-config. you need to specify that filename (and its explicit path) with the -config option after the xdm command. See the xdm reference page in Part Three of this guide for more information.
*Generally, this modification is required for xdm to run sessions on X terminals. However, as we’ll see, an increasing number of X terminals do not require an Xservers file entry in order to be controlled by xdm. See “X Terminals and the XDM Control Protocol (Release 4)” later in this appendix.
*Note that the technique described here will not work on earlier BSD systems, Xenix, or other systems which use the pre-BSD 4.3 ttys format.
Get X Window System User's Guide for X11 R3 and R4 of the X Window System now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
