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.

How To Install the LAMP Stack on CentOS 7

Reading Time: 4 minutes

Whether you’re new to hosting websites or a seasoned developer, you’ve more than likely heard of a LAMP stack. The LAMP stack is the base set of applications that most websites running on a Linux server are served from and is commonly referred to as “Lamp”. Rather than a single program that interacts with the website being served, LAMP is actually a number of independent programs that operate in tandem: Linux, Apache, MySQL/MariaDB, and PHP. Throughout this article, we’ll walk through installing the LAMP stack on your CentOS 7 server so you can run a website from any Dedicated Server or Virtual Private Server. Although we’re focusing on installing LAMP on a CentOS 7 server, the steps that we’ll cover are very similar across multiple Linux distributions.

Each environment differs slightly, so let’s discuss the environment that we will use throughout this tutorial. We’ll start with a clean installation of the latest version of CentOS 7 (version 7.6) on a virtual machine installed on a workstation. For ease of installation, we’ll use the root user to install the services. You can use an alternate system user if you choose, but you will need to prepend sudo to the following commands in order for them to install or interact with the software. For any environment that you choose, it is important that you are connected to the internet to access the yum repositories to download the packages to install.

Once the server is started and you are accessing the server via console or SSH terminal, we can start running through the next steps. If you need assistance with interacting with a server via terminal, please see our article on SSH.

Pre-flight Checks

To find out which Linux distribution you are running, use this command:
cat /etc/redhat-release
It’s now time to verify that our yum environment is clean and up to date, we’ll do this by cleaning all of the yum cache, and update yum using:
yum clean all
yum update

Installing LAMP

Now that we know what environment we’re working in let’s get started on installing the LAMP stack on CentOS 7:

L – Linux

The first part of the stack is Linux. This is your operating system and since it is already installed there no need to worry about installing it or make any modifications. Installing CentOS 7 is easy to download and install using the image files that are provided from centos.org. CentOS has a helpful installation guide if you need to reference it for additional installation instructions.

A – Apache

Apache is the next piece of the LAMP stack. Apache is the webserver software that is responsible for serving the content to your web browser from the server. It takes the requests that it receives and sends back the HTML code for your browser to interpret.
Install Apache using Yum:
yum -y install httpd

Open ports in the FW:
firewall-cmd --permanent -add-service=http -add-service=https
firewall-cmd --reload

Start and enable apache to run when the server starts:
systemctl start httpd
systemctl enable httpd

Default Apache installation locations:

Some important server locations to remember for Apache are listed below. These are out-of-the-box defaults and can be changed as you see fit:
httpd binary: /sbin/httpd
Apache configuration file: /etc/httpd/conf/httpd.conf
Website files: /var/www/html/
Apache logs: /var/log/httpd/

M – MySQL/MariaDB

MySQL and MariaDB are what handle your website’s database. In most of today’s websites, data is not stored in flat or static files. Instead, the base of the site is coded in PHP which can pull information from your website’s database to deliver more dynamic content. MySQL and MariaDB are popular database servers that help house that information. MariaDB is becoming more widely used, so we’ll use for installation. Both are very similar in setting up and configuring.

Install MariaDB:
yum -y install mariadb-server
systemctl start mariadb

Although securing mysql is optional, it is strongly recommended:
mysql_secure_installation
**Run through the steps on screen to secure your Mysql/MariaDB environment

Enable MariaDB to start when the server starts:
systemctl enable mariadb

Default installation locations:

Some important server locations to remember for MySQL/MariaDB are listed below. These are out-of-the-box defaults and can be changed as you see fit:
MariaDB binary: /bin/mysql
MariaDB Configuration file: /etc/my.cnf
Database location: /var/lib/mysql
MariaDB logs: /var/log/mariadb/mariadb.log

P – PHP

Most websites that exist today are built using PHP coding. PHP provides the programmer with more options for dynamic content compared to flat html code. Several PHP versions are available for use depending on what PHP version the website was built in. We’ll install the latest version of PHP.

In order to install the latest PHP version, we first need to install CentOS’s Software Collection repository (SCL):
yum -y install centos-release-scl.noarch

We’ll now have access to install PHP 7.2 :
yum -y install rh-php72

