Creating a BigFix relevance for AWS EC2 instances.

Hi,

I am in the process of creating a BigFix task with the following relevance, but it is not working:

(version of client >= “6.0.0.0”) AND (exists true whose (if true then (member of group NUMBER_ID_GOES_HERE of site “actionsite”) else false)) AND ((ids of it, names of it) of bes computers whose (value of result from (bes property “Agent Installed”) of it as string as lowercase = “false” AND (not correlation flag of it and agent type of it starts with “Proxy”)))

However, I checked the relevance in BigFix QNA portal, and it worked.

(ids of it, names of it) of bes computers whose (value of result from (bes property “Agent Installed”) of it as string as lowercase = “false” AND (not correlation flag of it and agent type of it starts with “Proxy”))

Did anyone run into this issue?
My end goal is to be able to automatically install the BESClient on AWS EC2 instances that does not have the BESClient installed.

Thank you in advance,

What you are confusing here is “session relevance” and “client relevance” - they look similar but are meant to be evaluated by different components of BigFix. “Session relevance” is evaluated by Web Reports/Explorer only; “Client relevance” for the client to evaluate. “bes computers” is session relevance and that can’t be a part of fixlet/task/computer group/etc which are all evaluated by the clients; member of group of site “actionsite” is client relevance.

To achieve what you are after, I suggest look-up for example the default property “Agent Type” and copy its relevance as that is what records can evaluate to read what kind of record it is, and that instead of “bes computers”.

1 Like

Here a reference for relevance language: https://developer.bigfix.com/relevance/

2 Likes

Are you trying to install the agent from the console or using the BigFix Rest API?
There is already a Fixlet(ID 5433) that BigFix provides to install the agent on AWS EC2 instances. It is not perfect because the Fixlet’s relevance is not capable of detecting the device correlation so it is more a manual work to select the ones that you know don’t have the agent installed.

For that reason we use the BigFix REST to retrieve the list of devices that don’t have a correlation in place(Meaning they don’t have the agent installed and making sure the AWS Account data is being pulled by the BigFix AWS Plugin).
This list can be retrieved by the following Session Relevance:

ids of applicable computers whose ((not correlation flag of it and agent type of it starts with "Proxy")) of bes fixlets whose(id of it = 5433)

Once you retrieve the list of instances, you can push a static action using the out of the box Fixlet or a custom fixlet as the action’s source.

1 Like

Hi all,
Thank you for the clarification.
I am trying to create a client relevance. The following is kind of my thinking for the relevance.

(version of client >= "6.0.0.0") AND (exists true whose (if true then (member of group **NUMBER_ID_GOES_HERE** of site "actionsite") else false)) AND (exists true whose (if true then (exists "Agent Installed" whose (it as string as lowercase = "false") AND not exist "correlation flag") else false))

Thank you,

Again, this is session relevance. Client is not even aware what “correlation” is and the fact there are record types; what properties exist and so on.

That said, I am not even sure if your goal is achievable at all - we don’t use “agent install” mechanism but if memory serves me right, it is only available via WebUI and not sure whether these sort of actions support “policy” at all. Second of all you need relevance that is not even considered “client relevance” - only the one that is evaluated by plugin server. The relevance would look something like:
(in proxy agent context) AND exists data source whose (it contains “Amazon”) and third - again, this needs to be in site subscribed to proxy records and not entirely sure whether you will be able to set-up open policies. Even if possible though, this only targets all AWS proxy records, it won’t know if agent is installed or not as proxy record is not aware of the agent and vice-versa…

For something like this you do need external automation where you use session relevance to pull all bes computers of type proxy that do not have correlation and then submit those sort of actions against the identified machines via RestAPI like @fermt suggested.

2 Likes