Simple Fixlet Not Relevant when it should be

Ok… so… I have a very simple custom Fixlet with 2 relevance clauses… Let’s call them R1 and R2.

Let’s call my test target T1.
Custom Site is Site1.

Site1 is subscribed to ALL Computers and T1 is verified as subscribed.
Using the QnA tool on T1, I can see that both R1 and R2 are TRUE.
In an analysis in Site1 I have matching properties for R1 and R2, as well as (R1) AND (R2) combined, all return TRUE.
Enter Fixlet1 which has the exact same R1 and R2 as relevance…

I see the client log showing it’s evaluating new content… but I never see it say Fixlet1 relevant or not relevant… And Fixlet1 never becomes relevant. A manual targeting of Fixlet1 at T1 says not relevant.

Both the server and client are at 9.2.5.130. No relay involved.

I tried copying Fixlet1 to Master action site… same thing.

Any thoughts???

Which is the relevance ?

That should be irrelevant. They both resolve to TRUE in QnA and in Analysis. Is there a situation where they would be true in one instance and not in the other?

R1:
Q: exists settings whose(name of it = “MaintenanceWindow_StartTime” AND exists value of it) of client
A: True
T: 0.040 ms

R2:
Q: not exists (unique values whose (it as lowercase = (regex “mw_win_\d(st|nd|rd|th)(sat|sun|mon|tue|wed|thu|fri)\d\d\d\d.*”)) of ((values of headers “subject” of relevant fixlets whose (value of header “X-Fixlet-Type” of it = “ComputerGroup”) of sites);(following texts of firsts “_Group_0” of names of settings whose (value of it = “True”) of client)))
A: True
T: 0.074 ms

What I would do is find the fixlet in your __besdata\actionsite folder of the client (actionsite if the fixlet is in the master action site, otherwise it may be somewhere else). If the Fixlet ID in the console is 9551 then the file will be called Fixlet 9551.fxf

The X-Relevant-When line in this file will be the result of how BigFix combines your relevance statements before running them.

Grab each X-Relevant-When: line from the .fxf file and run it through Fixlet Debugger and make sure it says true.

1 Like

I’ve seen problems where the clause may return plural results. Showing the “Type Information” from QnA is a little helpful here…it might show you that R1 or R2 gives a Plural Result. When the separate Relevance Clauses are merged together with a set of () AND () (as is done when put into a Fixlet or Action), the AND operation can’t deal with plurals and gives an error.

Example -

q: (true;true)
A: True
A: True
T: 0.041 ms
I: plural boolean

q: true
A: True
T: 0.032 ms
I: singular boolean

q: ((true;true)) AND (true)
E: class SingularExpressionRequired

You need to convert both clauses to a singular return value - which might be as simple as
Q: exist setting whose(name of it = "MaintenanceWindow_StartTime" AND exists value of it) of client
or as “correct” but easily misunderstood as
Q: exists true whose (exists settings whose(name of it = "MaintenanceWindow_StartTime" AND exists value of it) of client)

2 Likes

I have a PMR open right now about different results between QNA and the agent. What I would suggest is creating an analysis that tracks each component individually, and then one that does it all together.

Then you can start taking a look and get to the bottom of why it isn’t working.

Good thing you caught it early!

How are you evaluating this in QnA (or is it Fixlet Debugger) as “relevant fixlets” is a client only relevance so the “exists” and “whose” may be making this “True” for you but not on the client itself.

In this case, I believe exists <plural> will always return a singular result. It’s only when you do an iterator like this Q: (exists it) of ("test";"Test") that you end up with that situation.

For this in particular my favorite way of identifying this issue is by grabbing the X-Relevant-When lines from the raw fixlet file as that’s the exact relevance that the client is running.

Bill,

Confirmed that the X-Relevant-When: line is exactly as it appears in the fixlet and in the analysis. Copied and pasted directly to Fixlet Debugger (using local client evaluator) and resolves to True.

As noted previously, I also put both relevance statements into an analysis, and they both return true as well as a combined AND property… All are evaluated by the system in question and all return True.

So… so far:
X-Relevant-When - confirmed and returns True in Fixlet Debugger AND in analysis.
Analysis Test: Both return True

I decided to do make 2 copies of the fixlet and split the two relevance statements… My trouble maker is:

not exists (unique values whose (it as lowercase = (regex "mw_win_\d(st|nd|rd|th)_(sat|sun|mon|tue|wed|thu|fri)_\d\d\d\d.*")) of ((values of headers "subject" of relevant fixlets whose (value of header "X-Fixlet-Type" of it = "ComputerGroup") of sites);(following texts of firsts "__Group_0_" of names of settings whose (value of it = "True") of client)))

So… there’s something about that statement that returns True in Debugger and Analysis, but not in a fixlet…

And for grins, I did try

exists true whose (not exists (unique values whose (it as lowercase = (regex "mw_win_\d(st|nd|rd|th)_(sat|sun|mon|tue|wed|thu|fri)_\d\d\d\d.*")) of ((values of headers "subject" of relevant fixlets whose (value of header "X-Fixlet-Type" of it = "ComputerGroup") of sites);(following texts of firsts "__Group_0_" of names of settings whose (value of it = "True") of client))))

Still no go…

So… what’s different about the way a fixlet is evaluated versus an analysis?

@AlanM

