Skip to content
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

Closed
mwpower opened this issue Feb 1, 2019 · 10 comments · Fixed by #260
Closed

Permission contention on hiera.yaml between module and PE #245

mwpower opened this issue Feb 1, 2019 · 10 comments · Fixed by #260

Comments

@mwpower
Copy link

mwpower commented Feb 1, 2019

Affected Puppet, Ruby, OS and module versions/distributions

  • Puppet: 2018.1.7
  • Ruby: 1.8.7
  • Distribution: RHEL6.8
  • Module version: 3.3.4

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

@dan-wittenberg
Copy link
Contributor

This is also happening in the latest 2019.0.2 release, part of the new update.
puppet_enterprise::set_owner_group_permissions{'/etc/puppetlabs/puppet/hiera.yaml':
file_mode => '0644',
owner => 'root',
group => 'root',
target_type => 'file',
}

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.

@mwpower
Copy link
Author

mwpower commented Feb 7, 2019

@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 😟 )

@dan-wittenberg
Copy link
Contributor

dan-wittenberg commented Feb 7, 2019 via email

@repperille
Copy link

I am using eyaml.
I asked Puppet support about hiera.yaml and they said that the correct owner/group for hiera.yaml is root (644).
So I set the parameters owner and group in the hiera module to 'root' but that also inflict the keys in the keys directory '/etc/puppetlabs/puppet/keys' changing from 'pe-puppet' to 'root'
-rw------- 1 root root 1679 Nov 16 2016 private_key.pkcs7.pem
-rw-r--r-- 1 root root 1050 Nov 16 2016 public_key.pkcs7.pem

After a run the PE can not read the secret key. It is failing with:
"Permission denied - /etc/puppetlabs/puppet/keys/private_key.pkcs7.pem"

@rnelson0
Copy link
Member

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:

/etc/hiera.yaml (symlink)
/etc/puppetlabs/puppet/hiera.yaml
/etc/puppetlabs/puppet/hieradata / /etc/puppetlabs/code/environments/%{::environment}/hieradata ($datadir)
/etc/puppetlabs/puppet/keys
/etc/puppetlabs/puppet/keys/private_key.pkcs7.pem
/etc/puppetlabs/puppet/keys/public_key.pkcs7.pem

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:

total 56
drwxr-xr-x.  2 pe-puppet pe-puppet 4096 Mar 29 15:09 bootstrap
drwxr-xr-x.  2 pe-puppet pe-puppet 4096 Jan 14 21:45 data
drwxr-xr-x.  7 pe-puppet pe-puppet 4096 Nov 15  2017 dist
-rw-r--r--.  1 root      root        74 Mar 29 15:09 environment.conf
-rw-r--r--.  1 pe-puppet pe-puppet  865 Jun 12  2018 environment.conf.rpmnew
-rw-r--r--.  1 root      root      3089 Mar 29 15:09 Gemfile
drwxr-xr-x.  6 pe-puppet pe-puppet 4096 Mar 29 15:09 hiera
-rw-r--r--.  1 pe-puppet pe-puppet  518 Jun 12  2018 hiera.yaml
drwxr-xr-x.  2 pe-puppet pe-puppet 4096 Mar 29 15:09 manifests
-rw-r--r--.  1 root      root       907 Mar 29 15:09 metadata.json
drwxr-xr-x. 62 pe-puppet pe-puppet 4096 Mar 29 15:10 modules
-rw-r--r--.  1 root      root      2189 Mar 29 15:09 Puppetfile
-rw-r--r--.  1 root      root      3275 Mar 29 15:09 Rakefile
drwxr-xr-x.  6 pe-puppet pe-puppet 4096 Mar 29 15:09 spec

Any suggestions on what should be the proper owner of the various files?

@decibelhertz
Copy link

I am having the same issue on PE 2018.1.7 LTS. hiera.yaml needs to have separate owner/group parameters from the EYAML data.

Here is what happens when I set owner/group to root in this module...

[root@puppet ~]# puppet agent -t
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Info: Caching catalog for puppet
Info: Applying configuration version 'c9550c71fa696fc1002033b30ac07e4298892f2f'
Notice: /Stage[main]/Hiera::Eyaml/File[/etc/puppetlabs/puppet/keys]/owner: owner changed 'pe-puppet' to 'root'
Notice: /Stage[main]/Hiera::Eyaml/File[/etc/puppetlabs/puppet/keys]/group: group changed 'pe-puppet' to 'root'
Notice: /Stage[main]/Hiera::Eyaml/File[/etc/puppetlabs/puppet/keys/private_key.pkcs7.pem]/owner: owner changed 'pe-puppet' to 'root'
Notice: /Stage[main]/Hiera::Eyaml/File[/etc/puppetlabs/puppet/keys/private_key.pkcs7.pem]/group: group changed 'pe-puppet' to 'root'
Notice: /Stage[main]/Hiera::Eyaml/File[/etc/puppetlabs/puppet/keys/public_key.pkcs7.pem]/owner: owner changed 'pe-puppet' to 'root'
Notice: /Stage[main]/Hiera::Eyaml/File[/etc/puppetlabs/puppet/keys/public_key.pkcs7.pem]/group: group changed 'pe-puppet' to 'root'
Notice: /Stage[main]/Hiera/File[/etc/hiera.yaml]/owner: owner changed 'pe-puppet' to 'root'
Notice: /Stage[main]/Hiera/File[/etc/hiera.yaml]/group: group changed 'pe-puppet' to 'root'
Notice: /Stage[main]/Puppet_enterprise::Profile::Master/Puppet_enterprise::Set_owner_group_permissions[/etc/puppetlabs/puppetserver/ssh]/Exec[Set user/group of /etc/puppetlabs/puppetserver/ssh/ contents to pe-puppet:pe-puppet]/returns: executed successfully
Notice: Applied catalog in 28.75 seconds
[root@puppet ~]# puppet agent -t
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Function Call, Permission denied - /etc/puppetlabs/puppet/keys/private_key.pkcs7.pem (file: /etc/puppetlabs/code/environments/production/site/profile/manifests/accounts/ad.pp, line: 4, column: 5) on node puppet
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

...and here is what happens when I leave everything set to the default.

[root@puppet ~]# puppet agent -t
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Info: Caching catalog for puppet
Info: Applying configuration version 'f69350813f343b4ec6df34d30fe098e8e0af68c3'
Notice: /Stage[main]/Hiera::Eyaml/File[/etc/puppetlabs/puppet/keys]/owner: owner changed 'root' to 'pe-puppet'
Notice: /Stage[main]/Hiera::Eyaml/File[/etc/puppetlabs/puppet/keys]/group: group changed 'root' to 'pe-puppet'
Notice: /Stage[main]/Hiera/File[/etc/puppetlabs/puppet/hiera.yaml]/owner: owner changed 'root' to 'pe-puppet'
Notice: /Stage[main]/Hiera/File[/etc/puppetlabs/puppet/hiera.yaml]/group: group changed 'root' to 'pe-puppet'
Info: /Stage[main]/Hiera/File[/etc/puppetlabs/puppet/hiera.yaml]: Scheduling refresh of Service[pe-puppetserver]
Info: /Stage[main]/Hiera/File[/etc/puppetlabs/puppet/hiera.yaml]: Scheduling refresh of Service[pe-puppetserver]
Notice: /Stage[main]/Hiera/File[/etc/hiera.yaml]/owner: owner changed 'root' to 'pe-puppet'
Notice: /Stage[main]/Hiera/File[/etc/hiera.yaml]/group: group changed 'root' to 'pe-puppet'
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
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: executed successfully
Notice: /Stage[main]/Puppet_enterprise::Profile::Master/Puppet_enterprise::Set_owner_group_permissions[/etc/puppetlabs/puppetserver/ssh]/Exec[Set user/group of /etc/puppetlabs/puppetserver/ssh/ contents to pe-puppet:pe-puppet]/returns: executed successfully
Notice: /Stage[main]/Puppet_enterprise::Master::Puppetserver/Puppet_enterprise::Trapperkeeper::Pe_service[puppetserver]/Service[pe-puppetserver]: Triggered 'refresh' from 2 events
Notice: Applied catalog in 30.67 seconds

@TJM
Copy link

TJM commented Apr 4, 2019

As per my post to slack... looks like we need to detect Puppet 6 and default the permissions to root:root or else the Puppet Enterprise module will fight with the hiera module over the permissions (wow, they actually use "exec")

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

@rnelson0
Copy link
Member

rnelson0 commented Apr 4, 2019

Maybe instead of worrying about splitting up the ownership of hiera.yaml, we should just put the file resource behind an if ! $puppet6 block and not manage it at all in that case?

@TJM
Copy link

TJM commented Apr 4, 2019

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 .

@decibelhertz
Copy link

FWIW, my PE master (latest LTS 2018.1.7) reports 5.5.10 for puppet --version and manifests this problem. So, I expect the $puppet6 test will not resolve my particular issue. As suggested in #246, though, I may simply need to adjust some of the PE parameters.

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

Successfully merging a pull request may close this issue.

6 participants