CentOS Dilemma

Dec 12, 2020 | 8 minutes read

Authors: Luke Rawlins

Tags: CentOS

I should state right off the bat that everything you are about to read is just an opinion. I don’t have any insider information I didn’t reach out to anyone at Red Hat for comment, because there is already a ton of stuff online and I’m sure you can find it if you are looking. This also isn’t a post about CentOS Stream, I don’t really know anything about CentOS Stream as I’ve never used it, and I don’t have much interest in it at the moment. Instead this post is about taking a brief and honest look at what I think is the dilemma caused by the news that CentOS has shifted focus.

Red Hatters across the board have made their opinions known on Twitter, Reddit, Blogs etc. Their thoughts seem to range from toe the company line, to it’s not as bad as it sounds.

In my reading I particularly thought Scott McCarty gave the subject a fair treatment. Sort of a balance between toe the line and everything is going to be okay.

CentOS 8 was released in September of 2019 it was expected to be EOL (End of Life) sometime in 2029, as of December 8 of this year (2020) that timeline has been moved to December of 2021.

Ten years is a long time to support an OS, and some of the arguments have suggested that it’s an unreasonably long time to support an OS. That’s fair - 10 years is a long time to go without major upgrades… but no one forced Red Hat to commit to that timeline. CentOS 8 could’ve been released with a shorter life commitment, or as other have said, they could’ve just waited till CentOS 9. In any event I can’t help but wonder what changed over the last 15 months that caused this sudden change of plan. To make matters even worse anyone who upgraded from CentOS 7 to CentOS 8 is now in a weird position where they have an OS with a shorter life than the one they just upgraded from. What do you do then? Roll back if you can? Move on to an entirely new Distro? Convert to RHEL? A lot of possiblities to unpack in a year - especially after you thought you had already settled these issues.

This sudden change of plan is really what strikes me the most about the CentOS decision. It’s obvious that this couldn’t have been in the works for a long time, because if it was why was CentOS 8 ever projected to have such a long life in the first place? I don’t have an answer to this question - but I think Red Hat should’ve taken more caution around this subject because it really does speak to either a certain indecisiveness around CentOS, or a lack of respect for the people who have grown to depend on it and overcoming this impression will be an uphill battle. Especially in an open source community that, if we are honest, tends to be a bit extreme when it comes to corporate involvement in Linux.

Regarding the last bit about extremism in the open source world.

Red Hat doesn’t have to be evil, and CentOS Stream doesn’t have to be some unstable beta quality garbage for you to be angry about this decision. It’s enough that they shortened the life by 8 years and replaced it with something that while probably good enough for some, is not really comparable. If you were a CentOS 8 user maybe start testing Stream to see if fits your needs, or start using something else. More on that a little later - but if Red Hat gambled on expanding RHEL at the cost of CentOS and users flee to something with more regular release cycles and a long track record of long term support, then that is part of the risk they took with this decision and will have to live with it.

I just want to point out that contrary to popular opinion you can disagree with someone without demonizing them.

I agree that the untimely death of CentOS 8 Linux is a stain on the credibility of Red Hat, but I also know that Red Hat as a business has to make the best decisions it can for both itself and at least in theory for its paying customers.

Which brings me to my next point.

In my humble opinion you are taking an enormous risk by entrusting your valuable business infrastructure to a strictly community based project.

  1. CentOS has historically trailed Red Hat and Oracle (another Red Hat clone) in patching security issues by weeks and even months. That is something I can’t live with.
  2. A “project” is not a business, it doesn’t have customers, it doesn’t offer support outside of forums which to be honest is often a hard place to get any information, let alone good information.
  3. I don’t care how good you and your team are - unless you are Google or Facebook you are going to need support somewhere down the line and the risk of taking that all in-house is a bad decision.

The cost of doing business often includes software licensing, and subscriptions. Part of being a responsible steward of your resources sometimes involves paying for stuff, and on the occasion when you can get something for free don’t let yourself get too hooked on it.

I might get a lot of flack for this next statement but I believe it’s true.

