I'm having trouble accessing my Web Api that has been deployed to my Service Fabric cluster. I've followed the new Stateless Web Api template and have added the http endpoint seen below. I also made modifications that to the OwinCommunication as depicted here.
<Resources>
<Endpoints>
<Endpoint Name="ServiceEndpoint" Type="Input" Protocol="http" Port="8080" />
</Endpoints>
</Resources>
When creating my cluster I added a custom endpoint of 80 to my Node Type.
The client connection endpoint to my cluster is: mycluster.eastus.cloudapp.azure.com:19000
Also, I have a load balancing rule that maps port 80 to backend port 8080 over TCP. The probe associated is on port 80, and I have tried both protocols (http and tcp), but neither seem to work.
Locally, I can access an endpoint on my Web Api by calling http://localhost:8080/health/ping, and get back "pong". When I attempt to access it in service fabric cluster, a file is downloaded. The URL I use to access it in the cloud is http://mycluster.eastus.cloudapp.azure.com:19000/health/ping. I've tried other ports (19080, 80, 8080) but they either hang or give me a 400.
My questions regarding exposing a Web Api in a service fabric cluster are:
Should the probe be http or tcp?
Should the probe backend port be set to the web api port (e.g. 8080)?
Is my URL/port correct for accessing my api?
Why is a binary file being downloaded? This happens in all browsers, and the content being displayed in postman and fiddler.
Found the answer to my question after a number of heuristics. If my Web Api endpoint is set to port 8080 then I need the following:
Probe for port 8080 on TCP
A load balancing rule with port 80 and backend port 8080
Access the Web Api over the following URL: http://mycluster.eastus.cloudapp.azure.com/health/ping
As for #4, this is still a mystery.
http://mycluster.eastus.cloudapp.azure.com:19000/health/ping
This is wrong.
It should be http://mycluster.eastus.cloudapp.azure.com:8080/health/ping
At least this what the documentation says. So it should work without touching the load balancer.
Related
Please is it possible to configure reverse proxy using nginx for Grafana and Prometheus on same server. I have configured Prometheus access through https(listening on port 443 and direct output to port 9090). This works fine but configuring Grafana which is on same server to be accessed through https has been impossible. I tried it listening on port 80 and direct its output to port 3000, but it always default to http port. I also tried another port for listening but never worked.
Has anyone done this before and please can you share your valuable experience. Thanks.
Maybe this docker compose can be helpful https://github.com/vegasbrianc/prometheus/blob/master/README.md
The suggestion is to move the ssl termination to any web server (NGinx, Traefik, HAProxy) and forward the request in plain text to the underline services (prometheus and grafana). Here some examples: HAProxy exposes prometheus and Traefik
We did a network traffic capture while using the Discovery Node API and found that there was port access attempted on 621XX ports (62111, 62112, etc) and we were wondering if there was a specific set of ports the Discovery service typically uses.
This information would help immensely when firewall and corporate proxy settings come in to play.
The Watson Discovery API is an HTTPS service so only needs TCP port 443 to work. I would suggest that the activity on ports 621** are dynamic or private ports that your app is using to make the connections. They are not ports that need to be punched through firewalls, they are merely the port at which HTTPS connections to the remote server on port 443 are terminated.
All,
I have a web application running on tomcat on an amazon ec2 instance and I have a DNS name on godaddy which redirects to this web app on ec2 with an elastic ip.
Everything works fine when I open the port number 80 to all inbound traffic but recently I received an email from Amazon support saying Denial of Service (DoS) attacks were launched from my instance to IP(s) xxx.xx.xx.xxx via UDP port(s) 80.
How can i make the application accessible by closing port 80 to outside world?
Thanks in advance,
keran
http is over TCP. Only open TCP on 80, keep UDP on 80 closed. The webapp should work.
I have a web application running on tomcat on an amazon ec2 instance and I have a DNS name on godaddy which redirects to this web app on ec2 with an elastic ip.
A re-directs is an HTTP thing (and not very effecient, nor good for bookmarking). Do you mean your web app has an A record?
Everything works fine when I open the port number 80 to all inbound traffic
Yup, you need to open port 80 to serve traffic.
but recently I received an email from Amazon support saying Denial of Service (DoS) attacks were launched from my instance to IP(s) xxx.xx.xx.xxx via UDP port(s) 80.
There are 2 possible explanations:
1) Your software is buggy and trying to send data to their box via UDP. This isn't that likely, but is possible if you accidentally enabled/misconfigured collectd, syslogd, statsd, or some other package.
2) Your software is buggy and let a hacker take over your box. It could have been your web application, or it could have been some other service (if you have other ports open to the world).
Either way, a good system administrator could use TCPDump to figure out where the problem is.
How can i make the application accessible by closing port 80 to outside world?
You Can't. If you want to serve traffic to the world, you need an open port. Blocking port 80 TCP will not fix your problem because "incoming traffic on TCP port 80" (used for web servers) has nothing to do with "outgoing UDP port 80". If your box is sending UDP traffic, then it's a broken/misconfigured program running on your box.
That said, you can use a proxy service like CloudFlare to "hide" your servers behind their load balancers. But that won't fix your fundamental problem, which seems to be that your box insecure. If you are going to put a server on the Internet, you need to level up your security knowledge, or hire a system administrator.
If your content is "static" (i.e. not constantly changing, like a simple blog that's updated a few times per day), you should look into serving it from S3. S3 doesn't require a System Administrator, while EC2 does.
I have couchdb 1.2 running on the port 5984 by default and I've enabled the bind address 0.0.0.0 so that I can access the couch from the outside world. At the same time I've enabled the "required user" to true(which by defaults enables the basic auth for couchdb). I can access the couch from outside and I'm majorly using this for replication.
I have nginx in front of my application and so all the requests coming to http://example.com are reidrected to https://example.com and the requests are served by my passenger server which runs my rails application.
As I've enabled the couch from out side the world, currently I can access my couchdb either by http://ip_address:5984 or http://example.com:5984 (observer its not https).
I want to enable https to the requests which are served by couchdb. Couple of solutions which I've thought and will not be useful for me are -
1. Add a proxy to couchdb either through location ex: all requests to https://example.com/couchdb/ can be proxy passed to http://127.0.0.1:5984 (or)
2. Add a proxy by listen port ex: listen on a different port say "https://example.com:5985" and proxy pass the requests to http://127.0.0.1:5984.
3. I can't listen to 5984 and proxy pass it to http://...:5984 as the port is already being used by couchdb.
Is there a way I can say nginx to proxy pass all the requests to port 5984 through https?
ie any requests to http://example.com:5984 should be redirected to http**s**://example.com:5984
I guess the simple answer for my question would be its not possible to proxy pass requests from http://example.com:5984 to {https://example.com:5984}. For solving this problem i've enabled default https for couch so i can access my couch only through {https://example.com:5984}. SSL for couch was implemented from couchdb1.1
I have written a self hosted asp.net Web-API application which will serve on port 80. This is a restriction of the closed network it will be deployed on.
The application works fine, however suddenly during testing the service refused to start throwing the following error.
HTTP could not register URL http://+:80/ because TCP port 80 is being
used by another application.
Indeed we found that Skype had been started on that test machine and was listening on port 80. Killing Skype resolved the situation. However when deployed, we cannot guarantee our application will have port 80 to itself.
Therefore my question to is:
Is it possible to configure self hosted WebApi to share listening on port 80?
After some bit-mining, its pretty easy to fix this issue if you go to %appdata%\Skype\shared.xml and edit config\Lib\Connection\DisablePort80 to 1 and then reboot Skype, it will be fixed :)
I can't share the XML but here is it stripped:
<config timestamp="1365161986.70" serial="11206" version="1.0">
<Lib>
<DisablePort80>1</DisablePort80>
</Lib>
</config>