Index settings not found


#1

Hey,

Ive upgraded my ES (to 5.5.1) and ROR (same) plugin - and when starting ES, i get the following error:

[2017-08-14T14:32:57,491][INFO ][o.e.p.r.e.ReloadableSettingsImpl] [CLUSTERWIDE SETTINGS] index settings not found, have you installed ReadonlyREST Kibana plugin? Will keep on using elasticearch.yml. Learn more at https://readonlyrest.com

I cannot find relevant information on the website/documentation - so im a bit lost here :wink: the elasticsearch.yml has been working beautifully with an older version of ES (5.3.2) and ROR (for 5.3.2) - so I cant figure out whats missing or what has been changed. Where can I find this information - changelog?

Thanks in advance!


(Simone Scarduzio) #2

Hello @cmnfu28 welcome the forum!

Yes no worries about that log line, it’s not an error or anything. The URL should point to the “CLUSTERWIDE SETTINGS” section in https://readonlyrest.com/pro.html. Thanks for pointing out, need to fix that!

So what’s happening here is that you just upgraded to a ROR version that supports in-index settings, and ROR is initially looking for a settings index to load the ACL from. When it doesn’t find one, it informs the user about the feature.

I hope it helps!


#3

Hi Simon,

Thanks for the quick reply :slight_smile: So uhm, youre welcome I guess hehe. The thing is that Kibana stays RED - and ES is down. I cant spot the error - I thought I had to focus on the index thing :slight_smile:

From KIbana I can see: “Elasticsearch plugin is red”. The elasticsearch.log indicates that the ROR plugin is loaded succesfully. Ive just discovered:

"[2017-08-14T14:53:40,614][ERROR][o.e.p.r.e.SSLTransportNetty4] Failed to load SSL certs and keys from JKS Keystore!
[2017-08-14T14:53:40,614][ERROR][o.e.p.r.e.SSLTransportNetty4] Check the JKS Keystore path is correct: /usr/share/elasticsearch/keystore.jks"
I followed your link to the keystore generation - at first it looked good, but I still see:

[2017-08-14T15:33:05,096][ERROR][o.e.p.r.e.SSLTransportNetty4] Failed to load SSL certs and keys from JKS Keystore!
[2017-08-14T15:33:05,096][ERROR][o.e.p.r.e.SSLTransportNetty4] Check the JKS Keystore path is correct: /usr/share/elasticsearch/keystore.jks

The file exists and the path has not been changed. Can I verify the keystore somehow?

Kibana stays read.


(Simone Scarduzio) #4

Can you try putting the keystore in the plugin directory?

Example:


#5

<3 …!

That worked - so it is a requirement that the jks is in the ROR dir :slight_smile:

Between a shitload of “Cluster not ready…” I spotted the following:

[2017-08-14T15:44:52,931][WARN ][o.e.p.r.e.SSLTransportNetty4] io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record: 504f5354202f5f62756c…

Do you know what that is related to? Is it fatal? KIbana is still on the red side.


(Simone Scarduzio) #6

AWESOME.

So that error is when somebody sends a non-https request to ES and SSL is configured instead. Most likely you have to edit your kibana or logstash settings to point to https://… instead of http://…


#7

I see - so it could be a user error. Kibana/ES has always been running via HTTPS (using Nginx) - so I havent changed anything there.

When logging into Kibana now, I dont see a Status: RED - instead I get a “
Error
Request to Elasticsearch failed: “Bad Request”” in the top:

Error: Request to Elasticsearch failed: "Bad Request"
    at https://hostname.domain.tld:5601/bundles/kibana.bundle.js?v=15405:27:23337
    at processQueue (https://hostname.domain.tld:5601/bundles/commons.bundle.js?v=15405:38:23621)
    at https://hostname.domain.tld:5601/bundles/commons.bundle.js?v=15405:38:23888
    at Scope.$eval (https://hostname.domain.tld:5601/bundles/commons.bundle.js?v=15405:39:4619)
    at Scope.$digest (https://hostname.domain.tld:5601/bundles/commons.bundle.js?v=15405:39:2359)
    at Scope.$apply (https://hostname.domain.tld:5601/bundles/commons.bundle.js?v=15405:39:5037)
    at done (https://hostname.domain.tld:5601/bundles/commons.bundle.js?v=15405:37:25027)
    at completeRequest (https://hostname.domain.tld:5601/bundles/commons.bundle.js?v=15405:37:28702)
    at XMLHttpRequest.xhr.onload (https://hostname.domain.tld:5601/bundles/commons.bundle.js?v=15405:37:29634)

So ES seems to fail in responding correctly, but I guess this is not the right place to ask that question :slight_smile:


(Simone Scarduzio) #8

Try yourself if ES is well set up with SSL

curl  -vvv https://yourhost:9200 

or if you have a self signed cert

curl -k -vvv https://yourhost:9200 

If you use self signed certs, keep an eye on kibana SSL settings, so that you skip the cert verification, or use a custom CA.

PS: If I recall correctly you can also put the keystore under config/ (just where elasticsearch.yml lives) and it’s handier because when you upgrade ROR you uninstall and reinstall it, and you would delete the keystore if you leave it in plugins/readonlyrest/.


#9

ES responds alright on TLS connections - gives me unauth access via curl, so I think its alright on that part. I find it a bit odd that it would respond with “Bad request” even though it lets me do auth via ROR ACLs.

Thanks for the tip on placing the keystore. Maybe it would be good to mention that it probably should reside in the config folder - or only under the plugins folder.


#10

I solved the problem by deleting my kibana index (sigh).


(Simone Scarduzio) #11

Oh wow, that’s interesting. :thinking: