Fixing “java.awt.HeadlessException” when launching an AVD

I’ve just bought a new laptop (Lenovo x230), and decided to go with a Debian Testing install. One of the problems I ran into was that I was unable to start an AVD (Android Virtual Device) using the GUI – the AVD manager would just crash, and I’d end up with a “java.awt.HeadlessException” exception printed to my console.

Google suggested that this was due to some incompatability between the AVD Manager and `openjdk-7-jre`, and that the fix was to remove `openjdk-7-jre` and replace it with `openjdk-6-jre`. I didn’t really want to have to do that, so came up with an alternative solution.

By downloading openjdk-6-jre, and modifying the ‘android’ bash script (located in android-sdk-linux/tools/android) by changing the line:

java_cmd="java"

to

java_cmd="/usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java"

it becomes possible to use Java 7 by default, but run the AVD Manager under Java 6.

Introduction to virtualenv

Keeping track of  Python package dependencies can be a tricky task, especially when you’ve already got multiple packages installed and you’re not sure what your project is/isn’t using. Thankfully, a tool called virtualenv exists which helps keep track of your packages and lets you isolate installations.

Installing virtualenv is easy – it’s a Python script, and can be obtained by running pip install virtualenv.

Once virtualenv is installed, you can create your virtual environment by running virtualenv my_env_name. This will copy your system’s Python binary (you can specify a custom version by passing the --python=/path/to/your/desired/python flag), and install both pip and setuptools to the my_env_name folder. It also creates an activation script, which you can call by running source my_env_name/bin/activate. Activating your virtual environment will update your PATH to use the newly copied Python, as well as the new packages folder and pip install.

Now that your newly create virtual environment has been activated, any calls to Python, easy_install or pip will be passed to your newly created Python install. This means that pip will install packages to your virtual environment rather than to your system install, and that any system packages that you had previously installed are no longer accessible. A useful side-effect of running under a virtual environment is that both pip and easy_install no longer require special write privileges – you’ll no longer need sudo/root privileges to install packages.

Another handy use of virtualenv is to generate a list of requirements for your project – running pip freeze > requirements.txt will create a pip install -r compatible requirements.txt file for you, allowing you to easily distribute and keep track of project dependencies.

virtualenv can be de-activated by running deactivate from your shell, which restores your environment to its former self.

Quick and Dirty VPN Server with pptpd

I’ve recently found myself wanting to be able to quickly create a VPN server, with minimal client-side setup. Normally, my VPN Server of choice is OpenVPN, but this doesn’t really fill those criteria – server side, you’ve got to generate keyfiles, certificates, config files. This wouldn’t be so bad – but it’s a similar story client-side. If your grandma want’s a VPN connection, then having to send over OpenVPN installers, certificate files and configs isn’t ideal.

Most operating systems have built-in support for a VPN Protocol called “PPTP”, or Point-to-Point Tunneling Protocol, so I decided to investigate. It turns out that minimal effort is required to set up a PPTP server, and virtually NO effort is required on the client side. PPTP is supported by OS X, Windows, Android, iOS natively, and can clients are easily obtainable for Linux and various BSD distributions.

Before I go any further – I’d like to clarify that PPTP is NOT terribly secure. I wouldn’t use it for transferring any particularly sensitive information; I’m using it purely for convenience reasons. I’d recommend it for watching Netflix or Hulu from outside the US, but not for transferring mega secret nuclear launch-codes. Services exist that allow the cracking of MS-CHAPv2, the protocol that PPTP uses for encrypting communications.

OK, now that you know not to use PPTP/MS-CHAPv2 as a security measure, lets move on.

These instructions were tested on Debian 7.0 – but installation aside, should be valid for any distro.

Install PPTPD. This can be done via a simple apt-get install pptpd.

Open up /etc/pptpd.conf in your editor of choice. At the end of the file, add these lines:

localip x.x.x.x
remoteip y.y.y.y-z

