Error message:
MKGeneralException: Invalid regular expression ‘(?:(?:VM xyz)|(?:(?i)template))’: global flags not at the start of the expression at position
Service “filter” .*(?i)template should catch “windows server 2022 Template” or “windows server 2012R2 template” case insensitive. This as changed with the version 3.11 of python. and because checkmk constructs the regex starting with “(?:”
I’ve changed the expression as of now to .*[T|t]emplate but wouldn’t it maybe make sense to implement a case-insensitive possibility?
I’m aware of that. It’s in the rule of “Service discovery rules” “Disabled Services”.
And checkmk is then searching for Service name begins with XYZ and if I’d like to mach case insensitive names, I have to check with (?i)template but that doesn’t work because checkmk constructs the fields then into (?:(?i)template)).
Wait… the regular expression you posted was composed by Checkmk this way? If this is the case, I’ll forward it to the devs since this should be treated as a regression.
at least in the background… as you see in this is corresponding with the image below: MKGeneralException: Invalid regular expression ‘(?:(?:VM xyz)|(?:(?i)template))’: global flags not at the start of the expression at position
I already discussed this with the devs and product management. Short answer: You are likely to see several werks improving the situation during the next months, but no silver bullet that fixes everything at once.
I ran into the same issue.
There is a solution for most cases, though. Instead of using the global flag (?i), we can still use the group-limited version
Meaning, taking your example: .*(?i)template could be changed to .*(?i:template) to achieve the word template being matched case-insensitive (the .* part would still be matched case-sensitive in this case).
In short: Instead of using (?i) globally, use (?i: ... ) on the relevant parts (or the entire service description, if required). Have a look at the Python 3.11 docs for the re module to see what else is possible.
Nonetheless, I submitted a feature request on the portal (still in approval - and probably obsolete judging by this thread )
We are working on an automatic solution. For now, I updated the update_major article on the manual fix. Translation is in progress. Basically: Identify affected files with: