Supersedes errata

Is there a way we can enable supersedes errata ?

I have created a custom base line one month back and applied to my non-production environment. After a month I need to apply the same custom base line to production servers. But one of the errata on the custom baseline (1 month Old) is superseded and it has a latest version.

In my case I need to keep the same version of non-production errata in prod environment . is there a way we can retrieve and use the same non-prod errata

Please advise. Thanks,

Could some one please advise. thanks

You could use an “Offline Repo” with the RHSMPlugin or CentOSPlugin. Just be sure to keep innsync between your fixlets and the download repo.

Search for “RHSMPlugin offline” and you should be able to find it.

Are these two separate BigFix environments? How about exporting the baseline from non-production, and importing into your prod environment?

1 Like

@Aram

Thanks for the response.

No, this is a single BigFix environment and both non-prod, prod sit in a single custom site.
We use a single custom baseline for all non-prod and prod servers.
Baseline will apply in non-prod servers first then within a two-week gap same baseline will apply in production server, that case some of the fixlet applied in a non-prod are superseded and not able to roll them out to production since their action is marked.

I can use the latest errata for the superseded fixlet but that creates a package version mismatch in the non-prod and production servers. Not able to maintain the consistence across environments.

@JasonWalker

Thanks for the response.
could you please confirm, do we need to maintain a local additional repository to manage the offline repo or BigFix has a offline repo that can be used via this plugin ?

You would not need a custom repo, rather the cache optiins of the CentOSR2DownloadPlugin itself. See https://www.ibm.com/support/knowledgecenter/en/SS6MER_9.5.0/com.ibm.bigfix.patch.doc/Patch/Patch_CentOS/c_advanced_config_plugin_centos_r2.html and the link beneath it for airgap.
As Aram states above, the easiest way to handle it is to “freeze” your baselines in time, or copy the baseline from one environment to another. Whether to use the offline cache iption depends on how sensitive the environment is to change, and how much effort and skill you’ll be putting in to the download cache management.

Freezing the Baselines will leave the systems patching up to the same level of target packages. The issue I had encountered with that, is that sometimes the dependencies for an RPM get updated in the repo, so I might get a different dependency package even when issuing the same baseline at a later date.

@JasonWalker thanks for the update.

Trying to understand does the baseline export and import are we referring as “freeze”. I couldn’t see any option to freeze a base line.
Please find the snippet where it shows one of the fixlet in the base line is superseded and the action for this fixlet is marked as “false” so even if we export and import it to prod environment the fixlet still is unavailable to deploy.
I am sorry I have limited exposure to BigFix maybe I am completely wrong!
Please advise. Thanks.

@JasonWalker could you please advice, thanks.

It’s pretty much as I said before…as long as you don’t ‘Sync components’, the copy of the fixlet that’s in the baseline doesn’t change. The source fixlet can change, become superseded, have ‘FALSE’ added to it’s relevance, but the instance in the Baseline doesn’t change.

The only real risk is that the downloads that the fixlet requires can be removed, so you need to be sure you have copies of the rpms cached already.