Sqlite inspector: read-only databases?

What are you using this relevant fixlet info for? There might be a better option.

It sounds like you just need to run an action to populate a SQLite DB with this info, then read it back using an Analysis property using the SQLite relevance inspectors.

If the data you want is already in a SQLite db, then you just need to use the relevance inspectors to read it.

I have to take an action on workstations that evaluate TRUE a match (an intersection) between all relevant fixlets in Patch for Windows site and a list of fixlet ids.

This might be better done externally using the REST API to query using Session Relevance which computers should have this happen to them, and use the REST API to deploy.

What is the relevance you are using to determine which fixlets the client is relevant to?

Yes but I have thousands of workstations that could be relevant

Right… so the rest api lets you deal with that automatically. You should be able to deploy what you need to all of the machines that it should go to with a single action.

I feel like I am missing some of what you are trying to accomplish and why you are using the relevance or non relevance of fixlets on a computer to do it.

Also, it would help if you shared as much documentation that you have looked at that was relevant and helpful and why, but also whatever relevance approaches you have tried client side to get what you want, or at least explain it in much more detail so that I / Others can help with the best approach using either method to get what you want.

Have you looked at this:

http://bigfix.me/analysis/details/2994555

Related:

http://bigfix.me/relevance/details/2997224
http://bigfix.me/relevance/details/2998854
http://bigfix.me/relevance/details/2999556


I am working on something like this now.

http://bigfix.me/relevance/details/3002406

I’m looking to create session relevance to return all fixlets in the Patches for Windows site that should be deployed to clients and then automatically put that into a baseline and deploy it. I then plan to do something similar for 3rd party software patching.

jgstew,

In my environment we used the REST API with something like this…
fixlets whose (source severity of it as lowercase contains “$$Severity$$” and name of it does not contain “(Superseded)” and size of (applicable computer set of it) > 5 and category of it contains “Security Update” and script of default action of it does not contain “MANUAL_BES_CACHING_REQUIRED”) of bes sites whose (name of it contains “$$CustomSite$$”)"

The program would swap out $$Severity$$ and $$CustomSite$$ with the severity and custom site we wanted a baseline for. Because it was generic this allowed us to use it with the external sites as well as our internal sites.

This would then generate different baselines with each severity level for each custom site.

The way I ended up doing it took a lot of code, I couldn’t figure out another way to do it so I had to pull all the relevance and actionscript out of every fixlet to generate the baselines but it works!

1 Like

Thanks, thats helpful and definitely what I am looking to do in general.

Like I said, I’m taking a crack at it, so I’ll see if I come up with anything better as far as building the baseline itself. I think baselines require a copy of the actionscript/relevance of the fixlet so that they don’t change over time. This isn’t true of normal actions because you can use “SourcedFixletAction” which just includes a pointer to the origin fixlet instead of a copy of all of the code.

I’m planning to include fixlets in the Patches for Windows site that are newer than X days, plus those with at least X relevant computers. The idea is that if it is a new patch, you could have sleeping machines that haven’t reported in their relevance to those fixlets yet.

Hi
The solution jgstew is working on uses collected applicability data to evaluate which fixlets should be casted as actions to a specific number of machines.
Glbproject’s approach on the other hand, is to have the clients do the relevance evaluation locally: This would make things easier, avoiding a mailboxed action that targets thousands of machines individually, which could get problematic in very large environments, but poses the problem that the “relevant fixlet” inspector, by design, is unrealiable in such scenarios.
…so the question here seems to be if there’s a way to avoid such inspector shortcomings.

Using the sqlite inspector seemed a good idea, but we found it is not… can we think of a workaround? :smile:

My approach is to make baseline(s) that target all machines that should be patched, containing all patches that are relevant or very new. This means that machines with 0 relevant patches would still get targeted by the baseline, but they would not run it.

