search

voxpupuli / puppet-hiera

Hiera hierarchy module for templating `hiera.yaml`
https://forge.puppet.com/puppet/hiera
Apache License 2.0
32 stars 105 forks source link

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

Closed mwpower closed 5 years ago

mwpower commented 5 years ago

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

dan-wittenberg commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

It should affect if you are using it or not, as the defaults are root:root (should be fine since it's 0644 perms. The eyaml is an extra option in case your eyaml is stored somewhere that PE expect to be something other than your other config files.

On Thu, Feb 7, 2019 at 11:22 AM Michael Power notifications@github.com wrote:

@dan-wittenberg https://github.com/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 😟 )

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/voxpupuli/puppet-hiera/issues/245#issuecomment-461519246, or mute the thread https://github.com/notifications/unsubscribe-auth/ANCBg9sG35cfhVhf_KnS9gS61bBNS-K9ks5vLGDEgaJpZM4afNM9 .

--

Daniel Wittenberg | Sr. Technical Architect | AHEAD

Work: 312.508.4996 | Mobile: 319.329.9776 | Fax: 312.924.5076

dan.wittenberg@ThinkAHEAD.com | ThinkAHEAD.com http://info.thinkahead.com/e1t/c/*W6xgnfb3P660yN6FC2m6RB8ng0/*VZbrYd83jBHmW8yYcRc7tsC9Q0/5/f18dQhb0S5fw8XJ8hgW7-KP3h2qwv1yN32Gdlh5YWcwMf59TdXD6prW39Dr-N8pCDJGVYwxWD50wxKSW1wSwgX6PZxrZW1nrCGw96zRPSW6bT6L38RRjRDW5Ckvpl6vYDb4W7v70tS4RYYVxW3s1XjF51G0BFN4-0Bs5YSX-5W7m_B1R5c8d-SW377W4T2y-PYYW1chfKP7cMWqbW7yHnNh5v7qjJW8f27Mv160vTSW3JX9bz6QCkN4W3yrKmV25vJtRN6RRKCDDSjH1W1x2Rdy3scNzKW7cLGH22_P0-DW3TgRkj2BH5L0W3MfK-q6QtBYkW4VsJNn5tRSXLW2ptwYT7-18V4W3Jyb2b5c1xDZM9XCtYhzVNsW75f7r78csGDVVD2JF57dZRWvW5BbJtH3fDF-GW30D2Nn2tf-5XW4Wrj0H31GHfxW11PXZW1DylWwN91kcK-5LD0kW85GKv28HFk6-VGJMbw4x6kZpW4L1MlS4HzlXXf3hvFt-11

Subscribe to The Lab https://www.thinkahead.com/TheLAB/

repperille commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.