How To Plan a Red Hat Transition: CentOS 7 EOL Migration

Braden Stringer:

Welcome everyone to today’s webinar. We’re really excited to be presenting today on preparing for CentOS Linux 7 end-of-life and transitioning to Red Hat. We’re really grateful for all of you who’ve decided to join us. We’re especially grateful to Rebecca for presenting.

I’m super pleased to introduce Rebecca to everyone. I love working with Rebecca. It’s the best. She’s so great. She has a ton of experience. She is our resident Red Hat expert, and we’re so excited to have her. So I’ll go ahead and turn it over to you, Rebecca, and we’ll get started.

Rebecca Horton:

Thank you. Thank you. A little bit about me and why I know about Red Hat. Back in, I would say probably around 2014 or 2015, I had been in the SAM (Software Asset Management) and licensing compliance industry for about, I guess I would say, 10 years already. I started hearing about open source and open source hygiene and what that meant.

I knew from working with SAM customers that whenever we would create a document like the policy document, it would always state something along the lines of “proprietary software vendors, blah, blah, blah, blah," everything except in-house developed open-source software. There was always that phrase in there, “except in-house open-source developed software."

I was kind of like, “Well, why, why, like, why is that excluded?" And then I started learning about the risks around open-source software and how it actually underpins so many vital systems that exist in the world, like banking systems, airline booking systems, all different kinds of travel finance, transportation systems, basically every website in the world has open-source components to it.

So, I really got interested in understanding more about open source, and then I went to work actually for Red Hat back in 2016. I worked as the EMEA (Europe, Middle East, and Africa) Director for their subscription education awareness program. And that’s why I learned a ton more about Red Hat specifically. What are the contractual rules, rights, grants, and restrictions?

I learned tons about the GPL and what open source is and what vendors like Red Hat are actually selling. Because the code is free, right? The open source is free. So what are they selling? I asked that probably for nine months before I started getting answers that I really connected with.

So what I love doing is talking about open source, talking about why it’s important, helping them to understand again what their contractual requirements are. Rules, rights, grants, and restrictions, and how they can leverage, just like with their proprietary vendors, the most value.

One of the common questions that I get is, what is open source? What is the community? And where does CentOS fit into all of this sort of community and all of that? The community is literally millions. It’s more than just a million. It’s millions of little projects that exist out in the cloud, out in the ether where people are developing code.

Now, for anybody that knows me, if you’re on this call, you’ve spoken to me at least once, I’ve probably mentioned I’m not technical. So for me, the way I think about open-source code is I liken it to when I was very young many moons ago, and I would play with Lego. And our Lego table had all of these bins of all the different shapes and colors and types of Lego pieces. That is the community. Okay, people are creating new Lego pieces, but they’re also taking Lego pieces and building them into different things.

You might build a car, you might build a house, you might build a plane, you might build a robot, you might build a rocket. So you can take those Lego pieces, you can take that code. And you can compile it into really whatever you want.

Now, what happens in the first layer, the first downstream or up, sorry, upstream layer of the community is where you then start having packaged open source. So that’s where we get things like CentOS and you get things like Atomic and FeedHenry and Fedora and Foreman and previously Ansible was part of that.

And then Red Hat bought them and turned it into an upstream product. So what we’re talking about in that sort of second layer, is pre-packaged, pre-compiled houses, rockets, cars, airplanes that you can go out and you can take advantage of.

Okay. Through the community through various distribution resources. Now, you can buy support for these products. Okay. Usually, they’re done by some business that has developed an expertise in Java or CentOS or Apache or whatever it might be.

And they say, okay, we’re going to support you in your technical journey using these pre-packaged, pre-compiled, pre-made Lego bits and pieces of open source. Then if we go one more level out, this is where you have organizations like Red Hat, also IBM Linux, Oracle Linux, Oracle Java Red Hat, JBoss. Ansible, Red Hat Ansible.

Now what you’ve got is you’ve got vendors who not only compile but also then sell their own support. So they’re doing their own compilation, they’re building their own versions of those cars and those robots and those rockets, and they’re also selling support wrapped around it.

So the big difference between what you’re getting in that first layer of compiled software and the second layer is access to support direct from the person who’s compiling it and B it’s typically going to be what we would call enterprise-ready, meaning it’s been hardened. It’s been tested. It’s secure, it’s safe, and it is ready for use in an enterprise environment.

So when we talk about and think about open source, what we need to remember is open source really is what is driving innovation in the IT industry right now. If you’ve heard of edge computing, if you’ve heard of AI, if you’ve heard of containers, those are all open source. Okay. And it is truly foundational to every organization’s transformation. As I mentioned, critical systems are built on open source.

