'execution in relevance'? - Missing `static routes` Inspector

I know you can’t run a command/action from within relevance, but I’m trying to find a fixlet/task (that I thought was in an external site) that I remember seeing as having some form of this in it. I can’t remember the specifics, but when I saw it, I thought to myself “well that’s useful”. I thought it was for a Linux/Unix OS and that it had something like " sh " in the relevance, and that the entire relevance statement was in turquoise text in the console.

I’ve done some searches in my console with no good results. Does anyone recall seeing such content?

I’m not currently aware of any functionality like this but you can achieve a similar result by using a fixlet to run a script, outputting the results to a file, and using relevance to read the results from the file.

1 Like

There definitely wouldn’t be any relevance evaluation that causes any shell scripts to be executed. Only the scenario that @strawgate suggested would be possible.

Relevance is read only and a shell script would not be posssible to do that.

2 Likes

If

…then this was probably just a comment in the relevance.

2 Likes

Yes, i agree, it sounds weird, but I just vaguely remember it. The text was in turquoise, not Green, so I don’t think it was commented out. All I remember was that there was a UNIX command in it like “grep” or “sh” or something.

Or maybe I’m just losing it…

What is the result you are hoping to achieve?

There may be a way to do it in relevance without running anything first. Or you might have to use the method that @strawgate mentioned.

There are a lot of things available through relevance by getting creative about reading things from the file system dynamically.

I was trying to find a way to pull back any configured static routes configured on an OS. In windows, WMI can provide it so that works within a property, but on Linux/Unix, it looks like the ‘ip route’ command needs to be executed to get the output I’m looking for.

You should be able to easily just create a fixlet that runs once per day that does something like

ip route > /tmp/routeinfo

And then create an analysis to read in that file.

lines of file "/tmp/routeinfo"

BigFix actually handles this scenario fairly well as this is exactly how BigFix Inventory works – with actions repeating as often as every 30 minutes and having their data read in via analyses

1 Like

Hi, yup, very familiar with the process and that what you posted above is the easist way to get the results, but I just like to have a single evaluation occuring then 1 task for execution + 1 analysis to read the results.

The BESClient can obviously read and “execute” (in a way) commands when it reads from a file/registry/dmi/etc, It would be nice for it to be able to call a command and return the results, all within an Analysis.

While you’re right that the client has this capability internally I believe the thought is that the cost of running user scripts as part of a relevance statement is too high from a CPU perspective to allow. @jgstew’s thoughts on relevance read-only-ness is probably the official reason

The BigFix agent is suppose to be a tiny little agent with minimal impact and having a script run on the system every 10-15 minutes is just asking for trouble.

System Center does this with Compliance Items and it’s normally a cluster especially on the Mac side

1 Like

This is not the reason. The reason is that Relevance is strictly ReadOnly. They cannot allow arbitrary scripts to be executed while also enforcing Relevance’s ReadOnly status.

They do care about the resource usage of the client in general, but that is not the primary concern when it comes to arbitrary execution.

Relevance inspectors use various APIs, System Calls, and other things to read info from the system. It is not quite the same as execution. The client has code that it runs to power inspectors, but it isn’t executing external scripts to do so generally.

The run a fixlet periodically and read the results with an analysis is basically a workaround for missing inspectors.

You are really asking for a new inspector to be created on the platforms where it is missing. This new inspector could potentially use the command line tools to get this info, but it would much more likely be implemented directly in the code using some sort of API.

Please file an RFE for this with enough details, but also include a link to this forum post in the RFE: How to ask for product help: PMRs, RFEs, and more

CC: @AlanM