Today’s blog entry covers the basics of what you need to know to move from RHEL6/CentOS6 to RHEL7/CentOS7.
The release of Red Hat Enterprise Linux 7 and later its community supported cousin CentOS 7 was a major leap forward. The two most popular enterprise Linux distributions were rebuilt from the ground up to be faster, more versatile, and ready for the cloud. Here we are going to take a peek under the hood and see what is new. You can also practice/learn these steps by building your own lab on Ravello Systems and by using my public blueprints.
Let’s start by listing the most obvious differences:
- New initialization system, systemd.
- New firewall control, firewalld. This adds a more dynamic and flexible way to control the firewall module in the kernel, which is still netfilter.
- New bootloader. GRUB2 adds rich scripting support as well as support for the new hardware options offered on modern mainboards.
- New default filesystem, XFS. XFS adds support for larger single filesystems, faster format times (0 seconds), integrated snapshots, and live filesystem dumps for backup without first unmounting.
- GNOME 3 - This only really applies to those who use RHEL/CentOS in the desktop, like me. As with any other distro, you aren’t locked into GNOME 3. I personally like it, but KDE is readily available and others can be found on EPEL.
Perhaps the largest change is the scrapping of init/upstart for systemd. For the sake of clarity it is best we start by defining those terms.
- init - The init process was the first process to load and would stay loaded until the system was shut down. It used the idea of run levels to decide which daemons to start and it acted to control those processes. If init failed to start or died for some reason a kernel panic ensued. Services were started sequentially. This method is commonly referred to as System V Init, based off of the grandfather of Linux, System V.
Upstart – A init replacement daemon originally implemented in Ubuntu GNU/Linux and designed to start process asynchronously. This improved performance on boot and added a degree of stability.
systemd - A full replacement for init. It replaces run levels with targets. It also tightly integrates with the daemon control scripts, the firewall, and the bootloader to make a faster, more seamless system. This improves overall performance, security, and makes systemd far better suited to the dynamic cloud.
So what does all this mean to you? For one, daemons are now controlled using the systemctl command. The command goes ‘systemctl [start | stop | restart | enable |disable] [daemon]’. You can also use systemctl to switch targets, which are analogous to run levels. The two most common are multi-user.target, analogous to runlevel 3 and graphical.target, analogous to runlevel 5. The command to switch is ‘systemctl isolate [target]’. You can also use systemctl to restart or poweroff with ‘systemctl [restart | poweroff]’. If you use the older commands like service, chkconfig, etc. it runs the equivalent systemctl command with a message showing you the new method. Very helpful systemd.
Click here for more on target
Clich here for more on systemd in general.
The switch from iptables to firewalld offers a few major changes. One, when we add rules to the firewall the whole table doesn’t need to flush and reload. Differences are read in and no connections are dropped as a result. Two, the language has become more intuitive. Three, the addition of zones allows us to dynamically create rulesets that match a packet to a zone and only have to read through one table. On top of all that the rich rule language gives us added flexibility and allows more dynamic security, easily adapting to the ever changing and dangerous landscape of the cloud.
Click here for more on FirewallD:
GRUB has been the trusty bootloader for years now and feels very familiar, but it hasn’t kept pace with the exploding advances in hardware nor is it dynamic enough for the cloud. In steps GRUB2.
In recent years hardware manufacturers have switched from traditional BIOS based systems to UEFI secure boot. This created an issue for Linux as the requirements of UEFI were beyond the reach of traditional GRUB. GRUB2 adds those abilities along with a much more rich language allowing options to be passed at boot to load drivers, load networking, and other things we weren’t able to do before. This not only suits GRUB2 better to new hardware but also the ever changing cloud environments.
Click heere for more on GRUB2
The XFS filesystem was available in the RHEL/CentOS 6 releases with varying levels of support but in RHEL/CentOS 7 it has become the default filesystem. It is a high performance, highly scalable, journaling filesystem developed at Silicon Graphics, Inc. in 1993. It was ported to Linux in 2001 and has undergone a series of revisions to make it faster and more scalable. It can take advantage of being spanned across multiple devices allowing parallel I/O. It has a max file size of 8 EiB (exbibytes) – 1. That is (8 *1024^6) – 1 bytes. It has a max volume size of 16 EiB, or (16 * 1024^6). For scale let’s go old school. If you were to stack the number of 3.5 inch, 1.44MiB floppies needed to make 16 EiB, at 3mm/floppy it would extend approximately 645 million kilometers, reaching from earth to somewhere between the orbits of Jupiter and Saturn. Not all that important information, but fun to know.
Click here for more on XFS
Making the switch
Because of the major changes involved let me first give you this note. For the love of all that is good and right with the world, do not ever perform an in place upgrade of any production system without first thoroughly testing in a non-production environment. “But I don’t have the resources to replicate my physical hosts for testing,” you say. Have I told you about Ravello Systems yet? You can completely replicate your environment in the EC2 or Google clouds for testing purposes. Pay for what you use, no up front costs, no infrastructure investment, and great support to get you started. Free trial at Ravello Systems. Tell them Michael sent you.
Upgrading in place with all of your applications is no easy task. If you have the resources a fresh install of 7 with a migration of applications over in a phased upgrade may save you some heartaches. That said, there is an upgrade path. It goes as follows:
- Back up your entire system. All of it. Do not proceed until this is complete and verified. This step should be obvious but I can show you many a jobless IT Professional who did not perform this step.
- Read the upgrade doc for your distro (links below). There are subtle differences between RHEL and CentOS, most having to do with the subscription vs. standard repo model.
- From the instructions in the docs, obtain the pre-upgrade assistant. This is absolutely vital. It is safe to run as it does not modify the current system. It will generate a report of where you might find difficulties, what is upgrading, what is being replaced, and what is incompatible. It even writes post upgrade scripts that will do much of the heavy lifting for you. Trust me, this is a huge help.
- Once the tool is run it will exit with some codes. These are what will help you decide how to proceed.
- PASS = everything is fine, no incompatibility/issue detected by this checker
- FAIL = some incompatibility/issue that needs to be reviewed by the admin was detected. FAIL doesn't necessarily mean that the inplace upgrade will fail, but may result in a not 100% functional system
- FIXED = some incompatibility was detected, but the preupgrade-assistant was able to find an automated solution. Some of the fixes may require running postupgrade.d scripts after the upgrade. Fixed configs are available in /root/preupgrade/cleanconf directory. NOTE: The preupgrade-assistant itself doesn't handle the fixes automatically at the moment!
- INFORMATIONAL = nice to have information for admins (e.g. removed options in some common tools which may cause malfunctions of their scripts)
- NOT_APPLICABLE = package which should be tested but the check is not installed on the system (test therefore doesn't make sense)
- ERROR = shouldn't occur, does usually mean error in the preupgrade-assistant framework. All such errors should be reported to the Red Hat preupgrade-assistant team.
- It also provides you with an in place upgrade risk summary. Here is how those break down. Keep in mind, anything above a slight risk may result is an system that does not function as expected. You get to keep the pieces if it breaks.
- None - Default. It can be used as an indicator for some checks. It is not necessary to enter these values.
- Slight - We assessed this field and have not found any issues. However, there is still some risk that not all variants have been covered.
- Medium - It is likely that the area causes a problem in case of the inplace upgrade. It needs to be checked by the administrator after the inplace upgrade and after the system has been monitored for some time.
- High - The inplace upgrade can't be used safely without the administrator's assistance. This typically involves some known broken scenarios or existing 3rd party packages. After the administrator manually fixes the issue, it may be possible to perform the inplace upgrade, but it is not recommended.
- Extreme - We found an incompatibility which makes the inplace upgrade impossible. It is recommended to install a new system with the help of the preupgrade-assistant remediations.
- If you are sure, and I mean absolutely sure, run the upgrade tool listed in the instructions and reboot. Go have a coffee. If you are inclined to do so, pray.
- If all goes well and you have carefully followed the upgrade guides you will have a RHEL or CentOS 7 system. If all has not gone well, weep gently. Then go find your full backups. Of course you already tested all of this on Ravello and were totally prepared for the upgrade, right?
RHEL 6 to 7 (requires subscription)
CentOS 6 to 7
If you would like to learn more, Red Hat has a full series of courses on RHEL7. I recommend the following paths:
- For anyone who has never been exposed to RHEL/CentOS 7, including admins from earlier versions: Red Hat System Administration I, II, III, (RH124, RH135, and RH255 respectively).
For only experienced Linux admins who are ready rapidly ramp themselves up: RHCSA Rapid Track and RHCE Certification Lab (RH200 and RH300 respectively). Again note, these are really meant for the more experienced who can ramp themselves up. I’m not joking.
Please, if taking the first track, they build on each other. Don’t skip one. The second track is mostly self paced and crams multiple weeks of labs into four days so come in ready to cram. All of these courses have changed significantly since RHEL 6.
You can register for these classes direct through Red Hat or through one of their many training partners. Listings can be found here. Classes are offered via live training, instructor led virtual training, or the new Red Hat Online Learning subscription which incidentally provides access to your classroom environment using Ravello.
I’ve created a Ravello blueprint with two machines. One is CentOS 6.6 and the other is the CentOS 7 machine created in last week’s entry. If you would like to use it, let Ravello support representative know to load the 03-RampingUpFor7-BP blueprint and corresponding VMs into your Ravello account. Note, you will want to configure your own keys for these images to allow secure SSH. Details for that are here.
Get it on Repo
REPO by Ravello Systems, is a library of public blueprints shared by experts in the infrastructure community.
That’s all for this week. Join us next week, same bat time, same bat channel.
Other posts in the Linux Smart Lab in the Cloud series