And so when you think about the potential risks, as well as the importance of open source to an organization and its ability to operate and its ability to generate Revenue, it is genuinely foundational and quite often the biggest area where organizations are trying to transform is in those systems that are the closest to their customers.

So as far as risks and requirements for end of life, one of the big things with regards to products like CentOS going end of life is going to be vulnerabilities.

What we often see happen is when open source reaches its end-of-life, there’s a significant spike in threat vulnerabilities being leveraged by various nefarious individuals. They know that something is now end-of-life. They know that there will be no more patches, bug fixes, or security updates. So they will dig deep into that code and look for every potential vulnerability they can find. And that then becomes the new hot target for open source code.

Keeping in mind, 60 percent of all security attacks are actually targeted at open source technology. And I think we all remember a few years ago, about 5 or 6 now, there was a significant data breach in a financial organization that was targeted at open source. So it’s something to really consider.

So even if you don’t know what’s happening with your plans around CentOS or really any of your open source management practices, a great place to start is just asking questions, especially of the security team and also the DevOps team. How are we going to start managing this new risk? It’s just a great conversation starter and can lead to many different other conversations, but ultimately it’s about building a plan and making sure that you mitigate the risk.

So, CentOS end-of-life: In January 2014, Red Hat, I guess you could say, took over the CentOS project. The ownership of the CentOS trademarks was transferred to Red Hat, so you could say they bought it. Alright.

In December of 2020, the CentOS project, which is really Red Hat, announced that the distribution would be discontinued at the end of 2021 to focus on CentOS Stream. So, December 2021, CentOS 8 reached end-of-life, and in June 2024, CentOS 7 will reach end-of-life. So those are the dates that we’re currently aiming for right now.

The actual date is June 30th, 2024. So as of June 30th, there will be no more patches, bug fixes, or security updates released by CentOS, the CentOS project, AKA Red Hat. So what does that mean? That means you’re going to need to do something about it.

Also, on this date, June 30th, coincidentally, if you believe in those types of things, Red Hat Enterprise Linux 7 is going to reach the end of regular support. Okay. And I’ll talk a little bit more about what’s the difference between regular support and extended support, ELS (Extended Life Support), those kinds of things.

But if you’re on Red Hat Enterprise Linux 7 and you need to continue to access those patches and fixes, they will only be available if you have a subscription for ELS. Okay, there will be no new product development on Red Hat Enterprise Linux 7. So there’s no, I guess you could say upgrades. It’s just patches and fixes.

They will continue to do upgrades on version 8, version 9, and version 10 whenever it’s coming out. Usually, we see Red Hat has about three versions that are, I guess, full support, you could say, at any given time. So I suspect that we will soon see version 10 coming out.

So if you’re on CentOS 7 and you want to keep getting support, Red Hat is one of the ways, as I mentioned, that you can get support, and you can get phone support as well as access to ongoing patches and fixes. The cool thing is, because CentOS is the downstream version of Red Hat Enterprise Linux 7, it’s really easy to migrate, relatively speaking.

Again, I’m not technical. What we see most often is organizations will actually have heavy use of CentOS in their test dev environment. The reason being is because it is virtually exactly the same as the Red Hat version of that product. Okay, so if you’re developing on Red Hat Enterprise Linux 7, you can essentially put RHEL into your sandbox environment, and you can put your applications that you’re building on top of it or whatever you were doing with that instance of RHEL and do some, I would say, brief testing in your sandbox or pre-prod and then move it very quickly into prod.

Okay. So if you’ve got, for example, an environment that is currently CentOS 7, you’re going to migrate it to RHEL 7. Which, like I said, is relatively easy to do. You can take a look at that environment and go, okay, I’ve got 80 percent of what I’m moving to RHEL 7 is actually tested, and it’s for, of that 80 percent, 50 percent is for critical systems. 50 percent is for non-critical systems.

You could say, I’m going to take that 50 percent that’s for my critical systems in my test dev environment and just have ELS on that. Because those are the systems that I need to get my patches, my bug fixes, my updates on. Anything that’s in prod, same thing. Is it a critical system? Do I have to get those patches, updates, sorry, not updates, patches and fixes, the security fixes? And that question is individual to every organization. There’s no easy answer. And quite often what it ties back to is what are your business operational rules? And in particular, what are your governance rules?

A little bit more about how long the ELS is going to be available for. So you can see ELS for version six retires on the same day that, sorry, version 7 starts. So again, not a coincidence. So if you are receiving or have received an email with regards to this, all the dates are, you can still go to the Red Hat Errata system and take a look at all of these dates.

Now, the interesting thing with ELS is it doesn’t have to follow the all-or-nothing rule, but what it does do is, they have to backdate it if you add it after the fact. Okay. So let’s say, hypothetically speaking, you move a bunch of stuff to RHEL 7. You decide not to get the ELS. You’re like, “Yeah, no, I’m good."

