Actions
Bug #8862
closed
Broken agent parsing when some report data start or ends with a separator char
Pull Request:
Severity:
Minor - inconvenience | misleading | easy workaround
UX impact:
User visibility:
Infrequent - complex configurations | third party integrations
Effort required:
Small
Priority:
32
Name check:
Fix check:
Regression:
Description
For example
SSH key@@@ my key
Updated by Alexis Mousset over 8 years ago
We need to use the same algorithm as the webapp for parsing, and check the different separators separately instead of checking for #, ##, @ or #@ to reduce the amount of failures.
Updated by Florian Heigl over 8 years ago
in my case it turned out it's the line that sets the loghost @ip-addr from an NCF edit file.
Updated by Florian Heigl over 8 years ago
consider if i used tcp it would even be @@ as the log destination, so this is really a nasty case :-)
Updated by
Updated by François ARMAND over 8 years ago
- Assignee set to Benoît PECCATTE
- Priority changed from N/A to 4
It may be because regex are greedy by defaults, and should not be.
Updated by Jonathan CLARKE
Updated by Benoît PECCATTE over 5 years ago
- Effort required set to Small
- Priority changed from 18 to 32
I think the parsing has changed, but we must check this
Updated by Alexis Mousset over 5 years ago
- Status changed from New to Rejected
We can't do better with rsyslog/awk regexes. HTTP reporting uses a more complete parser, but our report format has no escaping mechanism so it won"t be perfect anyway.
Closing as it is not actually a bug.
Actions