X11 is a windowing system for *nix computers. There is one point about X11 that needs to be understood before anything that follows will make sense, so I’ve cribbed the following bit from the X11 wikipedia page to explain:
X features network transparency: the machine where application programs (the client applications) run can differ from the user’s local machine (the display server). X’s usage of the terms “client” and “server” is the reverse of what people often expect, in that the “server” is the user’s local display (“display server”) rather than the remote machine.
You could, for example, run an X11 application (X11 client) on a large mainframe and send the display to a lowly workstation (running an X11 server), and enjoy the full benefits of running the application on a fast machine, while also having a GUI. Another common scenario is to run both the X11 client and X11 server on the same machine, in which case the experience is similar to that of a standard desktop application.
On its own, X11 provides no facilities for ‘mobility’ that would allow you to move the GUI of a running application between hosts *while the application continues to run*. Typically, you have to tell the X11 application the location of the display server before it is launched. Enter xmove.
xmove(1) xmove(1) NAME xmove - pseudoserver to support mobile X11 clients SYNOPSIS xmove [ -server server_name:port ] [ -port listen_port ] DESCRIPTION xmove starts a pseudoserver which allows its X11 clients to be relo- cated from one display to another. Upon startup it will create a lis- tening port from which it accepts new client connections. All such clients will be displayed on the default server, until moved elsewhere. Several clients may connect through a single xmove, thus requiring only one per machine.
I installed xmove via macports, with the command:
sudo port install xmove
xmove probably won’t be incredibly worthwhile to you unless you use X11 applications on a semi-regular basis on different machines. In order to use xmove, you’ll need at least two X11 capable hosts – Mac OS X does nicely, as long as you have the X11 package installed (it’s on the Tiger DVD), or some other X11 server.
What follows is a walkthrough of a couple common usage scenarios. I’ve also created a narrated video walkthrough that you can download here in high [52 MB, 1.4 Mb/s] or medium [29 MB, 800 Kb/s] resolution. Both videos require QuickTime 7.
First, pick a machine on which to run xmove. To minimize network traffic, this should be the machine where most of the x11 apps are running and being displayed most of the time. For the purposes of this guide, we’ll call that machine ‘idio’.
When started, xmove will fire up an X11 pseudo-server. To determine where to send display output, it will either sense the value of $DISPLAY, or pick an appropriate default – typically hostname:0. I find that xmove works fine without having $DISPLAY set before launching xmove, since Apple’s X11 server listens on hostname:0 by default.
andre@idio[~]nohup xmove &
Next, before you launch X11 programs, you need to tell the X11 app to send its display to the xmove pseudo-server. Do this by setting $DISPLAY before launching the app. By default, xmove will listen for incoming X11 connections on hostname:1, so we’ll set $DISPLAY to idio.dreness.com:1, and then launch an X11 app. This should cause the X11 app to appear on the local host after being transparently routed through xmove.
andre@idio[~]export DISPLAY=idio.dreness.com:1 andre@idio[~]nohup xeyes &
We can examine the xmove application list with xmovectrl (which was installed along with xmove):
andre@idio[~]xmovectrl idio.dreness.com:1 -list 1 xeyes idio.dreness.com:0
Fire up some more apps, then get another list.
andre@idio[~]xmovectrl idio.dreness.com:1 -list 1 xterm idio.dreness.com:0 2 xeyes idio.dreness.com:0 3 xman idio.dreness.com:0 4 xlogo idio.dreness.com:0 5 line #%lu of file %s idio.dreness.com:0
(for some reason, eterm shows up as that weirdness next to #5. oh well.)
Okay, now we have some stuff going. Let’s move all the displays of the apps to another machine (called, for instance, pimp).
First, we need to make sure our destination host has allowed us to connect. Fire up X11 on the destination host and do
xhost +idio.dreness.com
to allow X11 connections from idio, which is the host of our X11 apps, and where xmove is running.
Once that’s done, we’re ready to move the apps:
andre@idio[~]xmovectrl idio.dreness.com:1 -moveall pimp.dreness.com
At this point, all the X11 app displays should magically disappear from idio and reappear on pimp. Fancy! Now we’ll take another listing…
andre@idio[~]xmovectrl idio.dreness.com:1 -list 1 xterm pimp.dreness.com:0 2 xeyes pimp.dreness.com:0 3 xman pimp.dreness.com:0 4 xlogo pimp.dreness.com:0 5 line #%lu of file %s pimp.dreness.com:0
Neat-o :) We can also move individual applications by referencing their index number.
andre@idio[~]xmovectrl idio.dreness.com:1 -move idio.dreness.com 1 andre@idio[~]xmovectrl idio.dreness.com:1 -list 1 xterm idio.dreness.com:0 2 xeyes pimp.dreness.com:0 3 xman pimp.dreness.com:0 4 xlogo pimp.dreness.com:0 5 line #%lu of file %s pimp.dreness.com:0
—
Now let’s do a slightly different example. Let’s say you have a machine in your cube at work, and to get there from home you have to VPN to the company network. You want to run an X11 app there and display it at home, but be able to pick it back up when you get back to work.
On the work machine:
Make sure $DISPLAY is unset and then start xmove.
andre@werk[~]echo $DISPLAY andre@werk[~]nohup xmove & [1] 23906 andre@werk[~]Implementing MIT-MAGIC-COOKIE-1 user authentication XMove 2.0 ready.
set DISPLAY to
andre@werk[~]export DISPLAY=dre:1 andre@werk[~]nohup xeyes & [2] 23932 andre@werk[~] andre@werk[~]xmovectrl dre:1 -list 1 xeyes dre.company.com:0
Now on the home machine, we need to allow x11 connections from the work box:
andre@idio[~]xhost access control enabled, only authorized clients can connect andre@idio[~]xhost +dre.company.com dre.company.com being added to access control list andre@idio[~]xhost access control enabled, only authorized clients can connect INET:dre.company.com andre@idio[~]
We’re almost ready to move the app to the local display. There is one catch, however. The VPN stipulates that all traffic from my machine at home to any IP at work must go through the VPN. Therefore, we cannot redirect the display from work to idio.dreness.com (my public IP), we have to use the IP address of the local VPN endpoint. Find that with ‘ifconfig’:
andre@idio[~]ifconfig ppp0 ppp0: flags=8051mtu 1280 inet 1.219.213.179 --> 1.219.212.15 netmask 0xff000000
1.219.213.179 is my VPN ip address, and this is where I’ll send the X11 display from the work machine. Because I’m doing this in the same session where I started the backgrounded instance of xmove, I’ll also see the xmove output (the lines starting with ETHAN and XMOVE. I don’t know who ETHAN is, but I would probably buy him a beer).
andre@werk[~]xmovectrl dre:1 -moveall 1.219.213.179 ETHAN: matching depth 24 to depth 24 XMOVE: switching client 1 to display 1.219.213.179:0 andre@werk[~]xmovectrl dre:1 -list 1 xeyes 1.219.213.179:0
Caveats:
- xmove doesn’t work like GNU screen in the sense that if any X11 connections are terminated for whatever reason, the app dies. Accordingly, make sure to redirect the display to another machine before, for example, logging out of VPN.
- Always start xmove and X11 apps by prepending ‘nohup’ and appending ‘&’. This launches the app in the background and allows the app to keep running once the terminal from which the app was launched disappears.
Pingback: Unix:Detach/reattach an application run on X over SSH? – Unix Questions
Pingback: Detach/reattach an application run on X over SSH?