just do a normal catalog and use the errata as include filters in the patching job ?
We created online catalog and using errata filter by adding errata we needed in the filters for RHEL 5, RHEL 6
it downloaded all the RPM's successfully.
Now we wanted to analyse only on SHELLSHOCK, ghosts etc?
What would be the best approach?
How frequently we should update catalog to get new data loaded based on errata releases?
I am thinking below two approaches:
1. Include RPM's at analysis job level related to shellshock ,ghost
2. At catalog log level , planning to create smart group and filter for shellshock and ghost
Why do you want to only include specific errata in your catalog ? why not include all errata and then use the include feature in the analysis job to filter down the check to only the errata you care about at that time ? otherwise you will be spending a lot of time manually fiddling w/ the filters in your catalog while cross-referencing the redhat site’s list of errata.
We are concerned about the space of the catalog download
one errata itself is downloading 1000's of rpms
, so we are including only one which is needed
What errata is downloading 1000s of rpms ?
Can you show a screenshot of your catalog config w/ the filters ?
Here's a screenshot of the catalog.
At a high level, while some system administration teams might wind up using a traditional redhat catalog and analysis and remediation jobs to actually patch systems, this configuration is a test to see how easily other teams like auditors and information security vulnerability management specialists, could use a catalog and only analysis jobs (with no potential to ever be used for remediation) essentially as a lightweight flavor of compliance check against systems to ensure that SOME rpm that fixes that particular errata is installed. This would relieve them of the burden of having to build actual component template + compliance jobs that look for a static list of acceptable rpms - which is easy to do quickly initially to get something in place, but if the RedHat erratas know which rpms fix the issue, in theory they should be able to leverage that.
ok - and the other filter also only includes a couple errata ? and you run the cuj and you are getting substantially more rpms than what's listed in the errata and are not just dependencies?
why not just use the errata as filters from an existing catalog? it seems like more work to setup a separate catalog rather than just a patching job w/ some filters.
Yes , we have added each filter with errata numbers
At patch analysis job level as attached, we have included errata number which we want to analyse the servers
But the results of analysis seems to be showing no vulnerabilities on the vulnerable servers
looks like we are missing a point, not sure where is the miss?
errata.png 106.7 K
ok, so where are the results from that run? and the job run log ?
Analysis didn't show required results and it completed successfully. Attached is the analysis log and here is sample message in log
Info 02/18/2015 11:16:00 Parsing analysis results for server: hostname
Info 02/18/2015 11:15:57 Analyzer execution complete on server: hostname, exitCode: 0
Info 02/18/2015 11:15:53 Starting analyzer execution on server: hostname
Info 02/18/2015 11:15:52 Copying analysis script to target: hostname
Info 02/18/2015 11:15:52 Copying repository metadata (repodata.tar.gz) from '//appserver/tech/bladelogic/patch/RedHat/catalog_2022900/RHES6x86_64/repodata.tar.gz' to '//lad1rmthd1001//var/tmp/stage/LinuxCatalog_2068001_lad1rmthd1001/repodata.tar.gz'
All servers shows
Missing RPM's as Zero , which is not correct at this point
errata.log.csv 35.3 K