Affects Version/s: None
Fix Version/s: PUP 5.3.4
Template:PUP Bug Template customfield_10700 217236
Team:Security, Compliance, & Reporting
Sprint:SCR 2017-12-13, SCR 2018-01-03, SCR 2018-01-17, SCR 2018-01-31
Method Found:Needs Assessment
Release Notes:Bug Fix
Release Notes Summary:Running "puppet apply" or "puppet resource" to modify state would update the transaction.yaml file used to determine corrective vs intentional change. The transaction.yaml file will now only be updated during an agent run.
QA Risk Assessment:Needs Assessment
Enforcing change using "puppet resource" or "puppet apply" causes the transactionstore.yaml file to be overwritten. This is often done as part of our integrations plus is common puppet usage among customers. The loss of the tx store mans that corrective change is not correctly identified on the run immediately afterwards. The next run causes the agent to restore the tx store again.
Step 1 - After a run the tx store looks as expected
Step 2 - Enforce a change with puppet resource and the tx store is overwritten
Step 3 - The next agent run restores the expected tx store
Step 4 - Same issue using puppet apply, also doesn't matter if the enforcement succeeds or fails
The proposed fix is to modify the agent to load and store the transaction file only for agent runs, not puppet resource/apply, and consider making that behaviour configurable. We should also document that if you use "puppet resource" to modify a resource that is also managed by the agent, this is considered an out-of-band change and reported as corrective (e.g. agent creates file foo, user removes file foo using "puppet resource", agent recreates file foo and considers it a corrective change).
Here's the original description explaining how this manifests in the wild.
Just had this happen during demo of 2017.3.0. I have a simple apache role with profiles and demo drift remediation by removing the index.html and having puppet heal it.
But on the first noop run, it shows that "intentional changes" would be needed, and then enforcement shows "intentional changes". When I did the same thing again, it showed "corrective changes". Baffling. Also, the node graph did not update with colors representing corrective or intentional change (separate ticket coming).
explanation of above:
- first run (bottom) is initial provisioning (intentional change makes sense)
- second run is green, (no changes makes sense)
- third run is after I executed rm -f /var/www/sample_website/index.html in an ssh session on the target machine. Shows intentional noop changes needed! Should be corrective noop!
- fourth run is intentional change, wrong, should be corrective.
- fifth run is after I executed rm -f /var/www/sample_website/index.html again. Got corrective noop this time, which is correct.
- sixth run is enforcement of corrective change, which is correct.