New CentOS Linux 8 Features and Updates
The CentOS 8 release is here. In this blog, we recap key CentOS 8 features and what the CentOS 8 update means for you.
10 Year Reign of CentOS Linux 8 Begins
The new CentOS 8 release brought several changes many people have questions about. This blog will cover the new CentOS 8 features and updates. Since Red Hat Enterprise Linux (RHEL) is the upstream for CentOS, CentOS follows the same life cycle that RHEL dictates. This means that CentOS 6 will reach End-of-Life (EoL) at the end of Nov 2020 and CentOS 7 will reach EoL at the end of June 2024. The RHEL ten-year life cycle makes CentOS 8, which released in 2019, the current release until 2029.
The terms “RHEL” and “CentOS” are pretty much interchangeable throughout the rest of this article. They can even be called Enterprise Linux to refer to both, or EL.
Major Changes with CentOS 8
The new CentOS 8 has provided major changes within a kernel update, repository structure, python, cockpit, RAM, and much more. Below are more details on each change and what those changes mean.
Some of the major changes that I’ve noted regarding CentOS 8 include a kernel update from 3.10.0 to 4.18.0, “replacement” of Software Collections with Modularity, deprecation of several packages, DNF software management, and a web-based management interface included by default.
DNF, which is actually YUMv4, is a newer version of YUMv3 that ships with CentOS 7. Since DNF is simply an evolution of yum, most of the commands are backwards compatible, making the switch to DNF no big deal!
One of the requirements that triggered the YUM->DNF change is the “replacement” of Software Collections with Modularity. You’ll note that I put “replacement” in quotes twice. That’s because modular packaging does not precisely replicate the features of software collections.
Software Collections would allow you to install multiple versions of the same software on a system and chose which one to use. Modular packages are more like package groups where you can install a package (or set of packages) to provide a particular software version for system users, but, in general, you cannot install more than one version of a package on the same system as you could with Software Collections. These changes are due to Red Hat’s focus on containerization in order to isolate software.
Repository Structure Changes
Along with modular packaging, the repository structure has changed considerably for the first time in what feels like forever! The OS is now in a repo called “BaseOS”, and applications (and modules) are in the “AppStream” repo. Both of these are rolling update repos, which means there’s no longer an “updates” repo. In order to obtain packages from a known point in time, which is very handy when attempting to rebuild a golden image using the same kickstart configuration, a sub-repo is created when the release is first published called, handily enough, “kickstart”.
Package deprecation is more like a rite of passage when a new release comes out, but I’ll mention a couple of packages that I feel deserve a call-out:
- The ntp package is no longer available – you must use chrony
- python2 has been replaced with python3 (which is not fully compatible with python2 )
For most systems, replacing ntpd with chronyd will not cause a lot of problems. They are both NTP protocol daemons, although the command line interfaces are quite a bit different. Plus, since ntp and chrony were both available in CentOS 7, so you may already be familiar with chrony.
Concerns with Python
The changes with python may be a bit more troublesome. Many package maintainers are doing their best to make their previously python2-dependant software work with python3. For instance, ansible will detect which version of python is installed on the target system and use the appropriate python2 or python3 scripts for core features. This doesn’t release the playbook author from making sure their custom python code works on both interpreters, though.
Cockpit Included with Installations
Cockpit is included by default with CentOS 8 installations and provides a web-based management tool for your system. With Cockpit, it feels more like you are managing a hypervisor, VM or container than a single standalone system. Of course, if your system is a hypervisor (or VM), then that won’t come as a surprise. There are many plugins available which provide slick web frontends like disk/system imaging, firewall configuration and virtualization management.
Also interesting is the increased minimum RAM requirement of 1.5 GB (vs 1 GB for CentOS 7). While these values are the listed minimums, I’ve had CentOS 7 systems run just fine with 768 MB of RAM and CentOS 8 systems that couldn’t even complete installation with less than 2 GB RAM.
Most of our customers run CentOS on x86_64, which makes sense because this was the primary architecture for CentOS 7. CentOS 7 releases for aarch64, armhfp, i386, power9, ppc64 and ppc64le are available as “alternate architectures”, but these felt like after thoughts and were often left behind with regards to package availability. CentOS 8 supports aarch64, ppc64le and x86_64 as primary architectures, increasing the hardware audience for the operating system.
New CentOS 8 Features
CentOS 8 new features include:
- Stratis storage manager
The first feature I want to mention is “Boom”. Boom is a BootLoader Specification (BLS) boot manager that makes booting from snapshots incredibly easy. It’s true that Boom was first introduced mid-CentOS 7, but it’s now a standard offering in CentOS 8.
Another utility with a lot of potential is the terminal logger, tlog. With tlog, it is possible to record a command line session, either locally or remotely, one line at a time and play it back. Since tlog uses a JSON output format to store the session data, it is also searchable. The possibilities are limitless with this tool!
I’ve already mentioned the Python-compatibility complications and the package management paradigm changes introduced with CentOS 8. But there are a couple of other things that may give you pause when considering CentOS 8 for your next system build.
Also, expanding on the minimum RAM requirements, some administrators have reported issues with installing EL8 with less than 2 GB or 4 GB of RAM, even though the published minimum requirement is 1.5 GB. These install failures result in the installer not being able to find block storage… or the install may lock up completely. These edge cases may be due to a “perfect storm” of configuration options but switching to a text-based install and/or throwing a little more RAM at the systems has resolved the issues that I’m aware of. As a side note, I think some of the underlying cause may be due to the fact that the default logging configuration “might consume 4 GB of RAM or more ”.
Stratis Storage Manager
CentOS 8 also introduces the optional stratis storage manager which boasts a lot of handy features, like copy-on-write (CoW) snapshots and flexible storage allocation, but our testing has shown that there are some problems with stratis which prevent us from recommending it for mission critical deployment.
First, filesystem utilization metadata is not properly reported by the usual tools; df, du and stratis pool all reported a different amount of used space. Second, snapshots are created with a unique UUID, which is awesome because snapshots can be mounted without manually altering the snapshot UUID, but snapshots are restored with yet another unique UUID. This isn’t a showstopper, but it does mean that restored filesystems cannot be mounted via UUID without additional configuration. Next, stratis only supports the XFS filesystem, so automagically expanded filesystems cannot be reduced in size. And, finally, corruption of the XFS filesystem is a very real possibility. Even though protection from data corruption due to the lack of available lower-level storage space is one of the intended features, I found it extremely easy to corrupt the filesystems (unrecoverably!) by filling the backing storage when testing stratis.
Final Thoughts on New CentOS 8 vs. CentOS 7
There are a lot of other differences between CentOS 7 and CentOS 8. These are just a handful of the ones I thought important enough to point out. If you were around when CentOS 7 was introduced, you no doubt are aware that, when the major version increments, we need to be thorough before jumping in with both feet. I believe that CentOS 8 will be a successful and appropriate OS solution for mission critical deployments, just as CentOS 7 and CentOS 6 were, but it’s going to take some diligence to ensure that success. Learn more about this technology in this CentOS guide.
So, install CentOS 8, put it through its paces and, should you run into a blocker, contact us and we’ll help you through it!