10

I'm using localtunnel v1. But I found that v2 allows you to customize the subdomain, and I need this feature.

I followed the tutorial described in the README from the repository, but it confused me in several parts and, in the end, it did not work.

First step is to run some web-app: checked, on port no. 8000.

Then, it says something about hostnames:

Localtunnel does some stuff with the hostname, so you want to set up two hostnames. One for localtunnel registration, one for your localtunnel. Normally it expects a wildcard, but we'll just hardcode a hostname for this example tunnel.

example.localtunnel.local -> 127.0.0.1
localtunnel.local -> 127.0.0.1

You can do this in /etc/hosts or use that fancy ghost utility.

I've got lost here, but still I edited my /etc/hosts:

127.0.0.1   localhost
127.0.1.1   my-pc-name
127.0.0.1   example.localtunnel.local
127.0.0.1   localtunnel.local

Next step...

Now you can start the server. It's based on a configuration file in the config directory. You can make your own, but this one is configured to run the server on port 9999 and expects the hostname localtunnel.local

ginkgo config/default.conf.py

Which one? Anyway... I created myconfig.conf.py based on the files in localtunnel repo's dir /deploy:

port = 9999
hostname = 'localtunnel.local'
service = 'localtunnel.server.TunnelBroker'

But, when I run:

lt --broker 127.0.0.1:9999 --name example 8000

I got:

Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/gevent/greenlet.py", line 390, in run
  result = self._run(*self.args, **self.kwargs)
File "/usr/local/lib/python2.7/dist-packages/localtunnel/client.py", line 53, in listen
  msg = self.ws.receive(msg_obj=True)
TypeError: receive() got an unexpected keyword argument 'msg_obj'
<Greenlet at 0xb6e0db1cL: <bound method TunnelClient.listen of <localtunnel.client.TunnelClient object at 0xb6def52c>>> failed with TypeError

And in the ginkgo process:

Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/gevent/pywsgi.py", line 438, in handle_one_response
  self.run_application()
File "/usr/local/lib/python2.7/dist-packages/ws4py/server/geventserver.py", line 85, in run_application
  self.result = self.application(self.environ, start_response_for_upgrade)
File "/usr/local/lib/python2.7/dist-packages/ws4py/server/wsgi/middleware.py", line 131, in __call__
  environ.copy()))
TypeError: handle_websocket() takes exactly 3 arguments (2 given)
<BrokerFrontend fileno=6 address=0.0.0.0:9999>: Failed to handle request:
  request = GET /t/example HTTP/1.1 from ('127.0.0.1', 35907)
  application = <ws4py.server.wsgi.middleware.WebSocketUpgradeMiddleware object at 0x95bc2ac>

127.0.0.1 - - [2012-05-14 17:18:18] "GET /t/example HTTP/1.1" 101 162 0.000933

And, obviously, http://example.localtunnel.local:9999 does not work.

How to fix this? And where I have to modify to change the final subdomain?

Sorry about the creepy english.

Edit

I've followed the paul suggestion and did the downgrading. But although changes have happened, errors still occur. ginkgo process:

$ ginkgo eco.conf.py  
Starting process with eco.conf.py...  
127.0.0.1 - - [2012-05-22 20:21:11] "GET /t/example HTTP/1.1" 400 116 0.000190

localtunnel process:

$ lt --broker 127.0.0.1:9999 --name example 8000
Traceback (most recent call last):
  File "/usr/local/bin/lt", line 9, in <module>
    load_entry_point('localtunnel==0.4.0', 'console_scripts', 'lt')()
  File "/usr/local/lib/python2.7/dist-packages/localtunnel/client.py", line 31, in main
    client.serve_forever()
  File "/usr/local/lib/python2.7/dist-packages/ginkgo/core.py", line 188, in serve_forever
    self.start()
  File "/usr/local/lib/python2.7/dist-packages/ginkgo/core.py", line 124, in start
    ready = not self.do_start()
  File "/usr/local/lib/python2.7/dist-packages/localtunnel/client.py", line 42, in do_start  
    self.ws.connect()
  File "/usr/local/lib/python2.7/dist-packages/ws4py-0.1.5-py2.7.egg/ws4py/client/threadedclient.py", line 72, in connect
    self.process_response_line(response_line)
  File "/usr/local/lib/python2.7/dist-packages/ws4py-0.1.5-py2.7.egg/ws4py/client/__init__.py", line 61, in process_response_line
    raise HandshakeError("Invalid response status: %s %s" % (code, status))
ws4py.exc.HandshakeError: Invalid response status: 400 Bad Handshake

Although ginkgo does not give any error now, localtunnel still raising errors different from previous errors. Apparently it tries to GET "/t/example" in the connecting process.

