XFree86 by remote
dugan at passwall.com
Mon Apr 2 22:53:51 PDT 2001
On Tue, 3 Apr 2001, Lincoln Peters wrote:
> Here's my situation:
> One computer, called OFFICEPRO, is a Pentium/166MHz with 80MB RAM
> Another, called ODYSSEUS, is an Athlon 1GHz with 256MB RAM. They are
> connected by a 100BaseTX LAN. Both are running Red Hat Linux 7.0.
> I want to use VMWare to run Windows NT, Windows 98, and Linux without
> dual-booting on both computers. I have tried VMWare on both under the
> evaluation license. OFFICEPRO simply is not powerful enough to run it, but
> ODYSSEUS runs it fine. However, most of my family would like to use it on
> Basically, I want to run VMWare in an on ODYSSEUS, but make it appear on
> OFFICEPRO's monitor in either its own X session or within a local X session.
> I'm pretty sure that this can be done, but I've never done it before and I
> couldn't find any clear instructions on the XFree86 web site or in the man
> pages. Anyone know how to do this?
Never used these apps, but if they run in X as most other X applications,
here is one common method for running x-sessions remotely (There are
security risks in this, but a good firewall policy will decrease the
risks. Discussion of this was partially covered in the firewall lecture
at nblug. :-)
As an example:
If both running Linux with X and a window manager:
Log into the machine that you want to have the application displayed
Start up X or if in X, proceed
(You do not need to start up X on the remote machine, or log into its
console or *at* the remote machine.)
open an "xterm" or x-based console.
type $ echo $DISPLAY
The DISPLAY variable used in your shell is used by the machine that is
running the shell where to send X-information for spawned applications.
It is in the form: Hostname.domain.tld:#.# where # is an integer not
necessarily the same numbers.
Usually, If this is the first X session on the box, DISPLAY may be
be assigned one of the following values:
The numbers will increase based on what graphics console is used etc.
Mostly remember the numbers after the hostname as you will need these
later in an "export DISPLAY="" arguement in a session to the remote
Look up the IP address of the Machine you are using (check out
ifconfig) we will call this IP address "REMOTE-IP"
Look up the IP address of the machine that you want to have run the
application for the machine mentioned prior. We will call this "LOCAL-IP"
In the current machine's X-session and x-term window, type:
$ xhost +REMOTE-IP
(the + immediately before the ip address adds permission for the local
machine to accept X session information from that IP address while a
"-" would remove it from havinf permission.
This will allow any packets claiming to come from that IP address that
want to "talk X" to connect and display stuff on the machine with the
Now, either ssh or telnet to the REMOTE-IP address.
once you have a shell on the machine with the REMOTE_IP address, you can
check out your DISPLAY variable with
$ echo $DISPLAY
If you are using ssh, then it is very likely X-started applications
started on the machine with REMOTE-IP will end up being displayed on the
machine with LOCAL-IP. -HOWEVER- these will be encrypted which is better
for security, *but* will be rather slow as graphics and X-displays are all
encrypted (CPU intensive). (Incidentally, the "xhost" directive above is
not needed with X over an existing ssh session.)
If you are using telnet, or want to have X-session info not be sent over
an encrypted channel in ssh, then on the machine with REMOTE-IP address,
you can try typing (assuming you shell is bash):
$ export DISPLAY="LOCAL-IP:0.0"
(If using csh instead of bash: % setenv DISPLAY "LOCAL-IP:0.0")
(unless the numbers reported in your check of the EXPORT variable on the
machine with the LOCAL-IP address had different numbers after the ":",
then use those numbers instead.
Now, in the shell started on the machine with the REMOTE-IP address, you
should be able to start just about *any* x-based application and have the
application appear on the machine with the LOCAL-IP address.
There are readme's and FAQs out there that describe this in more
detail. Commands related to this that might help in man pages include:
bash (env vars)
ssh (X-display and X-session encryption)
If something is not explained well enough, please let me know. Appologies
if this seems over-simplified, others on this list may not be as skilled
in this as you and want to do something similar.
Now, there are some things you can so with chroot-ed environments to
insulate their access to break things on the machine with REMOTE-IP and
there are things you can do to prevent them from having a "real" shell to
execute command on the remote machine, but the above should at least be a
Another that can be done is to set up a console on the LOCAL-IP linux box
to do the whole x-login with xdm much like the whole diskless client
system. (With *NIX like systems there are often many solutions to one
Hope something here helps,
More information about the talk