Jak poprawnie uruchomić localtunnel v2

Question

Używam localtunnel v1. Ale okazało się, że v2 pozwala na dostosowanie subdomeny i potrzebuję tej funkcji.

Podążyłem za tutorialem opisanym w README z repository, ale pomieszało mi to w kilku częściach, a na końcu nie zadziałało.

Pierwszym krokiem jest uruchomienie aplikacji internetowej: sprawdzone, na porcie nr. 8000.

Potem, to mówi coś o hostów:

Localtunnel robi pewne rzeczy z nazwą, więc chcesz założyć dwie hostów. Jeden do rejestracji lokalnej, jeden do twojego lokalnego tunelu. Zwykle oczekuje znaku wieloznacznego, ale po prostu utworzymy na stałe nazwę hosta dla tego przykładowego tunelu.

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

Można to zrobić w/etc/hosts lub użyć tego narzędzia fantazyjne ducha.

Mam stracił tutaj, ale ja wciąż edytowane mój /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 

Następny krok ...

Teraz można uruchomić serwer. Jest oparty na pliku konfiguracyjnym w katalogu konfiguracyjnym . Można tworzyć własne, ale ten jest skonfigurowany do uruchomić serwer na porcie 9999 i oczekuje, że nazwa hosta localtunnel.local

ginkgo config/default.conf.py

który? W każdym razie ... I stworzył myconfig.conf.py na podstawie plików w localtunnel repo reż /deploy:

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

ale kiedy uruchomić:

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

mam:

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 

I w procesie 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 

I, oczywiście, http://example.localtunnel.local:9999 nie działa.

Jak to naprawić? I gdzie muszę zmodyfikować, aby zmienić ostateczną subdomenę?

Przykro mi z powodu strasznego angielskiego.

---

Edit

Mam następnie Paul sugestii i zrobił obniżki. Ale mimo że nastąpiły zmiany, nadal występują błędy. Proces 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 

proces 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 

Chociaż ginkgo nie daje żadnego błędu teraz, localtunnel wciąż podnosząc różne błędy z poprzednich błędów. Najwyraźniej próbuje pobrać "/ t/przykład" w procesie łączenia.

Answer 1

Wygląda na to, że to oprogramowanie oczekuje starszej wersji ws4py. current version (0.2.1) z ws4py odpowiada temu, jak wygląda, podczas gdy 0.1.5 version of ws4py pasuje do tego, czego próbuje użyć localtunnel.

Obniżenie poziomu na ws4py 0.1.5 może wystarczyć, aby rozwiązać problemy, które masz.

Z drugiej strony nie wydaje się to najlepiej obsługiwanym oprogramowaniem na świecie. Jesteś pewien, że to właściwe rozwiązanie twojego problemu? Przejrzałem kod i wszystkie dokumenty dostarczone w tym repozycie, a otrzymałem to, że konfiguruje to dziwne tcp-tunnel-over-json-over-websockets (tak, websockets, dla czegoś z pythonem na obu po stronie serwera i klienta!), nie zapewniając nawet żadnych specjalnych zabezpieczeń ani własnych możliwości szyfrowania i niezawodności, i wydaje się, że nic nie robi, aby inne, bardziej powszechne narzędzia nie działały lepiej. Ale przyznaję, może brakuje mi czegoś ważnego.

Answer 2

Myślę, że musisz postępować zgodnie z instrukcjami, aby skonfigurować serwer localtunnel.com (tj. Jeśli chcesz uruchomić swój własny serwer localtunnel w innej domenie).

Instalacja localtunnel v2 do normalnego użytku powinna być tak łatwa jak uruchomienie pip install localtunnel (ewentualnie z sudo).

Po dokonaniu rejestracji, wystarczy uruchomić localtunnel-beta -n <subdomain> 8000

uzyskać więcej informacji, zobacz Jeff's blog post.