ES 5.5.0 halting on SSL checks?

1

Hey all, I’m currently running Elasticsearch 5.5.0 in a container (official Elastic image) with the associated ROR plugin bundled in and installed. When I try starting the container it halts when checking the SSL keystore (I think?); the logs show:

Caused by: java.util.NoSuchElementException: No value present
	at java.util.Optional.get(Optional.java:135) ~[?:1.8.0_131]
	at org.elasticsearch.plugin.readonlyrest.settings.RorSettings.<init>(RorSettings.java:98) ~[?:?]
	at org.elasticsearch.plugin.readonlyrest.es.SSLTransportNetty4.<init>(SSLTransportNetty4.java:55) ~[?:?]
	at org.elasticsearch.plugin.readonlyrest.es.ReadonlyRestPlugin.lambda$getHttpTransports$0(ReadonlyRestPlugin.java:86) ~[?:?]
	at org.elasticsearch.node.Node.<init>(Node.java:436) ~[elasticsearch-5.5.0.jar:5.5.0]
	at org.elasticsearch.node.Node.<init>(Node.java:244) ~[elasticsearch-5.5.0.jar:5.5.0]
	at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:232) ~[elasticsearch-5.5.0.jar:5.5.0]
	at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:232) ~[elasticsearch-5.5.0.jar:5.5.0]
	at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:351) ~[elasticsearch-5.5.0.jar:5.5.0]
	at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:123) ~[elasticsearch-5.5.0.jar:5.5.0]
	... 6 more

The keystore appears valid, and the pass I’m using in the config is correct. If I comment out the ‘http.type’ directive, ES throws a ton of errors which I assume is normal in this case. I honestly don’t know where the issue is here; any advice would be massively appreciated.

2

The issue is fixed; I had:

enable: true

just under the readonlyrest header, instead of the SSL section header. Argh.

1 Like
3

Hello @Mattsky, nice you found a workaround so fast!
What plugin version are you using? That exception sucks, need to put something more informative…

4

The filename is: readonlyrest-1.16.9_es5.5.0.zip

I’m thinking I haven’t fixed this quite as well as I thought… the ES containers are online, but they’re throwing a ton of “not an SSL/TLS record” issues (likely from clients not yet updated to use SSL) and I’m also unable to get cluster health status via curl; I guess I’ve just got more tweaking to do…

5

Never mind; the plugin was blocking my attempts to get cluster health from the Docker host. Running the status command on the container works fine. The cluster is hauling itself back up, Kibana appears to be able to communicate with it (got the cluster status page up and it asked for auth), so once it’s up and stable I’ll update a few of the beats agents and see how it goes.

1 Like