will applying security errata through Satellite ever update the base release of the server?
My linux guru recommends applying the security errata periodically. Unfortunately, neither one of us know how to check whether this will involve so many prerequisites that the server is upgraded to the next release for RHEL 6. Is there a way to do it on the Satellite server or with yum on the target host?
Responses
Hello, I think this will help Understanding Red Hat Content Delivery Network Repositories and their usage with Satellite 6.
Setting a minor release, such as via subscription-manager release --set=6.7 isn't the panacea that it appears to be. Yes, it keeps your system locked into RHEL 6.7 + 6.7's errata. But it doesn't protect you against errata that are released after 6.8 ships. That is, if there is an errata that is released after 6.8 you will NOT have access to it. (Since you've locked your system into a 6.7 content stream.) This is compounded by the fact that you may not even know that this 6.8 errata is applicable, due to your system being locked into 6.7 content. This means that when the next nasty bug comes along, (DROWN, FLOOD, or whatever it is named), you'll have to change your release version anyway.
Let me ask, what is the reasoning for needing to stay on a minor release?
If you have a yum.conf exclude for redhat-release on the box the base will not be updated. However last time I checked this while applying errata, if a yum.conf exclude exists and one of the errata attempts to apply something that is excluded the job will just exit. I believe there was a feature request to correct this issue and allow the job to continue.
The short version is yes, installing security errata may update the base release of the server. Errata are released based upon the current version of the package in question. As such, if you have a system that is running RHEL 7.1 (for example), installing a security errata released after RHEL 7.2 is released (such as DROWN), will potentially include dependencies from RHEL 7.2.
If the desire is to stay on a particular minor release (for internal reasons or due to an ISV application), EUS might be an option for you. EUS is:
... an optional offering for Red Hat Enterprise Linux subscribers. With EUS, Red Hat commits to providing backports of Critical-impact security updates and urgent-priority bug fixes for minor releases of Red Hat Enterprise Linux, even for systems that are still one or two minor releases behind the current one. EUS enables customers to remain with the same minor release of Red Hat Enterprise Linux for up to approximately 24 months, allowing for extremely stable production environments for mission-critical applications.
EUS provides the guarantee that a system will not be updated to a newer minor release AND the ability to not be exposed as critical bugfix & security errata are backported.
I think Rich is basically correct. I've found that minor versions in RHEL are somewhat ambiguous. A minor release seems to essentially be a check point at which Red Hat bundles a collection of packages. There aren't necessarily any major functional changes to the system at that point. In fact it is likely possible to simply apply the latest version of the redhat-release-server package which will install the /etc/redhat-release file which will report to you that you are now on some new version of RHEL. However, you really aren't as you haven't installed all of the packages that are baselined with said minor version. In short, I wouldn't get hung up on what minor version you are on. Keep your packages up to date with security and bug fixes. If this happens to change the minor version of the system what's the difference?
From: https://access.redhat.com/solutions/401413
Minor Release
Installed on top of major releases to provide larger-scale point-release updates via Red Hat Network, after initial installation via traditional methods (PXE, DVD, etc.). More difficult to identify since the installation of packages between minor releases is supported. Red Hat does not require a system to be entirely composed of packages from a single minor release, but many regard the kernel version and the contents of /etc/redhat-release as two data points that assist in labeling a minor release without deeper introspection into additional userspace package updates. Others have stated that minor releases are just hundreds of errata published on the same day and labeled as a release for convenience. For example, a system may have the kernel installed from Red Hat Enterprise Linux 6.1, but user space packages installed from Red Hat Enterprise Linux 6.2. This would still be considered fully supported.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
