Unix Compliance Patch Report

[Manish]

Hello All,

We are doing patching of RHEL using Custom Repository Management.
Now concern here is how we can generate the report which can talk about how many patches was deployed on the servers and how many patches are pending for respective months.

Regards,
Manish Singh

[Shahban]

I am also looking for the same report for my environment, any help will be appreciated.

Regards,
Shaban

[JasonWalker]

Are you subscribed to the normal patching sites so that relevant/non-relevant patches are reported? Those are the basis for compliance reports, doesn’t really matter how the patches get installed.

[Aram]

I would agree that reporting on Patch Compliance should be done based on Fixlet applicability. Aside from being able to report on your current Patch Compliance (available through a number of means), I would also recommend having a look at the Patch Reports for BigFix Compliance (see the following for reference):

https://www.ibm.com/developerworks/community/blogs/a1a33778-88b7-452a-9133-c955812f8910/entry/Availability_of_BigFix_Compliance_Analytics_1_10?lang=en

https://www.ibm.com/support/knowledgecenter/en/SS6MCG_9.5.0/com.ibm.bigfix.compliance.doc/Compliance/SCA_Users_Guide/c_reporting_patch.html

[Manish]

But the think here is bigfix does not support ltss and those pathces are not visible in bigfix console and even for rhel patches are not segregated based on minor update.
Then it would be difficult to result the accurate compliance or result for that particular month.
Hence was looking for some customise report which could help to understand or give proper visibility for the unix environment.

[jgstew]

You could have a bigfix action that periodically triggers a package manager (yum) command to report (but not install) what packages have updates available and output that to a text file, then pull that back with BigFix.

I have content to do this with Windows Update in the case of windows machines, but it is not hard to do the same with package managers.

BigFix patching content is the best way to report on the content that is covered, but everything else can be done through a periodic action and report.

[JasonWalker]

Related to this, we are considering where we can expand the Linux/UNIX content coverage and are exploring what repos or products we can cover. If you can reply here and tag me @JasonWalker, I’ll be sure to add it to our list for prioritization. The more specific the better, if you can list repo names that helps.