Let’s say six months from now, you go, “Ooh, shoot, there’s a really big security patch that I need access to, big threat has been discovered. I got to get that." Red Hat has a subscription model. Most subscriptions will start on the day that you purchase or distribute that software, but because ELS will have previously released patches and fixes and they are quite often iterative, meaning you have to build onto them, you can’t skip a release.

They will ask you to backdate that ELS right back to June 30th, 2024. Okay. So it is something to keep in mind. Do expect that if you do make a decision not to buy ELS, whether it’s for 7 or in the future 8 or any of the other versions, that is a bit of a gotcha that you might get caught up on.

As far as Discovery goes, there are lots of different ways that you can get a handle on, what do I have out there? And this is for CentOS, this is for RHEL, so Red Hat, this is for SUSE, right? This is a sort of a graphic that we use with our customers to talk to them about what I call the quality, completeness, and coverage of your Discovery data.

Okay, manual reporting where you phone someone up and go, “Hey, Bob, how many RHEL do you have deployed?" And he goes in and he looks something up. It’s horrible. It’s painful. And quite often it’s inaccurate. And it times out, right? Meaning, By the time you’re done calling everybody, you’ve got to start all over again because the first person you talked to was a year ago, and it’s probably all changed.

So manual reporting, not ideal.

The next opportunity is around having a CMDB or some sort of automated discovery tools. CMDBs can be great. They can also be challenging in that they don’t always discover the right things that need to be discovered. You can get a lot of CIs created as opposed to being able to identify what is the Red Hat or CentOS bundle of products. You’ll find all of its individual components, but not necessarily be able to compile that into a product for the purposes of tracking management and whatnot.

Better options would be if you’re using Satellite in some way, then that’s a great way to manage those distributions and help identify and discover those. The best way is a tool called Red Hat Discovery. This is a free discovery tool. If you own a single subscription of Red Hat Enterprise Linux, you have free access to this. Or Ansible, which is another Red Hat technology.

As far as managing patches, updates, fixes, the full life cycle is broken into three phases. When you move from ELS, you then get into EUS, which is Extended Update Support. It does not follow the all-or-nothing rule, but you have to be careful when you’re applying patches, fixes, and updates that you get from Red Hat to make sure that you’re not applying it to other areas that are not Red Hat instances, like SUSE Linux or your Oracle Linux products.

When you’re migrating your subscriptions, it is important to consider the following four areas: What is a subscription? What do you need? Okay. What support levels should be used? What are the rules, rights, grants, and restrictions, and how do you optimize those? So essentially, a subscription is access to the Red Hat pre-packaged software and support that could be phone support, could be 24/7, could be 9/5. And then it’s also support through their website. Okay, you get a couple of other benefits and things, but the main value is going to be the access to the software pre-packaged and pre-compiled by Red Hat.

And that support that you will get, there are various support options. Again, it’s going to depend really on what is the level of support that you and your business operational rules require. So I mentioned their standard support. There’s premium standard is nine by five premium is 24 by seven. There is a self-support option, but that is a very limited use case. Be very careful about buying that because you can get offside really fast with that.

A little gotcha to remember is that typically support does not follow the sun. So if you buy subscriptions in North America and distribute them in Europe or APAC, you need to be very careful because if you’re just buying standard support 9×5, they’re going to measure you on standard support 9×5 in North America where it was deployed, unless you have a really long argument with them.

When you’re migrating to Red Hat, there’s the all-or-nothing rule. They do have the right to review or audit. Okay, that’s the group that I used to run, Subscription Education and Awareness. We educated people on how to manage their subscriptions, but if and where necessary, we also did reviews. They have done a lot of growth in that area.

As far as goals around backdating IBM, in my opinion, sorry, in my opinion, this is an IBM influence that is coming through. And it’s important to really take a look and make sure that you’re optimizing your Red Hat environment. If you’re using it in the cloud, there are lots of considerations to take there. You want to make sure that you create an effective entitlement report or position, you want to have an effective license, or in this case, subscription position.

So that’s comparing what you’re entitled to your actual consumption. And then you want to try to look for opportunities to optimize that. Where can you use dev instead of prod? Where can you use the high-density virtualization versus the sort of typical and standard subscription rights?

So I think that is it. Thanks, guys, for staying late. Glad you were able to attend. If you do have any questions, please do feel free to reach out to me. You can connect with me on LinkedIn. You can also reach Anglepoint at info at anglepoint.com. And if you have something to talk about, just put in there that you’d like to talk to Rebecca, or the Red Hat team and we’ll make sure we get connected. So thank you, everybody, again. And I think that’s it.