-
-
Notifications
You must be signed in to change notification settings - Fork 104
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
Permission contention on hiera.yaml between module and PE #245
Comments
This is also happening in the latest 2019.0.2 release, part of the new update. You also can't change the owner/group to root:root because then it changes keys permissions too, so the module should probably default on PE to the same thing. |
@dan-wittenberg - That'll only affect an installation if 'eyaml' is being used as the backend though, yeah? My setup just uses yaml as the backend, and setting this to root:root hasn't shown any negative behaviour (.... yet 😟 ) |
I am using eyaml. After a run the PE can not read the secret key. It is failing with: |
I just upgraded to PE2019.0.2 and ran into this, so I started on a fix and it got complicated pretty quickly because I'm not sure where the boundaries on ownership should be. The following files are managed by this module:
I believe the first two files should be grouped, defaulting to root, and the rest should be grouped, defaulting to pe-puppet or puppet, but I honestly do not know the impact of ownership on these files. Looking at my controlrepo, ownership seems a little random:
Any suggestions on what should be the proper owner of the various files? |
I am having the same issue on PE 2018.1.7 LTS. Here is what happens when I set owner/group to
...and here is what happens when I leave everything set to the default.
|
As per my post to slack... looks like we need to detect Puppet 6 and default the permissions to Notice: /Stage[main]/Puppet_enterprise::Master/Puppet_enterprise::Set_owner_group_permissions[/etc/puppetlabs/puppet/hiera.yaml]/Exec[Set user/group of /etc/puppetlabs/puppet/hiera.yaml contents to root:root]/returns: changed ownership of ‘/etc/puppetlabs/puppet/hiera.yaml’ from pe-puppet:pe-puppet to root:root |
Maybe instead of worrying about splitting up the ownership of hiera.yaml, we should just put the file resource behind an |
Perhaps? I think managing the existence of the directory was originally done for a reason, maybe we could leave the permissions attributes out (put a File { user/group } inside the condition you spoke of? The code is almost there in #246 . |
FWIW, my PE master (latest LTS 2018.1.7) reports |
Affected Puppet, Ruby, OS and module versions/distributions
How to reproduce (e.g Puppet code you use)
This looks to happen with fairly minimal code in place.
What are you seeing
On each puppet run on my master, the hiera module will set ownership of my hiera.yaml to pe-puppet:pe-puppet (which is the default selection in the module,) but then the PE module will change it back to root:root. This happens every single time.
What behaviour did you expect instead
I would've expected the default in the module to match the default of the PE version.
Output log
Any additional information you'd like to impart
The text was updated successfully, but these errors were encountered: