Differences From Upstream RHEL
At work, we use some commercial software, that names RHEL6 as a supported OS, but not CentOS6. I would like to know the difference between CentOS and RHEL, in order to claim (or not) that we can support our users on CentOS instead of RHEL.
I see the release notes, that say “Packages modified by CentOS,” but it’s not clear what the modifications are. I have been browsing around for these details, and have not yet found specifics of *what* was modified in those packages.
Can anyone please direct me toward details of what’s modified in the packages that CentOS modifies?
11 thoughts on - Differences From Upstream RHEL
Mainly branding changes, as well as other minor changes to make things work with the CentOS infrastructure, eg replacing redhat-release with CentOS-release to point to CentOS package repositories instead of the RedHat ones.
You can tell which packages were modified because they have the word
“CentOS” in the release number, eg: “rpm -q httpd” (use repoquery instead of rpm if you don’t have the package installed yet) shows this:
httpd-0:2.4.6-31.el7.CentOS.1.x86_64
You can see better details of what has been changed by looking at the changelog for a particular package. CentOS changes will be at the top of the changelog, so again using httpd as an example: – 2.4.6-31.el7.CentOS.1
$rpm -q –changelog httpd
* Mon Aug 24 2015 CentOS Sources
– Remove index.html, add CentOS-noindex.tar.gz
– change vstring
– change symlink for poweredby.png
– update welcome.conf with proper aliases
…
Note that it is possible for there to be changes that aren’t listed in the changelog, nobody’s perfect. If you want to know for sure exactly what has changed then look up the package on git.CentOS.org.
Peter
That depends on what you mean by “support.”
It’s almost certainly possible to run the binaries on CentOS, but if you need any technical support from the vendor of that application, they might not provide it. Your first step should be to talk to them directly and find out what level of support is available for CentOS.
Then decide whether or not that’s a deal breaker.
CentOS changes branding (in the source code) to comply with Red Hat’s trademark requirements.
In general we do not make changes to the base os other than those branding changes before we rebuild the source code. We also take out links to their Red Hat Network and instead do updates from our CentOS
Mirrors.
However, we build the source code in our closed build system on CentOS. Red Hat has their own closed build system that contains RHEL packages in which they build.
This means that CentOS is not ‘exactly’ the same as RHEL .. so, not a clone. It SHOULD be functionally equivalent (ie, same commands, same services).
CentOS also rebuilds the source code for updates that are released by Red Hat .. however we do not provide any ‘software assurance’ or guarantees for fitness of the software. We just rebuild the source code in the order it is released .. nothing more.
If you require commercial support from an entity that releases software certified to run on RHEL, you need to ask them if they support said software on CentOS. Regardless of if they support it .. CentOS provides NO guaranteed support of any kind. If you require Service Level Agreement type support (updates within a certain amount of time, bugs fixed, etc.) then that is what RHEL is for.
If CentOS works for you and you want to use it, that’s why we build it
.. but if you require some sort of assurance of fitness, especially some sort of guarantee of timeliness for response to bugs, etc .. then CentOS
might not be what you are looking for.
–The above answer is right-on. From a technical perspective, you can probably expect the 3rd party software to work exactly the same on RHEL and CentOS (barring some implausible edge cases), however your
3rd party vendor may refuse to support you at all if you’re using something that’s not on their supported platforms list.
That is assuming you’re using mostly base CentOS or only repositories that are known to not conflict with base. See the CentOS wiki for details.
If they sign off on it, get it in writing (or save and print off that email).
Even if they do, you should still be using a UAT environment to satisfy yourself and provide due diligence.
Devin
Thanks, this gives me a fair bit of work, but it’s as reasonable as I could possibly expect. That works. :-)
Thanks for the explanation. Of course what I want to do is evaluate CentOS fitness for our purposes, without the effort of evaluating all the changelogs, and I think this answer is the best possible way to approach that.
Hehehe, for what it’s worth, I encountered one of those edge cases a few years ago. Dell OMSA, at least in the days of CentOS 4, was distributed as a self-extracting binary, that would read the contents of /etc/redhat-release and compare it against a list of predefined strings, and then refused to operate. The workaround was to hack /etc/redhat-release.
But anyway. That’s pretty unusual. Thanks…
IBM do something similar with GPFS. You have to tell it you are using RHEL when you are on CentOS.
—–BEGIN PGP SIGNATURE—
In my experience software compiled for RHEL “just work” with CentOS and I
don’t remember any case where it didn’t. I have however heard whisperings on a grapevine that RH may want to try and make future versions of CentOS
slightly incompatible with RHEL but these are probably just whisperings.
If you software vendor will not support CentOS as RHEL then they probably need a good LARTing.
Unmitigated rumors. Until someone official says otherwise there is no case where CentOS will ever purposefully be made incompatible with RHEL. There are some very minor edge cases where it can happen incidentally due to:
1. Certain identifying information being changed from RedHat to CentOS such as the previously mentioned issues where software vendors explicitly check the redhat-release file and refuse to run if it says CentOS.
2. The build process for RedHat is not known and so it is highly unlikely that the CentOS build process replicates the RedHat one to the degree needed for full 100% compatibility.
That said, if you find any case where CentOS acts differently to RHEL
with the same packages (and versions) installed in both then please file a bug report with CentOS as as this would likely constitute a bug in CentOS and should be fixed if at all possible.
If it runs on RHEL it should run on CentOS as well. I would fault a software vendor who explicitly checks the redhat-release file to exclude CentOS from running, but I don’t fault them for not wanting to support their software on CentOS, that is a choice they make.
At the end of the day when you run proprietary software you are fully subject to the whims of the software vendor, I never understood how a commercial business would not only voluntarily put themselves into such a position but often times want to seek it out over the freedom that FOSS offers. Anyways, the vendor is also free to support whatever OS they want, and you’re free to choose not to use their software.
Peter
—–BEGIN PGP SIGNATURE—
Except when you’re not. Because for whatever reason, the choice of software you (the sysadmin) will support is determined by the users (engineers, financial people, whatever) who use the software. And the software vendors publicize which OSes are “supported” to run their software.
As mentioned previously in this thread, the software in question is Cadence EDA software, which I’ve supported many times on CentOS before, but they do all their development and testing on RHEL, SLES, Solaris, and a few other commercial OSes, so they cannot say they support CentOS. If you encounter any fringe incompatibility cases, because of running CentOS, it’s your responsibility. But they’re not intentionally manufacturing any such cases into their software.
I’m comfortable with this. Even staking my reputation on it. But I brought up the questions because I need to make other people comfortable with it too.
I got all the answers I need – Thanks everyone for your help.