Checkmk 2.2 - python 3.11 - case insensitive

CMK version: 2.2.0

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?

The problem is the inline flag. (?i) must only be specified at the start of the regular expression:

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

@mschlenker do you need more informations, to decide if has to be forwarded to the devs?

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.

1 Like

@mschlenker thanks for looking into it.

Hi all

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 :slight_smile:

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 :wink: )

3 Likes

Thanks, will check that once I’m not anymore at the conference :smiley:

We have the same issue. We use the global flag (?i) for most of our rules.

Is there any news regarding an update?

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:

OMD[mysite]:~$ find etc/ -type f -name '*rules.mk' -exec grep -Hn '(?.)' {}  \;

And then run this Python script on them:

#!/usr/bin/env python3

import re
import shutil
import sys

def create_backup(fpath):
    bpath = fpath + ".bak"
    shutil.copyfile(fpath, bpath)

def modify_lines(fpath):
    bpath = fpath + ".bak"
    o = open(fpath, "w")
    with open(bpath) as f:
        for line in f:
            if re.search(r'\(\?i\)', line):
                print("OLD> " + line)
                line = re.sub(r'\(\?i\)(.*?)\'', r"(?i:\1)'", line)
                print("NEW> " + line)
            o.write(line)
    o.close

create_backup(sys.argv[1])
modify_lines(sys.argv[1]) 
6 Likes