I’m playing with getting Insight deployed on EC2 and as with anything like this, there are an awful lot of variables when debugging issues. Specifically, for whatever reason I couldn’t access our Django instance on port 8000 despite what I thought was opening it up in the EC2 security group. Even more puzzling, Hudson, running on port 8080 was running just fine.
This can be a variety of things. First off, you need to make sure that Django is binding to the right IP address. This can be a bit tricky on EC2, as there are both public and private IPs. But this can easily be solved by binding to all interfaces, 0.0.0.0.
% ./python manage.py runserver 0.0.0.0:8000
Sadly, that didn’t fix things for me.
Next up, can we see the IP from the box itself? An easy way to test that is to log in and then try to telnet to the port, doing a simple GET for sanity:
% telnet localhost 8000 Trying 22.214.171.124... Connected to ec2-184-73-211-105.compute-1.amazonaws.com (126.96.36.199). Escape character is '^]'. GET / .. ..
Ok, so that was working too. After verifying that the EC2 ports were indeed open and scratching my head further I decided to use a port scanner, namely nmap, to double check what ports were accessible, both from my machine at work, and from one of our other servers. That’s when I finally hit jackpot.
From one of our outside servers:
root@hq01-bot nicp]# nmap 188.8.131.52 Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2010-09-27 05:46 PDT Interesting ports on ec2-184-73-211-105.compute-1.amazonaws.com (184.108.40.206): (The 1656 ports scanned but not shown below are in state: filtered) PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 8000/tcp open http-alt 8080/tcp closed http-proxy
And from my local box:
lagom:~ nicp$ nmap 220.127.116.11 Starting Nmap 5.21 ( http://nmap.org ) at 2010-09-27 14:46 CAT Nmap scan report for ec2-184-73-211-105.compute-1.amazonaws.com (18.104.22.168) Host is up (0.32s latency). Not shown: 997 filtered ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 8080/tcp closed http-proxy
So, sure enough, my work ISP is for some reason blocking port 8000, but not port 8080. Arr!
Well at least I know what the problem is now, and that’s half the battle. If that didn’t work, my next step would have been looking to see if my instance had any firewall enabled (Ubuntu doesn’t out of the box).