Come eseguire localtunnel v2 correttamente

Question

Sto usando localtunnel v1. Ma ho scoperto che v2 ti permette di personalizzare il sottodominio, e ho bisogno di questa funzionalità.

Ho seguito il tutorial descritto nello repository, ma mi ha confuso in più parti e, alla fine, non ha funzionato.

Il primo passo è eseguire alcune web-app: spuntato, sulla porta n. 8000.

Poi, dice qualcosa che riguarda i nomi degli host:

Localtunnel fa alcune cose con il nome host, in modo che si desidera impostare due nomi host. Uno per la registrazione localtunnel, uno per il tuo localtunnel. Normalmente prevede un carattere jolly, ma eseguiremo un hardcode di un nome host per questo tunnel di esempio.

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

Si può fare questo in/etc/hosts o utilizzare tale utilità fantasma fantasia.

ho perso qui, ma ancora ho modificato il mio /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 

passo successivo ...

questo punto è possibile avviare il server. Si basa su un file di configurazione nella directory di configurazione . Si può fare il vostro proprio, ma questo è configurato per eseguire il server sulla porta 9999 e si aspetta il nome host localtunnel.local

ginkgo config/default.conf.py

Quale? Comunque ... Ho creato myconfig.conf.py in base ai file nella directory localtunnel di pronti contro termine /deploy:

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

Ma, quando ho eseguire:

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

ho ottenuto:

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 

E nel processo di 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 

E, ovviamente, http://example.localtunnel.local:9999 non funziona.

Come risolvere il problema? E dove devo modificare per cambiare il sottodominio finale?

Mi dispiace per l'inquietante inglese.

---

Modifica

ho seguito Paul suggerimento e ha fatto il declassamento. Ma anche se i cambiamenti sono avvenuti, si verificano ancora degli errori. processo di 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 

processo 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 

Anche se il ginkgo non dà alcun errore ora, localtunnel ancora alzando errori diversi da errori precedenti. Apparentemente tenta di ottenere "/ t/example" nel processo di connessione.

Answer 1

Sembra che questo software si aspetti una versione precedente di ws4py. Lo current version (0.2.1) di ws4py corrisponde a quello che sembra avere, mentre lo 0.1.5 version of ws4py corrisponde a ciò che localtunnel sta tentando di utilizzare.

Il downgrade a ws4py 0.1.5 può essere sufficiente per risolvere i problemi che si verificano.

D'altro canto, tuttavia, questo non sembra il software più supportato al mondo. Sei sicuro che sia la soluzione giusta per il tuo problema? Ho esaminato il codice e tutti i documenti forniti in quel repository e quello che ottengo è che esso crea questo strano tcp-tunnel-over-json-over-websockets (sì, websockets, per qualcosa con python su entrambi i lato server e client!), senza nemmeno fornire alcuna particolare sicurezza o capacità di crittografia o robustezza, e sembra non fare nulla che altri strumenti più comuni non possano fare meglio. Ma scontato, potrei mancare qualcosa di importante.

Answer 2

Penso che sia necessario seguire le istruzioni per configurare il server localtunnel.com (ad esempio se si desidera eseguire il proprio server localtunnel su un altro dominio).

L'installazione di localtunnel v2 per l'uso normale dovrebbe essere semplice come eseguire pip install localtunnel (eventualmente con sudo).

Una volta fatto, basta eseguire localtunnel-beta -n <subdomain> 8000

Per maggiori dettagli, vedere Jeff's blog post.