Reset potentially inherited defaults (since the mode is not always sp…

[alexfouche]

Reset potentially inherited defaults (since the mode is not always specified in below items

For example "${elasticsearch::homedir}/lib" was stripped of 'other' permissions, so my Elasticsearch was unable to start

[tylerjl]

Thanks @alexfouche. My concern here is that "fixing" resource defaults that occur above the elasticsearch module essentially means that the module is now attempting to proactively fix what the user is setting as resource defaults, and that is essentially unbounded. I'm definitely willing to consider the change, but it feels like this is less of a change the module needs to make and more of a tweak to the Puppet manifest that is making very broad resource defaults that impact other modules (for example, this module only uses resource defaults within the scope of resources it manages).

[alexfouche]

Hi, In fact, the fix is simply due to the fact that there is an item in this file to manage "${elasticsearch::homedir}/lib", which specifies owner and group to root, but does not specify a mode ​which is open to anyone, especially the $elasticsearch::elasticsearch_group Other ressources there may not specify the mode, but at least the user or group is set for Elasticsearch, which can have after all keep access. So an alternate fix could simply be sure that the mode is specified there, but the recurse makes it not ideal "${elasticsearch::homedir}/lib": ensure => 'directory', group => '0', owner => 'root', recurse => true;

[tylerjl]

While I agree with you that the recurse parameter doesn't make it ideal, I think the module has to accept that since it decides to manage the lib dir in the first place. Because the file resource can accept custom modes that aren't simply hex codes, what if we added the following to the file resource for the lib directory?

recurse => true,
mode => 'o+Xr',

That should the directory is r-x and all the files beneath it are r--, thoughts?

[fatmcgav]

Hi there,

Firstly, thank you for taking the time to contribute, and apologies for the radio silence from Elastic on this PR.

I'm going to be working on this module over the next few weeks, with an ultimate aim of updating the module to support the elasticsearch 7.x and simplifying the module to make it easier to use.

I'll be reviewing all the open issues and PRs over the next few days, and will merge or provide feedback where appropriate.

So please hang in there whilst we give this module some TLC.

Thanks again.

[elasticmachine]

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

[vox-pupuli-tasks]

Dear @alexfouche, thanks for the PR!

This is Vox Pupuli Tasks, your friendly Vox Pupuli Github Bot. I noticed that your pull request has CI failures. Can you please have a look at the failing CI jobs?
If you need any help, you can reach out to us on our IRC channel voxpupuli on Freenode or our Slack channel voxpupuli at slack.puppet.com.
You can find my sourcecode at voxpupuli/vox-pupuli-tasks

[vox-pupuli-tasks]

Dear @alexfouche, thanks for the PR!

This is Vox Pupuli Tasks, your friendly Vox Pupuli GitHub Bot. I noticed that your pull request contains merge conflict. Can you please rebase?

You can find my sourcecode at voxpupuli/vox-pupuli-tasks