![[ TABLE OF CONTENTS ]](../gx/indexnew.gif)
![[ FRONT PAGE ]](../gx/homenew.gif)
Copyright ® 1998 by Ron Jenkins. This work is provided on an "as is" basis. The author provides no warranty whatsoever, either express or implied, regarding the work, including warranties with respect to its merchantability or fitness for any particular purpose.
Corrections and suggestions are welcomed by the author. He can be reached by electronic mail at rjenkins@unicom.net.
This document came about as a result of a client's problem and my solution. I have since seen this question asked a zillion times on USENET right up there with "Why can't Linux see all my (insert your >64MB number here,) of RAM?"
One of my clients had a rather classical old-style Unix host to dumb terminal setup, connected through multiple serial termservers.
They also had a PC on every desk, also connecting through a "dumb" serial connection.
The problem was that they needed to administer the host, as well as run many other programs on the host that required a GUI. To accomplish this, they utilized a couple of Unix workstations.
Obviously this was unacceptable, as they had everyone fighting for time on the workstations.
The version of Unix they were running, had no CLI other than a network telnet session or the aforementioned serial setup, only administration through their proprietary interface running on top of X.
A quick investigation showed an X server running on the host, but not being utilized. A previous consultant from the company they purchased the two systems from had suggested X Terminals as a solution, which by coincidence, they just happened to have handy.
They never did tell me what his quote was, but rumor has it was staggering. (Look the price of an X Terminal sometime and you'll see what I mean.)
Enter Linux. First, I did away with the serial connections on the PC's and got them on a switched 10 base T network.
Next, I setup a couple of 486/100's as file servers and proxy hosts, using ip_masq and Samba. These machine then connected to the external WAN over a 10 base 2 bus. All the suits had quota'd storage, could e-mail and memo the begeezus out of each other, surf the "net, and were happy as clams.
One word - POLITICS.
To convince the suits (the ones with the money) to let me use Linux to solve the problem for the programmers and administrators (the ones who actually do the work to produce the money), I had to impress them first.
While they don't understand diddly squat about the technical side of the business, they do understand I gave them e-mail, file services, intranet, and Internet access for just the cost of my time, since they had the 486's setting in a closet collecting dust.
Now I had the go-ahead for the X solution I proposed, which was 2 more 486's also already on site, also not being used, upgraded to SCSI-3 Ultra Wide Disks, and honked up the RAM, to serve as X proxies, for reasons I can't go into. This interposes an additional barrier between the Xhost and the clients. You shouldn't need this, so I'm going to pretend everything behind the 486's does not exist.
Just to make it really fun, I was also asked to include the web design department on this subnet, who were all on Mac's and Power PC's.
After creating a 10 base T subnet with the 486's and the clients wired up and TCP/IP configured on all the clients, it was time to show 'em some magic.
From this point forward, the 486 will be referred to as the "X host", and any Windows 95/98/NT/Mac/PPC machine will be referred to as "the client".
On the X host, create a user account for each of the desired clients.
Acquire X server software for the clients.
I am a freeware fanatic, so I chose to use MI/X, available from https://tnt.microimages.com/www/html/freestuf/mix/, or my mirror, ftp.brokewing.com/pub/mix/.
An additional factor that led me to choose the MI/X package, is that it runs on all three platforms.
Install the MI/X software
Note for Windows clients - either install the program in it's own place like C:\mix, or if you put it in Program Files, create a shortcut directly to $BASEDIR\TNTSTART.EXE startmix (note the space) for some reason, on the 95 machines you may get a not enough memory message when you try to run it if you don't.
Acquire Telnet software for the clients.
In my case they were already setup for telnet, from the previous serial thing.
All Windows clients should already have telnet, the Mac's may or may not.
If not, NCSA produces a telnet client that runs on the Mac platform.
You should be ready to go. I am sure that this whole thing could be done more elegantly, but here's what I did:
For the bourne shell:
DISPLAY=<the IP of the client machine>:0.0
For example, DISPLAY=192.0.0.3:0.0
Now you need to tell the Xhost to use this Environment Variable for all subsequent programs.
The command to accomplish this is:
export DISPLAY
For the csh:
setenv DISPLAY <client IP as above>
You should now be able to run any X application you want on the Xhost and have it display on your client machine.
In the telnet window, to launch an xterm, type:
xterm &
After the xterm comes up in the MI/X window, you can close the telnet session.
That's all there is to it!