CentOS is free and that is its primary (and probably only) selling point. If you took a gamble on a free project and got burned I’m sorry, I really am, but if you are looking for someone to blame - either go down to your finance office and say “I told you so”, or go look in a mirror because those are the only two possible points of blame that I see. After that start evaluating whatever OS you plan to migrate to. I would suggest something that has people who’s feet you can hold to the fire if they don’t deliver on their promises, but that’s just me.

Having said all that I (paradoxically) would love to see RHEL go the free to play but pay to win route. i.e. Drop the subscription fee’s for RHEL and RHEL repositories, and sell services and support. Satellite is a great product that is worth the cost, hell even the Red Hat knowledge base is good enough to pay a subscription to gain access. Ubuntu has had a lot of success with this model and I think if Red Hat is removing CentOS as it traditionally existed they should replace it with RHEL offered for free if for no other reason than to stop the bleeding that will result as people move on to other distributions.

This is something that I’m guilty of as well. As a prototypical lazy sysadmin I don’t want to support more systems than I have to, and I don’t want to support a plethora of Operating Systems. Having said that it’s also clear that I may be making a mistake by placing all my trust in Red Hat’s commitments. The more I reflect on it the more I focus on something I’ve heard at several conferences hosted by Red Hat over the last few years. I’ve heard this formulated a few different ways, but it’s generally something to this effect “Red Hat doesn’t want to be just the Linux company, we are a cloud company.” As a sysadmin who focuses mostly with On-Prem stuff I don’t care about your cloud offerings. I care about Linux and that’s it. Containery, cloudy thingys are mysterious and scary I just want a solid OS that will run your cloudy containery thingys.

On that note I plan to start evaluating Ubuntu for use in the area’s that I can afford to have a little flexibility in the stack (I’ll argue for a support contract as well - so don’t send me hate mail about hypocrisy).

  1. They have long term support. 5 years on the LTS and you can pay for more if you have a group that is resistant to change.
  2. Say what you want about Canonical they have a track record for regular releases that are on time, well built, and supported as promised.
  3. It has a huge selection of packages often newer than what is found in Red Hat releases.
  4. I use what I know - I know RHEL systems better than Ubuntu, but I know Ubuntu well enough to get started. And outside of a few critical systems that must be on RHEL for application support issues, Ubuntu is likely just fine for many other common use cases.
  5. It’s the most commonly requested alternative Linux OS - in my experience anyway.

I don’t know how to conclude this except to say if you feel burned by Red Hat I sympathize with that feeling and I know it’s going to add a ton of work to your life in the very near future. I think it was a bad decision on their part. I also think trusting a community project is a bad business decision and I can’t be too empathetic as I wouldn’t make that decision myself (though I don’t often have the political will or power to stand up to those decisions myself).

If you are evaluating new OS’s or starting the conversion to CentOS Stream I wish you the best of luck.

Related Posts


Linux Server won’t restart

Not too long ago I ran into a problem where a server with systemd would not shutdown or reboot through normal means. When executing sudo shutdown -r now I would get a weird message back as output: Failed to start reboot.target: Connection timed out See system logs and 'systemctl status reboot.target' for details. Failed to open /dev/initctl: No such device or address Failed to talk to init daemon. I’m still not entirely certain what caused the problem and the suggestion of running systemctl status reboot. Read more

RPM package queries

This post is just a quick walk-through of some basic commands to help you find information about rpm packages. These commands will work for any rpm based distribution (Red Hat, Centos, Suse, Mageia). Debian based distributions like Ubuntu or Mint use dpkg instead of rpm and I’ll cover those in a different post. Query the rpm database You can query the rpm database to find a particular installed package using the -q option. Read more

Command not found!

So you’re running through some instructions to configure software on your system, or troubleshoot some problem with a service and you see an error at the command line that says “command not found”. Here is how to locate the packages you need to install in order to use commands that are not available on your system. CentOS/Red Hat - yum provides Yum is an excellent package manager with lots of great built in functions. Read more


Contact

If you’d like to get in touch, contact with me via email.

editor@sudoedit.com