It appears the root of the issue is with relevant fixlets of <site> I can get this to produce output in actionscript with appendfile and can get it to produce a true in fixlet debugger using client context but the client doesn’t appear to like it (9.5.3).

Left column is applicable computer count, right column is the relevance for the group.

Here is a .bes export with all of these groups. Groups for Testing.bes (3.9 KB)

site <string> and fixlets of <site> work just fine but relevant fixlets of site and relevance of <fixlet> do not appear to work in this case.

Are you saying you can do this with the client but you can’t do it with relevance?

Yes.

I can do the same piece of relevance in actionscript using:

appendfile {relevance}

But the same piece of relevance doesn’t work if I use it in the relevance part of the fixlet.

Bill

So… been doing some more testing on this… I also have a PMR open…

One thing I found interesting… The client on which I found this issue is at 9.2.5.130. I am able to reproduce in my lab which is at 9.5.2.56. BUT… My client has 2 stragglers that didn’t get upgraded and the clients are 9.0.649.0 and 9.0.835.0. On just those, the relevance works… So, something changed between 9.0 and 9.2 that broke this…

1 Like

So I have an analysis that does the following:

ids of relevant fixlets of site "http://sync.bigfix.com/cgi-bin/bfgather/bessupport"

This works for me fine (its an extension of the types of relevance you are using)

I somehow remember in the back of my mind using “relevant fixlets” in “relevance” for a fixlet doesn’t work as you can end up with a weird results… and yes I checked. You end up with an error if you use the fixlets or relevant fixlets iterators during relevance (to make a fixlet relevant) so this is 100% expected.

As someone who does a LOT of custom work in BigFix, I expect the client to be able to evaluate a relevance expression if that expression works in fixlet debugger and an analysis. Doesn’t make sense to me that what we’re seeing here is expected. Why would it evaluate true everywhere but in a fixlet? Why does it work in a 9.0 client?

There are several things that specifically relate to fixlet values that can’t be used in evaluating fixlet relevance.

There was a defect that was addressed in 9.1 where the expressions mentioned here would possibly work and possibly not depending on the state so it was corrected to the intent which is to not allow for X-Relevant-When type cases to evaluate this.

If you can think of this scenario you can see why this is disallowed. The fixlet is relevant when there are no fixlets relevant in the site but then its relevant so it is not relevant then it is relevant again… etc etc

This is why we can’t use it in this scenario.

The issue you address with FixletDebugger allowing it has to be understood that we have multiple ways of evaluating relevance.

  • X-Relevant-When relevance
  • ActionScript relevance
  • Property/Analysis relevance
  • Client API (Compliance) relevance
  • QnA relevance

Not all have the same results - but there is only a limited set that are different specifically this type of examination.

Thanks for staying on this, Alan! I appreciate the feedback even if it is bad news… :slight_smile:

FWIW, I also tried to use the same relevance in an automatic group… doesn’t work there either.

I guess I don’t understand the general underlying problem… Sure… relevant fixlets can change… so can a lot of things about a host. In this case just like any other, that’s why fixlets keep getting re-evaluated to see if the situation has changed… right? something changes and it’s not relevant… then something changes again and it’s relevant. Thats the whole idea, isn’t it?

And… if the client is going to puke on relevance because of some limitation, maybe a log entry saying something versus just evaluating false when it’s true? I rely on the fixlet debugger being accurate and then on analysis to back that up when coding relevance. Then when that fails, it’s to the client log I go… Would this have show up if the client were in debug mode?

So… I’m back to square one… I need a Fixlet to be relevant when a computer is in a group that matches a pattern… I do not want to hard code 20+ groups and have to remember to change the fixlet. And I don’t want to hard code 20+ groups to another group either. Same issue.

Seems there HAS to be a way in client relevance to get a list of groups?

The only workaround I can see right now is to make the fixlet a policy action to evaluate the groups in the action script then do an if/then/else. Ugly solution but should work if the tests above (works in action script) are true…

Let me know what you think…

Thanks!
-chad

For anything to be relevant it has to ALL result in a “True” answer so errors are considered not relevant. That happens in a lot of places, like when someone puts relevance that has no inspector on a specific platform.

For the issue you have I’m trying to see what the specifics that might help you are.

If you are talking about some groups do either of these help?

https://developer.bigfix.com/relevance/reference/site-group.html
https://developer.bigfix.com/relevance/reference/client.html#manual-group-of-client-manual-group

And by groups are you meaning automatic groups or manual groups? The client doesn’t know a lot about some groups which I think is why you are trying to get around this.

To extend on this. I have a “Group 6803.fxf” file in my actionsite. I can determine if I am a member of that automatic group by:

member of group 6803 of site "http://<servername>:52311/cgi-bin/bfgather.exe/actionsite"

Looks like the site group inspectors require the index of the group… So, same problem as hard coding the groups in any other way (fixlet, group groups).

I want to code my relevance based on a strict group naming convention… and make a fixlet relevant or not based on a computers group memberships or lack thereof by regex match of the name.

So… I really need an inspector that can return those memberships by name. If this doesn’t exist, then maybe it can in a future release… hint hint.

If there is no way to do this this in the more current versions of the client, then I guess I’ll be stuck with a parameter in action script with an if / then.

Curious: when it was removed in 9.1, what kind of actual issues were you seeing it cause?

Thanks again, Alan! I appreciate your time on this.
-chad