xpra

I recently discovered this little gem. It took a little time and effort to figure out the basic setup, but it was totally worth it.

The website bills it as “screen for X”. Which doesn’t really mean anything if you aren’t familiar with screen. The short version is that you can connect to a remote machine, use windows that it creates on your desktop, and reconnect to that same session later from a different computer.

Which, by itself, is awesome.

For my purposes, though, it means that I can ssh into some VM running on the cloud and locally interact with windows that it creates.

Setting it up wasn’t quite as seamless as it seems like it should have been, but this *is* a fairly tricky problem.

In one configuration, I’m running ubuntu 14.04.1, which packages version 0.12.3. That seems to be the latest release version, so isn’t horrible. Most distros are much farther behind (big surprise, I know). The “stable” one that gentoo includes by default is 0.8.8.

Which (according to their website) is horribly flaky and incompatible and should never be used under any circumstances.

The web site is also a little vague on the “getting started” part. Install a relatively recent version on both client (your desktop, in this scenario) and the server (my VM).

On the client/local machine, run:

xpra start ssh:SERVERHOSTNAME:100 --start-child=xterm

Buried somewhere in the middle of the output (which probably includes a bunch of warnings about missing packages, though that isn’t what they look like) is a request for the password. Of the user from your local machine.

You really want to pip install numpy and PyOpenGL on the remote/server, if they aren’t already. Then the actual command on the client becomes:

xpra start ssh:remote_user@SERVERHOSTNAME:100 --start-child=xterm

Which fails after login with an error that

sh: 1: /home/remote_user/.xra/run-xpra: not found

This error should actually say something along the lines of “run xpra on the server”. So ssh into there and run

xpra start :100

The number is just an identifier for the screen. You can pretty much pick whichever suits your fancy, except 0. If you’re going to have conflicts, you probably know more about this than I do anyway.

That should report that it’s entering daemon mode and tell you where it stores the error log (in my case, that’s ~/.xpra/:100.log).

You can list your currently running sessions (with their associated ports) with

xpra list

From this point, my gentoo install seemed like it was working, though it wasn’t actually doing anything.

On my ubuntu client, I got:

AssertionError: proxy/shadow-start: expected 1 argument but got 2

which led (thanks google!) to a ridiculous diatribe about how the developers are all horrible people for making such awful software publicly available. It’s vaguely amusing, as an example of how to not get help (though they were much nicer about it than I would have been), but I’m not going to promote flames or trolls by linking to it.

The solution to that particular problem was to edit /etc/xpra/xpra.conf, find the line that said

start-child = /usr/X11/Xsession true

and wrap quotes around the command to convert it to

start-child = "/usr/X11/Xsession true"

But I still wasn’t getting any windows.

xpra info

is another useful command. It spits out a ton of configuration settings. At the bottom, it has an entry for the number of active windows available.

Mine shows 0, apparently because the –start-child command to xpra start doesn’t work the way I expected.

So, back in the terminal where I’m ssh’d into the ‘server’, run

DISPLAY=100 && tmux new -s PICK_A_NAME

and then launch interesting pieces (like, say, an IDE) from in there.

 

jzmq and Error 0x16

I’ve been dabbling with JNI for a while, trying to get Curve Encryption working inside the java binding for 0mq.

Everything looks like it’s working nicely, until I try to actually set the server’s private key (which, honestly, is step 2…but I’m pretty thrilled that I finally got the monster to build at all).

Setting that socket option fails: “Invalid argument(0x16)”. I spent some time digging through my code trying to figure out how and when I might be supplying that. Then I verified that the same call basically works fine with the python bindings (though I didn’t dig in to look at details). And *then* I resorted to google.

Where all the results were about Storm, and rolling back to some really ancient version they forked back before jzmq had released any code. The general consensus seems that the fix is to roll your 0mq version back to something really obsolete, like 2.1.7.

All this was barking up the wrong tree. 0x16 is the hex code for EINVALID. I should have paid more attention to the actual error message.

I haven’t tracked down the actual problem yet, but the point is that this is an *extremely* generic error message/code.