Cómo ejecutar localtunnel v2 correctamente

Question

Estoy usando localtunnel v1. Pero descubrí que v2 le permite personalizar el subdominio y necesito esta característica.

Seguí el tutorial descrito en el README del repository, pero me confundió en varias partes y, al final, no funcionó.

El primer paso es ejecutar alguna aplicación web: marcado, en el puerto no. 8000.

Entonces, se dice algo acerca de los nombres de host:

Localtunnel hace algunas cosas con el nombre de host, por lo que desea establecer dos nombres de host. Uno para el registro del túnel local, uno para su túnel local. Normalmente espera un comodín, pero solo codificaremos un nombre de host para este túnel de ejemplo.

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

Usted puede hacer esto en/etc/hosts o utilizar esa utilidad fantasma fantasía.

Tengo perdido aquí, pero aún así he editado mi /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 

El siguiente paso ...

ya se puede iniciar el servidor. Se basa en un archivo de configuración en el directorio de configuración . Usted puede hacer su propio, pero éste está configurado para ejecutar el servidor en el puerto 9999 y espera que el nombre de host localtunnel.local

ginkgo config/default.conf.py

¿Cuál? De todos modos ... He creado myconfig.conf.py basado en los archivos de dir localtunnel de recompra /deploy:

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

Pero, cuando ejecute:

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

llegué:

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 

Y en el proceso de ginkgo:

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 

Y, obviamente, http://example.localtunnel.local:9999 no funciona.

¿Cómo solucionar esto? ¿Y dónde tengo que modificar para cambiar el subdominio final?

Disculpe el escalofriante inglés.

---

Editar

He seguido la sugerencia de Paul e hicieron la degradación. Pero aunque han ocurrido cambios, aún se producen errores. proceso de ginkgo:

$ 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 

proceso localtunnel:

$ 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 

Aunque el ginkgo no da ningún error ahora, todavía localtunnel lanzar errores diferentes de los errores anteriores. Aparentemente trata de OBTENER "/ t/example" en el proceso de conexión.

Answer 1

Parece que este software está a la espera de una versión anterior de ws4py. El current version (0.2.1) de ws4py coincide con lo que parece que tiene, mientras que el 0.1.5 version of ws4py coincide con lo que el túnel local está tratando de usar.

La degradación a ws4py 0.1.5 puede ser suficiente para resolver los problemas que tenga.

Por otro lado, sin embargo, este no parece ser el software mejor soportado en el mundo. ¿Estás seguro de que es la solución correcta para tu problema? He revisado el código y todos los documentos proporcionados en ese repositorio, y lo que obtengo es que configura este extraño túnel tcp-over-json-over-websockets (sí, websockets, para algo con python tanto en el del lado del servidor y del lado del cliente), sin siquiera proporcionar ninguna seguridad particular o capacidades de encriptación o robustez propias, y parece no hacer nada que otras herramientas más comunes no puedan hacer mejor. Pero concedido, me puede estar perdiendo algo importante.

Answer 2

Creo que debe seguir las instrucciones para configurar el servidor localtunnel.com (es decir, si desea ejecutar su propio servidor localtunnel en algún otro dominio).

Instalar localtunnel v2 para un uso normal debe ser tan fácil como ejecutar pip install localtunnel (posiblemente con sudo).

Una vez hecho esto, basta con ejecutar localtunnel-beta -n <subdomain> 8000

Para más detalles, véase Jeff's blog post.