I have an analysis that is supposed to return the version of the bash package installed on my linux endpoints. It works on most systems, but on others, it returns in the results tab of the analysis. The text of the relevance clause is as follows:
if name of operating system does not contain “Ubuntu” then (if exists (package “bash” of rpm as string) then (version of package “bash” of rpm as string) else “Not Installed”) else if name of operating system contains “Ubuntu” then (if exists (package “bash” of debianpackage as string) then (version of package “bash” of debianpackage as string) else “Not Installed”) else “N/A”
I’m not seeing why it’s not working on some systems where on others, it works fine. Is there any logging of analysis activities when its active? Is there a better way to get what I’m looking for?
I just copied/pasted the above relevance string into the qna utility, and it comes back with the expected results, so I don’t think there’s a problem with the clause itself. However, the in the console, the results tab for this analysis still shows for multiple systems.
You can mouse hover over the text for a more specific error message.
If you are able, run the relevance statement on the specific systems that report the error in local client evaluation mode, which should be identical to what the actual client is doing.
“Singular expression refers to a non-unique object” and “The expression could not be evaluated for an unknown reason” is what I get when I hover over them. Running the statement locally on the affected systems seems to work fine.
if name of operating system does not contain “Ubuntu” then (if exists (package “bash” of rpm as string) then (versions of packages “bash” of rpm as string) else “Not Installed”) else if name of operating system contains “Ubuntu” then (if exists (package “bash” of debianpackage as string) then (versions of packages “bash” of debianpackage as string) else “Not Installed”) else “N/A”
Turns out, there was nothing wrong with my relevance code after all (although adding the plural seems to give better results.) The problem was resolved by restaring the besclient service on the affected endpoints. Not sure why that helped, but it did. All of the results in the analysis went away completely.
Thanks for reporting back your findings. It does seem a bit odd, but I have seen some cases where errors were cleared by sending a refresh to the clients. It would make sense that restarting the service could have a similar effect in some cases.