borges
  • 3,627
  • 5
  • 29
  • 44

2 Answers2

2

It looks like this software is expecting an older version of ws4py. The current version (0.2.1) of ws4py matches what it looks like you have, while the 0.1.5 version of ws4py matches what localtunnel is trying to use.

Downgrading to ws4py 0.1.5 may be sufficient to solve the problems you're having.

On the other hand, though, this doesn't seem like the best-supported software in the world. Are you sure it's the right solution for your problem? I've looked through the code and all the docs provided in that repo, and what I get is that it sets up this weird tcp-tunnel-over-json-over-websockets (yeah, websockets, for something with python on both the server and client side!) thing, without even providing any particular security or encryption or robustness capabilities of its own, and it appears to do nothing that other more common tools can't do better. But granted, I may be missing something important.

the paul
  • 8,972
  • 1
  • 36
  • 53
  • Is there any other information I could provide or explain to improve my answer here? – the paul May 21 '12 at 18:28
  • A thousand apologies for the delay in responding ... But only downgrading ws4py did not work. Please see my edit. – borges May 22 '12 at 23:30
  • And about your comment, my goal with this tool is just to share local web servers for tests features that are not related to security. If you know any tool that does the same, I'd love to know! – borges May 22 '12 at 23:34
  • Are you familiar with ssh tunnels? If I'm understanding your problem correctly, they would solve it very well. – the paul May 23 '12 at 02:00
  • I guess one useful piece of information for finding your right solution would be this: what stops you from just making the local web servers listen on an external interface themselves? – the paul May 23 '12 at 04:44
  • I agree totally with this being the wrong tool. I think you'd be much better off with a more low-level tunnel (ssh, stunnel, netcat, etc) or a HTTP proxy or router port-forward, NAT, DMZ, etc. This is what you'd normally use in a production environment to expose a non-public service to a public network. – SpliFF May 23 '12 at 07:59
  • I've used ssh quite superficially. But have no experience in anything more advanced than the very basic. What I really like in this tool is that it generates a url that I can share without the need to have an external server and domain. But from what I understand it, if I wanted to repeat this behavior using ssh (eg) I need both. Am I correct? – borges May 23 '12 at 10:38
  • This localtunnel tool does still need an external server- there has to be some way for the two ends to connect. If both the remote end and the local end have not-publicly-routable addresses, then localtunnel won't help you–unless you use a third, public host as a go-between (but if you have that, then you have an external server). But neither ssh nor localtunnel require you to own a domain. – the paul May 23 '12 at 14:08
  • localtunnel v1 uses the `localtunnel.com` domain, we don't need to own neither a external server nor domain. Apparently this new version radically changes this behavior. – borges May 23 '12 at 15:56
  • Another thing, I really don't know if I should accept this answer, because it doesn't fully answer the question. So other people with the same question won't get their answer here. – borges May 23 '12 at 16:03
  • Ahh, I didn't realize that localtunnel.com was running as a public service, not just an example domain. It would probably have been a lot more helpful for these people to have set up a [NAT punch-through server](http://www.raknet.net/raknet/manual/natpunchthrough.html) instead of this odd wheel-reinvention. Is that the part that you wanted to change, the tunnel broker pointing at localtunnel.com? Or was it that you wanted to configure the hostname that gets used for your connections, XXX.localtunnel.com? – the paul May 23 '12 at 17:04
  • Obviously it's up to you whether to accept the answer, but wasn't the original question about how to fix those two tracebacks? – the paul May 23 '12 at 17:08
  • The v1 generates a random subdomain in localtunnel.com, but the v2 allows you to [customize this subdomain](https://github.com/progrium/localtunnel/issues/19#issuecomment-2327370). Then, to use a custom tunnel name and default tunnel broker (localtunnel.com) should do what I want. And yes, the original question is about how to fix the tracebacks, but the edit shows that it is not fixed properly. Please, don't get me wrong, I really appreciate your effort in helping me. My english sucks and sometimes I can't put in words what I am trying to say. – borges May 23 '12 at 18:08
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/11656/discussion-between-the-paul-and-borges) – the paul May 23 '12 at 18:50
  • See my answer below.. I think he was trying to set up the development version of localtunnel. – Michael Warkentin Jan 03 '13 at 15:28
1

I think you must be following the instructions to set up the localtunnel.com server (ie. if you wanted to run your own localtunnel server on some other domain).

Installing localtunnel v2 for normal use should be as easy as running pip install localtunnel (possibly with sudo).

Once that's done, just run localtunnel-beta -n <subdomain> 8000

For more details, see Jeff's blog post.

Michael Warkentin
  • 2,403
  • 1
  • 15
  • 10