HI

How to update RedHat or Centos without updating RedHat-release-server

my current release is 7.5 and the new release is 7.6, i want to apply updates as security and bug fix. But bugfix update info is showing release server 7.6 also.

The reason i want to exclude the release-server because as per application document it supports only on RedHat 7.5

Already application has some issue, so i don't want to point this update case

7.5 and 7.6 are "minor" updates of RHEL7 (and CentOS7). If your app runs on 7.5 it will run on 7.6. Vendors seldom update documents to show the new releases.

Updating all other packages without updating the release version is pointless as the release version just tells it what release it is - it is all the other packages that are updated that allow the release version to be updated - not vice versa.

On occasion there are package updates that might break things (e.g. Java) but for most of those RHEL/CentOS allows you to have multiple versions installed and set "alternatives" to specify the one used by default.

On rarer occasion some software will actually check for the release before they'll run but in such cases the logic is usually fairly simple and you can fake them out by updating /etc/issue and/or /etc/redhat-release. The only time I've had to do that was for Oracle app or DB installs and even then it was the major version (e.g. Tell it is RHEL5 even though it is RHEL6) rather than the minor update version.

The way RHEL (and therefore CentOS and other derivatives) work is they give you a specific upstream version of a package within their major release. In minor releases they give you the same upstream version but backport bug and security fixes from later upstream versions into that. When you see a package the first part of it tells you the upstream version it was based on and the next part shows you the RHEL extended version so you can determine what bug and security fixes are in it if you are interested.

1 members found this post helpful.

As you know Oracle is checking redhat-release.

if the documentation is saying " we support up to 7.5". suppose i updated release to 7.6, if any issue comes while opening a support case, they will simply wash their hands saying your release is updated, we cannot support properly. In this stage i need to find escalation methods and other stuff to go further, that will take time.

Sounds like you need to talk to Oracle if you’re concerned. As long as you’re paying them, I seriously doubt they’d “wash their hands” of anything.
I agree with MensaWater...it’s unlikley to be a problem.

1 members found this post helpful.

NOt Oracle, even it's bigger than that and they are customizing the software based on our needs and the team which came for that don't have any idea what they are doing, simply following documentation

As with the prior poster and my original post the differences between 7.6 and 7.5 are typically bug and security fixes. If they say they support 7.5 they'd be unlikely to tell you they won't support 7.6. They would, however, be very likely to tell you they don't support 8.0 as that would be the next "major" release so is going to be different from 7.x.

(8.0 beta is now available by the way.)

If you have some sort of configuration that Oracle has "certified" specifically for you then you can't even update individual packages without asking them but it doesn't sound as if that is the case.

If you have a Dev/Test/Staging environment you could try to do the full update there and verify everything still works properly before moving into Prod.

Alternatively rather than just running "yum update" to get the latest of all packages you can do "yum update <package>" on specific packages if there is one you feel a later update of the package will address issues.
e.g. yum update gnutls.

Note that the yum update as I mentioned only gets you the latest RedHat extended versions. If you're running a package named billybob.2.0.5-126.7 and desire to go to upstream billybob.4.0.1 the "yum update" won't do that. It will instead take you to something like billybob.2.0.5-132.3 where the 2.0.5 is the upstream version and the 126.7 and the 132.3 are the RHEL extended versions. To get billybob.4.0.1 you'd either have to find where someone else has packaged that into an rpm (e.g. Fedora EPEL has multiple packages not included in RHEL that can be installed in your RHEL or CentOS system but RedHat wouldn't support those packages even though they run.) or find the source and compile your own (which also wouldn't be supported by RedHat). Replacing the RedHat vetted upstream version with something else can cause unanticipated problems because RedHat verifies the mix of packages it uses work together. Replacing python with a later upstream version for example might break many of the administrative .py commands provided by RedHat. Sometimes you can install alongside and use the separate version for specific things (e.g. Oracle typically installs the Java they want as part of their installation rather than relying on the OS' installed Java.)

If you're really paranoid you could switch from RHEL7 to OEL7 since the latter is Oracle's fork of RHEL7 and is supported directly by Oracle rather than RedHat. You'd of course have to pay Oracle for OEL.

P.S. The first Oracle RAC install we did here years ago was done by a consultant sent by Dell/Oracle for a specific configurations. Their documentation for how to do the install was quite instructive on many things I didn't know but also said to do things in a way that knowledgeable System Admins knew could be done more easily in other ways. The consultant was distraught every time I did things the way I knew they could be done rather than following the exact commands in the document. He was always surprised when what I did worked. That by the way was the last time we used a consultant to do such an install. In all later installs we just figured it out from Oracle's online documentation.

1 members found this post helpful.

Just downgrade this package after whole upgrade. Harmless.

Added:
Just checked "yum ignore package" brings me:

I agree with what the others have said, but especially want to point out if it is that critical, you definitely should have a test environment where you could run the updates and then check if everything is working correctly before doing it in production.

Have you looked at this solution from RHEL:
https://access.redhat.com/solutions/10021

1 members found this post helpful.