Forums

I just got through pulling up some twisted code I did a while ago that I wanted to try using in python anywhere, but I ran into an issue. While it is possible to setup a WSGI app it looks like there's no supported way to get the public ip address of a console session for my twisted app. Have I missed anything?

Not a developer of the system here, but figured I'd chime in.

From what I can tell they have a standard Debian box that's running each user in it's own container (likely chroot, that's what it looks like to me). Then they have an Apache 2 server with mod_wsgi serving with a virtual host for each user pointed at their own unique wsgi app (wsgi middleware makes this dead simple to do, I really hope they have it there and not in apache honestly).

What all this means is that you share an IP. Found this out with my own tinkering, if I send a different SERVER_NAME wsgi param, I get routed to someone else's app (and it defaults to pythonanywhere.com). I'm not sure how this does with opening ports other than the std port 80 (likely disallows it entirely, as SSL isn't currently supported) since I would assume you are sharing a box with everyone else.

Now as for your telnet shell into the running twisted app (assuming I'm understanding what you're trying to do correctly), I would think they are running across multiple physical boxes on the amazon servers. Not sure what that does to running two bash shells, and trying to have one talk to the other, but worst case scenario you start up the twisted server with a "python myscript.py &" and then when it goes into the background, start up a telnet or netcat session to the port twisted is listening on.

If you're having trouble getting web traffic routed to an instance of your code without going through WSGI, there's only one thing that pops to mind and I don't know how it works. That would be setting up a wsgi->HTTP proxy (see the paste.proxy stuff) which talks to your code via HTTP. If your app doesn't talk WSGI, not a ton else I can think of is going to help, since that's currently what a lot of this stuff is based around.

Hello,

Yes that's a pretty good summary of how it all works. With a registered user account you can actually bind/listen on arbitrary ports above the reserved system ports. Because you have ssh access it is possible to do reverse tunnelling but that might not really help much.

So essentially: There is a single public IP that all requests are routed through by various means as Dragonfyre says.

Cheers

h

I figured as much, but if I could get the current IP then I could use it for development, instruction and demos. Of course, given the shared architecture, you might actually prefer to disallow this use entirely, but I'll ask and you can let me know.

• Andy

For the foreseeable future, we're not going to support incoming connections. The IP of our servers is not stable, so it would be pretty difficult for you to keep updating your client when it changes.

However, I think that sounds like a great feature that we could provide. I have added it to our tracking system. Post here if you'd like to vote for this feature.

I vote for this feature. Routing in to our sessions from outside would be highly useful!! That could even get me to upgrade my account...:)

I have voted for the ticket on your behalf.