Installing errata on Satellite Server

Latest response

Satellite-maintain 'locks' packages to help prevent installation of new software on the Satellite server which might introduce problems, making Satellite a bit like an appliance. This includes installing errata. Our security department is dinging me about a few CVE's that are being detected on the server and I'd like to install errata indicated by the corresponding RHSA's.

Documentation for installing errata on the Satellite server is not very extensive. Basically it says to run 'satellite-maintain packages update', but this results in updating EVERYTHING and is accompanied by a big warning stating that this should only be done prior to upgrading Satellite to a newer version, so I'm not really sure that this should be the proper course of action.

I'm really just looking for the equivalent of 'yum update --advisory RHSA-yyyy:####'. What's the best way to handle this? I've been running the commands to unlock, update, lock followed by satellite-installer (and a reboot if a new kernel was installed):

#satellite-maintain packages unlock
#yum update --advisory RHSA-yyyy:####
#satellite-maintain packages lock

Is there a better, or more proper way?



Hi Rob,

Which version of Satellite are you using? Are you on a version of Satellite that allows loading Satellite on RHEL 8? Are you on RHEL 7.x?

Maybe you can't post the specifics of which errata you wish to update. However, as a beginning, perhaps you could just evaluate with yum dry-runs of the errata rpms to start with. What I mean here is to look at the specific RPM from a given errata and attempt to install THAT RPM from the errata. You can do just one RPM as an initial test and make sure it is not something like foreman/katello/satellite/pulp (some core satellite component) and evaluate that just to start with. The initial concern I have is that there may be other things such as foreman, katello that get updated, and the excludes I mention below may be a factor.

Please examine this however, do dry runs, and do not execute until you've done a thoughtful review. However, there is no guarantee the errata RHSA advisories do not include something for foreman/katello/satellite/pulp. So please evaluate carefully, see next paragraph.

On principle, please do open a case with Red Hat just in case your yum actions result in need of support from Red Hat. This is probably very worthwhile to just run by them anyway, please do this before proceeding!

Besides what's in the link in two paragraphs above, also, you could potentially use "exclude" statements with yum such as mentions, and exclude rpms for satellite/katello/pulp/foreman/etc itself. do dry runs of the yum update to evaluate the resultant of rpms to be updated, and consider echo n | yum update along with the thought-out excludes arguments. NOTE: the article above mentions this even with the use of RHEL 8 and above, so while dnf is a thing with RHEL 8 and above, this means yum and excludes still works if you happen to have a version of Satellite that happens to be on RHEL 8 (we do not know at this time).


That's an initial approach.

What version of Satellite are you using? What version of Red Hat Linux is underlying on that system? How many updates (like when was the last time you updated, a week, month, or while ago)?


I may misunderstand, but wouldn't just keeping the satellite server updated do the same?
Typically something like satellite-maintain upgrade run --target-version 6.11.z.

Hi RJ, thanks for your input.

I'm currently running Satellite 6.11.2 on a RHEL8.6 server. I've recently run the process I outlined above to resolve a few RHSA that were identified by our Security team; a review of the packages for each RHSA showed no components for any Satellite-specific functions. It was for rhel8-bind (rhsa-2022:6778). I've also recently done rhsa-2022:6457, RHSA-2022:6463 and RHSA-2022:6460. I do review the packages prior to installing.

How frequently are new .z versions of Satellite released? If it's frequent enough then simply upgrading Satellite itself is a viable solution, although I'm not super-crazy about the idea of installing an entirely new version of the software simply to keep the OS up-to-date (I usually don't install a new version of Satellite unless I'm having a Satellite-specific issue). However, if that's the 'right way' to do it then I guess it's something I'll have to do more frequently.

Hello, Satellite z-streams are released every 4-6 weeks, see the past Satellite Release Dates.