Why Choose CentOS 6 or 7

Reading Time: 6 minutes

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.

Top 4 Lessons Learned Using Ubuntu

Reading Time: 5 minutes

When choosing a server operating system, there are a number of factors and choices that must be decided. An often talked about and referenced OS, Ubuntu, is a popular choice and offers great functionality with a vibrant and helpful community. However; if you’re unfamiliar with Ubuntu and have not worked with either the server or desktop versions, you may encounter differences in common tasks and functionality from previous operating systems you’ve worked with. I’ve been a system administrator and running my own servers for a number of years, almost all of which were Ubuntu, here are the top four lessons I’ve learned while running Ubuntu on my server.

  1. Understanding the “server” vs. “desktop” model
  2. Deciphering the naming scheme/release schedule
  3. Figuring out the package manager
  4. Networking considerations on Ubuntu

 

Understanding “Server” vs. “Desktop” Model

Ubuntu comes in a number of images and released versions. One of the first choices to consider is whether you want the “desktop” or “server” release. When running an application or project on a server the choice to make is the “server” image. You may be wondering what the difference is, and it comes down to two main differences:

  • The “desktop” image has a graphical user interface (GUI) where the “server” image does not
  • The “desktop” image has default applications more suited for a user’s workstation, whereas the “server” image has default applications more suited for a web server.

It is really that simple. Currently, the majority of the differences relate to the default applications offereed when installing Ubuntu and whether or not you need a GUI. When I first started using Ubuntu, there were a number of differences between the two (such as a slightly tweaked Linux kernel on the “server” image designed to perform better on server grade hardware), but today it is a much more simplified decision process.

The choice comes down to saving time for the individual by either adding or removing applications (also called “packages”) that they do or don’t need. At Liquid Web we offer “server” images since it’s best designed for operating on a web server. You do have the choice of the Ubuntu version, which brings me to my next lesson learned:

 

Deciphering the Naming Scheme/Release Schedule

Both Ubuntu and CentOS are based on what is called an “upstream” provider, or another operating system that then CentOS/Ubuntu tweak and re-publish. For Ubuntu, this upstream provider is the OS, Debian, whereas CentOS is based on Red Hat (which is further based on Fedora). It was confusing at first for me to try and understand what the names for Ubuntu releases meant: “Vivid Vervet”, “Xenial Xerus”, “Zesty Zapus”; but that’s just a cute “name” the developers give a particular version until it is released.

The company that oversees Ubuntu, called Canonical, has a regular and set release schedule for Ubuntu. This is a distinct difference between CentOS, which relies on Red Hat, which further relies on Fedora. Every six months a release of Ubuntu is published, and every fourth release (or once every two years) a “long-term support” or LTS release is published. The numbering they use for releases is fairly straight-forward: YY.MM where YY is the two digit year and MM is the month of the release. The latest release is 19.04, meaning it was released in April of 2019.

This was tricky for me to initially navigate and created a headache since the different versions have different levels of support and updates provided to them. For some people, this is not an issue. As a developer, you may want to build your application on the latest and greatest OS that takes advantage of new technologies. Receiving support may not matter because you won’t be using the server for very long. You may also be in a position where you need to know that your OS won’t have any server-crashing bugs.

Which version do you choose? How do you know whether your OS will be stable and receive patches/updates? I ran into these issues with when accidentally creating a server that lost support just a few months later; however, I learned an easy-to-use trick to ensure that in the future I chose an LTS release:

  • LTS releases start with an even number and end in 04

Liquid Web offers a variety of Ubuntu releases within our Core-Managed and Self-Managed support tiers:

Notice that all the version of Ubuntu that we offer are the .04 releases. These are all LTS releases, ensuring that you receive the longest possible lifespan and vital security updates for your OS.

 

Ubuntu’s Package Manager

Prior to working with Ubuntu, I had the most experience with CentOS. Moving to Ubuntu meant having to learn how to install packages since the CentOS package manager, yum, was no longer available. I discovered that the general process is the same with a few minor differences.

The first difference I encountered is that Ubuntu uses the apt-get command. This is part of the Apt package manager and follows a very similar syntax to the yum command for the most basic command: installing packages. To install a package I had to use:

apt-get install $package

Where $package was the name of the package. I didn’t always know the name of the package I wanted to find though so I thought I could search much like I could with yum search $package; however there is another utility that Apt uses for searching: apt-cache search $package

If you forget,  you’ll get an error that you’ve run an illegal operation:

One similarity to yum that is super useful: the “y” flag to bypass any prompts about installing the package. This was my favorite “trick” on CentOS to speed up installing packages and improve my efficiency. Knowing that it works the same on Ubuntu was a major relief:

Of course installing packages meant I had to add the repositories I wanted. This was a significant change since I was use to the CentOS location of /etc/yum.repos.d/ for adding .repo files. With the shift in the Apt system on Ubuntu, I learned that I needed to add a .list file, pointing to the repository file in question in the /etc/apt/sources.list.d/ folder. Take Nginx for example; it was quite easy to add once I realized what had to go where:

 

From here it was as straight-forward as installing Nginx with the apt-get install nginx command:

 

There was a time when adding a repository did not immediately work for me; however, it was quickly resolved by telling Apt that it needed to refresh/update the list of repos it uses with the apt-get update command.

Note
Don’t worry, the apt-get update command does not update any packages needlessly, this simply runs through the configured repositories and ensures that your system is aware of them as well as the packages offered.

 

Networking Consideration on Ubuntu

The last major lesson I want to talk about was one learned painfully. Networking on Ubuntu, by default, is handled from the /etc/network/ directory:

There is a flat file called interfaces, and this will contain all the networking information for your host (configured IPs/gateways, DNS servers, etc…):

Notice in the above configuration that both the primary eth0 interface and the sub-interface, eth0:1, are configured in the same file (/etc/network/interfaces). This caught me in a bad spot once when I made a configuration syntax mistake, restarted networking, and suddenly lost all access to my host. That interfaces file contained all the networking components for my host, and when I restarted networking while it contained a mistake, it prevented ANY networking from coming back up. The only way to correct the issue was to console the server, correct the mistake, and restart networking again.

Though this is the default configuration for Ubuntu, there is now a way to ensure that you have the configuration setup for individual interfaces so, a simple mistake does not break all of the networking: /etc/network/interfaces.d/

To properly use this folder and have individual configuration files for each interface, you need to modify the /etc/network/interface file to tell it to look in the interfaces.d/ folder. This is a simple change of adding one line:

source /etc/network/interfaces.d/*

This will tell the main interfaces configuration file to also review /etc/network/interfaces.d/ for any additional configuration files and use those as well. This would have saved me a lot of hassle had I known about it earlier.

Hopefully, you can use my mistakes and struggles to your advantage. Ubuntu is a great operating system, is supported by a fantastic community, and is covered by “the most helpful humans in hosting” of Liquid Web. If you have any questions about Ubuntu, our support or how you might best use it in your environment feel free to contact us at support@liquidweb.com or via phone at 1-800-580-4985.