I am trying to run this docker file https://gitlab.com/snippets/1713665
consoles
I have running iroha container as you can see in right console on 50051 port, but on running the above docker file for web GRPC then you can see in left console it is unable to make connection. as i have also tried with enabling and disabling the firewalls and also with opening the 50051 withudo ufw allow 50051 sudo ufw allow 50051 ...But in the end i have the same results
"Err: connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused". Reconnecting... system=system"
I have also posted this issue month ago but no once gave me any response, Thats why i am reposting with further elaboration
Try running the grpc web proxy, with the backend address as localhost, instead of whatever is default in the gitlab post.
ex. ./grpcwebproxy-v0.13.0-osx-x86_64 --backend_addr=localhost:50051 --run_tls_server=false
From the console logs, it looks like it is trying to connect to dev.localdomain:50051
Related
I am getting node down error on rabbitmq, this is happening sometimes.
Able to see the below error when I execute: sudo rabbitmqctl status or sudo rabbitmqctl list_queues
Error: unable to connect to node : nodedown
connected to epmd (port 4369) on host-name
epmd reports node 'rabbit' running on port 25672
can't establish TCP connection, reason: timeout
suggestion: blocked by firewall?
version: {rabbit,"RabbitMQ","3.6.9"}
os: Ubuntu 16.04
I have checked hostname which is ok with me, not changed since the installation
Also able to telnet localhost 25672
What could be the reason behind this error and possible solution?
And one more question, I am checking node status using below API
curl -s GET http://edx:edx#127.0.0.1:15672/api/healthchecks/node/
Is above API ok or not to check the health status of the node? Please suggest if there is anything else. I have set up one shell script which will call this API and if status is not ok then it will restart rabbitmq-server service. Script is executed from cron every minute.
Looks like your rabbitmq node is... down. rabbitmqctl needs a running node to perform these commands.
If you're using systemd, you can check the service status:
service rabbitmq-server status
Or just try to restart the node:
rabbitmqctl start_app
Telnet on port 25672 tells you the rabbitmqctl is running, but RabbitMQ itself does not run on that port (by default, it's listening on 5672).
Local flywheel is not starting properly because it cannot open port 443 ("Heads-up!, Local's routing is having trouble starting" is the message).
I used netstats -o and nothing was using port 443.
The log from FlyWheel says:
bind() to 0.0.0.0:443 failed (10013: An attempt was made to access a socket in a way forbidden by its access permissions)
try this
run CMD as admin
type net stop http
There is an easy solution...
Preferences> Advanced> Router Mode > Localhost
It will work then.
You can watch this too
Heads up! Local's router is having trouble starting - Solved
I am trying to access etcd from within a running Docker container. When I run
curl http://172.17.42.1:4001/v2/keys
I get
curl: (7) Failed to connect to 172.17.42.1 port 4001: Connection refused
I have four other hosts where this works fine, but every container on this machine has this problem. I'm really at a loss as to what's going on, and I don't know how to debug it.
My etcd environment variables are
ETCD_ADVERTISE_CLIENT_URLS=http://10.242.10.2:2379
ETCD_DISCOVERY=https://discovery.etcd.io/<token_removed>
ETCD_INITIAL_ADVERTISE_PEER_URLS=http://10.242.10.2:2380
ETCD_LISTEN_CLIENT_URLS=http://10.242.10.2:2379,http://127.0.0.1:2379,http://0.0.0.0:4001
ETCD_LISTEN_PEER_URLS=http://10.242.10.2:2380
I can also access etcd from the host with
curl http://localhost:4001/v2/keys
So there seems to be some error when routing from the container out to the host. But I can't figure out what it is. Can anyone point me in the right direction?
I observed I had to use the --advertise-client-urls and --listen-client-urls. Like so:
./etcd --advertise-client-urls 'http://0.0.0.0:2379,http://0.0.0.0:4001' --listen-client-urls 'http://0.0.0.0:2379,http://0.0.0.0:4001'
Then I was able to successfully do
curl -L http://hostname:2379/version
from any machine that could reach that server and it worked.
It turns out etcd was only listening on localhost:4001 on that machine, which is why I couldn't access it from within a container. This is despite me configuring one of the listen client urls to 0.0.0.0:4001.
It turns out that I had run sudo systemctl enable etcd2, which caused it to run before the cloud-config service ran. As such, etcd started with default configuration instead of the one that I had specified in my cloud config. Running sudo systemctl disable etcd2 fixed the issue.
From previous versions of the question, there is this: Browse website with ip address rather than localhost, which outlines pretty much what I've done so far...I've got the local IP working. Then I found ngrok, and apparently I don't need to connect via the IP.
What I am trying to do is expose my website running on localhost to the internet. I found a tool that will do this: ngrok.
Running the website in visual studio, the website starts up on localhost/port#. I run the command "ngrok http port#" in the command line. Everything seems to start up fine. I generate a couple of URLs, and the ngrok inspection url (localhost:4040) works.
The only problem is that when I go to the generated URLs, I get an HTTP error 400: bad request invalid hostname. This is a different error than when I run "ngrok http wrongport#", which is a host not found error...so I think something good is happening. I just can't tell what...
Is there a step I am missing in exposing my site to the internet via the tunneling service? If there is, I can't find it in the ngrok documentation.
Troubleshot this issue with ngrok. In the words of inconshrevable, some applications get angry when they see a different host header than expected.
Running the following command should fix the problem:
ngrok http [port] --host-header="localhost:[port]"
Depending on the version, you may also want to try:
ngrok http [port] --host-header="localhost:[port]"
Following command will fix the issue
ngrok http -host-header=localhost 8080
This didn't work for me.
you could do the following:
For IIS Express
In VS 2015:
Go to the .vs\config\applicationhost.config folder in your project
In VS 2013 and earlier:
Go to %USERPROFILE%\My Documents\IISExpress\config\applicationhost.config
Find the binding that says:
<binding protocol="http" bindingInformation="*:5219:localhost" />
For me it was a project running on port 5219
change it to
<binding protocol="http" bindingInformation="*:5219:" />
IIS Express will now accept all incoming connections on that port.
Disadvantage: you need to run IIS Express as admin.
or you could rewrite the host header in Ngrok:
ngrok.exe http -host-header=rewrite localhost:5219
For https this works:
ngrok http https://localhost:<PORT> --host-header="localhost:<PORT>"
UPDATED COMMAND FOR LATEST VERSION
Tested with: (Windows) (ngrok v3.0.5)
Use -- instead of -
ngrok http --host-header=localhost 8080
The simplest thing for me was using iisexpress-proxy + ngrok.
First I install iisexpress-proxy globally with npm
npm install -g iisexpress-proxy
Then I proxy my localhost with it. Say for instance my site is running on 3003.
iisexpress-proxy 3003 to 12345 where 12345 is the new http port I want to proxy to.
Then I can run ngrok on it.
./ngrok.exe http 12345
It just works! 😃
But I think it works only with http. Right now I don't use https to test, but even if it works, usually it's a lot of work as always.
For https this works:
ngrok http https://localhost:<PORT> --host-header="localhost:<PORT>"
Try with different locations from the Global infrastructure > Locations
ngrok http -region eu 8080
You can make a request and view any traffic passing through your tunnel using the ngrok traffic inspector at http://localhost:4040.
OR in command line
ngrok http -region eu 8080 --log=stdout
If one region fails then try with another.
ngrok runs tunnel servers in datacenters around the world. The location of the datacenter within a given region may change without notice (e.g. the European servers may move from Frankfurt to London).
us - United States (Ohio)
eu - Europe (Frankfurt)
ap - Asia/Pacific (Singapore)
au - Australia (Sydney)
sa - South America (Sao Paulo)
jp - Japan (Tokyo)
in - India (Mumbai)
First open ngrok configuration YAML file, run from terminal:
ngrok config edit
Example of yaml for localhost setup (client & server):
version: "2"
authtoken: {YOUR_AUTH_TOKEN_FROM_NGROK_WEBSITE}
tunnels:
client:
addr: 3000
proto: http
host_header: localhost
server:
addr: 4000
proto: http
host_header: localhost
Save the config file based on your client and server ports and run the following command:
ngrok start --all
This will make ngrok open a tunnel for all the configurations declared in the yaml file
Had IIS Express .net web API, had installed NGROK in docker (windows as a host)
Had "Bad Request" error, the next command worked for me:
docker run -it -e NGROK_AUTHTOKEN=<token> ngrok/ngrok --host-header=localhost:21852 http host.docker.internal:21852
As I understood later, --host-header needed because IIS Express refuses all requests from outside (must be "localhost:port
"), host.docker.internal I've used instead of localhost, because NGROK was running inside docker, while IIS Express was running on a windows host.
I had the same issue and used the following solution:
Make sure your application binding in your IIS is set to All Unassigned IP address
Run ngrok HTTP 127.0.0.1:173 --region=eu --hostname=yourcustomdomain.eu.ngrok.io
That's it. Works perfectly. This solution is also for paid pro accounts
Steps.
Run command on your console from ngrok.exe directory . ngrok http
port i.e ngrok http 80 https://www.screencast.com/t/oyuEPlR6Z Set
Ngrok url to your app .
It will create a tunnel to your application.
Thanks .
I've got a remote server on eapps.com that I'm using as my "production" server. I have my own computer at home that I'm using as my "development" server. I'm trying to use JNDI over HTTP to do some batch processing. The following works at home, but not on the eapps machine.
I'm connecting to some EJBs (stateless session), and have my jndi.properties set to this:
(this is for the eapps machine)
java.naming.factory.initial=org.jboss.naming.HttpNamingContextFactory
java.naming.provider.url=http://my.prodhost.com:8080/invoker/JNDIFactory
java.naming.factory.url.pkgs=org.jboss.naming.client:org.jnp.interfaces
# timeout is in milliseconds
jnp.timeout=15000
jnp.sotimeout=15000
jnp.maxRetries=3
(this is for my machine at home)
java.naming.factory.initial=org.jboss.naming.HttpNamingContextFactory
java.naming.provider.url=http://localhost:8080/invoker/JNDIFactory
java.naming.factory.url.pkgs=org.jnp.interfaces
java.naming.factory.url.pkgs=org.jboss.naming.client
# timeout is in milliseconds
jnp.timeout=15000
jnp.sotimeout=15000
jnp.maxRetries=3
As I said, it works at home, but when I try it remotely, I get:
Can not get connection to server. Problem establishing socket connection for InvokerLocator [socket://my.prodhost.com:4446//?dataType=invocation&enableTcpNoDelay=true&marshaller=org.jboss.invocation.unified.marshall.InvocationMarshaller&socketTimeout=600000&unmarshaller=org.jboss.invocation.unified.marshall.InvocationUnMarshaller]
...
Caused by: java.net.ConnectException: Connection timed out: connect
Am I doing something wrong here, or is it possibly a firewall issue? To the best of my knowledge, port 4446 is not blocked.
Are the differences in the jndi.properties intentional (at the java.naming.factory.url.pkgs property level)?
Also, can you run a netstat -a | grep 4446 on both machines and update the question with the output?
Update: If the netstat command didn't return anything for port 4446 (JBoss was running, right?), then the JBoss Remoting Connector for the UnifiedInvoker service is very likely not listening on your eApps host, hence the connection timeout. Maybe this service has been disabled by eApps, you should contact the support and discuss this with them.
Just in case, a sample Connector configuration can be found in the jboss-service.xml under the server node's conf directory. Maybe compare the remote one (if you have access to it) with your local file to confirm this (but if it's disable, there must be a reason, discuss it with the support).
And by the way, this is what I get when I run the netstat command with JBoss 4.2.3.GA started on my GNU/Linux machine (default configuration):
$ netstat -a | grep 4446
tcp 0 0 localhost:4446 *:* LISTEN