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

Also available in: Atom PDF