Any thought on below puppet concern ???
We saw Puppet make some crontab entry updates to the machines. We could not find any reason for Puppet to do this – we did not ‘tell’ it to configure anything new, and we did not remove anything in the crontab entries. This caused some concern...
When the systems were in a bad-state; owned by a non-root user, like “xyz” or some other account, root functions were running as this user. When Puppet ran, it ran as "xyz" and it looked for a crontab for that user – which it did not find. Puppet corrected this by creating a new crontab and mcollective entry for "xyz". All the while the original entry existed in the regular root crontab. These were the unexpected/unexplained updates that we saw that happened. At present we have stopped puppet on all those 25 nodes and made the manual changes reverting the ownership to root users.
Are there any configuration changes to be made for stopping such issues in future ? All the thoughts are welcomed.
Log Messages from one of the machine:
Jan 15 3:30:56 vm /usr/sbin/cron: (root) CMD (/opt/puppet/sbin/refresh-mcollective-metadata) Jan 15 3:33:36 vm puppet-agent: (at /opt/puppet/lib/ruby/site_ruby/1.9.1/puppet/type/package.rb:430:in `block (3 levels) in <module:Puppet>') Jan 15 3:33:24 vm crontab: (xyz) LIST (xyz) Jan 15 3:33:14 vm puppet-agent: (/Stage[main]/Puppet_enterprise::Mcollective::Server::Facter/Cron[pe-mcollective-metadata]/ensure) created Jan 15 3:33:14 vm crontab: (xyz) REPLACE (xyz) Jan 15 3:33:14 vm puppet-agent: Finished catalog run in 1.31 seconds
My Thoughts : 1. Making a manifests to confirm the root users on all folders can be done ? But again there would be issue that if at some point user ''xyz'' need to take ownership of that for so and so reason, puppet wont allow to do it. 2. Disabling the puppet run and doing an manual puppet, which doesn't make that sense. 3. Thinking ............
Thanking in advance.