Searchguard could not be Initialized with error: Root cause: MasterNotDiscoveredException[null] - elasticsearch

I use k8s to deploy Elasticsearch.
Dockerfile:
FROM docker.elastic.co/elasticsearch/elasticsearch:6.3.1
USER elasticsearch
RUN elasticsearch-plugin install --batch analysis-kuromoji
RUN elasticsearch-plugin install --batch org.codelibs:elasticsearch-analysis-kuromoji-neologd:6.3.1
RUN elasticsearch-plugin install --batch com.floragunn:search-guard-6:6.3.1-22.3
RUN mkdir -p /usr/share/elasticsearch/batch/scripts
RUN mkdir -p /usr/share/elasticsearch/batch/logs
COPY searchguard_not_initialized_check_batch.sh /usr/share/elasticsearch/batch/scripts/
RUN rm -f /usr/share/elasticsearch/config/elasticsearch.yml && rm -f /usr/share/elasticsearch/plugins/search-guard-6/sgconfig/* && mkdir -p /usr/share/elasticsearch/data
File searchguard_not_initialized_check_batch.sh to run
sh /usr/share/elasticsearch/plugins/search-guard-6/tools/sgadmin.sh -diagnose -cd /usr/share/elasticsearch/plugins/search-guard-6/sgconfig -cn pnt-es.stg -key /usr/share/elasticsearch/config/cert/kirk-key.pem -cert /usr/share/elasticsearch/config/cert/kirk.pem -cacert /usr/share/elasticsearch/config/cert/root-ca.pem -nhnv
Elasticsearch.yml:
cluster.name: "pnt-es.stg"
discovery.zen.ping.unicast.hosts: elasticsearch-service
discovery.zen.minimum_master_nodes: {{ elasticsearch_log_minimum_master_nodes }}
network.host: ['_site_', '_local_']
node.name: ${HOSTNAME}
http.port: 9200
transport.tcp.port: 9300
path.data: /usr/share/elasticsearch/data
path.logs: /var/log/elasticsearch
searchguard.ssl.transport.pemcert_filepath: cert/esnode.pem
searchguard.ssl.transport.pemkey_filepath: cert/esnode-key.pem
searchguard.ssl.transport.pemtrustedcas_filepath: cert/root-ca.pem
searchguard.ssl.transport.enforce_hostname_verification: false
searchguard.ssl.http.enabled: true
searchguard.ssl.http.pemcert_filepath: cert/esnode.pem
searchguard.ssl.http.pemkey_filepath: cert/esnode-key.pem
searchguard.ssl.http.pemtrustedcas_filepath: cert/root-ca.pem
searchguard.allow_unsafe_democertificates: true
searchguard.allow_default_init_sgindex: true
searchguard.enterprise_modules_enabled: false
searchguard.authcz.admin_dn:
- CN=kirk,OU=client,O=client,L=test,C=de
xpack.security.enabled: false
Error as below:
How can I fix it?
enter image description here

When I run this command, Error as below.
[elasticsearch#elasticsearch-daemonset-4qwcj ~]$ sh /usr/share/elasticsearch/plugins/search-guard-6/tools/sgadmin.sh --diagnos -cd /usr/share/elasticsearch/plugins/search-guard-6/sgconfig -cn pnt-es.stg -key /usr/share/elasticsearch/config/cert/kirk-key.pem -cert /usr/share/elasticsearch/config/cert/kirk.pem -cacert /usr/share/elasticsearch/config/cert/root-ca.pem -nhnv
Search Guard Admin v6
Will connect to localhost:9300 ... done
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by io.netty.util.internal.ReflectionUtil (file:/usr/share/elasticsearch/plugins/search-guard-6/netty-common-4.1.16.Final.jar) to constructor java.nio.DirectByteBuffer(long,int)
WARNING: Please consider reporting this to the maintainers of io.netty.util.internal.ReflectionUtil
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Elasticsearch Version: 6.3.1
Search Guard Version: 6.3.1-22.3
Connected as CN=kirk,OU=client,O=client,L=test,C=de
Diagnostic trace written to: /usr/share/elasticsearch/sgadmin_diag_trace_2019-Oct-03_05-35-51.txt
Contacting elasticsearch cluster 'pnt-es.stg' and wait for YELLOW clusterstate ...
vi /usr/share/elasticsearch/sgadmin_diag_trace_2019-Oct-03_05-35-51.Cannot retrieve cluster state due to: null. This is not an error, will keep on trying ...
Root cause: MasterNotDiscoveredException[null] (org.elasticsearch.discovery.MasterNotDiscoveredException/org.elasticsearch.discovery.MasterNotDiscoveredException)
* Try running sgadmin.sh with -icl (but no -cl) and -nhnv (If that works you need to check your clustername as well as hostnames in your TLS certificates)
* Make sure that your keystore or PEM certificate is a client certificate (not a node certificate) and configured properly in elasticsearch.yml
* If this is not working, try running sgadmin.sh with --diagnose and see diagnose trace log file)
* Add --accept-red-cluster to allow sgadmin to operate on a red cluster.
Cannot retrieve cluster state due to: null. This is not an error, will keep on trying ...
Root cause: MasterNotDiscoveredException[null] (org.elasticsearch.discovery.MasterNotDiscoveredException/org.elasticsearch.discovery.MasterNotDiscoveredException)
* Try running sgadmin.sh with -icl (but no -cl) and -nhnv (If that works you need to check your clustername as well as hostnames in your TLS certificates)
* Make sure that your keystore or PEM certificate is a client certificate (not a node certificate) and configured properly in elasticsearch.yml
* If this is not working, try running sgadmin.sh with --diagnose and see diagnose trace log file)
* Add --accept-red-cluster to allow sgadmin to operate on a red cluster.
Cannot retrieve cluster state due to: null. This is not an error, will keep on trying ...
Root cause: MasterNotDiscoveredException[null] (org.elasticsearch.discovery.MasterNotDiscoveredException/org.elasticsearch.discovery.MasterNotDiscoveredException)
* Try running sgadmin.sh with -icl (but no -cl) and -nhnv (If that works you need to check your clustername as well as hostnames in your TLS certificates)
* Make sure that your keystore or PEM certificate is a client certificate (not a node certificate) and configured properly in elasticsearch.yml
* If this is not working, try running sgadmin.sh with --diagnose and see diagnose trace log file)
* Add --accept-red-cluster to allow sgadmin to operate on a red cluster.

Related

Kibana startup fails with License information and later with Unable to retrieve version information

I'm tried to follow this guideline for installing ELK on Centos 8 (on top of one AWS cluster).
After installing elastic and kibana, the kibana startup failed with:
*"message":"License information could not be obtained from Elasticsearch
I googled it, and realized I should use OSS version (latest is 7.10.2)
so make sure to install only OSS version. you can use this guideline
after that, I got new error from kibana.log
-08T07:19:32Z","tags":["error","savedobjects-service"],"pid":62767,"message":"Unable to retrieve version information from Elasticsearch nodes."}
I tried to google it, but no solution worked for me.
my kibana.yaml:
server.port: 5601
server.host: "0.0.0.0"
elasticsearch.hosts: "[my public AWS instance ip:9200]"
my elasticsearch.yaml:
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
network.host: 0.0.0.0
http.port: 9200
discovery.seed_hosts: "[my private AWS instance ip]"
cluster.initial_master_nodes: "[my private AWS instance ip]"
Update:
If I'm changing this line in kibana.yaml file to:
elasticsearch.hosts: "http://localhost:9200"
Then it works. what is the root cause? why it can't access elastic public IP but only local?
Per #leandrojmp comment, the issue was indeed with the public IP in elasticsearch.hosts. Once I replaced it to my private ip, it works
also:
When installing the Elastic Stack, you must use the same version across the entire stack. For example, if you are using Elasticsearch 7.9.3, you install Beats 7.9.3, APM Server 7.9.3, Elasticsearch Hadoop 7.9.3, Kibana 7.9.3, and Logstash 7.9.3.
Using docker, I had to specify the elasticsearch.hosts as an environment variable: -e "ELASTICSEARCH_HOSTS=http://localhost:9200", so:
docker run -p 5601:5601 -e "ELASTICSEARCH_HOSTS=http://localhost:9200" arm64v8/kibana:7.16.3
Set elasticsearch.hosts ipaddress as local system's host ipaddress in kibana.yml file. Also you need to mount local kibana.yml file while running docker container.
docker run -d --name kibana -p 5601:5601 -v /home/users/mySystemUserName/config/kibana.yml:/opt/kibana/config/kibana.yml kibana:7.16.3
Add the below configs in
kibana.yml
server.name: kibana
server.port: 5601
server.host: "0.0.0.0"
elasticsearch.hosts: [ "http://192.168.0.102:9200" ]

Can't start ElasticSearch on Mac

I installed elasticsearch by brew install elasticsearch and started it with brew services start elasticsearch, however, curl http://127.0.0.1:9200 shows connection refused. I checked the port: netstat -a -n | grep tcp | grep 9200 and some ipv4 is running there. Ok, so I opened /usr/local/etc/elasticsearch/elasticsearch.yml and changed the port to 9300 and also uncommented and changed: network.host: 127.0.0.1. Still shows connection refused when I do curl http://127.0.0.1:9300. The OS is MacOS High Sierra 10.13.4. If we open /usr/local/var/log/elasticsearch/elasticsearch_nikitavlasenko.log the error seems to be:
Cluster name [elasticsearch_nikitavlasenko] subdirectory exists in data paths [/usr/local/var/lib/elasticsearch/elasticsearch_nikitavlasenko]. All data under these paths must be moved up one directory to paths [/usr/local/var/lib/elasticsearch]
Did you have an older version (2.x or before) installed before? It sounds a lot like this PR to check that you're not using the old behavior when there was the node name in the path.
What I would do:
If you don't need the data any more, just remove /usr/local/var/lib/elasticsearch/elasticsearch_nikitavlasenko and start fresh.
If you need the data, you could either change path.data in your config or move the folder one level up (just like the log message says).
PS: I wouldn't use port 9300 for HTTP, because that's generally the port used for communication of the nodes in a cluster itself.
This was the result of a bug in the Homebrew formula for Elasticsearch. It was creating a directory with the node name which is no longer allowed for Elasticsearch.
The formula has been updated to remove node name from path.data and no longer create the invalid directory which should resolve this problem.
Ran into this issue some time back, Please add a minimal Elastic config file. for me it looks like below
http.port: 9200
discovery.zen.ping.unicast.hosts: ["127.0.0.1"]
path.data: /usr/local/var/elasticsearch/
path.logs: /usr/local/var/log/elasticsearch/
# Set both 'bind_host' and 'publish_host':
network.host: 127.0.0.1
# 1. Disable multicast discovery (enabled by default):
discovery.zen.ping.multicast.enabled: false
script.engine.groovy.inline.aggs: on
I think I wasn't having below config which caused the issue:
network.host: 127.0.0.1
Please check if its there in your config? Also properly set your data and logs folder path.
Let me know if you face any issue and have questions on these configs.

curl: (7) Failed to connect to localhost port 9200: Connection refused. Even after having configured /etc/elasticsearch/elasticsearch.yml

I am trying to check if elasticsearch is properly working on Ubuntu 14.04. So for that, I am running following commands:
$ sudo service elasticsearch start
$ curl -X GET 'http://localhost:9200'
Error:
curl: (7) Failed to connect to localhost port 9200: Connection refused
I am attaching screenshot of my /etc/elasticsearch/elasticsearch.yml file here and also attaching my-application.log
The problem is pretty evident from the log file
org.elasticsearch.ElasticsearchException: X-Pack is not supported and Machine Learning is not available for [linux-x86]; you can use the other X-Pack features (unsupported) by setting xpack.ml.enabled: false in elasticsearch.yml
Simply add this to your elasticsearch.yml config file and restart the service
xpack.ml.enabled: false

sgadmin.sh failed elasticsearch && searchguard

While trying to exucte
./sgadmin.sh -ts truststore.jks -tspass 90f3cbdb3eabe04f815b -ks CN=sgadmin-keystore.jks -kspass a65d2a4fa62d7ed7a4d5 -h host -p 9200 -nhnv -cn eslcl1 -cd ../sgconfig/
I am getting the following error:
Cannot retrieve cluster state due to: None of the configured nodes are available: [{#transport#-1}{6PPXnCNqTt-W5g-0fmeZuQ}{host}{host:9200}]. This is not an error, will keep on trying
error:
WARNING: JAVA_HOME not set, will use /usr/bin/java
Search Guard Admin v5
WARNING: Seems you want connect to the a HTTP port.
sgadmin connect through the transport port which is normally 9300.
Will connect to host:9200 ... done
### LICENSE NOTICE Search Guard ###
If you use one or more of the following features in production
make sure you have a valid Search Guard license
(See https://floragunn.com/searchguard-validate-license)
* Kibana Multitenancy
* LDAP authentication/authorization
* Active Directory authentication/authorization
* REST Management API
* JSON Web Token (JWT) authentication/authorization
* Kerberos authentication/authorization
* Document- and Fieldlevel Security (DLS/FLS)
* Auditlogging
In case of any doubt mail to <sales#floragunn.com>
###################################
Contacting elasticsearch cluster 'eslcl1' and wait for YELLOW clusterstate ...
Cannot retrieve cluster state due to: None of the configured nodes are available: [{#transport#-1}{6PPXnCNqTt-W5g-0fmeZuQ}{host}{host:9200}]. This is not an error, will keep on trying ...
Root cause: NoNodeAvailableException[None of the configured nodes are available: [{#transport#-1}{6PPXnCNqTt-W5g-0fmeZuQ}{host}{host:9200}]] (org.elasticsearch.client.transport.NoNodeAvailableException/org.elasticsearch.client.transport.NoNodeAvailableException)
* Try running sgadmin.sh with -icl (but no -cl) and -nhnv (If thats works you need to check your clustername as well as hostnames in your SSL certificates)
* Make also sure that your keystore or cert is a client certificate (not a node certificate) and configured properly in elasticsearch.yml
* If this is not working, try running sgadmin.sh with --diagnose and see diagnose trace log file)
* Add --accept-red-cluster to allow sgadmin to operate on a red cluster.
My conf in elasticsearch.yml is
######## Start Search Guard Demo Configuration ########
searchguard.ssl.transport.keystore_filepath: CN=x.x.x.x-keystore.jks
searchguard.ssl.transport.keystore_password: 8a17368ff585a2c3afdc
searchguard.ssl.transport.truststore_filepath: truststore.jks
searchguard.ssl.transport.truststore_password: 90f3cbdb3eabe04f815b
searchguard.ssl.transport.enforce_hostname_verification: false
searchguard.ssl.http.enabled: false
searchguard.ssl.http.keystore_filepath: CN=x.x.x.x-keystore.jks
searchguard.ssl.http.keystore_password: 8a17368ff585a2c3afdc
searchguard.ssl.http.truststore_filepath: truststore.jks
searchguard.ssl.http.truststore_password: 90f3cbdb3eabe04f815b
searchguard.authcz.admin_dn:
- CN=sgadmin
cluster.name: eslcl1
network.host: x.x.x.x
Is there any configuration that I might need to look into ?
You need to connect to port 9300 (the transport protocol), not 9200 which is typically the HTTP/S port. On port 9300 the elasticsearch nodes talk to each other through a binary TCP protocol. On port 9200 the REST api is accessible via HTTP/S.
sgadmin connect through the binary TCP protocol to elasticsearch, so you need to use port 9300.
Therefore you get this warning
WARNING: Seems you want connect to the a HTTP port.
sgadmin connect through the transport port which is normally 9300.
So your command should look like
./sgadmin.sh -ts truststore.jks -tspass 90f3cbdb3eabe04f815b -ks CN=sgadmin-keystore.jks -kspass a65d2a4fa62d7ed7a4d5 -h host -p 9300 -nhnv -cn eslcl1 -cd ../sgconfig/ -nhnv
(Add -nhnv to disable hostname verification if your certificates are not matching your hostnames)

Elasticsearch: Failed to connect to localhost port 9200 - Connection refused

When I tried connecting to Elasticsearch using the
curl http://localhost:9200 it is working fine.
But when I run the curl http://IpAddress:9200 it is throwing an error saying
Failed to connect to localhost port 9200: Connection refused
How to resolve this error?
Edit /etc/elasticsearch/elasticsearch.yml and add the following line:
network.host: 0.0.0.0
This will "unset" this parameter and will allow connections from other IPs.
By default it should bind to all local addresses. So, assuming you don't have a network layer issue with firewalls, the only ES setting I can think to check is network.bind_host and make sure it is either not set or is set to 0.0.0.0 or ::0 or to the correct IP address for your network.
Update: per comments in ES 2.3 you should set network.host instead.
In my case elasticsearch was started.
But still had
curl: (7) Failed to connect to localhost port 9200: Connection refused
The following command was unsuccessful
sudo service elasticsearch restart
In order to make it work, I had to run instead
sudo systemctl restart elasticsearch
Then it went all fine.
Tried everything on this page, and only instructions from here helped.
in /etc/default/elasticsearch, make sure these are un-commented:
START_DAEMON=true
ES_USER=elasticsearch
ES_GROUP=elasticsearch
LOG_DIR=/var/log/elasticsearch
DATA_DIR=/var/lib/elasticsearch
WORK_DIR=/tmp/elasticsearch
CONF_DIR=/etc/elasticsearch
CONF_FILE=/etc/elasticsearch/elasticsearch.yml
RESTART_ON_UPGRADE=true
make sure /var/lib/elasticsearch is owned by elasticsearch user:
chown -R elasticsearch:elasticsearch /var/lib/elasticsearch/
Why don't you start with this command-line:
$ sudo service elasticsearch status
I did it and get:
"There is insufficient memory for the Java Runtime..."
Then I edited /etc/elasticsearch/jvm.options file:
...
################################################################
# Xms represents the initial size of total heap space
# Xmx represents the maximum size of total heap space
#-Xms2g
#-Xms2g
-Xms512m
-Xmx512m
################################################################
...
This worked like a charm.
None of the proposed solutions here worked for me, but what eventually got it working was adding the following to elasticsearch.yml
network:
host: 0.0.0.0
http:
port: 9200
After that, I restarted the service and now I can curl it from both within the VM and externally. For some odd reason, I had to try a few different variants of a curl call inside the VM before it worked:
curl localhost:9200
curl http://localhost:9200
curl 127.0.0.1:9200
Note: I'm using Elasticsearch 5.5 on Ubuntu 14.04
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000085330000, 2060255232, 0) failed; error='Cannot allocate memory' (errno=12)
be sure that the server is started. I've seen this problem when my virtual machine had too litle RAM and es could not start.
sudo systemctl status elasticsearch
the above will show you if es is indeed running.
Edit elasticsearch.yml and add the following line
http.host: 0.0.0.0
network.host: 0.0.0.0 didn't work for
For this problem, I had to use :
sudo /usr/share/elasticsearch/bin/elasticsearch start
to be able to get something on ports 9200/9300 (sudo netstat -ntlp) and a response to:
curl -XGET http://localhost:9200
I experienced a similar issue.
Here's how I solved it
Run the service command below to start ElasticSearch
sudo service elasticsearch start
OR
sudo systemctl start elasticsearch
If you still get the error
curl: (7) Failed to connect to localhost port 9200: Connection refused
Run the service command below to check the status of ElasticSearch
sudo service elasticsearch status
OR
sudo systemctl status elasticsearch
If you get a response (Active: active (running)) like the one below then you ElasticSearch is active and running
● elasticsearch.service - Elasticsearch
Loaded: loaded (/usr/lib/systemd/system/elasticsearch.service; disabled; vendor preset: enabled)
Active: active (running) since Sat 2019-09-21 11:22:21 WAT; 3s ago
You can then test that your Elasticsearch node is running by sending an HTTP request to port 9200 on localhost using the command below:
curl http://localhost:9200
Else, if you get a response a different response, you may have to debug further to fix it, but the running the command below, will help you detect what caveats are holding ElasticSearch service from starting.
sudo service elasticsearch status
OR
sudo systemctl status elasticsearch
If you want to stop the ElasticSearch service, simply run the service command below;
sudo service elasticsearch stop
OR
sudo systemctl stop elasticsearch
N/B: You may have to run the command sudo service elasticsearch status OR sudo systemctl status elasticsearch each time you encounter the error, in order to tell the state of the ElasticSearch service.
This also applies for Kibana, run the command sudo service kibana status OR sudo systemctl status kibana each time you encounter the error, in order to tell the state of the Kibana service.
That's all.
I hope this helps.
I had the same problem refusing connections on 9200 port.
Check elasticsearch service status with the command sudo service elasticsearch status. If it is presenting an error and you read anything related to Java, probably the problem is your jvm memory. You can edit it in /etc/elasticsearch/jvm.options. For a 1GB RAM memory machine on Amazon environment, I kept my configuration on:
-Xms128m
-Xmx128m
After setting that and restarting elasticsearch service, it worked like a charm. Nmap and UFW (if you use local firewall) checking should also be useful.
Open your Dockerfile under elasticsearch folder and update "network.host=0.0.0.0" with "network.host=127.0.0.1". Then restart the container. Check your connection with curl.
$ curl http://docker-machine-ip:9200
{
"name" : "vI6Zq_D",
"cluster_name" : "elasticsearch",
"cluster_uuid" : "hhyB_Wa4QwSX6zZd1F894Q",
"version" : {
"number" : "5.2.0",
"build_hash" : "24e05b9",
"build_date" : "2017-01-24T19:52:35.800Z",
"build_snapshot" : false,
"lucene_version" : "6.4.0"
},
"tagline" : "You Know, for Search"
}
For versions higher than 6.8 (7.x) you need two things.
1. change the network host to listen on the public interface.
In the configuration file elasticsearch.yml (for debian and derivatives -> /etc/elasticsearch/elasticsearch.yml).
set the network.host or network.bind_host to:
...
network.host: 0.0.0.0
...
Or the interface that must be reached
2. Before going to production it's necessary to set important discovery and cluster formation settings.
According to elastic.co:
v6.8 -> discovery settings that should set.
by e.g
...
# roughly means the same as 1
discovery.zen.minimum_master_nodes: -1
...
v7.x -> discovery settings that should set.
by one single node
discovery.type: single-node
#OR set discovery.seed_hosts : 127.0.0.1:9200
at least one of [discovery.seed_hosts, discovery.seed_providers, cluster.initial_master_nodes] must be configured.
In this case, first of all you need to check the java version using below command:
java -version
after running this command you get something like this:
java version "1.7.0_51"
OpenJDK Runtime Environment (rhel-2.4.5.5.el7-x86_64 u51-b31)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
then use this command:
update-alternatives --config java
and select the below version
*+ 1 /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51-2.4.5.5.el7.x86_64/jre/bin/java
2 /usr/java/jdk1.8.0_73/jre/bin/java
Enter to keep the current selection[+], or type selection number: 2
curl -XGET http://127.0.0.1:9200
My 2 cents,
I just followed the install procedure on Digital Ocean, apparently the package available in the repos is not up to date, I deleted everything and followed the install procedure direct from Elastic Search and everything is working now, basically the out of the box behaviour is on a localhost pointing to 9200. Same thing/issue found with Kibana, the solution for me was too, to remove everything and just follow their procedure, Hope this saves someone two hours (the time I spent figuring out how to setup ELK!)
en
Update your jdk to latest minimum version for your elasticsearch.
Change the network.bind to 0.0.0.0 and http:port to 9200. The bind address 0.0.0.0 means all IPv4 addresses on the local machine. If a host has two IP addresses, 192.168.1.1 and 10.1.2.1, and a server running on the host listens on 0.0.0.0, it will be reachable at both of those IPs.
If you encounter the Connection refused error, simply run the command below to check the status of ElasticSearch service
sudo service elasticsearch status
This will help you decipher the state of ElasticSearch service and what to do about it.
For those of you installing ELK on virtual machine in GCP (Google Cloud Platform), make sure that you created firewall rule of Ingress type (i.e. for incoming to VM traffic). You can specify in the rule multiple ports at a time by separating them with comma: 5000,5044,5601,9200,9300,9600.
In that rule you may want to specify a tag (pick tag's name as you like, for example docker-elk that will target your VM (Targets column):
On VM's settings page assign that tag to your VM:
After doing that I was able to access Elasticsearch in my browser via port 9200. And I didn't have to edit elasticsearch.yml file whatsoever.
I have run across this problem every time I install or upgrade ES (7.0+). And the solution was ALWAYS just wait for ES to fully start. It takes about a minute for the REST API to be reponsive. No matter what service status says.
service elasticsearch start
*started
*wait for at least a minute
curl now works and returns responses on the port 9200
After utilizing some of the answers above, don't forget that after an apt install, a total reboot might be in order.
Just to add on this, I've came across many docs through google that said to set network.host to localhost.
Doing so gave me the infamous connection refused. You must use an IP address (127.0.0.1), not a FQDN.
Jeff
Make sure that port 9200 is open for my case it was an amazon instance so when i opened it in my security group the curl command worked.
Disabling SELinux worked for me, although I don't suggest it - I did that just for a PoC
My problem was I could not work with localhost I needed to set it to localhost's IP address
network.bind_host: 127.0.0.1
In my case, the problem is with java version, i installed open-jdk 11 previously. Thats creating the issue while starting the service. I changed it open-jdk 8 and it started working
I experienced this on CentOS 7, and the issue was that /etc/hosts had the following:
127.0.0.1 localhost.localdomain
which I updated to include localhost as follows:
127.0.0.1 localhost localhost.localdomain
after that, no issues.
you have to edit /etc/elasticsearch/elasticsearch.yml
by default all configurations will be commented ,add following configuration
network.host: 0.0.0.0
http.port: 9200
discovery.seed_hosts: [0.0.0.0]
then restart the service
I ran into a related situation recently.
Here's my take on the subject: Accessing Elastic 5.5 in vagrant guest from host through a private network
TL;DR
The settings:
network.host: 0.0.0.0
http.port: 9200
work fine. One just needs to wait enough time for ES to complete its initialization procedure, bind to the network iface and start listening on the port.
Now, from within the guest, curl http://localhost:9200 works and from the host, curl http://192.168.54.2:9200 works as well.
For Windows user try,
https://localhost:9200/
It worked for me.

Resources