Regression in 2.6.5
Nigel Kersten
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.
Nigel Kersten
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.
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.
Nigel Kersten
The situation is significantly better than my outline above stated.
Correction:
We were only writing out the :absent symbol when the source-managed
file *really* was absent, not when content was modified.
Given that we have a fix we're currently testing for the 2.6.5 bug
where all source-managed files had auditing turned on, users upgrading
from 2.6.{0,1,2,3,4} to 2.6.6 will only be affected if:
* The local file was absent, being managed, and not being audited in
2.6.x prior to 2.6.5.
* The user updates to 2.6.6 at the same time as they turn on auditing
for the given resource.
The impact for them will be one extra notify event for such a file,
and then life will return to normal.
Note that if you did upgrade to 2.6.5, you'll have dealt with the cost
of the extra notify event already.