For folks who have had an eye on potential CentOS alternatives, Rocky Linux has been living in the spotlight. As a drop-in replacement for CentOS Linux (not to be confused with CentOS Stream) it has all the appearances of being a spiritual successor to CentOS Linux.
But for enterprise organizations, adopting a new distribution like Rocky Linux raises a number of questions. Will it be reliable? How will it be supported? What does the community look like? What do we need to consider before migrating? To help answer some of these questions, we put together an overview of Rocky Linux, including how it compares to CentOS, support and migration considerations, and the current status of Rocky Linux repositories.
Rocky Linux, the brainchild of CentOS founder Gregory Kurtzer, is a free, 100% bug-for-bug compatible fork of Red Hat Enterprise Linux 8 developed by the Rocky Enterprise Software Foundation.
In addition to Gregory Kurtzer, the CentOS Project was cofounded by Rocky McGaugh who has since passed away. In memory of Rocky, Greg decided it name this new distribution after him:
"Thinking back to early CentOS days... My cofounder was Rocky McGaugh. He is no longer with us, so as a H/T to him, who never got to see the success that CentOS came to be, I introduce to you...Rocky Linux" — Gregory Kurtzer, Founder of Rocky Linux
Licensing of Rocky Linux itself is 3-Clause BSD but, because Linux distributions are a collection of packages, each package may have its own licensing.
Anyone who switched, or consider switching, to CentOS Linux 8 and doesn’t want to deal with the extra overhead of switching to CentOS Stream 8 should consider Rocky Linux 8 as a potential candidate for their infrastructure.
Rocky Linux 8 is a downstream rebuild of RHEL 8 and, as such, aligns with the RHEL 8 lifecycle and therefore will be actively maintained until 2029.
There are several options regarding support for Rocky Linux. Official support is offered by CIQ, another company founded and owned by Mr. Kurtzer and comprised of many of the same people who are intimately involved with Rocky Linux, but the RESF has stated that anybody can provide support for Rocky Linux.
Get Technical Support for Rocky LinuxOpenLogic provides technical support for the most popular Enterprise Linux distributions, including Rocky Linux. This allows our customers to engage with a single point of support for homogenous, heterogenous or hybrid OS deployments. Interested in learning more about how we can support your Rocky Linux deployments?Talk to an Expert
OpenLogic provides technical support for the most popular Enterprise Linux distributions, including Rocky Linux. This allows our customers to engage with a single point of support for homogenous, heterogenous or hybrid OS deployments. Interested in learning more about how we can support your Rocky Linux deployments?
Talk to an Expert
If you are planning or conducting an migration to Rocky Linux, there are a number of considerations to keep in mind.
Get Support for Your Rocky Linux MigrationNeed help performing your migration to Rocky Linux? Talk to an expert today to see how we can make your migration a success.Talk to a Migration Expert
Need help performing your migration to Rocky Linux? Talk to an expert today to see how we can make your migration a success.
Talk to a Migration Expert
As of early August 2021, Rocky Linux has almost 100 mirrors, including a global CDN (Content Delivery Network). Over 80 mirrors provide HTTP, over 80 mirrors provide HTTPS and over 50 provide RSYNC connections.
Secure communication with the repos over HTTPS is not strictly necessary since no authentication is required to access the repos. Utilizing HTTPS will cause proxies to not be able to cache the packages. Certain proxies (like squid) can be configured to accept HTTP requests from the client and connect to the upstream repos via HTTPS, though.
RSYNC access is primarily useful if you’d like to create your own local mirror to distribute the RPMs to your clients. A caching proxy or local mirror is something that I recommend for most of our customers, not just for the packages published by the OS vendor (Rocky Linux, in this case), but also for 3rd party application repos or private repositories like we provide for our customers.
When the Rocky Linux repositories were first populated, signed repository metadata was not provided. This changed around July 11, 2021 with the inclusion of GPG signed metadata. With the latest update to the libdnf package, you can set repo_gpgcheck=1 in your DNF configuration to verify the repo metadata via GPG.
Rocky Linux has just started offering errata with their updates. This means commands like dnf updateinfo list --security --available and
dnf updateinfo list --security --available
dnf upgrade --cve CVE-20xx-xxxx will work in Rocky Linux! (CentOS users have been wanting this feature for a very long time.)
dnf upgrade --cve CVE-20xx-xxxx
# dnf updateinfo list --security --available
RLSA-2021:2714 Important/Sec. bpftool-4.18.0-305.10.2.el8_4.x86_64
RLSA-2021:2570 Important/Sec. bpftool-4.18.0-305.7.1.el8_4.x86_64
RLSA-2021:2714 Important/Sec. kernel-4.18.0-305.10.2.el8_4.x86_64
RLSA-2021:2570 Important/Sec. kernel-4.18.0-305.7.1.el8_4.x86_64
RLSA-2021:2714 Important/Sec. kernel-core-4.18.0-305.10.2.el8_4.x86_64
RLSA-2021:2570 Important/Sec. kernel-core-4.18.0-305.7.1.el8_4.x86_64
RLSA-2021:2714 Important/Sec. kernel-modules-4.18.0-305.10.2.el8_4.x86_64
RLSA-2021:2570 Important/Sec. kernel-modules-4.18.0-305.7.1.el8_4.x86_64
RLSA-2021:2714 Important/Sec. kernel-tools-4.18.0-305.10.2.el8_4.x86_64
RLSA-2021:2570 Important/Sec. kernel-tools-4.18.0-305.7.1.el8_4.x86_64
RLSA-2021:2714 Important/Sec. kernel-tools-libs-4.18.0-305.10.2.el8_4.x86_64
RLSA-2021:2570 Important/Sec. kernel-tools-libs-4.18.0-305.7.1.el8_4.x86_64
RLSA-2021:2569 Moderate/Sec. libxml2-2.9.7-9.el8_4.2.x86_64
RLSA-2021:2575 Moderate/Sec. lz4-libs-1.8.3-3.el8_4.x86_64
RLSA-2021:2569 Moderate/Sec. python3-libxml2-2.9.7-9.el8_4.2.x86_64
RLSA-2021:2714 Important/Sec. python3-perf-4.18.0-305.10.2.el8_4.x86_64
RLSA-2021:2570 Important/Sec. python3-perf-4.18.0-305.7.1.el8_4.x86_64
RLSA-2021:2574 Moderate/Sec. python3-rpm-4.14.3-14.el8_4.x86_64
RLSA-2021:2574 Moderate/Sec. rpm-4.14.3-14.el8_4.x86_64
RLSA-2021:2574 Moderate/Sec. rpm-build-libs-4.14.3-14.el8_4.x86_64
RLSA-2021:2574 Moderate/Sec. rpm-libs-4.14.3-14.el8_4.x86_64
RLSA-2021:2574 Moderate/Sec. rpm-plugin-selinux-4.14.3-14.el8_4.x86_64
RLSA-2021:2574 Moderate/Sec. rpm-plugin-systemd-inhibit-4.14.3-14.el8_4.x86_64
RLSA-2021:2717 Important/Sec. systemd-239-45.el8_4.2.x86_64
RLSA-2021:2717 Important/Sec. systemd-libs-239-45.el8_4.2.x86_64
RLSA-2021:2717 Important/Sec. systemd-pam-239-45.el8_4.2.x86_64
RLSA-2021:2717 Important/Sec. systemd-udev-239-45.el8_4.2.x86_64
Let’s examine the release lag for updates posted since Rocky Linux went GA. Here’s what I’ve seen with a cursory evaluation. There were a large number of updates published by Red Hat on June 29th and taking a look at a sample of these shows that Rocky Linux published their updates the same day.
Since June 29th, there have been 8 security updates and 4 bugfix updates for RHEL packages present in Rocky Linux:
I think that this demonstrates that security updates are a priority for the Rocky Linux Release Engineering Team and that Rocky Linux users will not have to wait long to receive them. OpenLogic will continue to monitor the release lag of Rocky Linux (and other CentOS alternatives) as package updates are published and new point releases materialize.
Both projects are RHEL-rebuilds emerging in response to the Red Hat announcement on Dec 8, 2020 that CentOS Linux was being discontinued.
For some background, Red Hat stated that CentOS Linux 8 will now have a diminished lifecycle that will go end of life (EOL) in December of 2021 — 8 years earlier than previously announced. CentOS Linux 6 went EOL on Nov 30, 2020 (as scheduled) and CentOS Linux 7 has not received any change in EOL at this time.
With both projects coalescing to fill the same vacuum that will be left by CentOS 8, both should be relatively identical. Not only to each other, but to the upstream RHEL release that they are rebuilt from.
Where we expect to see differences is in release lag, responsiveness to bug reports, communication and transparency of the project leads.
Rocky Linux 8 is intended to be a drop-in replacement for CentOS Linux 8.
As mentioned above, Rocky Linux is providing update errata! The updateinfo metadata is provided, which means you can perform security-centric package management such as installing only security-only updates, query for patched vulnerabilities, etc. CentOS Linux does not provide the updateinfo metadata, but up until CentOS 7, package announcements were available via a mailing list. CentOS 8 doesn’t have the updateinfo metadata, either, and even the package announcements on the CentOS-announce mailing list are absent.
The entire reason that Rocky Linux exists is to fill the void that will exist when Red Hat terminates CentOS Linux 8 in Dec 2021. You can be assured that Rocky Linux will not contain the newest versions of the packages shipped with CentOS Stream. This is by design. If an upstream distribution like CentOS Stream fits your business and technical models, then CentOS Stream should be available for many years to come.
Rocky Linux appears to be gaining acceptance at a rapid pace! Stats from our OpenLogic image usage show that our Rocky Linux images are launched as much as (or more than) the other Enterprise Linux distribution images that we publish, including CentOS.
If you’re interested in trying out Rocky Linux, OpenLogic has several images published that you can try out, including our Vagrant boxes, AWS images, GCE images, and Azure images.
If you're working with open source Enterprise Linux deployments, OpenLogic can provide the expert technical support and services you need to succeed. Whether that's with end of life CentOS Linux versions, or with new distributions like Rocky Linux, our team is here to help. Talk to an expert today and see how we can support your goals.
Enterprise Linux Developer, OpenLogic by Perforce
Rich Alloway has over 25 years of professional Linux experience in academic, Internet service provider and telco carrier environments. He has filled many production roles: SysAdmin, Systems/Network/RF Engineer and CTO. He is currently a member of the Enterprise Linux Team at OpenLogic by Perforce, and serves as a contributor on the Rocky Linux QA and Testing Team.