where x.x.x.x is the external IP of your server, and remoteip y.y.y.y-z, where y.y.y.y is the first address in the range you wish to assign to your clients, and z is the last octet of the last address you wish to assign to clients. For instance, if I wanted client IPs to lie in the range 192.168.0.1-192.168.0.254, I’d enter remoteip 192.168.0.1-254. You don’t need to do anything special to be able to assign these IPs, it’s all handled for you. Just make sure you use private address space, it’d be rude not to.

You should also append:

ms-dns 208.67.222.222
ms-dns 208.67.220.220

to the file, in order to specific the DNS servers you want your clients to use. You can, of course, substitute the 208.67.222.220/208.67.222.220 with DNS servers of your choice.

Now that the pptpd is configured, we need to allow our server to forward IPv4 traffic. This can be done by editing /etc/sysctl.conf, and uncommenting the line that reads #net.ipv4.ip_forward=1. We then need to reload the sysctl.conf file – this can be done by running sudo sysctl -p.

We also need to configure iptables to perform NAT – this can be done by running iptables -A POSTROUTING -t nat -j SNAT --to-source z.z.z.z, where z.z.z.z is the external IP of your VPS. It’s worth noting that iptables rules aren’t persisted to disk – check out this article to see how to make them survive a reboot.

We’re almost set – all that’s left to do is to create a pptpd user. This is done by editing the file /etc/ppp/chap-secrets. Entries are stored in the form username service password ip – so if I wanted to add a user called bob, with the password bananna and the IP 192.168.0.1, I’d add the line:

bob pptpd bananna 192.168.0.1

(Bear in mind that passwords in /etc/ppp/chap-secrets are stored in plaintext.)

Your pptpd VPN server is now configured – all that’s left to do is to run /etc/init.d/pptpd restart to make the changes take effect.

Tunneling OpenVPN Through SSH

I have recently discovered that it is fairly easy to tunnel OpenVPN through SSH. This is useful if you are behind a restrictive firewall that uses SPI to block services rather than plain old port blocking. An SPI firewall is able to distinguish between one packet type and another, without just checking the port that is in use. You can, of course, get a much more in-depth and accurate account of what SPI does/doesn’t do from Wikipedia, however that it’s really the purpose of this post.

You’ll need root access to the OpenVPN Server, as you have to change some of the server config files

So, on to the technical part of the procedure. You need to do the folllowing:

  1. Set the OpenVPN server config file to use TCP rather than UDP. This is done by changing the line proto udp to proto tcp in the server config file (normally located at /etc/openvpn/server.conf).
  2. Set the OpenVPN client config file to use TCP rather than UDP. You can do this by changing the line proto udp to proto tcp-client in the client config file.
  3. Change the OpenVPN client config to connect to localhost rather than the remote server address. This is done by changing the “remote” line of the server to remote localhost 1194
  4. Create an SSH tunnel between the client machine and the OpenVPN Server, and forward from remote:1194 to localhost:1194. This can be done by running the command:
    ssh user@server -L 1194:localhost:1194 on the client machine (assuming you’re running Linux/Unix with the OpenSSH client binary installed)

All being well, after making those config file changes and creating your SSH tunnel, you’ll be able to tunnel OpenVPN through SSH.

It’s not the ideal solution – the is a lot more overhead when running OpenVPN in TCP mode, and even more when tunneling TCP over TCP, which is what you’re doing by using an SSH tunnel with VPN Traffic. However, needs must – and this is one way of getting round an SPI Firewall when SSH connections are allowed

Dedicated to VPS Migration

If you’re reading this, then my blog has successfully been migrated to a different server!

I decided that it didn’t make much sense to have my old dedicated server any more, now that I’ve got a VPS node – so I span up a Debian Instance, and setup nginx, mysql and php-fcgi, and started migrating my sites over. So far, it’s been a great experience – there have been no issues, and I’m pretty sure that the site is much much faster. Just try out the search function!

I’m also hosting the previously mentioned VPS wiki on this machine, and have plenty of resources left to host several more dynamic sites.

I hope to do a quick writeup for the VPS wiki in the near future.