I would like to send HTTPS requests to the same host but I would like to choose the target IP every time.
For example "dig digitalocean.com" shows these IPs:
digitalocean.com. 300 IN A 104.16.110.208
digitalocean.com. 300 IN A 104.16.112.208
digitalocean.com. 300 IN A 104.16.109.208
digitalocean.com. 300 IN A 104.16.113.208
digitalocean.com. 300 IN A 104.16.111.208
With HTTP it works:
HTTPoison.get("http://104.16.110.208/", [{"host","www.digitalocean.com"}])
{:ok,
%HTTPoison.Response{body: "", headers: [...], request_url: "http://104.16.110.208/",
status_code: 301}}
But with HTTPS I get an error:
HTTPoison.get("https://104.16.110.208/", [{"host", "www.digitalocean.com"}])
{:error,
%HTTPoison.Error{id: nil,
reason: {:options, {{:server_name_indication, '104.16.110.208'}}}}}
Is there a way to achieve this with HTTPS with HTTPoison, or in Elixir/Erlang without modifying etc/hosts?
You need to use it like below
HTTPoison.get("https://104.16.110.208/", [{"host","www.digitalocean.com"}], hackney: [{:ssl_options, [{:server_name_indication, "digitalocean.com"}]}])
or
HTTPoison.get("https://104.16.110.208/", [{"host","www.digitalocean.com"}], hackney: [ssl_options: [server_name_indication: 'digitalocean.com']])
Since you are using IP to connect, by default the server_name_indication will be assumed as the IP. This is what you need to override in your case
Related
I am new in SOLR 8.11.2 and trying to enable SSL and authentication but when I follow the manual all start working but communication between nodes and shard is still in HTTP.
https://127.0.0.1:8981/solr/admin/collections?action=CLUSTERSTATUS&indent=on
{ "responseHeader":{ "status":0, "QTime":4}, "cluster":{ "collections":{ ".system":{ "pullReplicas":"0", "replicationFactor":"2", "shards":{"shard1":{ "range":"80000000-7fffffff", "state":"active", "replicas":{ "core_node3":{ "core":".system_shard1_replica_n1", "base_url":"http://solr3:8984/solr", "node_name":"solr3:8984_solr", "state":"active", "type":"NRT", "force_set_state":"false", "leader":"true"}, "core_node4":{ "core":".system_shard1_replica_n2", "base_url":"http://solr1:8984/solr", "node_name":"solr1:8984_solr", "state":"active", "type":"NRT", "force_set_state":"false"}}}}, "router":{"name":"compositeId"}, "maxShardsPerNode":"1", "autoAddReplicas":"false", "nrtReplicas":"2", "tlogReplicas":"0", "znodeVersion":6, "configName":".system"}}, "properties":{"urlScheme":"https"}, "live_nodes":["solr2:8984_solr", "solr1:8984_solr", "solr3:8984_solr"]}}
my environment settings:
SOLR_SSL_ENABLED: 'true'
SOLR_SSL_KEY_STORE: /etc/solr-ssl.keystore.jks
SOLR_SSL_KEY_STORE_PASSWORD: $SOLR_SECRET
SOLR_SSL_TRUST_STORE: /etc/solr-ssl.keystore.jks
SOLR_SSL_TRUST_STORE_PASSWORD: $SOLR_SECRET # Require clients to authenticate
SOLR_SSL_NEED_CLIENT_AUTH: 'false' # Enable clients to authenticate (but not require)
SOLR_SSL_WANT_CLIENT_AUTH: 'false' # Define Key Store type if necessary
SOLR_SSL_KEY_STORE_TYPE: JKS
SOLR_SSL_TRUST_STORE_TYPE: JKS SOLR_SSL_CHECK_PEER_NAME: 'false'
Do i miss anything?
I have a service named alpha (created using python-django) that runs on http://127.0.0.1:9000 and has these two endpoings
/health returns {"health": "OK"} status 200
/codes/<str:code> returns {"code": code} status 200
I also have a kong api-gateway in the db-less declarative mode that runs on localhost port 80
in kong.yaml I have two services
services:
- name: local-alpha-health
url: http://host.docker.internal:9000/health
routes:
- name: local-alpha-health
methods:
- GET
paths:
- /alpha/health
strip_path: true
- name: local-alpha-code
url: http://host.docker.internal:9000/code/ # HOW TO WRITE THIS PART???
routes:
- name: local-alpha-code
methods:
- GET
paths:
- /alpha/code/(?<appcode>\d+) # Is this right???
strip_path: true
If I send a GET request to http://127.0.0.1/alpha/health it returns {"health": "OK"} status 200 which shows kong is working.
I want to send a request such as http://127.0.0.1/alpha/code/123 and I expect to receive {"code": 123} status 200 but I don't know how to setup kong.yaml file to do this. If I send a request to http://127.0.0.1/alpha/code/123 I get 404 from (from the alpha django application) which means kong is routing the request to alpha service but if I send a request to http://127.0.0.1/alpha/code/abc I get {"message": "no Route matched with those values"} which shows the regex is working
I could do this
services:
- name: local-alpha-health
url: http://host.docker.internal:9000/
routes:
- name: local-alpha-health
methods:
- GET
paths:
- /alpha
strip_path: true
Then a request sent to http://127.0.0.1/alpha/code/123 would go to ``http://127.0.0.1:9000/code/123` but I cannot control with regex
Any idea How to route requests to a dynamic endpoint on kong api-gateway?
This content seems related but cannot figure it out how to set it up
https://docs.konghq.com/gateway-oss/2.5.x/proxy/
Note that a request like http://127.0.0.1/alpha/code/abc will indeed not match the rule you have added, because of the \d+ (which matches one or more digits). Also, http://127.0.0.1/alpha/code/123 will reach the upstream as a request to /, since you have strip_path set to true.
I have tested your example with some minor tweaks to proxy to a local httpbin service, which has a similar endpoint (/status/<code>).
Start a local httpbin service:
$ docker run --rm -d -p "8080:80" kennethreitz/httpbin
Start Kong with the following config:
_format_version: "2.1"
services:
- name: local-alpha-code
url: http://localhost:8080
routes:
- name: local-mockbin-status
methods:
- GET
paths:
- /status/(?<appcode>\d+)
strip_path: false
Note that strip_path is set to false, so the entire matching path is proxied to the upstream.
Test it out with:
$ http :8000/status/200
HTTP/1.1 200 OK
I have installed Elastisearch 2.1.0 and kibana 4.3.0 in single machine.
Kibana.yml Configurations :
# Kibana is served by a back end server. This controls which port to use.
server.port: 5601
# The host to bind the server to.
server.host: "IP"
# A value to use as a XSRF token. This token is sent back to the server on each request
# and required if you want to execute requests from other clients (like curl).
# server.xsrf.token: ""
# If you are running kibana behind a proxy, and want to mount it at a path,
# specify that path here. The basePath can't end in a slash.
# server.basePath: ""
# The Elasticsearch instance to use for all your queries.
elasticsearch.url: "http://IP:9200/"
# preserve_elasticsearch_host true will send the hostname specified in `elasticsearch`. If you set it to false,
# then the host you use to connect to *this* Kibana instance will be sent.
elasticsearch.preserveHost: true
# Kibana uses an index in Elasticsearch to store saved searches, visualizations
# and dashboards. It will create a new index if it doesn't already exist.
kibana.index: ".kibana"
# The default application to load.
kibana.defaultAppId: "discover"
# If your Elasticsearch is protected with basic auth, these are the user credentials
# used by the Kibana server to perform maintenance on the kibana_index at startup. Your Kibana
# users will still need to authenticate with Elasticsearch (which is proxied through
# the Kibana server)
# elasticsearch.username: "user"
# elasticsearch.password: "pass"
# SSL for outgoing requests from the Kibana Server to the browser (PEM formatted)
# server.ssl.cert: /path/to/your/server.crt
# server.ssl.key: /path/to/your/server.key
# Optional setting to validate that your Elasticsearch backend uses the same key files (PEM formatted)
# elasticsearch.ssl.cert: /path/to/your/client.crt
# elasticsearch.ssl.key: /path/to/your/client.key
# If you need to provide a CA certificate for your Elasticsearch instance, put
# the path of the pem file here.
# elasticsearch.ssl.ca: /path/to/your/CA.pem
# Set to false to have a complete disregard for the validity of the SSL
# certificate.
elasticsearch.ssl.verify: true
# Time in milliseconds to wait for elasticsearch to respond to pings, defaults to
# request_timeout setting
# elasticsearch.pingTimeout: 1500
# Time in milliseconds to wait for responses from the back end or elasticsearch.
# This must be > 0
# elasticsearch.requestTimeout: 300000
# Time in milliseconds for Elasticsearch to wait for responses from shards.
# Set to 0 to disable.
# elasticsearch.shardTimeout: 0
# Time in milliseconds to wait for Elasticsearch at Kibana startup before retrying
# elasticsearch.startupTimeout: 5000
# Set the path to where you would like the process id file to be created.
pid.file: /var/run/kibana.pid
# If you would like to send the log output to a file you can set the path below.
logging.dest: /var/log/kibana/kibana.log
# Set this to true to suppress all logging output.
# logging.silent: false
# Set this to true to suppress all logging output except for error messages.
# logging.quiet: true
# Set this to true to log all events, including system usage information and all requests.
# logging.verbose: true
While I am doing curl -IP:5601 , I am getting this output:
**HTTP/1.1 200 OK
x-app-name: kibana
x-app-version: 4.3.0
cache-control: no-cache
content-type: text/html
content-length: 217
accept-ranges: bytes
Date: Wed, 20 Jan 2016 15:28:35 GMT
Connection: keep-alive
<script>var hashRoute = '/app/kibana';
var defaultRoute = '/app/kibana';
var hash = window.location.hash;
if (hash.length) {
window.location = hashRoute + hash;
} else {
window.location = defaultRoute;
</script>
Elasticsearch and kibana both are up and running still I am not able to access Kibana GUI from the browser. It is not displaying the page.
I checked the configurations of elasticsearch.yml too.The host and IP is correct there. Curl command is giving this output for elasticsearch [Command :curl http://IP:9200/]
{
"name" : "node-1",
"cluster_name" : "elasticsearch",
"version" : {
"number" : "2.1.0",
"build_hash" : "72cd1f1a3eee09505e036106146dc1949dc5dc87",
"build_timestamp" : "2015-11-18T22:40:03Z",
"build_snapshot" : false,
"lucene_version" : "5.3.1"
},
"tagline" : "You Know, for Search"
}
Could anybody tell what could be the issue.
Did you install elasticsearch and kibana on your local machine, I mean your laptop or computer that you are workng on? Or is it running on a separate server?
If you are running it on the same machine that you are accessing the browser, then you could just access it as localhost:port
As your error includes the status
Elasticsearch is still initializing the kibana index, I would recommend you to try the steps mentioned in this page:-
Elasticsearch is still initializing the kibana index
I am trying to connect a Google Docs extension to a MySQL database via JDBC Service. The MySQL database is running on a shared server that requires using CPanel. CPanel only lets me add one whitelist rule at a time, and I can only use the % wildcard character (which matches to 0 or more of any type of character). I wrote a script to generate rules in this format from the IP address ranges, but there are more than 300 of them. I'm trying to find an easier way to do this.
Is there a domain name for the Google JDBC Service that I can whitelist instead of the IP address ranges? Does CPanel have a more efficient whitelisting mechanism that I'm not aware of? Is there a program that could automate filling out CPanel's webform with my whitelist?
Here is the CPanel-formatted whitelist I generated, in case someone with the same problem finds my question.
64.18.0.%
64.18.1.%
64.18.2.%
64.18.3.%
64.18.4.%
64.18.5.%
64.18.6.%
64.18.7.%
64.18.8.%
64.18.9.%
64.18.10.%
64.18.11.%
64.18.12.%
64.18.13.%
64.18.14.%
64.233.160.%
64.233.161.%
64.233.162.%
64.233.163.%
64.233.164.%
64.233.165.%
64.233.166.%
64.233.167.%
64.233.168.%
64.233.169.%
64.233.170.%
64.233.171.%
64.233.172.%
64.233.173.%
64.233.174.%
64.233.175.%
64.233.176.%
64.233.177.%
64.233.178.%
64.233.179.%
64.233.180.%
64.233.181.%
64.233.182.%
64.233.183.%
64.233.184.%
64.233.185.%
64.233.186.%
64.233.187.%
64.233.188.%
64.233.189.%
64.233.190.%
66.102.0.%
66.102.1.%
66.102.2.%
66.102.3.%
66.102.4.%
66.102.5.%
66.102.6.%
66.102.7.%
66.102.8.%
66.102.9.%
66.102.10.%
66.102.11.%
66.102.12.%
66.102.13.%
66.102.14.%
66.249.80.%
66.249.81.%
66.249.82.%
66.249.83.%
66.249.84.%
66.249.85.%
66.249.86.%
66.249.87.%
66.249.88.%
66.249.89.%
66.249.90.%
66.249.91.%
66.249.92.%
66.249.93.%
66.249.94.%
72.14.192.%
72.14.193.%
72.14.194.%
72.14.195.%
72.14.196.%
72.14.197.%
72.14.198.%
72.14.199.%
72.14.200.%
72.14.201.%
72.14.202.%
72.14.203.%
72.14.204.%
72.14.205.%
72.14.206.%
72.14.207.%
72.14.208.%
72.14.209.%
72.14.210.%
72.14.211.%
72.14.212.%
72.14.213.%
72.14.214.%
72.14.215.%
72.14.216.%
72.14.217.%
72.14.218.%
72.14.219.%
72.14.220.%
72.14.221.%
72.14.222.%
72.14.223.%
72.14.224.%
72.14.225.%
72.14.226.%
72.14.227.%
72.14.228.%
72.14.229.%
72.14.230.%
72.14.231.%
72.14.232.%
72.14.233.%
72.14.234.%
72.14.235.%
72.14.236.%
72.14.237.%
72.14.238.%
72.14.239.%
72.14.240.%
72.14.241.%
72.14.242.%
72.14.243.%
72.14.244.%
72.14.245.%
72.14.246.%
72.14.247.%
72.14.248.%
72.14.249.%
72.14.250.%
72.14.251.%
72.14.252.%
72.14.253.%
72.14.254.%
74.125.%
173.194.%
207.126.144.%
207.126.145.%
207.126.146.%
207.126.147.%
207.126.148.%
207.126.149.%
207.126.150.%
207.126.151.%
207.126.152.%
207.126.153.%
207.126.154.%
207.126.155.%
207.126.156.%
207.126.157.%
207.126.158.%
209.85.128.%
209.85.129.%
209.85.130.%
209.85.131.%
209.85.132.%
209.85.133.%
209.85.134.%
209.85.135.%
209.85.136.%
209.85.137.%
209.85.138.%
209.85.139.%
209.85.140.%
209.85.141.%
209.85.142.%
209.85.143.%
209.85.144.%
209.85.145.%
209.85.146.%
209.85.147.%
209.85.148.%
209.85.149.%
209.85.150.%
209.85.151.%
209.85.152.%
209.85.153.%
209.85.154.%
209.85.155.%
209.85.156.%
209.85.157.%
209.85.158.%
209.85.159.%
209.85.160.%
209.85.161.%
209.85.162.%
209.85.163.%
209.85.164.%
209.85.165.%
209.85.166.%
209.85.167.%
209.85.168.%
209.85.169.%
209.85.170.%
209.85.171.%
209.85.172.%
209.85.173.%
209.85.174.%
209.85.175.%
209.85.176.%
209.85.177.%
209.85.178.%
209.85.179.%
209.85.180.%
209.85.181.%
209.85.182.%
209.85.183.%
209.85.184.%
209.85.185.%
209.85.186.%
209.85.187.%
209.85.188.%
209.85.189.%
209.85.190.%
209.85.191.%
209.85.192.%
209.85.193.%
209.85.194.%
209.85.195.%
209.85.196.%
209.85.197.%
209.85.198.%
209.85.199.%
209.85.200.%
209.85.201.%
209.85.202.%
209.85.203.%
209.85.204.%
209.85.205.%
209.85.206.%
209.85.207.%
209.85.208.%
209.85.209.%
209.85.210.%
209.85.211.%
209.85.212.%
209.85.213.%
209.85.214.%
209.85.215.%
209.85.216.%
209.85.217.%
209.85.218.%
209.85.219.%
209.85.220.%
209.85.221.%
209.85.222.%
209.85.223.%
209.85.224.%
209.85.225.%
209.85.226.%
209.85.227.%
209.85.228.%
209.85.229.%
209.85.230.%
209.85.231.%
209.85.232.%
209.85.233.%
209.85.234.%
209.85.235.%
209.85.236.%
209.85.237.%
209.85.238.%
209.85.239.%
209.85.240.%
209.85.241.%
209.85.242.%
209.85.243.%
209.85.244.%
209.85.245.%
209.85.246.%
209.85.247.%
209.85.248.%
209.85.249.%
209.85.250.%
209.85.251.%
209.85.252.%
209.85.253.%
209.85.254.%
216.239.32.%
216.239.33.%
216.239.34.%
216.239.35.%
216.239.36.%
216.239.37.%
216.239.38.%
216.239.39.%
216.239.40.%
216.239.41.%
216.239.42.%
216.239.43.%
216.239.44.%
216.239.45.%
216.239.46.%
216.239.47.%
216.239.48.%
216.239.49.%
216.239.50.%
216.239.51.%
216.239.52.%
216.239.53.%
216.239.54.%
216.239.55.%
216.239.56.%
216.239.57.%
216.239.58.%
216.239.59.%
216.239.60.%
216.239.61.%
216.239.62.%
Oday,
Your suggestion won't work as the IP ranges aren't all inclusive. Here is the list that Google says to whitelist.
As an example...how do I white list 64.18.0.x to 64.18.15.x
I should have looked harder in stackoverflow. For others that stumble upon this post, here is the answer that I found at
Whitelist IP addresses ranges using cPanel
64.18.0-15.%
64.233.160-191.%
64.102.0-15.%
66.249.80-95.%
72.14.192-255.%
74.125.%
173.194.%
207.126.144-159.%
209.85.128-255.%
216.239.32-63.%
This is long overdue, but the easiest solution is to use the % wildcard like this to make it easier:
64.18.%.%
64.233.%.%
66.102.%.%
...etc
When I use nslookup for "google.com" I get the following:
Addresses: 2607:f8b0:400a:801::1001
173.194.33.32
173.194.33.36
173.194.33.34
173.194.33.37
173.194.33.33
173.194.33.46
173.194.33.39
173.194.33.41
173.194.33.38
173.194.33.40
173.194.33.35
However when I call GetAddrInfoW and pass it L"google.com" I get the following:
173.194.33.41
173.194.33.39
173.194.33.46
173.194.33.33
173.194.33.37
173.194.33.38
173.194.33.40
173.194.33.34
173.194.33.35
173.194.33.36
173.194.33.32
Where'd the IPv6 address go?
Edit: If I do the same lookup with the same code for "localhost" the output is:
0000:0000:0000:0000:0000:0000:0000:0001
127.0.0.1
Which is even more of a head scratcher.