Now we’ll fix the symbolic link for the binary:
ln -s /opt/rh/rh-php72/root/usr/bin/php /usr/bin/php

Install the updated PHP Module for Mysql/MariaDB:
yum -y install rh-php72-php-mysqlnd

Restart apache to work with the newly installed PHP:
systemctl restart httpd

If your website’s code requires additional PHP and Apache modules, they can be installed using yum . If you need to verify what exactly your website is using for PHP, you can set up a PHP info page. For more information, see Setting up a PHP info page.

The LAMP stack is the minimum that is required in order for any modern website to run on a Linux server. There are many variations to these environments that can be tailored to suit your needs. Luckily, our Fully Managed Server and Core Managed servers come with the LAMP stack pre-installed and ready for you to install your website on. For more information about ordering your new server, contact our Solutions Team. Our support teams are also trained in handling issues that may arise with each component of the LAMP stack and are able to answer any questions that you might have.

How Do I Connect My Mac to Windows?

Reading Time: 1 minute

Mac users work in their native Unix environment are familiar with using the terminal to SSH into their Linux based servers. When using a Mac to log into a Windows environment, or vice versa,  the task is performed differently. Window machines use a different protocol, one aptly named RDP (Remote Desktop Protocol). For our tutorial, we’ll explore how to use your Mac to connect to a Windows server.  Let’s get started!

 

Pre-flight

 

Step 1:  Open Finder >> Applications >> App Store.  We’ll be going to the App Store to download Microsoft Remote Desktop.

 

Step 2. Use the search bar to locate Microsoft’s Remote Desktop. Select Get >> Install App. After installed, click on the Microsoft Remote Desktop icon in your Applications folder.

Note
iCloud is absolutely free, but they require a valid credit card on file, even for free apps.

 

Step 3: Launch the app by finding it in your Applications folder.

 

Step 4: For our connection select + New and fill out the information in the highlighted boxes for the Windows server.Connection Name: A nickname to identify this connection

PC Name: Window’s server IP address

User Name: Administrator

It seems counter-intuitive but close the edit window to save the settings. Immediately, you’ll see the server show up in your My Desktops list.

 

Step 5: Click on the server name to connect to your Windows environment. If all the information was correctly entered you’ll see the Window’s environment with the familiar Windows desktop background.

 

Troubleshooting: Can’t Resolve Hostname

Reading Time: 2 minutes

You may find the “can’t resolve hostname” or “temporary failure in name resolution” error when using retrieval command like wget, cURL, ping or nslookup. There are many reasons why these commands can cause an error, including file corruption.  For the sake of brevity, we look towards commonalities between these commands to solve the issue.

These commands connect to the Internet using gateways to communicate and provide information.   If the connection from your local machine, in this case, a CentOS server, is disconnected you’ll likely run into issues trying to access the world wide web. In this troubleshooting tutorial, we’ll show you some common solutions to connectivity issues.

Step 1: Amongst many other configuration tasks, the resolv.conf file is used to resolve DNS requests. Manually editing the resolv.conf file to configure name resolution will only do so temporarily. The Network Manager controls this essential /etc/resolv.conf file to create permanent changes. So, we’ll first stop and disable the Network Manager:

Note
Be sure to run these commands as the root user, or a privileged user using sudo before each command.

chkconfig NetworkManager off; service NetworkManager stop

 

Step 2: The method for permanent changes is to edit the /etc/sysconfig/network-scripts/ifcfg-eth0 file instead of resolv.conf file. Open the file:

vim /etc/sysconfig/network-scripts/ifcfg-eth0

Next, we’ll set our DNS IP’s to use Google’s Public DNS (8.8.8.8 & 8.8.4.4).

DEVICE="em1"
BOOTPROTO="static"
DNS1="127.0.0.1"

DNS2="8.8.8.8"


DNS3="8.8.4.4"

GATEWAY="some_ip"
HWADDR="hwid"
IPADDR="some_ip"
IPV6INIT="yes"
NETMASK="255.255.255.0"
NM_CONTROLLED="yes"
ONBOOT="yes"
TYPE="Ethernet"

Save and quit the file using ESC and :wq.

 

Step 3: Enable and restart your network, using the commands associated with your server version.

CentOS 6, CloudLinux 6, RHEL 6:

