This is the right idea, but not correct for the file format, which was hard to tell in the forum post.
I agree with this idea. This might not be the right inspector for RHEL, but you could query this directly from a RHEL system in a few different ways. You can just return the list of services / processes running so that you can use that info for debug and analysis elsewhere, but you can also just directly look to see if things are missing on the system with relevance.
I’m being a bit pedantic, but just for the sake of vocabulary so we can be on the same page. Analyses have Properties, Properties have Relevance.
if exists (match (regex "NO") of is Relevance, which in this case is being used in a Property and the Property used Within an Analysis.
This part of the relevance is causing it to only check a single line of the file, not the whole file.
In general, I would recommend making many properties, not just what you want as the final result. Make properties which give you all the raw data, then create a property that filters that raw data to just the results you want (lines containing “NO” for instance) then write another property that turns that into a real result like “compliant” or “not compliant” so that it is easy to audit. The issue is if you try to build up all the logic at once in relevance, then it is impossible to tell what went wrong and where.
It sounds like what you ultimately want in the end is that if the file contains “>>” followed by “NO” anywhere in the file, then it should be considered non-compliant.
In that case, I would start with the results of:
lines containing ">>" of files "c:\_RHEL_GSD.txt"
Then look at:
(it as trimmed string) of following texts of firsts ">>" of lines containing ">>" of files "c:\_RHEL_GSD.txt"
(multiplicity of it, it) of unique values of (it as trimmed string) of following texts of firsts ">>" of lines containing ">>" of files "c:\_RHEL_GSD.txt"
not exists unique values whose(it contains "NO") of (it as trimmed string) of following texts of firsts ">>" of lines containing ">>" of files "c:\_RHEL_GSD.txt"
This should give you TRUE if compliant, and FALSE if not compliant. (you could reverse this just by removing the NOT in front)
Once this value returns what you want, then you can adapt it into returning words like “Compliant” or “Not-Compliant” instead of True/False, but you really need to build up to that and not start there.
::: ¡Very Important! :::
You should make sure your custom analysis properties are NOT set to “Every Report” and should instead be much less often. I would make most of them once every 6 hours or less often, and just one or two that you care about set to something like once an hour, but honestly, there isn’t a need to have the client run through the relevance that often in a day. When you are making changes to the analysis, all the clients should update all of the properties right away, it just when you are done, you don’t want clients aggressively evaluating properties that rarely ever change, as it will slow down the evaluation of all other properties and everything else the client does if you have too many over time evaluating too often.