BigFix LABs, Cache Management Dashboard malfunction after installing Cloud plugins

To the attention of BigFix Developers,

We would like to share with you our most recent experience with Multicloud plugins available in BigFix v10 - Managing your cloud environment? BigFix 10 has a solution!

Last week we managed to install the vSphere and AWS plugins on our environment running BigFix v10 patch 1 (10.0.1). When a cloud plugin is installed, the correlation feature for computers discovered by that plugin is automatically activated. The correlation computer is a logical entity, and the BigFix Console shows it as an expandable object in the Computers view. The root element of the object represents the correlation computer itself and has its own Computer ID. The ID of the correlation computer is created at correlation time and typically falls in a range higher than the IDs of the single representations. Correlated representations are shown slightly indented when expanding the correlation computer.

Here is the detailed explanation for the Computer correlation: Computer Correlation

What was the problem after installing the plugins.

We are usually managing BigFix Relay cache on a weekly basis by using the BigFix Labs, Cache Management Dashboard. The Dashboard itself is working based on the following Analyses ID 8, BES Relay Cache under the BigFix Labs site. This analysis returns information about relay cache status, and about the files that are in the cache. This analysis must be activated in order to use the Cache Management dashboard.

It appears that after the installation of Plugins and Computer correlation the Cache content management stop working.

This is an error alert that was popping up whenever you try yo select any of the Relay Servers:

“11/25/2020 04:22:05.095 [ERROR] ComponentLibrary.js
BFEvaluateRelevance Error: Singular expression refers to nonexistent object.
onSuccess: (function() {functionToBind.apply(objToBindTo,arguments);})…
relevance: values of results(bes computer whose (id of it = -533423351), property 1 of fixlet 8 of bes site whose (name of it starts with “BigFix Labs”))”

Basically, the cached content is not able to be evaluated as it is trying to query not only the Native agent but Proxied as well.

To get rid of this situation we had to uninstall the plugin and then manually delete correlated representations related to our Relay Servers including the BES Root Server as well so they can appear as standalone computers.

Applying this workaround the Cache Management Dashboard started working again!

Of course, we raised and PMR to HCL, however, they were not able to help us as this is out of their scope, referring to the disclaimer displayed on top of the BigFix Labs sheet:

"BigFix Labs

BigFix Labs contains add-ons, prototypes, and other interesting extensions we have made to the Bigfix platform and applications.
BigFix Labs contains various projects and information provided “as is” by multiple authors.
BigFix Labs projects are not supported by IBM Support.
However, you are welcome to post questions/issues/requests on developerWorks Forum for BigFix Labs.
BigFix Labs projects are NOT put through extensive QA, so you should test extensively and use the projects cautiously in a production environment."

With all this, we would like to request further development of the Multicloud services so they are fully compatible with Cache Management which is one of the core features for keeping the Relay infrastructure in a healthy state - especially BigFix Root Server.

Thanks in advance for taking this into consideration.

Best regards,
Tsvetan Petrov (Subject Matter Expert)

1 Like

This might be fixed by excluding the cloud plugin proxy agent from the content, potentially just by excluding it from the entire site.

Try adding the following to the site subscription criteria:

if exists property "in proxy agent context" then ( NOT in proxy agent context ) else TRUE

This should allow the native agent to subscribe to the site but NOT the proxy agent for the same device. It is probably best to do this for ALL traditional bigfix sites that do not contain content meant for plugin proxy agents, including all existing custom sites. You should create new custom sites specifically for plugin proxy agent content and have the opposite relevance that would ONLY include devices that are in fact plugin proxy agents.

Like:

if exists property "in proxy agent context" then ( in proxy agent context ) else FALSE

You should NOT need to do this in most cases. It is usually better to increase the size of the Relay caches and let the BigFix relays handle this automatically. The only reason to do this is to speed up patch delivery during narrow patch windows with slow links between relays, and even then, it is generally not needed if everything is working correctly and you have test machines behind the same relays that you have already patched ahead of the production roll out.

There CAN be good reasons to do this in a specific set of circumstances, but generally over use of this dashboard is a sign of a different problem.

I would look at the relay health dashboard to see if your relay caches are rolling over too often and need larger caches.

2 Likes

Thanks for the reply JG. We will take a look at implementing that and let you know.

We do have an n-tier relay architecture with child relays on slow links. However, those we don’t have to actively manage. It’s the parent relays and root server where we actively manage the cache as they don’t seem to clear out old content on their own and eventually are unable to accept new content when the cache fills up.

On a related note, there is a bug in the correlation wherein ad-hoc computer groups don’t form correctly and many devices get dropped. This has caused some havoc in our compliance reporting automation but I am told there is a fix in the works in v10.0.2.