I am trying to install code-server 3.6.2 on a cloud platform. I have tried both AWS and digitalocean machines but in both systems, I can open code server but it gives an error "WebSocket close with status code 1006".
I have followed the procedure from https://www.digitalocean.com/community/tutorials/how-to-set-up-the-code-server-cloud-ide-platform-on-ubuntu-20-04
code-server uses websocket to connect.Do you use HTTPS?
If so, you should Use wss to forward ws.like this:
// forward websocket (wss -> ws)
httpsServer.on('upgrade', function (req, socket, head) {
proxy.ws(req, socket, head, {
target: 'ws://...',
ws: true
})
})
Usually this and other errors happen when you use code server locally
To solve it you can use the --link parameter that gives you a url with temporary https, or you can also use ngrok
//Option 1
code-server --host 127.0.0.1 --bind-addr 0.0.0.0:9000 --auth password --link
//Option 2
code-server --host 127.0.0.1 --bind-addr 0.0.0.0:9000 --auth password
ngrok http 9000
Related
I created a simple nodejs app on the aws-ec2 server following the instructions. The code is:
#!/usr/bin/env nodejs
var http = require('http');
http.createServer(function (req, res)
{
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World\n');
}).listen(8080, '138.68.244.XXX');
//138.68.244.XXX is the IP of my ec2 server
console.log('Server running at http://localhost:8080/');
After I started the app by the command: node hello.js
I got output:
Server running at http://localhost:8080/
I was able to curl the URL:
curl http://138.68.244.XXX:8080
to get “Hello World” on the server itself, however, when I tried:
http://138.68.244.XXX:8080
in a browser, I got:
ERRCONNECTIONTIMED_OUT
Please help,
Thank you!
Check this FAQ entry (how to open a port on an instance with a public IP). As port 8080 is not a standard HTTP port, you probably need to update the security group and ACL.
I am trying to run a django-channels project locally using https (the app has a facebook login that requires https).
I have followed the instructions for generating a key and certificate using mkcert ( https://github.com/FiloSottile/mkcert ) and have attempted to use the key and certificate by running daphne -e ssl:443:privateKey=localhost+1-key.pem:certKey=localhost+1.pem django_project.asgi:application -p 8000 -b 0.0.0.0
The server seems to be starting OK however when I try to visit https://0.0.0.0:8000 nothing happens and eventually I get a 'took too long to respond' message.
No new output is added to the standard daphne output that appears when I start up the server:
2019-07-16 19:23:27,818 INFO HTTP/2 support enabled
2019-07-16 19:23:27,818 INFO Configuring endpoint ssl:8443:privateKey=../sec/localhost+1-key.pem:certKey=../sec/localhost+1.pem
2019-07-16 19:23:27,823 INFO Listening on TCP address 0.0.0.0:8443
2019-07-16 19:23:27,823 INFO Configuring endpoint tcp:port=8000:interface=0.0.0.0
2019-07-16 19:23:27,824 INFO Listening on TCP address 0.0.0.0:8000
Can anyone help with this?
You should map the 8000 host port to port 443 of the container while runnig the server.
docker run ... -p 8000:443 ...
Turns out that setting up the Twisted ssl stuff overrides the port that you're setting up in daphne, so in the example above, the site would be shown on port 443
I have installed CouchDB in my AWS server. When I run the command
curl localhost:5984
then I got a response like:
{"couchdb":"Welcome","uuid":"b7a38141c61a37390945a99fd88f0015","version":"1.6.0","vendor":{"version":"15.10","name":"Ubuntu"}}
But when I run this command:
curl ip_address:5984
then it gives:
curl: (7) Failed to connect to Ip-address port 5984: Connection refused
Your CouchDB is not listening on all interfaces. Edit your couch.ini file and modify the line to:
bind_address = 0.0.0.0
and restart couch service. If it still doesn't work, post the output of netstat -plan | grep 5984.
Clearly explained here: CouchDB HTTP Server
bind_address : Defines the IP address by which CouchDB will be accessible:
[httpd]
bind_address = 127.0.0.1
To let CouchDB listen any available IP address, just set up 0.0.0.0 value:
[httpd]
bind_address = 0.0.0.0
We are running "helloworld" example from https://grpc.io/docs/quickstart/cpp.html#update-a-grpc-service and we received the following ERROR:
14: Connect Failed
Greeter received: RPC failed.
The server and the client are listening on: 0.0.0.0:50051. The Server is running.
First we receive just a packet on the server and the client crashes, I checked it with tcpdump. We checked on different hosts as well as on the same host but it didn't work for either cases.
Should we change a different IP or different Port number?
I got the same issue on my PC(OS: ubuntu 16.04 LTS, protobuf 3.4.0)
so I search for the reason and I found this:
Reason
If on a linux machine, the environment has the usual "http_proxy" environment variable configured, gRPC will take that into account when trying to connect, however, will then proceed to ignore the companion no_proxy setting:
For example:
$ env
http_proxy=http://106.1.216.121:8080
no_proxy=localhost,127.0.0.1
$ ./greeter_client
D0306 16:00:11.419586349 1897 combiner.c:351] C:0x25a9290 finish old_state=3
D0306 16:00:11.420527744 1896 tcp_client_posix.c:179] CLIENT_CONNECT: ipv4:106.1.216.121:8080: on_writable: error="No Error"
D0306 16:00:11.420567382 1896 combiner.c:145] C:0x25a69a0 create
D0306 16:00:11.420581887 1896 tcp_client_posix.c:119] CLIENT_CONNECT: ipv4:106.1.216.121:8080: on_alarm: error="Cancelled"
I0306 16:00:11.420617663 1896 http_connect_handshaker.c:319] Connecting to server 127.0.0.1:50051 via HTTP proxy ipv4:106.1.216.121:8080
Basically, it's using the http_proxy url to connect even though localhost is in the no_proxy list. Since the default for no_proxy includes localhost on most linux machines; the end result is that any user with an http_proxy configured will never be able to connect to localhost. --- [1]
Other solution
You can enable grpc tracing with
export GRPC_TRACE=all && ./greeter_server and same thing for the client.
Verification
Terminal 1
Terminal 2
That should do the trick
ps. for more information about GRPC_TRACE - gRPC environment variables
Reference
gRPC doesn't respect the no_proxy environment variable
I installed node.js on a hosted Apache server. The simple server I placed on the server runs fine, but when I go to the website I cannot see the website.
I initially tested this on my local machine and it works fine, but I need this on a production website. How can I do this.
My Node.js code
[code]
// Load the net module to create a tcp server.
var net = require('net');
// Setup a tcp server
var server = net.createServer(function (socket) {
// Every time someone connects, tell them hello and then close the connection.
socket.addListener("connect", function () {
sys.puts("Connection from " + socket.remoteAddress);
socket.end("Hello World\n");
});
});
// Fire up the server bound to port 7000 on localhost
server.listen(1337, "localhost");
[/code]
// Put a friendly message on the terminal
console.log("TCP server listening on port 1337 at localhost.");
Then I run node test.js
Response : TCP server listening on port 1337 at localhost.
Then I go to www.mywebsite.com:1337
Oops! Google Chrome could not connect to www.mywebsite.com:1337
So I tried using the actual IP
server.listen(1337, "xx.xx.xx.xx");
And the URL
server.listen(1337, "http://mywebsite.com");
// this actually broke the server immediatly
So how can I do this?
You will need a firewall rule to allow incoming traffic.
iptables -A INPUT -p tcp --dport 1337 -j ACCEPT
and do not bind to localhost, but on the port only:
server.listen(1337/*, "localhost"*/);
http://nodejs.org/api/net.html#net_server_listen_port_host_backlog_callback
EDIT: This comments out the host, so your server will listen on all adresses (this is the same as:)
server.listen(1337);
If you still encounter problems, this is most likely a firewall problem.