Question

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.

Answer 1

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.