chkconfig network on

service network start

 

CentOS 7, CloudLinux 7, RHEL 7:

systemctl enable network.service

systemctl start network.service

 

Step 4: Test the reachability of a host by using ping, curl, wget or any testing tool of your choice. In our example, we’ve successfully ping’d Google!  

ping google.com
PING google.com (172.217.4.46) 56(84) bytes of data.
64 bytes from lga15s46-in-f14.1e100.net (172.217.4.46): icmp_seq=1 ttl=57 time=6.65 ms
64 bytes from lga15s46-in-f14.1e100.net (172.217.4.46): icmp_seq=2 ttl=57 time=6.68 ms
64 bytes from lga15s46-in-f14.1e100.net (172.217.4.46): icmp_seq=3 ttl=57 time=6.68 ms

You don’t have to rack your brain over connectivity issues!  Liquid Web customers enjoy 24/7 support for our Managed products. Our knowledgable team of support techs have experience with solving errors of this nature.  Access our support team through a ticket, chat or phone call!

Troubleshooting: MySQL/MariaDB Error #1044 & #1045 Access Denied for User

Reading Time: 1 minute

When using phpMyAdmin, it’s essential to have the correct user permissions to create edits/writes to the database.  Otherwise insufficent permissions can lead to  errors like the ones pictured below “#1044 – Access denied for user …[using password: YES]” and “#1045 – Access denied for user…[using password: YES]”.  In our tutorial, we’ll show you how to correct this issue using the command line terminal.  Let’s get started! Continue reading “Troubleshooting: MySQL/MariaDB Error #1044 & #1045 Access Denied for User”

How to Setup Let’s Encrypt on Ubuntu 18.04

Reading Time: 3 minutes

Sites with SSL are needed more and more every day. It’s ubiquitious enforcement challenges website encryption and is even an effort that Google has taken up. Certbot and Let’s Encrypt are popular solutions for big and small businesses alike because of the ease of implementation.  Certbot is a software client that can be downloaded on a server, like our Ubuntu 18.04, to install and auto-renew SSLs. It obtains these SSLs by working with the well known SSL provider called Let’s Encrypt. In this tutorial, we’ll be showing you a swift way of getting HTTPS enabled on your site.  Let’s get started! Continue reading “How to Setup Let’s Encrypt on Ubuntu 18.04”

How to Install Apache 2 on Ubuntu 18.04

Reading Time: 2 minutes

Apache is the most popular web server software in use today.  Its popularity is earned through its stability, speed, and security.  Most likely if you are building out a website or any public facing app, you’ll be using Apache to display it. At the time of this writing, the most current offering of Apache is 2.4.39, and it is the version we will be using to install on our Ubuntu 18.04 LTS server.  Let’s get started! Continue reading “How to Install Apache 2 on Ubuntu 18.04”

5 Android/iPhone Apps for IT Admins

Reading Time: 3 minutes

As administrators for our servers, we may find ourselves needing to do certain things while on the go. We may also not have a laptop or PC within reach. But one thing most of us have at all times is a cell phone. Whether we have an Android or an iPhone, most of us do possess a smartphone. One thing great about these smartphones is their constant connection to the Internet. Having that constant connection makes it simple to use various apps that assist with admin tasks through our smartphones. Here is a list of five applications available both on iPhone and Android. If you are interested in checking them out, click on your phone’s type next to the application name. You can also search for these applications by name in your smartphone’s app store. Continue reading “5 Android/iPhone Apps for IT Admins”

How Do I Secure My Linux Server?

Reading Time: 6 minutes

Our last article on Ubuntu security suggestions touched on the importance of passwords, user roles, console security, and firewalls. We continue with our last article and while the recommendations below are not unique to Ubuntu specifically (nearly all discussed are considered best practice for any Linux server) but they should be an important consideration in securing your server. Continue reading “How Do I Secure My Linux Server?”

Best Practices for Security on Your New Ubuntu Server: Users, Console and Firewall

Reading Time: 4 minutes

Thank you for taking the time to review this important information. You will find this guide broken down into six major sections that coincide with Ubuntu’s security policy guide. The major topics we talk on throughout these articles are as follows:

Continue reading “Best Practices for Security on Your New Ubuntu Server: Users, Console and Firewall”