At my job it’s common to develop products in a virtualized environment (e.g. in Virtozzo containers) using following schema: create a VPS (build machine), ssh to VPS, checkout source code, work with source code, build product. The reason for this is that products (e.g. OSA) require too much resources to build (memory, disk space, CPU), have many custom maven plugins and are strictly bound to platform (e.g. CentOS 6). This makes it almost impossible to build a product on a local machine (e.g. laptop). However working within a VPS reduces productivity since it leaves you with a vim or emacs. These editors are great but it’s much easier to develop in some IDE with code analysis, hot deployment, debugging and other cool features. My choice is an Eclipse – it supports C++ and Java – two major languages our product is written in. However Eclipse requires GUI which is not available within VPS. To overcome this a “Remote Eclipse” schema described below could be used.
The main idea is to utilize benefits of X11 network architecture: your local machine is treated as a server where a client could connect to and render GUI.
This is known as a X11 forwarding and it means that it’s possible to launch Eclipse (X11 client) within a VPS (build machine) and ask it to render its GUI on a local machine (X11 server).
2 X11 Forwarding
The most easiest and natural way to get X11 forwarding is to make it via ssh: you login over ssh to VPS, launch Eclipse and it renders on your screen! Here is the algorithm to do this for VPS on CentOS 6:
- ssh to VPS
- download and install JDK
- download and unpack Eclipse archive
- install RPMs which will allow authentication of X11 remoting:
- install RPMs which will help Eclipse to render nice GUI:
- enable X11 forwarding – add (or modify) following lines in /etc/ssh/sshd_config:
- ask sshd daemon to reread changes just made to its configuration:
- leave VPS:
- Now it’s possible to login to VPS and launch Eclipse from there:
Note: thanks to this article written by Dan Nanni for a helpful ssh options which optimize X11 forwarding performance.
If everything is done properly then Eclipse’s window will appear but Eclipse will operate on a remote system! And all this in a seamless fashion!
3 Direct X11 Connection
Described X11 forwarding over ssh works well but could be slow sometimes (especially when working over slow VPN). This could be mitigated by a direct X11 connection: X11 server on your local machine opens a TCP port where a remote clients could directly connect to.
Note: direct X11 connection is treated as completely insecure and can be used only in a trusted environment, e.g. in within a LAN or VPN.
Here is the algorithm for a direct X11 connection for Debian (e.g. Ubuntu) based local machines:
- ask your local X11 server to allow connections from remote clients – add (or modify) following line in /etc/lightdm/lightdm.conf:
- restart X11 server so it picks up changes made to its configuration:
- add VPS to the list of hosts which are allowed to connect to X11 server:
- resolve a display serial number which will be used for connecting from a VPS to X11 server:
Last digit of 600x will correspond to a display number, serial. E.g. 6001 will correspond to a display serial #1.
- login to VPS:
- set a DISPLAY environment variable which will describe how to connect to your X11 server:
- start Eclipse
Working with Eclipse remotely turns out to be not so complex. X11 fowarding or X11 direct connection allows to run Eclipse wherever your want but to render its GUI on your local machine. No need for disk network sharing or ugly chrooted environment – benefits of two worlds at one place!
It’s even possible to operate several Eclipse instances at once (e.g. for different product version or different platforms) without performance degradation of your local machine – each instance will reside within its own VPS.
Also one may think about automation of steps described before within some script. This will allow to create shortcuts on your desktop for a lightning fast access to a remote Eclipse instances.