in my collection.
The IBM X-station 130 is a very nice little X-server (terminal) which boots
its operating code and retrieves its font (typeface) information from another
server, usually one running IBM's AIX operating system. This document will
show the reader how to run the X-station 130 without benefit of a companion
AIX server. Much of the information used in this document was taken from
a manual on IBM's WWW site, The IBM Xstation Handbook .
The rest of it was acquired by experimentation with the
X-station 130
in my collection.
Note that you, the reader, must acquire the X-station operating code on your own; I cannot assist in this as I would be breaking all manner of license agreements. That said, the code may be lifted from any RS/6000 which has the "x_st_mgr" product on it.
The "IBM Xstation Handbook" strongly suggests that the 130 requires an AIX companion to serve the 130's boot code and fonts and provide login services. However, it is possible to run the 130 in a completely non- AIX environment. My intent with this document is to demonstrate to hobbyists, and others who may have a 130 but no systems capable of running AIX, that the 130 can be successfully put to use.
The 130 can be configured to boot over the integral Ethernet interface, a SLIP line or, if the machine is so equipped, a token- ring link. I boot mine over Ethernet because that's what my LAN, for the most part, runs over. I haven't tried booting it using the optional token- ring card, nor SLIP. This document will cover Ethernet only, although the others should be fairly self- explanatory.
The X-station 130 supports both AUI-style (10-Base5, aka "thick-wire" Ethernet) and 10-Base2 ("thin-wire") Ethernet; there are internal jumpers that are set depending on which style of attachment one desires. The jumpers are on a block labelled "JP2". JP2 may be found by opening the machine up and, holding the machine with the power switch towards you looking toward the rear of the motherboard (the "planar" in IBM parlance), is located near the AUI (15-pin) connector. Thin-wire is selected by placing all the jumpers to span the "middle-to-rear" pins and thick-wire by spanning the "middle-to-front" pins. Note that the machine will not talk on the network if the jumpers are incorrectly set.
Most environments today will probably use 10-BaseT transceivers that plug into the 15-pin AUI connector. This calls for the "thick-wire" setting described above.
There are a number of different ways to get the 130 to work, "out of the box" in a non- AIX environment. Here are a few of them:
In a statically- configured environment, the 130 must be properly configured to contact the machine which stores the 130's boot code and font information. This is done in the setup screens which are accessed by pressing <F12> during the boot procedure. In this instance all the boot- time information must be provided. The Xstation-130 has a NVRAM (Non- Volatile RAM) subsystem in it, so it'll store the configuration across power- downs.
When the machine is first powered on, it will attempt to boot to the last host it was configured to contact; to interrupt this process, and enter the network configutation screens, one presses the <F12> key. This will place the operator at the first, or SLIP, configuration screen. Mine, in the static configuration, looks roughly like this:
Network Setup Page 1
-----------------------------------------------
Primary Network..................Ethernet
Enable SLIP......................NO
Serial Port...................SERIAL 1
Baud Rate.....................9600
Terminal Internet Address.....
Host Internet Address.........
Subnet Mask...................
Dial String...................
Disable Bootp.................YES
TFTP File Name.............
Tag Field..................
-----------------------------------------------
Advancing to the next page (with <Page Down>), the second page of configuration in my setup contains:
Network Setup Page 2 ----------------------------------------------- Ethernet/IEEE 802.3 ..............Automatic Gateway Internet Address ......... Terminal Internet Address ........192.168.1.9 Host Internet Address ............192.168.1.1 Disable BOOTP ....................YES TFTP File Name ................/var/tftp/Xstation/boot/bootfile4 Tags Field .................... -----------------------------------------------
The "Terminal Internet Address" is the IP address of the X-station 130; the "Host Internet Address" is the IP address of the server which contains the 130's boot code and fonts. Note that this need not be the same machine as the login server. The 130 is capable of gathering this information via bootp, for a discussion of that mode, see the Dynamic Configuration section.
The "TFTP File Name" above points to the name of the secondary boot loader which is loaded into the 130 which subsequently loads the main X-server operating code.
On the boot server, I enabled TFTP in the /etc/inetd.conf file by placing into it a line like:
tftp dgram udp wait root /usr/sbin/tcpd in.tftpd /var/tftp /tmp
Note that this makes use of an IP wrapper so I can control who gets into my TFTP server. As TFTP is incapable of any sort of authentication, it's considered prudent to control who and what gets access to the server, and even then chroot them to someplace safe. Linux is actually quite good about this; the above entry will only allow TFTP access to the "/var/tftp" and "/tmp" directories. The code and fonts live in a subdirectory of the "/var/tftp" directory. A paging file is created by, but seems unused by, the 130 and lives in "/tmp".
In that "/var/tftp" directory tree are all the things that the 130 needs to run efficiently and be happy. See the disclaimer above about the server code.
The fonts can be had by gunzipping the pcf font files on a Linux machine and building the appropriate "fonts.dir" and "fonts.alias" files. This is what I have in "/var/tftp" on my boot server:
/var/tftp: Xstation/ tmp/ Xstation: boot/ <--- Boot and Operation code directory fonts/ <--- X Fonts directory rgb.txt <--- Colour descriptor database rsh.sh* <--- Logon startup commands Xstation/boot: bootfile4 <--- Xstation bootstrap code x11xor4.out <--- X11R4 server code bootfile4.cf <--- Server configuration data (see below) keymap.kj <--- Kanji keymap file keymap.wt <--- Keymap file (locale unknown) keymap.us <--- US keymap file msg <--- (empty in my configuration) Xstation/fonts: <--- Standard X11 PCF fonts 10x20.pcf clR6x6.pcf helvBO14.pcf lubBI10.pcf ncenI24.pcf 12x24.pcf clR6x8.pcf helvBO18.pcf lubBI12.pcf ncenR08.pcf 12x24rk.pcf clR7x10.pcf helvBO24.pcf lubBI14.pcf ncenR10.pcf 5x7.pcf clR7x12.pcf helvO08.pcf lubBI18.pcf ncenR12.pcf 5x8.pcf clR7x14.pcf helvO10.pcf lubBI19.pcf ncenR14.pcf 6x10.pcf clR7x8.pcf helvO12.pcf lubBI24.pcf ncenR18.pcf 6x12.pcf clR8x10.pcf helvO14.pcf lubI08.pcf ncenR24.pcf 6x13.pcf clR8x12.pcf helvO18.pcf lubI10.pcf nil2.pcf 6x13B.pcf clR8x13.pcf helvO24.pcf lubI12.pcf olcursor.pcf 6x9.pcf clR8x14.pcf helvR08.pcf lubI14.pcf olgl10.pcf 7x13.pcf clR8x16.pcf helvR10.pcf lubI18.pcf olgl12.pcf 7x13B.pcf clR8x8.pcf helvR12.pcf lubI19.pcf olgl14.pcf 7x14.pcf clR9x15.pcf helvR14.pcf lubI24.pcf olgl19.pcf 7x14B.pcf courB08.pcf helvR18.pcf lubR08.pcf symb08.pcf 7x14rk.pcf courB10.pcf helvR24.pcf lubR10.pcf symb10.pcf 8x13.pcf courB12.pcf luBIS08.pcf lubR12.pcf symb12.pcf 8x13B.pcf courB14.pcf luBIS10.pcf lubR14.pcf symb14.pcf 8x16.pcf courB18.pcf luBIS12.pcf lubR18.pcf symb18.pcf 8x16rk.pcf courB24.pcf luBIS14.pcf lubR19.pcf symb24.pcf 9x15.pcf courBO08.pcf luBIS18.pcf lubR24.pcf tech14.pcf 9x15B.pcf courBO10.pcf luBIS19.pcf lutBS08.pcf techB14.pcf charI08.pcf courBO12.pcf luBIS24.pcf lutBS10.pcf term14.pcf charI10.pcf courBO14.pcf luBS08.pcf lutBS12.pcf termB14.pcf charI12.pcf courBO18.pcf luBS10.pcf lutBS14.pcf timB08.pcf charI14.pcf courBO24.pcf luBS12.pcf lutBS18.pcf timB10.pcf charI18.pcf courO08.pcf luBS14.pcf lutBS19.pcf timB12.pcf charI24.pcf courO10.pcf luBS18.pcf lutBS24.pcf timB14.pcf charR08.pcf courO12.pcf luBS19.pcf lutRS08.pcf timB18.pcf charR10.pcf courO14.pcf luBS24.pcf lutRS10.pcf timB24.pcf charR12.pcf courO18.pcf luIS08.pcf lutRS12.pcf timBI08.pcf charR14.pcf courO24.pcf luIS10.pcf lutRS14.pcf timBI10.pcf charR18.pcf courR08.pcf luIS12.pcf lutRS18.pcf timBI12.pcf charR24.pcf courR10.pcf luIS14.pcf lutRS19.pcf timBI14.pcf clB6x10.pcf courR12.pcf luIS18.pcf lutRS24.pcf timBI18.pcf clB6x12.pcf courR14.pcf luIS19.pcf ncenB08.pcf timBI24.pcf clB8x10.pcf courR18.pcf luIS24.pcf ncenB10.pcf timI08.pcf clB8x12.pcf courR24.pcf luRS08.pcf ncenB12.pcf timI10.pcf clB8x13.pcf cursor.pcf luRS10.pcf ncenB14.pcf timI12.pcf clB8x14.pcf deccurs.pcf luRS12.pcf ncenB18.pcf timI14.pcf clB8x16.pcf decsess.pcf luRS14.pcf ncenB24.pcf timI18.pcf clB8x8.pcf fonts.alias luRS18.pcf ncenBI08.pcf timI24.pcf clB9x15.pcf fonts.dir luRS19.pcf ncenBI10.pcf timR08.pcf clI6x12.pcf helvB08.pcf luRS24.pcf ncenBI12.pcf timR10.pcf clI8x8.pcf helvB10.pcf lubB08.pcf ncenBI14.pcf timR12.pcf clR4x6.pcf helvB12.pcf lubB10.pcf ncenBI18.pcf timR14.pcf clR5x10.pcf helvB14.pcf lubB12.pcf ncenBI24.pcf timR18.pcf clR5x6.pcf helvB18.pcf lubB14.pcf ncenI08.pcf timR24.pcf clR5x8.pcf helvB24.pcf lubB18.pcf ncenI10.pcf xhextris.pcf clR6x10.pcf helvBO08.pcf lubB19.pcf ncenI12.pcf xmahjongg.pcf clR6x12.pcf helvBO10.pcf lubB24.pcf ncenI14.pcf clR6x13.pcf helvBO12.pcf lubBI08.pcf ncenI18.pcf tmp: [ This directory is empty ]
Note the "fonts.dir" and "fonts.aliases" files in the "fonts" directory. These files contain the mappings of human- readable font names to file names on the boot server. They can be generated (in the "native" X directory) on a Linux host then copied into place in the fonts/ directory. The X-station 130 loads fonts on an as- needed basis, so not all of these will be loaded at run- time.
I am given to understand that some individuals have had difficulty in getting some of the images in the "boot" directory to load correctly, especially with code loaded from FTP sources. Here are the sizes and simple Linux checksums ("sum filename") for the key files:
bootfile4 284906 bytes sum: 47791 279 x11xor4.out 593636 bytes sum: 61110 580
Please do note that the checksums above are only for the version of the X-station code that I happen to have here. Other revisions of the code will, of course, show different values.
Once the "bootfile4" bootstrap code is loaded from the boot server, it needs to be told where the other data are found. It does this by loading and reading the "bootfile4.cf" file in the boot directory. The format is fixed concerning line order, but it's pretty straight- forward. Here's mine:
/var/tftp/Xstation/boot/keymap /var/tftp/Xstation/boot/msg /var/tftp/Xstation/boot/x11xor4.out /var/tftp/Xstation/fonts /var/tftp/Xstation/rgb.txt
Once all of this is done, the little 130 should be able to boot up its X-server code and put it into execution. This will be apparent when the familiar grey crosshatch screen comes up with the "X" cursor in the center of the screen.
Once the 130 is booted the user needs a way to log into a system and start the X-client programs he desires. In the IBM world, this is typically handled by the Xstation manager daemon. In a non- IBM environment, however, that program doesn't exist and a substitute has to be found. That substitute is "xdm" - the "X Display Manager".
XDM is capable of managing a display in either a dedicated manner or in a dynamic manner with displays (X-stations) requesting login service via broadcast messages. The X-station 130 is capable of functioning in either environment.
In a statically configured envirionment, the XDM configuration file which specifies which displays are to be serviced gets modified. In this case the xdm's configuration file "/usr/lib/X11/xdm/Xservers" needs to be modified. The line:
192.168.1.9:0 foreign
is what I use here. Substitute the address of your 130 in place of the one I used (it's the same as the "Terminal Internet Address" field from the setup screens on the 130.
Xdm does not cope well with statically- configured servers which it thinks have gone off- line; this means that if you're going to power your 130 off for any appreciable period of time in such an environment you're going to have to restart the xdm process. Fortunately under UNIX this is easy and is done with a "kill -HUP" giving the PID of the xdm process as an argument. (You'll have to do this when you modify the Xservers file as well.)
As an alternate to static configuration, it is possible to have the X- station 130 broadcast a "request for service" to systems on the local area network which are running xdm. This method makes use of the X Display Manager Control Protocol, or XDMCP. To configure the 130 to use XDM, one makes a single change on the Networking Setup screens. All that needs to be done is to set the "Tags" field in the network settings to:
T178=1:
In addition to configuring the X-station to use XDMCP the file "/usr/lib/X11/xdm/Xaccess" on the desired host needs to be altered to have a line of:
*
(That's right -- a single asterisk in the leftmost column) entered into it and xdm restarted. This states that a request from any X-station should be honoured and a login prompt granted.
Once those steps are taken and the X-station rebooted, the X-station should come up with a logon screen without xdm needing to be reset again. Note that if you're on a large LAN you may get several logon services at once.
Finally, as a third option, it is possible to allow the X-station to acquire its configuration from a BOOTP server. In this environment, the operator doesn't need to put anything in the X-station's configuration screens, but does need to make changes to a file on the LAN's BOOTP server. This section will describe how it's done.
With BOOTP enabled on the X-station, it becomes possible to completely clear out the configuration screens, thusly:
Network Setup Page 2 ----------------------------------------------- Ethernet/IEEE 802.3 ..............Automatic Gateway Internet Address ......... Terminal Internet Address ........ Host Internet Address ............ Disable BOOTP ....................NO TFTP File Name ................ Tags Field .................... -----------------------------------------------
From the first page in the setup screens, the operator must find the hardware address of the X-station and give it to the LAN administrator who must then create an entry for the X-station in the "/etc/bootptab" file. That entry, on my Linux box, looks like (without the comments):
x-station:\ # Xstation name
:ht=ether:ha=0x000000000000:\ # Hardware Address Here
:ip=192.168.1.9:sm=255.255.255.0:\ # Xstation IP addr + mask
:sa=192.168.1.1:gw=192.168.1.1:\ # Code server and def gateway
:hd=/var/tftp:bf=Xstation/boot/bootfile4:\ # Boot file
:vm=rfc1084:T178=01: # Magic - see below
In the above example, the hardware (MAC) address gets placed into the file as a hexidecimal constant following the :ha= tag. This allows the bootp server to recognise the Xstation and give it the right information when the Xstation boots up. The last line instructs the bootp server how it should behave when a boot request comes in, and that it should pass back the "T178" tag with a value of "1" in it. This enables XDMCP so the terminal can get a login prompt.
Note that it's really not practical, or advisable, to run in this mode and try to statically configure your login service in the Xservers file. It is possible, as you're assigning a static IP address (in /etc/bootptab) but why go to the bother. XDMCP is easier to deal with, anyway.
I currently do DHCP and XDMCP dynamic configuration of my X-station 130. I use ISC's DHCP daemon and run XDM on a machine in my network that has connectivity to both my token-ring and Ethernet segments.
My /etc/dhcpd.conf file entry for my X-station reads thusly:
host uillagh {
hardware ethernet 08:00:5a:7a:18:c8;
fixed-address 192.168.1.9;
filename "/var/tftp/Xstation/boot/bootfile4";
server-name "syzygy.cacm.org";
next-server 192.168.1.1;
always-reply-rfc1048 true;
option host-name "uillagh.cacm.org";
option xstation-mode 3;
option xstation-mgr 192.168.1.1;
allow bootp;
allow booting;
}
In addition to the stanza above, I have the following entries in the global portion of the file:
option xstation-mode code 178 = unsigned integer 8; option xstation-mgr code 179 = ip-address;
Those entries define tags 178 and 179 to the DHCP server. Note
that all the other bits associated with running a DHCP server
must be in place to support the above. At an absolute minimum
one will require subnet-mask, broadcast-address,
and range statements.
The "xstation-mode 3" entry specifies that the machine is to make indirect XDM requests to the node specified in the "xstation-mgr" statement. This is to say that the X-station will contact the "xstation-mgr" machine and ask to call up the XDM "chooser" program. The XDM chooser program will then display a list of machines on network segments that it can "see" that are willing to provide XDM logon sessions to clients.
In addition to getting the X-station to boot, which the above
configuration allows, one must grant it access to the various
X servers and to the chooser program on the "indirect" node.
To facilitate this, I have the following lines in my
/usr/lib/X11/xdm/Xaccess file active:
* #any host can get a login window * CHOOSER BROADCAST #any indirect host can get a chooser
In addition to all of the above, the X-station is NFS-aware. This allows for enhanced access to fonts and to the paging file. To take advantage of this facility, the directory hierarchies listed in the bootfile4.cf file must be exported for NFS access to the X-station (or, more commonly, the entire LAN). Using NFS for font-file access is several times faster than using TFTP for the same function.
The X-station 130 is also capable of using standard X11 font servers in addition to NFS and TFTP. I have had very mixed results in my testing of font-servers, and instead have settled on using NFS as the preferred access mechanism.
Once the 130 boots it will take a few moments to load the required fonts for the login prompt, so be patient. Once things are rolling, the performance is pretty good on the 130. The one I have is more than sufficient for command shell windows, checking mail, and even simple graphics. However as mine only has 1 Mo of mainstore getting something large and complex (e.g. Netscape) running on it is asking for trouble. A typical boot takes roughly 45 seconds. Power- up from a cold start takes a while longer as the machine has to run through its POSTs before it begins the boot process.
Good luck configuring yours!
]
[ Museum Catalogue ]
[ Carl's Homepage 
]
Last Modified: Thu Nov 28 13:21:09 EST 2002