nextCoder

If you are like me, maintaining a server at home is like a hobby.  There is a certain satisfaction to be able to install whatever we like without having to ask for anybody’s permission.

And sometimes thanks to our tinkering, we discover good solutions that are applicable to the task given to us at work.  Think about it as giving our employers a bonus.

One of the most important rules in running a server is to never expose unnecessary information publicly.  Want an example? how about an obvious one, your router’s administration application.  This should never be accessible from outside of your home network for an obvious reason, obviously.

But the benefit of this approach is also its own downside.  Consider the following (highly likely) case:

You need to urgently change a setting on your router, while you are not at home.

Yep, you can’t.  Not without doing something extra anyways.

And that something extra is SSH tunneling.  Now, there are at least two ways that I know of on how to accomplish this.  For simplicity’s sake, let’s talk about one now:

If you are on a Windows machine, get yourself Putty and follow the steps on this website while replacing the forwarded port numbers with the one that you are trying to use.

http://www.cs.uu.nl/technical/services/ssh/putty/puttyfw.html

Basically, you are telling Putty to tunnel port number x from a machine within your home network to port number y on the machine where you are working on.

So in the above example, to access your router’s admin application, you can setup the tunnel from port 80 on your router’s ip-address, to let’s say port 8080 on the local machine (where you are working from).

In the UNIX world, that translates into the following:

ssh -L 8080:your_router_ip:80 your_username@your_home_server.net

After successfully loggin into your home serve remotely, you can start a browser (on the machine where you’re working on currently), then go to localhost:8080 and voila! you’ll see your router’s administration application as though you are at home.

Pretty handy, eh?

Now why on earth would you want to run GUI Linux programs on Windows?

If you were to ask me that a week ago, I would not be able to come up with a good business scenario.  Other than the fact that I did it at home, because my main computer is a Windows box and my development stuff is on my Linux server.

But at the moment I am stuck with an old laptop at work — which, being a good corporate laptop, of course is running Windows XP — because the giant four-letter computer company has messed up the shipment for my new computer.

So to make lemonade out of a lemon, I have enlisted two powerful free software that can get me out of this jam: PuTTY and Xming.

The idea is to use a powerful Linux machine to host and run the GUI programs that I need to work with from my very resource-limited old laptop (Pentium 4 Mobile with 512 MB, anyone?).

What applications? you say…

Let’s pick a big one, how about the Eclipse IDE.

Step one:

You install Xming and fire up XLaunch.  Out of the three modes that Xming offered: 1) multiple apps in one window, 2) each app running in a separate window, 3) fullscreen mode, mode 2 is one that works the best in this scenario.

So I went ahead and created an .xlaunch file that basically fired up Xming in the background, ready to accept X-window connections on the old laptop. NOTE: Don’t forget to check a box that says “No Access Control” otherwise your Linux application will be rejected when it tried to connect to Xming.

NOTE: Xming has a file called X0.hosts (that’s X and zero, not the letter ‘o’) which is usually located in the Xming install directory.  This file may need to be modified to include the IP address of the linux box.  But only if it connects to Xming via another network domain (other than the primary one).

For example, I setup a virtual linux guest on my windows 7 machine, the local network subdomain looks like 192.168.56.x unlike the default network domain which is 192.168.1.x.  The latter is where Xming waits for connections from.  Therefore I need to add 192.168.1.101 (the IP address of the linux machine) to the end of X0.hosts file (a line by itself), then Xming will work as expected.

A subnote, on my machine, windows 7 forces me to become administrator user to edit this file.  Although not as elegant as UNIX’s sudo command, the Switch User facility in windows makes this not as painful as it could have been.

Next, I fired up PuTTy.  I followed the steps to configure a PuTTy session that will allow X-forwarding and all that good stuff on this website.

Once you are connected to the Linux server, in which I already have downloaded the appropriate Eclipse distribution, ready to go.

All I need to do once I connected via PuTTy is:

1. Set the DISPLAY environment variable to point to the laptop’s Xming instance: export DISPLAY=192.168.x.x:10.0 (the 192.168.x.x being the laptop’s internal IP address, of course).
2. Run Eclipse IDE: ./eclipse &

And voila! Eclipse is running on the Linux server with every bit of its UI tunneled via X onto the old laptop.  Of course the performance depends on the network connection, but it is surprisingly snappy on a typical 100Mbps Gigabit Ethernet.  And I am talking about Eclipse loaded with a large project.

Now if this article does not make you run to the storerooms in the back and pull out those old laptops and give those out to your developers, I don’t know what else will :)