Starting an X11 client on another machine, without ssh

[Jerry Feldman]

On 03/23/2010 03:06 PM, Bill Freeman wrote:
>> On 03/23/2010 12:03 PM, Bill McGonigle wrote:
>>     
>>> On 03/22/2010 04:13 PM, Bill Freeman wrote:
>>>  
>>>       
>>>> It seems like ssh is overkill for talking
>>>> to a VM on your own box.
>>>>    
>>>>         
>>> You're running two operating systems on one piece of hardware.
>>>
>>> -Bill
>>>
>>>  
>>>       
>> In a way I agree with Freeman. But, a VM can be configured using
>> different methods to virtualize the ethernet adaptor. If you are
>> bridged, then that adaptor is open to the outside world (or al least
>> your LAN). On most VMMs you can set up a common directory for file
>> sharing. But, since you are on the same box, you should be able to
>> access the guest OS desktop.
>>
>> --
>> Jerry Feldman <gaf at blu.org>
>>     
> The VM in NATed to the network by the host (maybe even by vmware player
> somehow, but the hostside interface shows up in ifconfig).  Only ports
> on the VM that the NAT knows about could be accessed from off box.
>
> The host, however, has unNATed access to the VM, so looking ssh-ing in
> works, and looking at the twisted running on the VM with the host
> browser (the VM doesn't run an X server) works fine.
>
> The point is not to open the VM to the outside world, but to let X
> clients running on the VM (particularly emacs) to access the X server
> on the host.  Then I can run emacs on the VM using my screen, keyboard,
> and mouse.
>
> This all works fine, set up by hand:
>
>    * Figure out that ubunto 9.10 runs X with -nolisten tcp and fix.
>    * Permit access from the client.  I'm using:
>         xhost +name_of_vm_in_etc_hosts_or_just_its_ip_address
>    * On the vm, set the DISPLAY environment variable using the host's IP
>      and DISPLAY variable setting (':0.0').
>    * Run emacs in the background, pops up in host X.
>
> But the old xon script was so darned convenient, taking care of everything
> except the first item (which is a one time fix).
>
> So now I have a pair of bash scripts, one on the host that just does:
>
>    xhost +vm_client
>    ssh username at vm_client '$HOME/remote_scripts/emacs '"$DISPLAY"
>
> And one on the client in the not on the path "remote_scripts" directory,
> which:
>
>    * Sources ~/.bash_profile to pick up path adjustments and environment
>      variables.
>
>    * Parses the host ip out of the SSH_CLIENT environment variable and
>      combines it with $1 (host's $DISPLAY) to set and export DISPLAY,
>
>    * Runs emacs in the background(*).
>
>    * Exits.
>
> Which works, making me happy at the moment, but something more general,
> akin to xon, would be superior.
>
> Bill
>
> [* This was the hardest to get right.  If you just do:
>
>    emacs &
>
> things work, but the emacs is holding open the pseudo-tty on stdin, stdout
> and stderr, even though it's running on the X display.  This keeps sshd
> from closing, and that keeps ssh, and thus the script, on the host from
> exiting.  Redirecting all three to /dev/null fixes this.]
>
>
>   
Shouldn't that be

ssh -X username at vm_client '$HOME/remote_scripts/emacs
An ssh tunnel sets up the DISPLAY variable to an internal port. 
I've never tested connecting to a guest OS through the host OS. 

So basically, you have a host os that you are connecting to from somewhere else. Then you are connecting to the guest OS running under VMWare Player or Workstation?

I'm not sure if you are doing this as an exercise or what, but you do have the ability to let VMWare assign the guest OS a bridged port so it's IP address can be accessed externally.  



-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20100323/3d266d39/attachment.bin