Lubuntu on VMWare Tutorial – “Behind a Proxy” Edition

A Lubuntu virtual machine on VMWare Player is currently one of my standard tools for developing and testing software. I had a Hard Time (c) the first time I installed and fully configured such an instance because I was (suspense, suspense…) behind a proxy! The need for this setup has been triggered by the fact that I like my VMWare machines to be able to resize the desktop as I resize the VMWare window that contains them. That feature is available in most Linux distros only if you install the VMWare-tools package on the guest machine. That, in turn, requires the build-essential package (gcc, make, and the like).

Here’s the outline:

1. set the system-wide proxy;
2. tell apt to use the proxy (’cause no, it won’t use the fucking system proxy);
3. update and upgrade apt;
4. install build-essential with apt-install;
5. install VMWare-tools.

Now that I read it, it seems like an easy thing to do, but it took me some time to have all the pieces set up, so I guess it’s worth to write a brief tutorial to share what I have learned. Of course, I did not find out all these things by myself: this a just a summary of the knowledge that I gathered from the Internet (thank you, Internet).

1. Set the system-wide proxy.

Interestingly, Lubuntu does not have a nice GUI to let you set the proxy, so you have to do it some other way. For me, the best way is to just set the appropriate variable inside the /etc/environment file, so that it is shared across all users. Since it is going to be a development box I do not care about which user logs in at all. I just want the variable available and I want it fast.

to do that, open the aforementioned file with:

sudo nano /etc/environment

or with your favourite text editor (I am sorry if it’s vim), and make sure that the following lines are added:

http_proxy=http://101.101.101.101:3456
https_proxy=http://101.101.101.101:3456
ftp_proxy=http://101.101.101.101:3456
no_proxy="localhost,127.0.0.1"

(As you might imagine, you have to replace the fake IP addresses and ports with your proxy’s ones). To make the change effective you must log out and log in again.

2. Tell apt to use the proxy.

Because otherwise it won’t. Open the file /etc/apt/apt.conf for edit. If it does not exist, create it. Add the following lines:

acquire::http::proxy "http://101.101.101.101:3456"
acquire::https::proxy "https://101.101.101.101:3456"
acquire::socks::proxy "socks://101.101.101.101:3456"
acquire::ftp::proxy "ftp://101.101.101.101:3456"

again, replace the “101” and “3456” placeholders with your actual addresses and ports, and save it.

3. update and upgrade apt.

Run the following command to make apt up to date:

sudo apt-get update
sudo apt-get upgrade

4. Install build-essential with apt-install.

Now you are ready to use apt commands behind your proxy. Type

sudo apt-get install build-essential

to install the necessary build tools.

5. Install VMWare-tools

Now that you have all the prerequisites, you are ready to install the VMWare-tools. Select the menu item as in the picture below, follow the instructions that VMWare Player prompts to you, and you should be fine.

Easy deployment made hard

I recently started “evaluating” OpenShift, the fanta-mega-giant cloud offer by Red Hat. OpenShift basically offers you what most so called cloud services offer today: virtual servers that you can remotly manage with a certain degree of autonomy. What took me to OpenShift was the fact that I was searching for a way to host a Java EE web application, possibly with a free basic plan. My initial idea was to find a provider of a simlple Tomcat 7 or 6 and a basic way to upload a WAR file. This requirement has turned out to be surprisingly hard to meet. So long, OpenShift has been the only platform to be able to satisfy me but it has been anything but easy to achieve.

OpenShift is capable of hosting a vast range of applications, spanning from PHP to Ruby On Rails, with almost anything you can imagine in the middle. One of the options is JBoss EWS, a profile that is able to host Tomcat which, in turn, can contain your applications.

Once you have your account you are in Red Hat territory and you have to follow their rules. It can take quite a long time to get started, especially if it is the first time that you do that. First, you have to install on your machine a lot of stuff to enable the development tools necessary to upload the applications and manage the server. Note: you have to install stuff to be able to install the OpenShift tools. Once you are done with Ruby, ssh and the rhc utility, you can create an application and start coding.

The basic configuration of the application is decided by OpenShift: you choose the name, OS choose all the rest. It creates a remote Git repository with a directory tree for your project and a Maven pom file for managing the build process. Now, if you have not already given up, you can clone the project and start coding on your dev machine. So OS gives you anything: a Git repo, an application server for deploying, a build process and a standard directory structure for your source files. Whenever you want to deploy your application remotely, you can do a “git push”: the server will automaticaly recognize the changes, start a build and, if anything goes right, deploy the resulting war. Seems easy, doesn’t it? Nop.

OS gives you much. It actually gives you too much. What if I have a preexistent project, possibly connected with another repository, and with dependencies from other projects? I just want to deploy the fucking war and see what happens, ok? I don’t what to spend three hours trying to figure out how I can map it all on the project created by OS. And I am sincerely thankful, OpenShift, for your commitment in making me aware of the advantages of continuous integration, but I just wanted to deploy the war, please.

I finally figured out that this is the answer to all my problems. The only thing is: you better read all the thread, because the final post is foundamental: you have to tell JBoss to unpack the war.