Admins Supporting Both RHEL And CentOS

Home » CentOS » Admins Supporting Both RHEL And CentOS
CentOS 18 Comments

With a few exceptions, I see most admins treat CentOS as a single rolling release and rely on the ABI commitment assuming things just work between point releases. On the other hand I see the opposite with RHEL where admins constrain installations to the point release.

What is the case with users on this list who support both?

Thanks, Joseph L. Casale

18 thoughts on - Admins Supporting Both RHEL And CentOS

  • I can’t really speak for anyone else, but for me, a lot depends on the use of the systems. I typically treat RHEL and CentOS the same way as far as updating to the latest point release. It’s never bit me in the past that I am aware of.

    The only exception to that is with the SGI Altix 4300/4400s I used to manage. We migrated from SLES to RHEL and in those cases, barring a serious enough bug, those boxes were left alone until time came to refresh them, such as the move from RHEL5 to RHEL6.

  • Note that RHEL is a special case as there’s some situations companies will pay out for the Extended Update Support (EUS)[0] in order to stay on a particular milestone for longer.

    In addition there is the slight bonus of access to beta of the next milestone or major release which may affect your workflow if you have a suitable test environment, and of course you’ll get the milestone quicker on release so that needs to be paid attention to for testing.

    Outside of this area the two can be, and should be, treated identically in terms of update policies.

    [0] https://access.redhat.com/support/policy/updates/errata

  • I personally run RHEL just like my CentOS installs, as a rolling release.

    If you want to get more input on this idea, you might want to also ask the Scientific Linux mailing list, since SL can be run in a ‘constrain to the point release’ mode with full security updates maintained, and you’re likely to get a broader response base as to why this is done.

  • And also note that Red Hat does not publicly release the SRPMs for their EUS packages. The CentOS Project therefore can not build those, so there is NO EUS in CentOS Linux. The only way to get Security updates in CentOS Linux is to be on the current (latest) point release.

    Also, since all updates are built against the current (latest) release as they are released, there is no way to get only security updates in CentOS Linux. You could TRY to only install security updates on your own .. however, since there are rebases during point releases, things that are built against the newer openssl will not work with older ssl’s OR things build against the newer gnome will not work with older gnome’s, etc.

    The only tested way to run CentOS Linux is with all the updates installed together.

  • Joseph L. Casale wrote:
    Only time we use CR is on *some* servers during the upgrade to a new subrelease. Otherwise, nope.

    mark

  • When I was a sysadmin for a living, I used CR in my test/staging area to see if everything worked. After I worked out all the kinks, I then either used CR on my production servers and/or waited until the actual point release, based on how close the release was going to be after I
    finished evaluating in testing/staging.

    In general, for CentOS Linux 6 and before .. CR takes 3 or 4 days and final release is usually 14 to 21 days.

    For CentOS Linux 7 (because of more rebases to newer versions that are much less conservative than EL6 and before) CR usually takes 10-14 days and final point release 35 to 42 days.

    So, the delta in both cases (from CR done to final point release) is 2
    to 4 weeks after CR rpms are released.

  • I treat them as rolling releases. Except for those I don’t. :-)

    Seriously, some of the RHEL-boxes we use, require a particular point release as well as not allowing any updates to the OS. At all. Yeah, I know… If updated, the instrument software will break, like in an atomic mushroom cloud, rendering critical hardware non-working and lab people standing outside my office with torches, pitch-forks and all the shebang. Yupp, unfortunately that’s the current state of some lab equipment manufacturers that use RHEL as a base…

  • Even Red Hat technically on RHEL doesn’t “support” only installing updates marked security as they always have an assumption all previous errata are applied.

  • Hi Joseph,

    I concur with the latter: I also often see RHEL installations where the admins assume they are running “RHEL 7.3” rather than “RHEL 7”. In some cases there isn’t even an upgrade mechanism in place: Systems are installed from ISO images (usually by the solution vendor) and there are no upgrades whatsoever until the system gets decommissioned.

    While that may seem a bit strange insofar as the upgrade mechanism with RHEL works quite the same as with CentOS by default (running updates regularly will make RHEL cross .x boundaries when they are reached), the different behaviour might come from three facts: 1. some vendors restrict their support to specific .x releases, 2. RHEL systems tend to run in production environments more often than CentOS systems, so they are subject to stricter rules regarding testing and clearance of updates, and 3. maintaining a RHN satellite or allowing internet access for RHN-registered systems is not part of the enterprise’s IT strategy (don’t laugh).

    I for my part treat RHEL and CentOS basically the same with respect to upgrades wherever possible: The test stages are quite near to the current bleeding-edge release (if that expression is not too far-fetched for an enterprise distribution), and after successful testing (usually a couple of weeks to a month, with the exception of security updates which are higher prioritised) they go into production.

    Cheers,

    Pete.

  • That is indeed correct and it is on every errata released from Red Hat:

    “Before installing an update, make sure all previously released errata relevant to the system have been applied.”

    Therefore the only real difference in recommendations is that EUS is available in RHEL packages.

  • No, it’s Varian/Agilent. A big player in lab instruments.

    Funny thing, just googled them and apparently they’ve opensoured the culprit software, and according to the below link, it’s not locked to a particular point release anymore!

    http://openvnmrj.org/Downloading/

    It does however still require the original software – which _is_ locked to a particular point release. Dammit’, so close!

  • Yes, our spectrometers that run VNMRJ are not allowed directly on the network. They are tucked away safely behind a NAT’d firewall with very few ports open and access is only allowed by proxy SSH from a few IP
    addresses (for some reason the users want to retrieve their data from it!). The extra cost of a firewall is nothing compared to the cost of the instrument.

    P.

  • particular to a

    Same setup here. It’s the SOP for these systems I guess. We were even able to find that specific consumer grade Zyxel router!

    We solved the user access to the spectra with a script that pulled in the data-folders from the instrument boxes via rsync to a Processing computer, to which they could connect with eg WinSCP, after first having plugged a hole in the firewall/router.

    For some reason the users don’t like going down three or four stairs to the basement to pick up the spectra on a usb-stick, then dumping it to their own computers and do a more detailed processing.