Check the status of CVEs. Learn More.
Keeping your systems up 100% of the time requires live patching. Our solutions will align strongly with your risk, compliance, and operational uptime requirements.
TuxCare is trusted by the most innovative companies across the globe.
Learn about TuxCare's modern approach to reducing cybersecurity risk with Blogs, White Papers, and more.
Continually increasing Cybersecurity, stability, and availability of Linux servers and open source software since 2009.
TuxCare provides live security patching for numerous industries. Learn how TuxCare is minimizing risk for companies around the world.
2x a month. No spam.
June 24, 2021 - TuxCare PR Team
We’ve received requests for assistance with converting systems running RHEL 7 to CentOS 7. There are several reasons for this, from wanting to standardize the server fleet (on a recently released survey, roughly 73% of the respondents said they had a single OS fleet), licensing changes, future migration paths or other scenarios.
What could, at first glance, look like a simple repository change is actually somewhat more involved. So we created a script to automatically perform the conversion. This article provides an in-depth look at the script and the migration process.
The script is written in Python, and it performs 9 distinct operations:
Let’s dig a little deeper into each of these.
The script is designed to be idempotent. That means that it can be executed multiple times without any risk. The status of every step is stored in a special file so the script will never execute a previously completed step again. If all steps have already been done, the script will just print a “The system has already migrated to CentOS 7” message and exit.
Most of the commands executed by the script require root privileges, so this is checked at the very beginning.
The script checks that the installed system is indeed RHEL 7. Each operating system has its own specific characteristics, and trying to use the script on an unsupported system can lead to unexpected results.
This step removes packages specific to RHEL – logos and configuration files with information about the release and repositories. These are the packages mainly responsible for the “branding” of the distribution.
The packages removed in the previous step are replaced with the corresponding packages from CentOS. From now on, you will use the CentOS repositories to install and update packages.
A regular update of all system packages to the latest versions available in the CentOS repositories is performed.
The extra step of keeping the packages in sync with the latest versions available in the CentOS repositories is necessary for cases where a package in CentOS has a lower version than the equivalent RHEL one. Such packages are very rare. However, this situation may still need to be handled.
This step is very important for converting systems running in UEFI (not BIOS) mode. Most solutions and articles do not provide information on the steps needed to manage these systems, but not doing this can result in an unbootable operating system following conversion. RHEL and CentOS use different paths for the Shim and Grub2 boot loaders – /boot/efi/EFI/redhat and /boot/efi/EFI/centos respectively.
This causes two problems. The first is that after the conversion, the Grub2 bootloader will look for its configuration in the new path while it is still located in /boot/efi/EFI/redhat dir. The second problem is the boot entries in the UEFI firmware. An RHEL entry will remain pointing to the bootloader in /boot/efi/EFI/redhat, but it is no longer available using this path. A fallback mode is implemented in most UEFI firmware, where the bootloader will still be detected and launched. However, the implementation of this mode is optional, and some hardware does not support this. In this case, after migration, the system will not be able to boot. Both these problems are automatically solved at this step.
Also, at this step, the script makes sure that the Shim and Grub2 boot loaders and the kernel are installed from the CentOS repository. If any of the listed packages remain from RHEL, the system will not be able to boot into Secure Boot mode. Such packages will be detected and reinstalled from CentOS.
Typically, RHEL systems have several recent kernels installed. Therefore, the script sets the kernel from CentOS as the default kernel for the next boot in the last step. This step is also required for systems running in Secure Boot mode.
And at this point, the system is, for all intents and purposes, running CentOS 7. It will show up as CentOS in management systems (you may need to refresh the system information if it’s stored centrally), and will accept any CentOS specific automated management operations you may use on other systems. The script effectively eliminates the complexity of the process and automatically performs all these steps.
The script is open source, and you can find it here: https://github.com/cloudlinux/rhel2centos
Usage instructions are simple:
$ sudo python migrate_7.py … The system is migrated to CentOS 7
# check release file $ cat /etc/redhat-release CentOS Linux release 7.9.2009 (Core) # check that the system boots CentOS kernel by default $ sudo grubby –info DEFAULT | grep CentOS title=CentOS Linux (3.10.0-1160.31.1.el7.x86_64) 7 (Core)
(version numbers may vary as updates are released)
Learn About Live Patching with TuxCare
End-of-life software is just a fact of our fast-paced technology...
Look, everyone knows that it’s a tough act. Thousands of...
The public sector, including state and federal agencies, are at...
If your organization deploys IoT solutions, you know that development...
We continue to look at the code issues that cause...
Catastrophic risks such as natural disasters and indeed cyberattacks require...