Accessing Django Runserver on Shared Hosting

Question

I'm developing a Django application on a shared hosting service (hostmonster) and am, of course, unable to access the runserver on the default localhost ip of 127.0.0.1:8000 over Firefox. The Django Project site's documentation details how to set up remote access to the run-server, but I'm not having any success with that. Setting the runserver to 0.0.0.0:8000 leaves it inaccessible. Though I figured it wouldn't work, I tried to configure the runserver to my home ip address. That gave me a "That IP address can't be assigned-to" error, as I'd expected.

So, I tried configuring it to my hosted IP, the one through which I SSH in the first place. That set up properly, but still was unable to access the address via Firefox. When I plug in the IP address on its own, I just get a hostmonster error page. When I affix the port number, the connection times out. When I plug in the IP, port number and the /admin to access the Django admin page I've created, I also time out.

Answer 1

Other comments about (not) using runserver on production environments apply.

If you really must run it this way I would recommend using SSH tunnelling, via the -L switch.

e.g. ssh -L 8888:127.0.0.1:8000 <user>@<remotehost>

Then you should be able to view the site on your local machine via http://localhost:8888

This is assuming you are only trying to make the application available to yourself during development.

Answer 2

Running : python manage.py runserver 0.0.0.0:8000

Hosts the website on port 8000 and can be accessed over http://site.com:8000/

Running : python manage.py runserver 0.0.0.0:80 (You would need the root access)

This hosts the website on port 80 and can be accessed over http://site.com/ (port 80 is implicit here).

But, since you say that you are on a shared hosting - so you won't get the root access, so you can't host on port 80 like this. For porting hosting on port 80 on a shared hosting you would have to create virtual hosting on the webserver running on that shared server and that can only be done if you own a domain name.

So, for testing purposes - I would suggest that you use port 8000 and use it via http://site.com:8000/ from your home.

Here, 0.0.0.0 means its hosted for all ip ranges. (change site.com with your ip address if you don't have the domain name)

If you are still not able to access - that might mean that port hosting is banned on that server for users, since that is not easy on a shared server with many many sharing users.

Answer 3

I'm betting that port 8000 is blocked. That explains the timeouts you mention in the last couple sentences: the firewall is set to simply drop the packets and not return any connection refusal responses.

You're going to have to ask your hosting company if there's a way around this, but there might not be one. At the least, they'll have to open a non-root port (8000 or something else over 1023), but the OS can't tell when it's you opening the port or something else, so it'll be a potential security hole (e.g. an intruder can set up something to listen for commands on that port, just like you are).

runserver wasn't really designed to be run on the production box. It's designed to be run on your development machine, with a small test database or something. This lets you get most of the bugs out. Then you push your code to a beta server, configured with the real server apps (e.g. apache on port 80) and databases and such, to do the heavy testing (make sure there's a filter for what IPs can connect, at least). Then you push to production from there. Or not; there are lots of ways to do this.

Answer 4

First, a webserver typically has at least two "interfaces", each with one or more IPs. The "loopback" interface will have the IP 127.0.0.1, and is ONLY accessible from the machine running the server.

So, running on 127.0.0.1:8000 means that you are telling runserver to be accessible ONLY from that server itself, on port 8000. That's secure, but a little rough for testing. In order to see the result in a web browser you would need to use an SSH tunnel with port forwarding. (I'd explain how to do that, but honestly, it won't solve your real issue. But I'll come back to that.)

Running on :8000 means that you are telling runserver to be accessible from the internet - which is probably what you want. If that's not working, then it probably means they're firewalling the port. You could contact support and ask them to open a hole, OR use an SSH tunnel, but at this point I have to ask: What are you trying to achieve?

You shouldn't use runserver for production. Use runserver on your local machine for testing, then deploy to Hostmonster. (Apparently they support Django via FastCGI, according to their website.) Don't use runserver on Hostmonster, it won't do what you want.