create a smart group or include list that contains the list of specific rpms that you want to analyze for.
thanks for the quick replay bill.
so instead of analyzing against the repository analyze against the smart group and when remediating it will ignore the latest version in the repository and only patch to the version that is in the smart group ?
I believe that if the customer is more interested in going for a specific version and not the latest, They can even order the ISO format from Redhat and get it shiipped and via bladelogic you can use Patchdownloader uitlity to extract RPM package to a particular version that can be used later as a specific Patch catalog
The below link gives you the insight of it.
Bill , Correct me if i'm wrong..
Unfortunately this method does not work. Inspite of specifying a lower version of the RPM from the Patch Catalog in the approved list when remediating it remediates to the latest version in the patch catalog.
I have just emailed you the .doc file with the screenshots for each one of the steps and the results for the same.
Please let me know if you think there might be something wrong here but by the looks of it it remediates to the latest version and not the specific version.
Tanveer in that case the method I have suggested would work good..Check with the Unix team to provide you the ISO file of the version and follow the procedure asper the document link below..
thanks soundappan however we cannot use this method
1. multiple repositories with different versions of RPM's is not an acceptable solution to the customer since different versions of different packages reside across different repositories
2. every few weeks a different list is out so they cannot create a repository every time a list is out.
3. the Include List or SmartGroup option should work and has been confirmed by Bill as a possible defect in this scenario where it is not working, sp a hotfix may need to be requested from support.
Many of my Windows customers create a new Patch Catalog every month and freeze it. That way that have Patch Catalogs at different points in time. Would something like this work for RHEL patching?
Here in this case of Tanveer I believe that its something kind of a new environment and needs more attention via BSA for a particular patch level. The case where Joe mentioned is for existing setup.
Correct me if i'm wrong.
That is correct. My question was in regards to a long term patching strategy. With a new installation, you would still run into this issue.
What if the ISO contains an RPM called "program-1.01.rpm" and the latest version is "program-1.07.rpm" but the customer is approved to install "program-1.05.rpm"
If this RPM requires a lot of dependencies, what is the best way to handle a situation like that?