Today I learned of a relevance inspector that I had not noticed before.
It was introduced in 9.5.7 for most platforms but I never really noticed it until today when @AlanM mentioned it in our BigFix slack channel.
It seems most useful for three specific use cases.
What is the serial number of the machine, in a cross platform type of way. There are smbios and wmi and other methods for getting at this, which have been in use for a long time. I like that this method is a lot more straightforward and easy.
q: serial of hardware
A: PXXXXXXXX3
Is this a BigFix native agent or a plugin representation? This supports the newer Cloud correlation elements of BigFix which join up a real agent running in the OS with the information from the cloud hypervisor about the guest.
q: virtual of hardware
A: False
q: uuid of hardware
A: 4xxxxxxb-dxx0-bxx1-axxc-fxxxxxxxxxxx7
q: proxied of hardware
A: False
How does serial of hardware compare, speed-wise, to the BIOS/SMBIOS/WMI methods I wonder?
<wanders off to experiment/>
q: serial of hardware
A: XXXXXXXXXX
T: 11.308 ms
I: singular string
q: string values of selects "SerialNumber from Win32_BIOS" of wmi
A: XXXXXXXXXX
T: 11.167 ms
I: plural string
q: value "serial_number" of structure "system_information" of smbios
A: XXXXXXXXXX
T: 0.604 ms
I: singular smbios value
q: serial_number of system_information of dmi
A: XXXXXXXXXX
T: 0.194 ms
I: singular string
Maybe @AlanM can comment. If I had to hazard a guess, based on the timings it looks like it would try WMI and if WMI is not available fallback to the SMBIOS or DMA information.
Your time aligns with the WMI query time so itâs probably using that first.
DMA and SMBIOS queries are fast, because that info is cached on the client when the client starts up. But using the âhardwareâ inspector may allow for other data sources in the future (like Apple plist maybe?)
Yea, just FYI the inspectors are not working across the board and have room for improvements to be desired! I went through a very thorough exercise of comparing results of the two inspectors to the real-data and there are issues. For example:
inspectors donât work at all on s390x architecture although the inspector lists that it works on all Linux (tested it specifically on RHEL s390x)
On the different Solaris virtualization types - itâs complete mess! They did add some documentation around those and some of if makes sense but there are lapses there too
On AIX the data was wrong for the virtual machines
I have been trying to find a relevance expression that I can use in order to subscribe only the plugins representations that come from the new Cloud Amazon Plugin.
However I havenât been lucky as native agents are still being subscribed to the custom site(Along with the plugin representation).
My intention is to have only Amazon instances that donât have the BigFix agent subscribed to this custom site for reporting purposes.
I have used the following expression:
( if exists property "in plugin portal context" then ( in plugin portal context ) else false ) and ( data source = "Amazon Web Services" )
And also tried the hardware inspector without any luck:
proxied of hardware
Is there any relevance expression that evaluates true for Amazon instances that donât have a native agent on top of them?
I used the following structure for the custom property that I wrote (for portions of it I did use hardware inspector but did have to build myself a LOT of exceptions). I made it to return the Cloud Instance ID (regardless if AWS or Azure) for Proxy records.
if (if exists property âin proxy agent contextâ then ( not in proxy agent context ) else true) then (⌠custom code for all native records âŚ) else (instance id)