8000 Tribe node clients using wrong config path · Issue #16253 · elastic/elasticsearch · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Tribe node clients using wrong config path #16253

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
clintongormley opened this issue Jan 27, 2016 · 4 comments
Closed

Tribe node clients using wrong config path #16253

clintongormley opened this issue Jan 27, 2016 · 4 comments
Assignees
Labels

Comments

@clintongormley
Copy link
Contributor

This is a duplicate of #15880

To replicate, copy the config directory to a new location and add a simple tribe config, eg:

cp -a elasticsearch-2.2.0/config tribe
echo "tribe.t1.cluster.name: foo" >> tribe/elasticsearch.yml

Start the tribe node as follows:

./elasticsearch-2.2.0/bin/elasticsearch --path.conf tribe

The process dies with:

Exception in thread "main" java.security.AccessControlException: access denied ("java.io.FilePermission" "/Users/clinton/workspace/servers/elasticsearch-2.2.0/config/hunspell" "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.UnixPath.checkRead(UnixPath.java:795)
at sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:49)
at sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
at java.nio.file.Files.readAttributes(Files.java:1737)
at java.nio.file.Files.isDirectory(Files.java:2192)
at org.elasticsearch.indices.analysis.HunspellService.scanAndLoadDictionaries(HunspellService.java:127)
at org.elasticsearch.indices.analysis.HunspellService.<init>(HunspellService.java:102)
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:422)
at <<<guice>>>
at org.elasticsearch.node.Node.<init>(Node.java:200)
at org.elasticsearch.tribe.TribeClientNode.<init>(TribeClientNode.java:35)
at org.elasticsearch.tribe.TribeService.<init>(TribeService.java:141)
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:422)
at <<<guice>>>
at org.elasticsearch.node.Node.<init>(Node.java:200)
at org.elasticsearch.node.Node.<init>(Node.java:128)
at org.elasticsearch.node.NodeBuilder.build(NodeBuilder.java:145)
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:178)
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:285)
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:35)

The reason for this is that, when the tribe node tries to create a client to connect to the cluster, it doesn't pass on the path.conf setting to the client, so that when HunspellService tries to resolve the hunspell directory it uses path.home instead of the custom path.conf.

Adding the absolute config path to the tribe node configuration works around this:

echo "tribe.t1.path.conf: /Users/clinton/workspace/servers/tribe/" >> tribe/elasticsearch.yml
@javanna javanna self-assigned this Jan 27, 2016
@javanna javanna removed the help wanted adoptme label Jan 27, 2016
javanna added a commit to javanna/elasticsearch that referenced this issue Jan 27, 2016
If we don't do this, and some path.conf is set when starting the tribe node, that path.conf will be ignored and the inner tribe clients will try to read elsewhere, where they most likely don't have permissions to read from.

Closes elastic#16253
Closes elastic#16258
javanna added a commit that referenced this issue Jan 27, 2016
If we don't do this, and some path.conf is set when starting the tribe node, that path.conf will be ignored and the inner tribe clients will try to read elsewhere, where they most likely don't have permissions to read from.

Closes #16253
Closes #16258
javanna added a commit that referenced this issue Jan 27, 2016
If we don't do this, and some path.conf is set when starting the tribe node, that path.conf will be ignored and the inner tribe clients will try to read elsewhere, where they most likely don't have permissions to read from.

Closes #16253
Closes #16258
javanna added a commit that referenced this issue Jan 27, 2016
If we don't do this, and some path.conf is set when starting the tribe node, that path.conf will be ignored and the inner tribe clients will try to read elsewhere, where they most likely don't have permissions to read from.

Closes #16253
Closes #16258
@gbjuno
Copy link
gbjuno commented Jan 28, 2016

@clintongormley hi. I do as you said, but it doesn't work!

elasticsearch@repository:/$ cat /etc/elasticsearch/elasticsearch.yml 
transport.tcp.port: 9300
http.port: 9200
node.name: es-center
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
network.host: 0.0.0.0
tribe:
    t1:
        path.conf: /etc/tribe-client/
        cluster.name: ydnj-es
        discovery.zen.ping.multicast.enabled: false
        discovery.zen.ping.unicast.hosts: ["10.2.89.182:50002"]
    t2:
        path.conf: /etc/tribe-client/
        cluster.name: ytyq-es
        discovery.zen.ping.multicast.enabled: false
        discovery.zen.ping.unicast.hosts: ["10.2.89.182:50003"]

elasticsearch.yml in /etc/tribe-client/ without anything in it.

elasticsearch@repository:/$ ls -al /etc/tribe-client/elasticsearch.yml 
-rw-r--r-- 1 elasticsearch root 0 Jan 27 20:01 /etc/tribe-client/elasticsearch.yml

HOWEVER, I get the result.

elasticsearch@repository:/$ /usr/share/elasticsearch/bin/elasticsearch --path.conf /etc/elasticsearch
[2016-01-28 11:00:06,314][INFO ][node                     ] [es-center] v
8000
ersion[2.1.1], pid[126326], build[40e2c53/2015-12-15T13:05:55Z]
[2016-01-28 11:00:06,314][INFO ][node                     ] [es-center] initializing ...
[2016-01-28 11:00:06,353][INFO ][plugins                  ] [es-center] loaded [], sites []
[2016-01-28 11:00:07,421][INFO ][node                     ] [es-center/t1] version[2.1.1], pid[126326], build[40e2c53/2015-12-15T13:05:55Z]
[2016-01-28 11:00:07,421][INFO ][node                     ] [es-center/t1] initializing ...
[2016-01-28 11:00:07,480][INFO ][plugins                  ] [es-center/t1] loaded [], sites []
Exception in thread "main" java.security.AccessControlException: access denied ("java.io.FilePermission" "/etc/tribe-client/hunspell" "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.UnixPath.checkRead(UnixPath.java:795)
    at sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:49)
    at sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
    at sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
    at java.nio.file.Files.readAttributes(Files.java:1737)
    at java.nio.file.Files.isDirectory(Files.java:2192)
    at org.elasticsearch.indices.analysis.HunspellService.scanAndLoadDictionaries(HunspellService.java:127)
    at org.elasticsearch.indices.analysis.HunspellService.<init>(HunspellService.java:102)
    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)

seems that the path.conf send to the tribe. but it still search for hunspell.

Enviroment: es 2.1.1; java 1.8.0_72

@gbjuno
Copy link
gbjuno commented Jan 28, 2016

the same configuration with environment: es 2.0.2

[2016-01-28 11:07:17,016][INFO ][node                     ] [es-center] version[2.0.2], pid[127071], build[6abf5d8/2015-12-16T12:49:58Z]
[2016-01-28 11:07:17,017][INFO ][node                     ] [es-center] initializing ...
[2016-01-28 11:07:17,064][INFO ][plugins                  ] [es-center] loaded [], sites []
[2016-01-28 11:07:18,040][ERROR][bootstrap                ] Guice Exception: java.security.AccessControlException: access denied ("java.io.FilePermission" "/etc/tribe-client/elasticsearch.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.UnixPath.checkRead(UnixPath.java:795)
        at sun.nio.fs.UnixFileSystemProvider.checkAccess(UnixFileSystemProvider.java:290)
        at java.nio.file.Files.exists(Files.java:2385)

@clintongormley
Copy link
Contributor Author

@gbjuno for the workaround to work, the path.conf that you specify on the command line must be the same as the path.conf that you specify in the tribe node config.

@gbjuno
Copy link
gbjuno commented Jan 29, 2016

@clintongormley ,thank you.After changing the path.conf to /etc/elasticsearch, the tribe node started running.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants
0