Well, in our environment (we have this translates in several thousands machines spending a huge share of their time evaluating patches (IBM’s repacks of Microsoft patches often have relevances in the order of 40kb, several hundred lines of code EACH) and I find this approach very inefficient.

We’re developing a strategy where the baselines (better: multiple action groups) run in a dedicated site, and the machines subscribe say, once a month, to that site, run the relevant actions, and then unsubscribe. This way all the machines evaluate the baseline, but only once or twice a month, and not constantly.

So are you seeing long evaluation loops on your clients? Are you resistant to increasing the workidle setting a bit?

So the clients won’t subscribe to patches for windows at all, just this separate site periodically?

I wonder if there is a good way to only have a baseline action evaluated periodically by just putting something in the beginning relevance that would cause it to evaluate to false, halting further evaluation, but then evaluate to true periodically which would cause evaluation to continue without the need to pop in and out of subscribing to a site, which seems messy. You could definitely do this with an action that tags them if it has been a while and another action that removes the tag, but this seems similar to what you are doing.

You can have the client only do eval loops on a periodic bases using the following setting:

_BESClient_Resource_PowerSaveEnable

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Endpoint%20Manager/page/Configuration%20Settings

Seems like this is what you are looking for as far as building a baseline component XML out of a set of fixlets:

http://bigfix.me/relevance/details/3002440

Session Relevance: (incomplete)

concatenations "%0a" of ("<BaselineComponent Name=%22" & item 0 of it & "%22 IncludeInRelevance=%22" & item 1 of it & "%22 SourceSiteURL=%22" & item 2 of it & "%22 SourceID=%22" & item 3 of it & "%22 ActionName=%22" & item 4 of it & "%22><ActionScript MIMEType=%22" & item 5 of it & "%22>" & item 6 of it & "</ActionScript><SuccessCriteria Option=%22" & item 7 of it & "%22>" & item 8 of it & "</SuccessCriteria><Relevance>" & item 9 of it & "</Relevance></BaselineComponent>") of (name of it, (it as string as lowercase) of (not success on run to completion of default action of it), url of site of it, (it as string) of id of it, content id of default action of it, script type of default action of it, ("<![CDATA[" & it & "]]>") of script of default action of it, (if (success on custom relevance of it) then "CustomRelevance" else if (success on original relevance of it) then "OriginalRelevance" else if (success on run to completion of it) then "RunToCompletion" else "") of default action of it, (if (not success on custom relevance of it) then "" else ("<![CDATA[" & it & "]]>") of (custom success relevance of it)) of default action of it, ("<![CDATA[" & it & "]]>") of relevance of it) of fixlets whose(name of it contains "Windows" AND name of it does not contain "(Superseded)" AND name of it as lowercase contains "endpoint manager" AND name of it as lowercase contains "client" AND globally visible flag of it) of bes sites whose("BES Support" = name of it)

Escaped Session Relevance: (works with curl)

"concatenations %22%22 of (%22<BaselineComponent Name=%2522%22 & ( concatenation %22and%22 of substrings separated by %22%26%22 of item 0 of it) & %22%2522 IncludeInRelevance=%2522%22 & item 1 of it & %22%2522 SourceSiteURL=%2522%22 & item 2 of it & %22%2522 SourceID=%2522%22 & item 3 of it & %22%2522 ActionName=%2522%22 & item 4 of it & %22%2522><ActionScript MIMEType=%2522%22 & item 5 of it & %22%2522>%22 & item 6 of it & %22</ActionScript><SuccessCriteria Option=%2522%22 & item 7 of it & %22%2522>%22 & item 8 of it & %22</SuccessCriteria><Relevance>%22 & item 9 of it & %22</Relevance></BaselineComponent>%22) of (name of it, (it as string as lowercase) of (not success on run to completion of default action of it), url of site of it, (it as string) of id of it, content id of default action of it, script type of default action of it, (%22<![CDATA[%22 & it & %22%5d%5d>%22) of script of default action of it, (if (success on custom relevance of it) then %22CustomRelevance%22 else if (success on original relevance of it) then %22OriginalRelevance%22 else if (success on run to completion of it) then %22RunToCompletion%22 else %22%22) of default action of it, (if (not success on custom relevance of it) then %22%22 else (%22<![CDATA[%22 & it & %22%5d%5d>%22) of (custom success relevance of it)) of default action of it, (%22<![CDATA[%22 & it & %22%5d%5d>%22) of relevance of it) of fixlets whose(name of it does not contain %22(Superseded)%22 AND name of it as lowercase contains %22endpoint manager%22 AND name of it as lowercase contains %22client%22 AND globally visible flag of it) of bes sites whose(%22BES Support%22 = name of it)"

Maybe…

  1. Create large baselines with a years worth of patches
  2. Add a task to each yearly baseline that always evaluates to true and set the post-action of the baseline so that it sets a client setting for example: OSPatch2015 = 1 on {now}
  3. Add baseline applicability relevance for if (OSPatch2015 = 0 or date of setting OSPatch2015 > 3 months ago)

Then the baseline will only evaluate if the baseline has not evaluated before or if it was more than 3 months ago and because of the task we added when it is 3 months past, the baseline relevance will be true and then it will evaluate the component relevance and update the OSPatch2015 setting.

Or maybe we should just put in an RFE for an analysis style, “Evaluate only every…”

1 Like

Oops, sorry for the late reply, I had issues with my account (and my posts being flagged as spam) and have been able to log back just a yesterday.

From my experience, it does not matter how early you do that:
false & [long relevance here]
does not perform any faster than
[long relevance] & false
due to the client evaluating all of the relevance clauses.

This is especially true for superseded fixlets: one of the first relevances is false (since they’re not useful anymore) yet they are taking very long evaluation times on our clients (a shame)

This is incorrect, order of relevance DOES matter.

Faster:

false AND [long relevance]

Faster:

true OR [long relevance]
1 Like

Hi
You’re right: I re-did my tests and truly,
false & [long relevance]
is indeed faster than
[long relevance]

Now I’m wondering… my findings were (I think) true some time ago, when we were running Bigfix 8.2… now we are on 9.2 and I can confirm the above…
someone still on 8.x can make a similar test?

Thanks!

You could probably do the test in the 8.2 Fixlet Debugger and see.

I started using BigFix around version 8.1 I believe, and I was always under the impression that this was true.

I have posts about (session) relevance optimization here: