bcc:puppet-dev Please follow the general status of this issue on the -users list. There will be a follow-up email to the -dev list about how best to resolve the remaining issue.
On Tue, Mar 1, 2011 at 7:53 AM, Nigel Kersten <[email protected]> wrote: > http://projects.puppetlabs.com/issues/6443 > > We have a regression that causes spurious errors and log messages due > to auditing being auto-enabled incorrectly in some situations. > > Do not upgrade to 2.6.5. > > We will be resolving this issue and providing further information as > we run through testing. > I believe this is an accurate characterization of the issue: Overview: In versions of Puppet from 2.6.0 to 2.6.4, files being managed via a source => attribute caused incorrect symbols to be written out to the audit log, even when auditing was not enabled. In Puppet 2.6.5 we accidentally enabled auditing for all files managed via the source attribute. At the same time we fixed the bug that caused incorrect symbols to be written out. As we're moving from incorrect_value -> correct_value, a notification is fired due to the audit value change. Note that this was the design goal of audit, to allow you to send events for attribute changes that you are not managing via Puppet. We have a patch for the accidental enabling of auditing that resolves that issue. However, if you are deliberately auditing, you will still get the spurious notify the first time you run with that patch. We're currently investigating the best way to resolve the single spurious notify. Gory details follow. Gory Details: Glossary: 2.6.e3dfe41 means commit e3dfe41ce7da108fc345e58c7df8c1576ea951a0 https://github.com/puppetlabs/puppet/commit/e3dfe41ce7da108fc345e58c7df8c1576ea951a0 This is the commit that resolves the primary issue with source-managed files incorrectly creating entries in the audit log, state.yaml. Description: On 2.6.5, we are auditing by default for all source managed files. If you were on 2.6.4 (and probably earlier) and if you managed a file with the source parameter and if the local file was absent or content differed, we wrote out: !ruby/sym type: !ruby/sym absent !ruby/sym owner: !ruby/sym absent to state.yaml, even if you weren't auditing. Also, if you managed a file recursively with source, we also wrote out: !ruby/sym content: !ruby/sym absent As of 2.6.5, when auditing all attributes, we write out the correct value: !ruby/sym type: file !ruby/sym owner: 1000 !ruby/sym content: This is a value change for the attribute being audited, and will thus send appropriate events. Implications: If you move from 2.6.4 -> 2.6.5 and you have a file resource with a notify parameter, you will send a single spurious notify. If you move from 2.6.4 -> 2.6.e3dfe41 and you are auditing file or owner (or content with a recursive file), you will send a single spurious notify. If you move from 2.6.4 -> 2.6.e3dfe41, and are not auditing type or owner (or content with a recursive file), you will never have the :absent entries removed from state.yaml. Resolution: Assuming that 2.6.6 will be equal to 2.6.e3dfe41, the only remaining issue is the single spurious notify sent for files that have the relevant attributes marked for audit. This will only affect users who have explicitly turned on audit for those attributes. We have three potential workarounds: a) Tell users to remove state.yaml and lose all audit history b) Provide a one-off script to clean up incorrect entries from state.yaml c) Fix it in the code. I'll start a new thread about option c) to the -dev list in a few minutes. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
