config dirs/files and install dirs/files should be owned by root, not es_user

[koertkuipers]

for example i see wrong owner in

logging_template = template 'logging.yml' do
      path   "#{new_resource.path_conf[es_install.type]}/logging.yml"
      source new_resource.template_logging_yml
      cookbook new_resource.cookbook_logging_yml
      owner es_user.username
      group es_user.groupname
      mode 0755
      variables(logging: new_resource.logging)
      action :nothing
    end

and many other places

the es user has no business modifying stuff in config or install dir.

[martinb3]

It looks like there's some varying behavior of ES on how ownership is handled now. Specifically, as of about 2 months ago, it uses whatever the permissions on the config dir are, according to elastic/elasticsearch#14048 and elastic/elasticsearch#14088 and elastic/elasticsearch#14017.

[martinb3]

I'm not sure there's going to be a way to do this nicely, while still maintaining compatibility for older versions of ES that use different permissions, especially for the plugin directories. We may need to split out releases of this cookbook that specifically support different ES versions (seems like it could be a nightmare, I'll need to review this to see if we can maintain compat any better across ES versions with breaking changes).

[koertkuipers]

good point... i just realized that our current installs (done with the
elasticsearch cookbook < 1.0) also have elasticsearch:elasticsearch as the
owner of the install_dir and config_dir. i never noticed this before.

i dont like it much... but its what i already have apparently

On Sun, Dec 6, 2015 at 11:02 PM, Martin Smith [email protected]
wrote:

I'm not sure there's going to be a way to do this nicely, while still
maintaining compatibility for older versions of ES that use different
permissions, especially for the plugin directories. We may need to split
out releases of this cookbook that specifically support different ES
versions (seems like it could be a nightmare, I'll need to review this to
see if we can maintain compat any better across ES versions with breaking
changes).

—
Reply to this email directly or view it on GitHub
#405 (comment)
.

[koertkuipers]

not sure i understand why elasticsearch cares so much about the plugin dir
being owned by elasticsearch? isn't bin/plugin supposed to be run with sudo?

On Mon, Dec 7, 2015 at 12:10 AM, Koert Kuipers [email protected] wrote:

good point... i just realized that our current installs (done with the
elasticsearch cookbook < 1.0) also have elasticsearch:elasticsearch as the
owner of the install_dir and config_dir. i never noticed this before.

i dont like it much... but its what i already have apparently

On Sun, Dec 6, 2015 at 11:02 PM, Martin Smith [email protected]
wrote:

I'm not sure there's going to be a way to do this nicely, while still
maintaining compatibility for older versions of ES that use different
permissions, especially for the plugin directories. We may need to split
out releases of this cookbook that specifically support different ES
versions (seems like it could be a nightmare, I'll need to review this to
see if we can maintain compat any better across ES versions with breaking
changes).

—
Reply to this email directly or view it on GitHub
#405 (comment)
.

[martinb3]

You can check out the docs here:
https://www.elastic.co/guide/en/elasticsearch/plugins/2.1/plugin-management.html

There's a note about installing via rpm/deb vs. tarball (we have both options in this repo).

[martinb3]

Hello! I believe we fixed this in the latest master, via #421. Could you give that a try and let us know? We haven't released yet but plan to do the release today.

[koertkuipers]

i will not be able to test this today
but thank you for working on this
best, koert

On Fri, Jan 8, 2016 at 11:38 AM, Martin Smith [email protected]
wrote:

Hello! I believe we fixed this in the latest master, via #421
#421. Could you
give that a try and let us know? We haven't released yet but plan to do the
release today.

—
Reply to this email directly or view it on GitHub
#405 (comment)
.

[martinb3]

I've released v2.1.1 with a fix for this issue. Let me know if you hear of any other breakages with the plugin user and group. Thank you!