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.1You 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.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With