Introduction

The servers that run our applications, our businesses, all depend on the stability and underlying features offered by the operating system (or OS) installed. As administrators, we have to plan ahead and think to the future of how our users will use the machines we oversee while simultaneously ensuring that those machines remain stable and online. There are numerous operating systems to choose from; however one of the most popular, most stable, and highly supported OSes is CentOS. A combination of excellent features, rock-solid performance stability, and the backing of enterprise-focused institutions such as Red Hat and Fedora have led to CentOS becoming a mainstay OS that administrators can count on.

Though extremely stable in both iterations, the change from CentOS 6 to CentOS 7 brought about a number of changes that have polarized the community surrounding CentOS and put administrators into a position of having to determine which is best for their projects and organization. Choosing which version you use for a given project depends on a number of factors that only you will know. However, there are some common concerns/points of interest that can help make your decision easier.

Evaluating Current Needs

The first, and ultimately most important aspect to consider, is what need are you trying to fulfill? Knowing what the problem actually is will provide a clear path in determining what the solution will ultimately be. Some of the example “needs” that I’ve helped clients attempt to negotiate requirements for here at Liquid Web are:

• Utilize newer and more powerful hardware while supporting legacy applications
• Prepare a testing and staging environment for a to-be-developed project
• Migrate client data/system applications from end-of-life software to supported software

All of the above require examining the requirements of the systems in place and considering what difficulties would be involved and how to overcome those. Some points to consider:

• If you have legacy systems you’re attempting to support or perhaps systems already utilizing CentOS 6 that you’re attempting to simply migrate to newer hardware you will want to consider a test environment running CentOS 7 prior to migrating to it in a production environment. There are numerous changes to the underlying OS, command syntax, and even package versions available. Running into problems in production due to there being a change in the expected environment is an easily avoidable problem.
• Maintaining a consistent environment can dramatically reduce support overhead. Furthermore: if your environment is currently made up of CentOS 6 based hosts you will not have to worry about the education aspect of training you or your staff on the differences/nuances that separate CentOS 6 from 7. If you have Fully Managed servers here at Liquid Web you can rest more easily since our Support staff is comprised of both RHEL 6 and 7 Red Hat Certified System Administrators (more on this below).
• If you have the opportunity to start a project off with either CentOS 6 or 7 you will want to think about the lifetime of that project. If this is a short term project the benefits of being on an operating system that you’re familiar with may be greater than an OS that is newer. If the project will be supported for the long-term you will want to factor in the lifetime of the software packages and support offered for the OS.

If this is a new project it would be strongly recommended to utilize CentOS 7 simply because of the continuation of support it will receive, which is my next topic of discussion:

Support Timeline

CentOS has a unique versioning scheme that they have adopted for their most recent operating system. It is important to recognize the version you’re on, what version you need/want, and the benefits of any given version. If your project timeline sees the project lasting for any decent amount of time, you will want to consider the need for updates/patches to your operating system. Weight the benefits of using CentOS 6 vs CentOS 7 can entirely depend on how long you need to receive support.

The CentOS wiki  does an excellent job of breaking down the meaning of the version numbers for CentOS 7 (point #29); however, the basic way to remember versioning for CentOS 7 is: “two-digit year two-digit month”. So the following: CentOS-7-1406 is representative of the CentOS 7 build from June of 2014. The main reason for the change is to provide a quick reference to when a CentOS 7 version was released and allow you to understand if it will be supported. The ONLY images being supported are the most recent image in the minor branch. Liquid Web regularly updates our Fully-Managed servers to ensure they’re running the most recent minor branch, ensuring that you receive the updates/patches necessary to stay protected.

The deadline for CentOS 6 no longer receiving updates is November 30th, 2020. After this point in time CentOS 6 will be declared “End of Life” and receive no further updates (patches, security, etc…). Though this means that CentOS 6 will eventually suffer from issues that have not yet been discovered or will not be supported by newer hardware, it does not mean that it cannot still be used for a project and work without issue. Liquid Web Support will also continue to provide assistance with CentOS 6 based servers as well as guide you on how you can best upgrade to CentOS 7 should you choose. This also gives you time to start testing CentOS 7 (perhaps with a virtual server that can easily be created/torn down) and discovering what changes you will need to make so that your application can operate without issue on the newer operating system.

While you have time to decide on whether CentOS 6 or 7 can be used, it is best to be looking towards the future of your hosting environment. CentOS 6 no longer receiving updates creates a potential security risk as malicious individuals will be able to exploit bugs/weaknesses that are discovered later on without fear of those holes being patched. It takes time to migrate infrastructure and those people looking to take advantage of that fact will be probing your servers and applications to try and find those weaknesses that won’t be corrected. The amount of time it takes to migrate though is dependent on a number of factors, including the large changes and differences between CentOS 6 / CentOS 7. The next section discusses what many consider to be the largest change:

SystemD

Without a doubt, it was the introduction of SystemD that created the most controversy around the release of CentOS 7. Though it was known for a while that it would trickle down from the upstream source (CentOS uses Red Hat as an upstream source, which in turn uses the Fedora project as the upstream source), it was nonetheless a major change for individuals accustomed to CentOS 6. This adoption of SystemD meant that applications and software had to be examined and tested to ensure that they worked correctly on CentOS 7 and that the SystemD architecture didn’t cause issues. The SystemD design was such that it should be backward compatible; that does not mean that every change is something that can be overlooked because it won’t cause issues. Items to consider when choosing CentOS 7 for your project:

• Do you need to have complete control over your system and logging?
• Does your application need to interact with daemons and other services regularly?
• Do you expect to be able to override operating system defaults with your own package choices?

Once such example of why SystemD can create issues: SystemD brought about “targets”, which were similar to the “init levels” of CentOS 6. Each “target” sets the services that will start and are designed around specific purposes. However, this is a prime example of why testing to ensure that your application works is key: targets are not init run levels and customizations you may have made to a given run-level may not work. This change in the default behavior can have unintended consequences if your environment is not designed to handle those changes. The alteration of defaults is a prevalent theme in CentOS 7 and that brings me to my last topic:

Defaults Have Changed

The last topic to touch on is the default changes you will see between CentOS 6 and 7. Again, this all ties back to what you designed your application to handle. The following are some of the changed defaults from CentOS 6 to CentOS 7 that individuals are likely to notice:

• Default file system changes from EXT4 to XFS
• Default kernel changes from 2.6 to 3.10
• Default firewall changes from Iptables to FirewallD
• Default database management system changes from MySQL to MariaDB

These options can be worked around, but you run the risk of creating a system that you’re constantly trying to “fix” and correct so that you can handle the changes introduced. Evaluating whether you even need to be concerned about these changes is another component to determining if CentOS 6 or 7 will make a difference in your project.

Conclusion

Though CentOS 7 has been out for a while and SystemD has been used for longer still in the upstream, there are bugs and issues being resolved. CentOS has been a mainstay in the hosting world for the rock-solid stability it provides, and most of that carries over in CentOS 7. It is still tested thoroughly and has a large community surrounding the development. The future is with SystemD and the changes that are occurring, and should you need support or expect updates you will be forced to use CentOS 7. However, only you know what your project requires and depends on. Whether you’re familiar with CentOS 7, SystemD, and the process of migrating your data, Liquid Web is here to help.

If you’re interested in seeing some of the changes that CentOS 7, check out the Knowledge Base for articles discussing CentOS 7 and common operations/tasks.