Bug #22388
closed
Bad report maching when reportid are present
Added by Nicolas CHARLES almost 2 years ago.
Updated over 1 year ago.
Category:
Web - Compliance & node report
Severity:
Major - prevents use of part of Rudder | no simple workaround
UX impact:
I hate Rudder for that
User visibility:
Getting started - demo | first install | Technique editor and level 1 Techniques
Description
Which seriously breaks everything
See for instance a linux command, applicable on linux only
the NA report don't contain the $1, and thus don't match the expected report
It also happens with powershell commmand where $_ needs to be replaced by ${const.dollar} which is highly inconvenient
Files
- Effort required set to Small
- Priority changed from 142 to 148
This is definitely reproducible.
A possible solution would be to forbid the interpretation of the component value for the reporting.
This should be very easy to implement for the generation:
$componentKey = "lastlog $1 stuff"
Must be replaced by:
$componentKey = @'
lastlog $1 stuff
'@
And the technique editor must forbid or escape the "'`n" and "`n'" sequences.
The drawback is that the reporting will only display the raw variable before replacement, but it should be fine as I am pretty sure that this component value replacement is only useful when using an iterator, which will most likely never be implemented on the windows agent. This should still be confirmed by scala devs.
no, we used to have a lot of logic to correctly match these cases. We really want to see what was the expansion on the node, esp when we have several values that otherwise can't be differentiated.
Plus, now that we have component id, it should be easy
I mean: I don't know if we want to evaluate the $ on windows (does it make sense?). But in any case, we should be able to correctly match the resulting report in rudder compliance.
So:
- if a reportid is present, it should be used and be the only thing that matters. So if the report id is correctly set, the observed behavior is a bug
- if there is no reportid, then we are in compat mode, and the observed behavior is what is expected for compat mode: the component value does not match, we don't have a ${} => not matching
In base, we have a report id for the problematic report => bug in report id ?
- if we had a ${}, it is working.
- Project changed from 78 to Rudder
- Subject changed from $ are evaluated in policy to Bad report maching when reportid are present
- Category changed from Techniques to Web - Compliance & node report
- Assignee set to François ARMAND
- Target version changed from 7.2 to 7.2.9
So: we do not want to check when there is reportid the component part, it must be done only in compat mode (when reportid = 0).
- Status changed from New to In progress
- Related to Bug #20071: Compliance incorrectly computed when two components have the same name and cfe vars are involved added
- Related to Architecture #23084: Remove constraint on component name pattern for matching reports added
- Status changed from In progress to Pending technical review
- Assignee changed from François ARMAND to Vincent MEMBRÉ
- Pull Request set to https://github.com/Normation/rudder/pull/4899
- Related to Bug #23090: Multiline string in component name or value breaks pattern comparison for expected report added
- Status changed from Pending technical review to Pending release
- Priority changed from 148 to 147
- Fix check changed from To do to Checked
- Status changed from Pending release to Released
This bug has been fixed in Rudder 7.2.9 and 7.3.4 which were released today.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by Anonymous 
Updated by 
Updated by