LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Server
User Name
Password
Linux - Server This forum is for the discussion of Linux Software used in a server related context.

Notices


Reply
  Search this Thread
Old 12-04-2018, 11:01 PM   #1
bentech4u
Member
 
Registered: Feb 2009
Posts: 36

Rep: Reputation: 0
How to update RedHat or Centos without updating RedHat-release-server


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
 
Old 12-05-2018, 09:16 AM   #2
MensaWater
LQ Guru
 
Registered: May 2005
Location: Atlanta Georgia USA
Distribution: Redhat (RHEL), CentOS, Fedora, CoreOS, Debian, FreeBSD, HP-UX, Solaris, SCO
Posts: 7,544
Blog Entries: 15

Rep: Reputation: 1491Reputation: 1491Reputation: 1491Reputation: 1491Reputation: 1491Reputation: 1491Reputation: 1491Reputation: 1491Reputation: 1491Reputation: 1491
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.
 
Old 12-05-2018, 11:25 PM   #3
bentech4u
Member
 
Registered: Feb 2009
Posts: 36

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by MensaWater View Post
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.
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.
 
Old 12-06-2018, 10:35 AM   #4
scasey
Senior Member
 
Registered: Feb 2013
Location: Tucson, AZ, USA
Distribution: CentOS 7.5
Posts: 2,171

Rep: Reputation: 681Reputation: 681Reputation: 681Reputation: 681Reputation: 681Reputation: 681
Quote:
Originally Posted by bentech4u View Post
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.
 
Old 12-06-2018, 11:47 AM   #5
bentech4u
Member
 
Registered: Feb 2009
Posts: 36

Original Poster
Rep: Reputation: 0
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
 
Old 12-06-2018, 02:01 PM   #6
MensaWater
LQ Guru
 
Registered: May 2005
Location: Atlanta Georgia USA
Distribution: Redhat (RHEL), CentOS, Fedora, CoreOS, Debian, FreeBSD, HP-UX, Solaris, SCO
Posts: 7,544
Blog Entries: 15

Rep: Reputation: 1491Reputation: 1491Reputation: 1491Reputation: 1491Reputation: 1491Reputation: 1491Reputation: 1491Reputation: 1491Reputation: 1491Reputation: 1491
Quote:
Originally Posted by bentech4u View Post
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.
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.

Last edited by MensaWater; 12-06-2018 at 02:06 PM.
 
Old 12-09-2018, 04:10 PM   #7
voleg
Member
 
Registered: Oct 2013
Distribution: RedHat CentOS Fedora SuSE
Posts: 331

Rep: Reputation: 50
Just downgrade this package after whole upgrade. Harmless.

Added:
Just checked "yum ignore package" brings me:
Code:
# yum update --exclude=PACKAGENAME

Last edited by voleg; 12-09-2018 at 04:13 PM.
 
Old Yesterday, 05:38 AM   #8
bradvan
Member
 
Registered: Mar 2009
Posts: 309

Rep: Reputation: 59
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
RHEL latest Patch update without updating OS version Iyyappan Red Hat 8 01-03-2013 08:20 PM
Should I be updating my CentOS 4.6 server to CentOS 5.3? Ujjain Linux - Newbie 3 04-25-2009 09:00 AM
updating redhat server from CentOS repository bajones Linux - Newbie 4 04-23-2009 09:04 PM
Updating VMWare After Updating CentOS Linux31 Red Hat 2 09-18-2007 03:49 PM
dselect - how to update & install a package without updating all others? ryryur Linux - Newbie 2 01-19-2005 12:58 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Server

All times are GMT -5. The time now is 08:31 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration