Bug #22388
closed
Bad report maching when reportid are present
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
Updated by Félix DALLIDET 10 months ago
- 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.
Updated by François ARMAND 10 months ago
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
Updated by François ARMAND 10 months ago
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.
Updated by François ARMAND 10 months ago
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.
Updated by François ARMAND 10 months ago
- 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).
Updated by François ARMAND 10 months ago
- Related to Bug #20071: Compliance incorrectly computed when two components have the same name and cfe vars are involved added
Updated by François ARMAND 10 months ago
- Related to Architecture #23084: Remove constraint on component name pattern for matching reports added
Updated by François ARMAND 10 months ago
- 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
Updated by François ARMAND 10 months ago
- Related to Bug #23090: Multiline string in component name or value breaks pattern comparison for expected report added
Updated by Anonymous 10 months ago
- Status changed from Pending technical review to Pending release
Applied in changeset rudder|bfad70e21fefa242f7f35fa350e1855e80099883.
Updated by Nicolas CHARLES 9 months ago
- Priority changed from 148 to 147
- Fix check changed from To do to Checked
Updated by Vincent MEMBRÉ 9 months ago
- 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.