ZABBIX BUGS AND ISSUES
  1. ZABBIX BUGS AND ISSUES
  2. ZBX-10316

ZABBIX 2.4 on RHEL - Unable to add step to Web Monitor Scenario

    Details

      Description

      Created: Application "Web checks" on "MicroStrategy Web Production".
      preg_grep(): Compilation failed: range out of order in character class at offset 11 [httpconf.php:292 → CFrontendApiWrapper->create() → CApiWrapper->__call() → CFrontendApiWrapper->callMethod() → CApiWrapper->callMethod() → CFrontendApiWrapper->callClientMethod() → CLocalApiClient->callMethod() → call_user_func_array() → CHttpTest->create() → CHttpTest->validateCreate() → CHttpTest->checkSteps() → preg_grep() in /wawa_mnt1/apache_httpd/httpd-2.2.31/htdocs/zabbix/include/classes/api/services/CHttpTest.php:650]
      Web scenario step name should contain only printable characters.

        Activity

        Hide
        Brian Dougherty added a comment -

        Also got this error -

        preg_match(): Compilation failed: range out of order in character class at offset 11 [popup_httpstep.php:55 → check_fields() → check_field() → calc_exp() → calc_exp2() → eval() → preg_match() in /wawa_mnt1/apache_httpd/httpd-2.2.31/htdocs/zabbix/include/validate.inc.php(105) : eval()'d code:1]
        Incorrect value "Zabbix Homepage" for "Name" field.

        Show
        Brian Dougherty added a comment - Also got this error - preg_match(): Compilation failed: range out of order in character class at offset 11 [popup_httpstep.php:55 → check_fields() → check_field() → calc_exp() → calc_exp2() → eval() → preg_match() in /wawa_mnt1/apache_httpd/httpd-2.2.31/htdocs/zabbix/include/validate.inc.php(105) : eval()'d code:1] Incorrect value "Zabbix Homepage" for "Name" field.
        Hide
        Aleksandrs Saveljevs added a comment -

        It seems to complain about the following regular expression:

        preg_grep('/([^\x{00}-\x{1F}]+?)?/i', $stepNames)
        

        Have you installed Zabbix for the first time? Has it ever worked in prior versions? Have you upgraded Web server or PHP packages recently?

        Show
        Aleksandrs Saveljevs added a comment - It seems to complain about the following regular expression: preg_grep('/([^\x{00}-\x{1F}]+?)?/i', $stepNames) Have you installed Zabbix for the first time? Has it ever worked in prior versions? Have you upgraded Web server or PHP packages recently?
        Hide
        Aleksandrs Saveljevs added a comment - - edited

        While we still need to figure out your original problem, there is something to be fixed anyway.

        In particular, there is the following code in CHttpTest.php:

        $stepNames = zbx_objectValues($httpTest['steps'], 'name');
        if (!empty($stepNames) && !preg_grep('/'.ZBX_PREG_PARAMS.'/i', $stepNames)) {
        	self::exception(ZBX_API_ERROR_PARAMETERS, _('Web scenario step name should contain only printable characters.'));
        }
        

        This is true - Web scenario step name should only contain printable characters. However, it verifies the name using the regular expression in the previous comment, but not all ASCII characters from 0 to 127 are printable! Also, why ^ symbol is needed there?

        That regular expression is defined in the following way:

        define('ZBX_PREG_PRINT', '^\x{00}-\x{1F}');
        

        Apparently, this is a misnomer.

        Ivo Kurzemnieks The ^ means not in the range. The particular example doesn't say that, but we have to look at it this way

        [^\x{00}-\x{1F}]

        . But the problem might with curly braces. They are optional since there are only two hexadecimal digits. Not sure whether it's a bug in PCRE library or what, because

        [^\x{00}-\x{1F}]

        and

        [^\x00-\x1F]

        are both correct syntaxes. I think the curly braces are used only because we use eval() function in frontend while checking through check_fields() all that complex chain of other functions. If we remove them, we need to change
        this

        return 'preg_match("/'.ZBX_PREG_PARAMS.'/",{'.$var.'})&&';

        to this

        return 'preg_match(\'/'.ZBX_PREG_PARAMS.'/\',{'.$var.'})&&';

        in KEY_PARAM()
        to work with eval() correctly. Otherwise there will be new problems. However, I understood that the validation for non-printable characters is not actually needed, since we allow anything inside item key. But if we remove the validation, we could then have problems with trigger expressions. There is another complex expression using ZBX_PREG_PRINT. So maybe removing validation is not a good option. And here's the catch. We can write the expression like this

        /([^\x00-\x1F]+?)?/i

        , but it somehow passes through the validation. I'm not quite sure why. But there is another function checkNames() that uses same expression. We could use the same regular expression for step names used in scenario names and it will look like this

        /^([^\x00-\x1F])+$/u

        Or maybe just add ^ and $? It could look like this

        ^([^\x00-\x1F]+?)?$

        Any thoughts on this matter? I'm still puzzled by this.

        Ivo Kurzemnieks In the end we have decided to remove the non-printable character restriction for scenario names and change the regular expression so that it doesn't use curly braces.

        Show
        Aleksandrs Saveljevs added a comment - - edited While we still need to figure out your original problem, there is something to be fixed anyway. In particular, there is the following code in CHttpTest.php: $stepNames = zbx_objectValues($httpTest['steps'], 'name'); if (!empty($stepNames) && !preg_grep('/'.ZBX_PREG_PARAMS.'/i', $stepNames)) { self::exception(ZBX_API_ERROR_PARAMETERS, _('Web scenario step name should contain only printable characters.')); } This is true - Web scenario step name should only contain printable characters. However, it verifies the name using the regular expression in the previous comment, but not all ASCII characters from 0 to 127 are printable! Also, why ^ symbol is needed there? That regular expression is defined in the following way: define('ZBX_PREG_PRINT', '^\x{00}-\x{1F}'); Apparently, this is a misnomer. Ivo Kurzemnieks The ^ means not in the range. The particular example doesn't say that, but we have to look at it this way [^\x{00}-\x{1F}] . But the problem might with curly braces. They are optional since there are only two hexadecimal digits. Not sure whether it's a bug in PCRE library or what, because [^\x{00}-\x{1F}] and [^\x00-\x1F] are both correct syntaxes. I think the curly braces are used only because we use eval() function in frontend while checking through check_fields() all that complex chain of other functions. If we remove them, we need to change this return 'preg_match("/'.ZBX_PREG_PARAMS.'/",{'.$var.'})&&'; to this return 'preg_match(\'/'.ZBX_PREG_PARAMS.'/\',{'.$var.'})&&'; in KEY_PARAM() to work with eval() correctly. Otherwise there will be new problems. However, I understood that the validation for non-printable characters is not actually needed, since we allow anything inside item key. But if we remove the validation, we could then have problems with trigger expressions. There is another complex expression using ZBX_PREG_PRINT . So maybe removing validation is not a good option. And here's the catch. We can write the expression like this /([^\x00-\x1F]+?)?/i , but it somehow passes through the validation. I'm not quite sure why. But there is another function checkNames() that uses same expression. We could use the same regular expression for step names used in scenario names and it will look like this /^([^\x00-\x1F])+$/u Or maybe just add ^ and $ ? It could look like this ^([^\x00-\x1F]+?)?$ Any thoughts on this matter? I'm still puzzled by this. Ivo Kurzemnieks In the end we have decided to remove the non-printable character restriction for scenario names and change the regular expression so that it doesn't use curly braces.
        Hide
        Brian Dougherty added a comment -

        Hello Aleksandrs,

        Quick update on this - the main error I receive repedtly now is the following - I have been unable to reproduce the initial error that I posted with this bug.

        preg_match(): Compilation failed: range out of order in character class at offset 11 [popup_httpstep.php:55 → check_fields() → check_field() → calc_exp() → calc_exp2() → eval() → preg_match() in /wawa_mnt1/apache_httpd/httpd-2.2.31/htdocs/zabbix/include/validate.inc.php(105) : eval()'d code:1]
        Incorrect value "Zabbix Homepage" for "Name" field.

        To answer your questions - This is a brand new install of Zabbix installed from source - 2.4.7. I have never been able to get this work and also have not upgraded or changed apache or php.
        Thanks!

        Show
        Brian Dougherty added a comment - Hello Aleksandrs, Quick update on this - the main error I receive repedtly now is the following - I have been unable to reproduce the initial error that I posted with this bug. preg_match(): Compilation failed: range out of order in character class at offset 11 [popup_httpstep.php:55 → check_fields() → check_field() → calc_exp() → calc_exp2() → eval() → preg_match() in /wawa_mnt1/apache_httpd/httpd-2.2.31/htdocs/zabbix/include/validate.inc.php(105) : eval()'d code:1] Incorrect value "Zabbix Homepage" for "Name" field. To answer your questions - This is a brand new install of Zabbix installed from source - 2.4.7. I have never been able to get this work and also have not upgraded or changed apache or php. Thanks!
        Hide
        Ivo Kurzemnieks added a comment - - edited

        Hello, Brian!

        I'm just curious what is the version of PCRE library? I doubt that the problem is due to old version, but still would be interesting to know since I could only reproduce the error with that regular expression on PHP 5.0.4 and PHP 5.0.5. And the PCRE library for those PHP versions is very, very old (4.5 01-December-2003). Also I'm, 99.99% positive that the same error might be also in tr_logform.php, because it uses same regular expression there. I cannot check if that's true, since Zabbix requires PHP >= 5.1.6 (for v2.0).

        Show
        Ivo Kurzemnieks added a comment - - edited Hello, Brian! I'm just curious what is the version of PCRE library? I doubt that the problem is due to old version, but still would be interesting to know since I could only reproduce the error with that regular expression on PHP 5.0.4 and PHP 5.0.5. And the PCRE library for those PHP versions is very, very old (4.5 01-December-2003). Also I'm, 99.99% positive that the same error might be also in tr_logform.php , because it uses same regular expression there. I cannot check if that's true, since Zabbix requires PHP >= 5.1.6 (for v2.0).
        Hide
        Brian Dougherty added a comment -

        Ivo,

        Here you go -

        PCRE version 7.8 2008-09-05
        Compiled with
        UTF-8 support
        Unicode properties support
        Newline sequence is LF
        \R matches all Unicode newlines
        Internal link size = 2
        POSIX malloc threshold = 10
        Default match limit = 10000000
        Default recursion depth limit = 10000000
        Match recursion uses stack

        Show
        Brian Dougherty added a comment - Ivo, Here you go - PCRE version 7.8 2008-09-05 Compiled with UTF-8 support Unicode properties support Newline sequence is LF \R matches all Unicode newlines Internal link size = 2 POSIX malloc threshold = 10 Default match limit = 10000000 Default recursion depth limit = 10000000 Match recursion uses stack
        Hide
        Ivo Kurzemnieks added a comment - - edited

        (1) Removed translation strings:

        • Scenario step name should contain only printable characters.

        Gunars Pujats CLOSED

        Show
        Ivo Kurzemnieks added a comment - - edited (1) Removed translation strings: Scenario step name should contain only printable characters. Gunars Pujats CLOSED
        Hide
        Ivo Kurzemnieks added a comment -

        RESOLVED in svn://svn.zabbix.com/branches/dev/ZBX-10316

        Show
        Ivo Kurzemnieks added a comment - RESOLVED in svn://svn.zabbix.com/branches/dev/ZBX-10316
        Hide
        Gunars Pujats (Inactive) added a comment -

        Successfully tested!

        Show
        Gunars Pujats (Inactive) added a comment - Successfully tested!
        Hide
        Ivo Kurzemnieks added a comment -

        Fixed in:

        • pre-2.0.17rc1 r59024
        • pre-2.2.12rc1 r59026
        • pre-3.0.2rc1 r59027
        • pre-3.1.0 (trunk) r59028
        Show
        Ivo Kurzemnieks added a comment - Fixed in: pre-2.0.17rc1 r59024 pre-2.2.12rc1 r59026 pre-3.0.2rc1 r59027 pre-3.1.0 (trunk) r59028
        Hide
        Ivo Kurzemnieks added a comment - - edited

        (2) API changelogs: 2.0, 2.2 and 3.0 updated. Please, review.

        Alexander Vladishev CLOSED

        Show
        Ivo Kurzemnieks added a comment - - edited (2) API changelogs: 2.0 , 2.2 and 3.0 updated. Please, review. Alexander Vladishev CLOSED

          People

          • Assignee:
            Unassigned
            Reporter:
            Brian Dougherty
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: