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.
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.
Related
I am trying to make calls using PJSIP module in python. For setup of SIP transport, I am doing like
trans_cfg = pj.TransportConfig()
# port for VoIP communication
trans_cfg.port = 5060
# local system address
trans_cfg.bound_addr = inputs.client_addr
transport = lib.create_transport(pj.TransportType.UDP,trans_cfg)
when I finish the call I am clearing the transport setup as, transport = None.
I am able to make call to user by running my program. But every time I restart my PC alone, I get an error while I run my python program
File "pjsuatrail_all.py", line 225, in <module>
main()
File "pjsuatrail_all.py", line 169, in main
transport = transport_setup()
File "pjsuatrail_all.py", line 54, in transport_setup
transport = lib.create_transport(pj.TransportType.UDP,trans_cfg)
File "/usr/local/lib/python2.7/dist-packages/pjsua.py", line 2304, in
create_transport
self._err_check("create_transport()", self, err)
File "/usr/local/lib/python2.7/dist-packages/pjsua.py", line 2723, in _err_check
raise Error(op_name, obj, err_code, err_msg)
pjsua.Error: Object: Lib, operation=create_transport(), error=Address already in use
Exception AttributeError: "'NoneType' object has no attribute 'destroy'" in <bound method Lib.__del__ of <pjsua.Lib instance at 0x7f8a4bbb6170>> ignored
For this currently I am doing like
$sudo lsof -t -i:5060
>> 1137
$sudo kill 1137
Then I run my code it works fine.
By instance from error, I can understand that somewhere I am not closing my transport configuration properly. Can anyone help in this regards.
Reference code used
From the inputs you give, it can be understood that its not the problem with pjsip wrapper. Transport configurations looks fine.
Looking in to the 'create_transport' error, the program is not able to create the connection because 5060 port is already occupied with some other program.
For that you are killing that process and you are able to run the program with out any error. And you say it only on restart, so on your system restart some program is occupying the port.
You can try like this
sudo netstat -nlp|grep 5060
in your case it will give like
1137/ProgramName
go to the 'ProgramName' in your startup configurations and make modifications such that it wont pickup the port.
I am having problem for running the following program (sparql_test.py). I am running it from Linux machine. I am installing Virtuoso server in the same Linux machine. In the Linux server, I don't have sudo permission nor browser access. But, I can execute SPARQL query from isql prompt (SQL>) successfully.
Program: sparql_test.py
from SPARQLWrapper import SPARQLWrapper, JSON
sparql = SPARQLWrapper("http://localhost:8890/sparql")
sparql.setQuery("select ?s where { ?s a <http://ehrofip.com/data/Admissions>.} limit 10")
sparql.setReturnFormat(JSON)
result = sparql.query().convert()
for res in result["results"]["bindings"]:
print(res)
I got the following error:
[suresh#deodar complex2vec]$ python sparql_test.py
Traceback (most recent call last):
File "sparql1.py", line 14, in "<module>"
result = sparql.query().convert()
File "/home/suresh/.local/lib/python2.7/site-packages/SPARQLWrapper/Wrapper.py", line 687, in query
return QueryResult(self._query())
File "/home/suresh/.local/lib/python2.7/site-packages/SPARQLWrapper/Wrapper.py", line 667, in _query
raise e
urllib2.HTTPError: HTTP Error 502: Bad Gateway
However, the above program run smoothly in my own laptop. What might be the problem? Is this issue of connection?
Thank you
Best,
Suresh
I do not believe this error is raised by Virtuoso. I believe it is raised by SPARQLWrapper.
It looks like there's something between the outside world (which includes the Linux machine itself) and the Virtuoso listener on port 8890. The "Bad Gateway" suggests there may be two things -- a reverse proxy, and a firewall.
Port 8890 (set as [HttpServer]:Listen in the INI file) must be open to communications, direct or proxied, for SPARQL access to work.
iSQL talks to port 1111 (set as [Parameters]:Listen in the INI file), which apparently doesn't have a similar block/proxy.
I'm trying to figure out how to deploy a Bokeh slider chart over an IIS server.
I recently finished up a Flask application, so I figured I'd try the route where you embed through flask:
https://github.com/bokeh/bokeh/tree/master/examples/howto/server_embed
It's nice and easy when I launch the script locally.. but I can't seem to set it up properly over IIS. I believe the complexity is stemming from the fact that the wfastcgi.py module I'm using to deploy over IIS can't easily multi-thread without some sort of hack-like work around.
So, my second attempt was to wrap the flask app in tornado as below OPTION B
(without much success, but still think this is my best lead here)
Run Flask as threaded on IIS 7
My third attempt was to try and run Bokeh server standalone on a specific port. I figured I'd be able to run the server via standalone_embed.py using wfastcgi.py on say port 8888 & while using port 5000 for the server callbacks. However, the Server function:
from bokeh.server.server import Server
still launches it locally on the host machine
server = Server({'/': bokeh_app}, io_loop=io_loop, port=5000)
server.start()
So this actually works if I go to http://localhost:5000/ on the host,
but fails if I go to http://%my_host_ip%:5000/ from a remote machine.
I even tried manually setting the host but get an "invalid host" error:
server = Server({'/': bokeh_app}, io_loop=io_loop, host='%my_host_ip_address_here%:5000')
server.start()
ERR:
Error occurred while reading WSGI handler: Traceback (most recent call last): File "C:\Python34\lib\site-packages\bokeh\server\server.py", line 45, in _create_hosts_whitelist int(parts[1]) ValueError: invalid literal for int() with base 10: '' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "C:\WebsitesFlask\bokehTest\wfastcgi.py", line 711, in main env, handler = read_wsgi_handler(response.physical_path) File "C:\WebsitesFlask\bokehTest\wfastcgi.py", line 568, in read_wsgi_handler return env, get_wsgi_handler(handler_name) File "C:\WebsitesFlask\bokehTest\wfastcgi.py", line 537, in get_wsgi_handler handler = import(module_name, fromlist=[name_list[0][0]]) File ".\app.py", line 41, in server = Server({'/': bokeh_app}, io_loop=io_loop, host='%my_host_ip_address_here%:5000') File "C:\Python34\lib\site-packages\bokeh\server\server.py", line 123, in init tornado_kwargs['hosts'] = _create_hosts_whitelist(kwargs.get('host'), self._port) File "C:\Python34\lib\site-packages\bokeh\server\server.py", line 47, in _create_hosts_whitelist raise ValueError("Invalid port in host value: %s" % host) ValueError: Invalid port in host value: : StdOut: StdErr:
First off, the --host parameter should no longer be needed in the next 0.12.5 release. It's probably been the most confusing stumbling block for people trying to deploy a Bokeh server app in a "production" environment. You can follow the discussion on this issue on GitHub for more details.
Looking at the actual implementation in Bokeh that generates the error you are seeing, it is just this:
parts = host.split(':')
if len(parts) == 1:
if parts[0] == "":
raise ValueError("Empty host value")
hosts.append(host+":80")
elif len(parts) == 2:
try:
int(parts[1])
except ValueError:
raise ValueError("Invalid port in host value: %s" % host)
The exception you are reporting that states that int(parts[1]) is failing:
Traceback (most recent call last):
File "C:\Python34\lib\site-packages\bokeh\server\server.py", line 45,
in _create_hosts_whitelist int(parts[1])
ValueError: invalid literal for int() with base 10:
So, there is something amiss with the string you are passing for hosts that's causing the part after the colon to not be able to be converted to in int But without seeing the actual string, it's impossible to say much more. Maybe there is some encoding issue that needs to be handled differently or better. If you can provide a concrete string example that reproduces the problem I can take a closer look.
This is the problem:
File "/app/.heroku/python/lib/python2.7/site-packages/django/utils/six.py", line 535, in next
return type(self).__next__(self)
File "/app/.heroku/python/lib/python2.7/site-packages/django/http/multipartparser.py", line 344, in __next__
output = next(self._producer)
File "/app/.heroku/python/lib/python2.7/site-packages/django/utils/six.py", line 535, in next
return type(self).__next__(self)
File "/app/.heroku/python/lib/python2.7/site-packages/django/http/multipartparser.py", line 406, in __next__
data = self.flo.read(self.chunk_size)
File "/app/.heroku/python/lib/python2.7/site-packages/django/http/request.py", line 267, in read
six.reraise(UnreadablePostError, UnreadablePostError(*e.args), sys.exc_info()[2])
File "/app/.heroku/python/lib/python2.7/site-packages/django/http/request.py", line 265, in read
return self._stream.read(*args, **kwargs)
File "/app/.heroku/python/lib/python2.7/site-packages/django/core/handlers/wsgi.py", line 59, in read
result = self.buffer + self._read_limited(size - len(self.buffer))
File "/app/.heroku/python/lib/python2.7/site-packages/django/core/handlers/wsgi.py", line 47, in _read_limited
result = self.stream.read(size)
UnreadablePostError: error during read(65536) on wsgi.input
My current configuration reads like this:
[uwsgi]
http-socket = :$(PORT)
master = true
processes = 4
die-on-term = true
module = app.wsgi:application
memory-report = true
chunked-input-limit = 25000000
chunked-input-timeout = 300
socket-timeout = 300
Python: 2.7.x | uWsgi: 2.0.10
And to make the problem even more specific, this is happening when I process images synchronously along with an image upload. I know that ideally I must do this using Celery, but because of a business requirement I am not able to do that. So need to configure the timeout in such a way that it allows me to accept a large image file, process it and then return response.
Any kind of light on the question will be extremely helpful. Thank you.
The error quoted in the description isn't the full picture; the relevant part is this lot entry:
[uwsgi-body-read] Error reading 65536 bytes … message: Client closed connection uwsgi_response_write_body_do() TIMEOUT
This specific error is being raised because (most probably) the client, or something between it and uWSGI, aborted the request.
There are a number of possible causes for this:
A buggy client
Network-level filtering (DPI or some misconfigured firewall)
Bugs / misconfiguration in the server in front of uWSGI
The last one is covered in the uWSGI docs:
If you plan to put uWSGI behind a proxy/router be sure it supports chunked input requests (or generally raw HTTP requests).
To verify your issue really isn't in uWSGI, try to upload the file via the console on the server hosting your uWSGI application. Hit the HTTP endpoint directly, bypassing nginx/haproxy and friends.
I am trying to open a telnet connection, write one string, then print everything from the telnet server in Python. I assume I am missing something obvious because the documentation seems pretty self-explanatory and doing what I think is the exact same thing in terminal works fine.
Here is the Python code:
import telnetlib
telnet = telnetlib.Telnet()
telnet.open('192.168.1.128', 9801, 10)
telnet.write("SYSTEM_CAL")
print(telnet.read_all())
This times out after 10 seconds / doesn't successfully connect to the server I assume. Here is the output:
Traceback (most recent call last):
File "/Volumes/Work/Scripting/Telnet Test/main.py", line 9, in <module>
print(telnet.read_all())
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/telnetlib.py", line 385, in read_all
self.fill_rawq()
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/telnetlib.py", line 576, in fill_rawq
buf = self.sock.recv(50)
socket.timeout: timed out
In the image below I connect to the same server in terminal and everything works fine. At the end I give the "DISCONNECT" command taken by the server which is why the connection closes.
Am I missing something? Why is this working in Terminal and not in Python?
I suppose you are sending your command too early, and the receiving end is ignoring it. Try to read the banner first:
print(telnet.read_until("Welcome."))
telnet.write("SYSTEM_CAL")
print(telnet.read_all())
EDIT:
I also note that you don't have a line-terminating sequence at the end of "SYSTEM_CAL". I presume that, in the interactive session, you press ↵ ENTER after you type "SYSTEM_CAL". If that is the case, you'll need to add \n at the end of the write() call:
telnet.write("SYSTEM_CAL\n")
Depending upon other factors outside of your question, it is possible that you may need one of the following instead:
telnet.write("SYSTEM_CAL\r")
telnet.write("SYSTEM_CAL\r\n")