Project

General

Profile

Actions

Bug #7758

closed

When several directives value have a CFEngine var, we get "unexpected" due to bad regex matching

Added by François ARMAND about 8 years ago. Updated about 8 years ago.

Status:
Released
Priority:
1
Category:
Web - Compliance & node report
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

Description

The problem happen when we have several values with a CFEngine variable in them, and that the pattern of the variables are alike. In that case, we match received report against these pattern at random, which may fail.

A concret example to understand:

- directive file edit on file:
1. /tmp/foo.${some_var}
2. /tmp/foo.backup.${some_other_var}

- receved reports:
a. /tmp/foo.txt
b. /tmp/foo.backup.txt

Now, if we match a. with 1. and b. with 2., everything is OK.
On the other hand, if we match b. with 1. , it will be OK BUT matching a. with 2. will obviously fail.

The real good solution is to add a unique identifier to each report to uniquely match one report value into an expected one. That can't be done without modification in CFEngine.

As a workaround, we could try to take into account the lenght of the prefix, starting with prefix of greater lenght. That won't help for pathological case like:
- directive edit file:
1. /tmp${sys.fstab} (where sys.fstab is typically "/etc/fstab")
2. /tmp/${sys.arch}/${sys.hostname}

But it will help in the first example. And I don't think that with that method, we are likelly to reject case that were accepted before.


Related issues 2 (0 open2 closed)

Related to Rudder - Bug #7855: When using a ${rudder.node.hostname} value in a component, the compliance level is always UnexpectedRejectedFrançois ARMANDActions
Related to Rudder - Bug #12719: Some reports are duplicated between agent and postgres leading to "unexpected" compliance ReleasedFrançois ARMANDActions
Actions #1

Updated by François ARMAND about 8 years ago

  • Target version changed from 2.11.18 to 3.0.13

The bug seems to be 3.0 and up specific, as the logic used to match reports against values (with or without parameter) was not the same in 2.11 and does not seem to be problematic.

Actions #2

Updated by François ARMAND about 8 years ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from François ARMAND to Nicolas CHARLES
  • Pull Request set to https://github.com/Normation/rudder/pull/1033
Actions #3

Updated by François ARMAND about 8 years ago

  • Status changed from Pending technical review to Pending release
  • % Done changed from 0 to 100
Actions #4

Updated by Vincent MEMBRÉ about 8 years ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 3.0.13, 3.1.6 and 3.2.0 which were released today.

Actions #5

Updated by Nicolas CHARLES about 8 years ago

  • Related to Bug #7855: When using a ${rudder.node.hostname} value in a component, the compliance level is always Unexpected added
Actions #6

Updated by François ARMAND almost 6 years ago

  • Related to Bug #12599: Rudder agent 4.3 needs libxml-treepp-perl on debian added
Actions #7

Updated by François ARMAND almost 6 years ago

  • Related to deleted (Bug #12599: Rudder agent 4.3 needs libxml-treepp-perl on debian)
Actions #8

Updated by François ARMAND almost 6 years ago

  • Related to Bug #12719: Some reports are duplicated between agent and postgres leading to "unexpected" compliance added
Actions

Also available in: Atom PDF