Upgraded from 5.4.0 to 5.6.0 Now wont start

(Cronin) #1

I am hoping to get a bit of help. I just upgraded elastic from 5.4.0 to 5.6.0 and not elastic is refusing to start I checked the logs and I am seeing the following error. Any help would be great.

[2017-09-13T15:49:02,198][ERROR][o.e.b.Bootstrap ] Guice Exception: java.security.AccessControlException: access denied (“java.io.FilePermission” “config/readonlyrest.yml” “read”)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
at sun.nio.fs.UnixChannelFactory.open(UnixChannelFactory.java:245)
at sun.nio.fs.UnixChannelFactory.newFileChannel(UnixChannelFactory.java:136)
at sun.nio.fs.UnixChannelFactory.newFileChannel(UnixChannelFactory.java:148)
at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:212)
at java.nio.file.Files.newByteChannel(Files.java:361)
at java.nio.file.Files.newByteChannel(Files.java:407)
at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384)
at java.nio.file.Files.newInputStream(Files.java:152)
at org.elasticsearch.common.settings.Settings$Builder.loadFromPath(Settings.java:1032)
at org.elasticsearch.plugin.readonlyrest.es.SettingsManagerImpl.getCurrentSettings(SettingsManagerImpl.java:55)
at org.elasticsearch.plugin.readonlyrest.configuration.ReloadableSettings.(ReloadableSettings.java:50)
at org.elasticsearch.plugin.readonlyrest.es.ReloadableSettingsImpl.(ReloadableSettingsImpl.java:29)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at <<>>
at org.elasticsearch.node.Node.(Node.java:499)
at org.elasticsearch.node.Node.(Node.java:245)
at org.elasticsearch.bootstrap.Bootstrap$5.(Bootstrap.java:233)
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:233)
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:342)

(Simone Scarduzio) #2

Hello @cronin, you surely will get some help. :slight_smile:
can you run this command on your elasticsearch installation?

cat plugins/readonlyrest/plugin-descriptor.properties

So I can check what exact plugin version is this.

(Cronin) #3


description=Safely expose Elasticsearch REST API

ES 2.x compatibility


(Simone Scarduzio) #4

Oh I see what’s wrong. The new experimental code to read the settings from readonlyrest.yml ended up in the 5.5.3 and 5.5.0 because Elastic has released those new version right after ROR 1.16.10 was released.

A fix is coming, hold on @cronin.

(Simone Scarduzio) #5

Can you please try again with this build?


(Cronin) #6

YES! Worked perfect!!!

Now upgrading Kibana and installing ROR Enterprise. Very exciting.

(Simone Scarduzio) #7

Awesome! If you have any questions or issues, just tell me. Enjoy!

(Cronin) #8

Follow up question in ROR Enterprise how do I enable the “Group/Tenancy selector” in Kibana?

(Simone Scarduzio) #9

Hi @cronin, see the video and attached configuration example here:

(Cronin) #10

Thanks for this I’m noticing some odd:
When I make changes to ROR settings in my .yml file they don’t take hold when I look back in Kibana I still see my old settings. is this intential? Should I make all chnages moving forward in Kibana?

(Simone Scarduzio) #11

Yes the Settings UI saves the configuration on an index, and the index settings have priority at node start up.

The lifecycle of the settings is intended like this

  1. Set up the basic failsafe credentials and ACL in the ES node’s YAML file (i.e. credentials for kibana server, logstash, and ROR admin).
  2. Get the Kibana plugin up and running and log in as administrator
  3. Open the Settings UI from Kibana. If this is the first time, it will inherit whatever settings it reads from the YAML file (to give you a starting point)
  4. Tweak the settings, hit the commit button and they are saved in the .readonlyrest index (ES settings automatically picks up the changes)
  5. From now on, even if you restart the ES node, the settings are going to be loaded exclusively from the .readonlyrest index and can be edited from Kibana only.

If you want to revert to file-based settings

  1. back up the YAML you see in the Settings UI
  2. write those settings to the node’s YAML file
  3. delete the readonlyrest index from ES
  4. restart the node

(Cronin) #12

Okay @sscarduzio last few question I swear…
Currently when applying kibana rw rules Im applying them at the group level like so:
name: "::XXX::"
groups: [“XXX”]
kibana_index: ".kibana_xxx"
kibana_access: rw

But can I apply them at the user level instead like this:

  • username: greg
    auth_key_sha256: "ABC"
    kibana_access: rw
    groups: [“XXX”]

#groups Below
name: "::XXX::"
groups: [“XXX”]
kibana_index: “.kibana_xxx”

Also same question for kibana_hide_apps.

(Simone Scarduzio) #13

Hi @cronin, in the blocks under under the “users” section you should only have the “group” rule to define what groups are associated to this user, and some authentication related rule (e.g. auth_key, auth_key_sha256, etc).
Although some more advanced things are possible like LDAP + local groups. But that’s another story.

Does this answer your question?

(Cronin) #14

Not exactly. Let me rephrase a bit here is an example of my new user settings:
name: "::XXX::"
groups: [“XXX”]
kibana_index: “.kibana_XXX”
name: "::XXX_RO::"
groups: [“XXX RO”]
kibana_index: ".kibana_XXX"
kibana_access: ro
kibana_hide_apps: [“readonlyrest_kbn”, “timelion”, “kibana:management”, “kibana:discover”, “kibana:visualize”, “kibana:dev_tools”]

  • username: greg
    auth_key_sha256: "XYZ"
    groups: [“XXX”, “XXX RO”]

Now this works as expeted however the readonly group “XXX RO” can still edit and crate items in dashbaords. My understanding is that the “RO” flag would prevent that from happening.

(Simone Scarduzio) #15

I’m testing this with the example settings you provided. One thing I didn’t mention is that all indices need to be lowercase, the example should have kibana_index: ".kibana_xxx"

Beside that, to your point. I actually reproduced the issue in the sense that I could get a green confirmation message when I add a viusalization to the dashboard, but when I refresh my dashboard doesn’t have the visualization added.
Can you confirm you see the same?

(Cronin) #16

Yes, that’s exactly what I’m saying. Also if you edit a dashboard edit an element and save you get a 400 error and then logged out.

(Cronin) #17

Also to your point all my indexes are lowercase I just removed client names and replaced with XXX.

(Simone Scarduzio) #18

So basically the expected behaviour would be to get the 400 without the logout, I guess?

(Cronin) #19

I mean to be honest the ideal scenario would be if you have RO access you shouldn’t even see the Edit buttons in the UI I mean what’s the point if you can only read?

But yes if that’s not possible there should be no logout just a 400 that it couldn’t save.

(MCI) #20

Hi Simone

I have the same problem starting elasticsearch 5.6.

Error injecting constructor, java.security.AccessControlException: access denied (“java.io.FilePermission” “config/readonlyrest.yml” "$
at org.elasticsearch.plugin.readonlyrest.es.ReloadableSettingsImpl.(Unknown Source)
while locating org.elasticsearch.plugin.readonlyrest.es.ReloadableSettingsImpl
for parameter 5 at org.elasticsearch.plugin.readonlyrest.es.IndexLevelActionFilter.(Unknown Source)
while locating org.elasticsearch.plugin.readonlyrest.es.IndexLevelActionFilter
while locating org.elasticsearch.action.support.ActionFilter annotated with @org.elasticsearch.common.inject.multibindings.Element(setNam$
at unknown
while locating java.util.Set<org.elasticsearch.action.support.ActionFilter>
for parameter 0 at org.elasticsearch.action.support.ActionFilters.(Unknown Source)
while locating org.elasticsearch.action.support.ActionFilters
for parameter 2 at org.elasticsearch.index.reindex.TransportDeleteByQueryAction.(Unknown Source)
while locating org.elasticsearch.index.reindex.TransportDeleteByQueryAction
Caused by: java.security.AccessControlException: access denied (“java.io.FilePermission” “config/readonlyrest.yml” “read”)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)

This is my plugin version

description=Safely expose Elasticsearch REST API

Could you help me please