BBSˮľÇ廪վ¡Ã¾«»ªÇø
·¢ÐÅÈË: reden (Óã ¡« ¾ý×ÓÂɼºÒÔÀûÈË), ÐÅÇø: Linux
±ê Ìâ: Running Remote X Sessions on Windows
·¢ÐÅÕ¾: BBS ˮľÇ廪վ (Mon Oct 5 00:16:03 1998) WWW-POST
"Linux Gazette...making Linux just a little more fun!"
Running Remote X Sessions on Windows
95/98/NT/Mac/PPC Clients
By Ron Jenkins
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?"
The original problem
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.
What does this have to do with X sessions and Windows?
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".
Step One:
On the X host, create a user account for each of the desired clients.
Step Two:
Acquire X server software for the clients.
I am a freeware fanatic, so I chose to use MI/X, available from
http://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.
Step Three:
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.
Step Four:
You should be ready to go. I am sure that this whole thing could be done more
elegantly, but here's what I did:
Start MI/X on the client.
Open a telnet session to the Xhost:
telnet 192.162.0.1
After logging in, you need to tell the Xhost to display the output of a
program running on the Xhost on a different machine
(the client.)
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!
--
°×Âí´øÖøËýÒ»²½²½µÄ»Øµ½ÖÐÔ¡£°×ÂíÒѾÀÏÁË£¬Ö»ÄÜÂýÂýµÄ×ߣ¬
µ«ÖÕÊÇÄܻص½ÖÐԵġ£½ÄÏÓÐÑîÁø¡¢ÌÒ»¨£¬ÓÐÑà×Ó¡¢½ðÓã¡¡
ººÈËÖÐÓеÄÊÇÓ¢¿¡ÓÂÎäµÄÉÙÄ꣬ÙÃÙÎäìÈ÷µÄÉÙÄê¡¡µ«Õâ¸öÃÀ
ÀöµÄ¹ÃÄï¾ÍÏñ¹Å¸ß²ý¹úÈËÄÇÑù¹ÌÖ´:
¡¸ÄǶ¼ÊǺܺúܺõģ¬¿ÉÊÇÎÒÆ«²»Ï²»¶¡£¡¹
¡ù À´Ô´:¡¤BBS ˮľÇ廪վ bbs.net.tsinghua.edu.cn¡¤[FROM: 202.99.18.67]
BBSˮľÇ廪վ¡Ã¾«»ªÇø