Configure Nginx to Read PHP on Ubuntu 16.04

Nginx is an open source Linux web server that accelerates content while utilizing low resources. Known for its performance and stability Nginx has many other uses such as load balancing, reverse proxy, mail proxy, and HTTP cache. Nginx, by default, does not execute PHP scripts and must be configured to do so.  In this tutorial, we will show you how to enable and test PHP capabilities with your server.

Pre-Flight Check

  • This article assumes you are logged in as root and using Ubuntu 16.04 LTS server. If not logged in as root, please add sudo before each command or login as root user.
  • This article also assumes you have installed Nginx. If you have not yet installed Nginx or are unsure how to do so, please reference this easy to follow article
  • This article is tested using NGINX 1.10.3+,  older versions should work, but it’s a good idea to update to the latest version if available before you try to configure PHP.
  • This article will be running php7.0-fpm or later  (as of Dec 31, 2018, PHP 5.6 will be approaching “end of life” and no longer supported.)

 

Step 1a: Give Me the Packages!

First, we want to make sure our manager is up-to-date. Run the following command
sudo apt-get update && apt-get upgrade
You also want to make sure that your Nginx is up-to-date. You can check the current version by running this command. nginx -v
The result should return something like this.

Running the command nginx -v allows you to see which NGINX version you are currently using.

Note
Note: This article is using Nginx 1.10.3. If you need to update your Nginx version make sure you backup your configuration BEFORE you make any changes.

sudo cp /etc/nginx/nginx.conf   / etc/nginx/nginx.conf.1.x.x.backup

This article will NOT cover updating your Ngnix as its focus is for PHP configuration.

You can test your NGINX configuration file for syntax errors with the following command

nginx -t

If successful you should get something similar to the following
Test a NGINX configuration file for syntax errors using the nginx -t command.Using nginx -t should also give you a starting point to look for errors if for some reason this was unsuccessful it will return an error.

Note
Note: Ngnix should have started on its own after install. However, here are a couple of commands to keep on hand.

sudo systemctl stop nginx.service

sudo systemctl start nginx.service

sudo systemctl enable nginx.service

sudo systemctl restart nginx.service

Step 1b: PHP Version Check

Now it is time to check that your PHP version is running and using the correct version. You can do so with the following:

sudo systemctl status php7.0-fpm
You will see something similar to this if working properly:Check your PHP version is running and using the correct version.

Note
Note: If you need to install PHP you can run the following line :

sudo apt-get -y install php7.0 php7.0-fpm

Replace 7.0 with whatever version of PHP is the most recent. You can check for updates here.

Alternatively, if you need to update PHP to the latest version, please be sure you make a backup BEFORE any changes then run the following:

sudo apt-get upgrade

Step 2:Time for Some NGINX Configuration

Once you have verified that both PHP and Nginx are running on your system, it’s time to configure your PHP settings!

From home cd into your NGINX folder

cd ~

cd /etc/nginx
To configure your NGINX PHP settings. Cd into the etc/php folder.
cd etc/php/
Depending on which PHP version you are using the following folders may differ. This article is using PHP 7.0. You can replace the 7.0 with the version of PHP you are using. We are looking for a file called the php.ini file.

On PHP 7.0 and 7.1 that is located at :
vim 7.0/fpm/php.ini

Or
vim 7.1/fpm/php.ini
The php.ini  is a giant file but it’s where you can customize your environment. If this is your first time, it might be a good idea to make a copy of this file BEFORE you make any changes.
cp php.ini php.ini_copy
However, if you are pro and just like to read articles for the warm fuzzies you feel inside, then go ahead and edit away!

Note
First time using vim?  Use the I command to insert, Esc to exit and :wq to save the file. If you need to leave the file without saving that command is :q. Feel free to use whatever file editor you most comfortable with.
Here are a couple of the recommended values for the php.ini file.

max_execution_time = 300

max_input_time = 60

memory_limit = 256M

upload_max_filesize = 100M

Simply find these variables in the file and update the values.

Before Edit :Set the max_execution_time to 300 in the php.ini file.

After edit:Setting the max_execution_time to 300 in the php.ini file allows more processing time.

Step 2b: Default Sites Configuration

We are almost done!  Now it is time to set your default sites environment. Open your sites configuration file. It should be stored by default at the following path.

/etc/nginx/sites-available/default

You can cd there or open it right up with vim.

You want to remove the following commented out lines. Here is an example for both PHP7.0 and PHP 7.1

PHP 7.0
#
server {
listen 80 default_server;
listen [::]:80 default_server;
# SSL configuration
#
# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;
#
# Note: You should disable gzip for SSL traffic.
# See: https://bugs.debian.org/773332
#
# Read up on ssl_ciphers to ensure a secure configuration.
# See: https://bugs.debian.org/765782
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
# include snippets/snakeoil.conf;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name _;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
     location ~ \.php$ {
include snippets/fastcgi-php.conf;

#
#     # With php7.0-cgi alone:
#     fastcgi_pass 127.0.0.1:9000;
#     # With php7.0-fpm:
            fastcgi_pass unix:/run/php/php7.0-fpm.sock;
}

 

PHP 7.1
server {
listen 80;
listen [::]:80;
root /var/www/html;
index  index.php index.html index.htm;
server_name  example.com www.example.com;
location / {
try_files $uri $uri/ =404;
}
# pass PHP scripts to FastCGI server
#
     location ~ \.php$ {
             include snippets/fastcgi-php.conf;
  #
#     # With php-fpm (or other unix sockets):
            fastcgi_pass unix:/var/run/php/php7.1-fpm.sock;
#     # With php-cgi (or other tcp sockets):
#     fastcgi_pass 127.0.0.1:9000;
}
}

Step 3: Testing PHP on NGINX

Once you have made the necessary edits go ahead and restart NGINX and PHP with the following lines.
sudo systemctl restart nginx.service
To test your PHP configuration by creating a  phpinfo.php file in the /var/www/html file path.
sudo vim /var/www/html/phpinfo.phpAdd the following inside the file and save :
<?php phpinfo( ); ?>
To test your setup go to your server IP followed by /phpinfo.php in your web browser.

http://localhost/phpinfo.php

If you see the following then kick back and relax because you are all done! Congrats you deserve it!Set up a PHP info page to ensure PHP is enabled on your NGINX server.

Install Rsync and Lsync on CentOS, Fedora or Red Hat

Have you ever needed to copy files from your local computer over to your web server? You may have previously used File Transfer Protocol (FTP) applications for this task, but FTP is prone to being insecure and can be challenging to work with over the command line. What if there was a better way? In this tutorial, we’ll be covering two popular utilities in the Linux world to securely assist in file transfers, rsync and lsyncd. We’ll show you how to install and use both in this article. Let’s dig in!

 

What is Rsync?

The first utility we’ll look at is called rsync, and this command is a real powerhouse! Most simply, it is used for copying files between folders, but it has some extra features that make it very useful. We’ll start with the most basic usage for rsync, and work into more complicated examples to show you how versatile it can be.

 

Install Rsync on CentOS, Fedora, or Red Hat

If you are using CentOS, Fedora, or Red Hat, you can use the yum package manager to install:

Note:
You’ll need to be the “root” user to install packages!

yum install rsync

 

Install Rsync on Ubuntu or Debian

If you are using Ubuntu or Debian, you can use the apt-get package manager to install:

Note:
You’ll need to be the “root” user to install packages!

apt-get install rsync

 

How to Use Rsync

The syntax for running rsync looks like this:

rsync -options <source> <destination>

You are not required to specify “options”, but you’ll always need to tell rsync a source and destination.  In this example, we’re using rsync to copy “file.txt” into the “/path/of/destination/” folder:

rsync /path/of/source/file.txt /path/of/destination/file.txt

Important
When you run rsync, remember always to put the “source” first, and “destination” second!

Now that you have the basics let’s try another common task. In this example, we’re going to use rsync to copy a directory from our local computer over to our web server “192.168.0.100”.

rsync -avHl /path/of/source/folder root@192.168.0.100:/path/to/destination/folder

Notice how just as before, we specified our source first, and destination second. One of the great things about rsync is that it performs remote transfers of data securely, through SSH. Using SSH is fantastic from a security point of view, and it allows you to use SSH keys to avoid typing passwords.

As one last example, let’s try copying something from your remote server “192.168.0.100” over to your local machine. Once again, rsync is the tool for the job!

rsync -avH  root@192.168.0.100:/path/of/remote/folder /path/of/destination/folder

We used some special options in that last example. Let’s break them down.

-a = archive mode (includes several commonly used options: -rlptgoD, check the rsync man page for detailed info.)

-v = print verbose messages to screen, (very helpful!)

-H = preserve hard links when copying

One of the great things about rsync is that it intelligently copies files. If only the last few bits of a file has changed, rsync solely copies the changes, rather than the whole file. Transferring only the changed parts of a file can be a huge time saver, but especially when copying files remotely like in that last example.

 

Introducing Lsyncd

Finally, we’ll talk about lsyncd. The utility lsyncd is somewhat similar to rsync in that it is used to synchronize two folders. Unlike rsync, which has to be run manually, lsyncd is a daemon. Sounds scary, but in computer terminology, daemons are merely applications that run as a background process. You usually don’t have to manually run daemons every time you want to use them, as they are typically configured to start automatically when your server boots. When you configure lsycnd correctly, it can automatically synchronize folders between two computers. Imagine if you didn’t have to manually create backups of your website on your web server every time you made a small change? That could be a real time saver! Let’s dig in.

 

Install Lsyncd on CentOS, Fedora, or Red Hat

If you are using CentOS, Fedora, or Red Hat, you can use the yum package manager to install:

Note
You’ll need to be the “root” user to install packages!

yum install lsyncd

 

Install Lsyncd on Ubuntu or Debian

If you are using Ubuntu or Debian, you can use the apt-get package manager to install:

Note
You’ll need to be the “root” user to install packages!

apt-get install lsyncd

 

How to Use Lsyncd

Unlike rsync, lsyncd runs as a daemon. You don’t run it directly. Instead, it starts automatically with your server at boot time, and runs silently in the background. It’s a great automated way to sync folders on your server! All we need to do is configure lsyncd, so it knows what folders to sync.

First, we’ll create some files and folders.

Create the configuration folder location
mkdir /etc/lsyncd

Create a folder to sync FROM, feel free to name it what you would like
mkdir /source_folder

Create the folder to sync TO
mkdir /destination_folder

Create the log folder location
mkdir /var/log/lsyncd

Make the log file
touch /var/log/lsyncd.log

Create the status file
touch /var/log/lsyncd.status

This is an example file for our sync tutorial
touch /source_folder/hello_world.txt

Next, we need to configure lsyncd to use our newly created files. Open a new file for editing using your favorite Linux text editor.

vi /etc/lsyncd/lsyncd.conf.lua

Paste in the following configuration, and save the file.

settings = {
logfile = "/var/log/lsyncd/lsyncd.log",
statusFile = "/var/log/lsyncd/lsyncd.status"
}
sync {
default.rsync,
source = "/source_folder",
target = "/destination_folder",
}

Now all that remains is to start the program! First, we’ll tell lsyncd to start automatically when your server boots:

systemctl enable lsyncd

Next, we’ll start lsyncd manually, (this only needs to be done once.)

systemctl start lsyncd

We’ve successfully installed lsyncd, but it is good practice to double check your work. We’ll check to see if it is running using this command:

systemctl status lsyncd

If you see a line that reads: active (running), it is running correctly!

Finally, we check the contents of /destination_folder to make sure that it contains our “hello_world.txt” file.

ls -l  /destination_folder
total 0
-rw-r--r-- 1 root root 0 Nov 17 07:15 hello_world.txt

 

You should see that “hello_world.txt” has been automatically synchronized over to “/destination_folder”. Everything is working! In practice, you can set “/source_folder” and “/destination_folder” to any folders you need synchronizing.

As you can see, these two utilities rsync and lsyncd are great tools for copying files and folders in Linux. Have questions about how to use these tools on your Liquid Web web server? Reach out to the Most Helpful Humans in Hosting. We’re here to help, 24×7!

 

Create a Cron Task in Ubuntu 16.04

Cron jobs are an incredibly useful Linux tool aimed at saving you time by scheduling tasks within your server. A programmed cron task will execute commands within a script by the minute, day, week or month. They can be scheduled to do many tasks including backing up your server’s files nightly, updating inventory orders in a database or even compressing files for migrating. Repetitive tasks become a cinch when incorporating a cron job. While there are numerous ways to run a cron task, we will be using the crontab option that is inherent within Ubuntu to set up a nightly backup of our website.

Pre-flight

Log in to your Ubuntu 16.04 LTS server, preferably not as root if you aren’t altering anything on the server level.

Setting Up a Website Backup through Cron

Step 1: Update your server. As a best practice, we will update and upgrade our server with the following command.

apt-get update && apt-get upgrade

 

Step 2: Verify if the cron package is installed.
dpkg -l cronOur example output let’s us know that the cron package is installed, along with its version:
||/ Name Version Architecture Description
+++-=========================-=================-=================-========================================================
ii cron 3.0pl1-128ubuntu2 amd64 process scheduling daemon

Install cron package if necessary.
sudo apt-get install cron

Ensure that the cron service is running with the following command:
systemctl status cronExample Output:
* cron.service - Regular background program processing daemon
Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2018-10-27 02:53:20 EDT; 5 days ago

 

Step 3: Configure the cron job. When you are logged in as your user, you are creating a cron job under that user. Creating a cron jobs owner is helpful when to know who is in charge of the cron as well as how to alter the cron job in the future.

crontab -e

The system asks which editor you’d like to use; this tutorial is using option 2 (vim.basic).

tom@host2:~$ crontab -e
no crontab for tom - using an empty one
Select an editor. To change later, run 'select-editor'.
1. /bin/ed
2. /usr/bin/vim.basic
3. /usr/bin/vim.tiny
Choose 1-3 []: 2

In this file, you’ll see # signs followed by the direction on how to use the file. Allow us a minute to explain the syntax needed to create a cron task.

# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * user-name command to be executed

Each set of digits designates the time for that section and follows the time set in your server The first set represents minutes, the next set hours, the next set day of the month and so on. You may be asking yourself what the asterisk mean. They represent every or all value for that set. So, if you put an asterisk on the month column, you’ll be telling the system to perform the tasks every month.

After the digits section is the /bin/sh and the type of file that should be executed, lastly, the final column assigns the command of which to run.

Backup Cron:
Let’s say you want to backup your website files daily. Our example uses 4 am since server traffic is low during this time. Take note of the .sh extension, indicating a bash script. Use the appropriate extension for your script. Be sure to save the script when exiting with :wq

crontab -e

After altering the /path/to/script/backup-script.sh path to match the location of your script, set the command in a new line, below the hashtag (#), like so:

# m h dom mon dow command
0 4 * * * /bin/sh /path/to/script/backup-script.sh

 

Step 4: Place Script in Path. Most importantly is the creation and placement of your script. With our example script we are creating a backup that will compress files and directories, indicated by the /SOURCE/DIRECTORY/. The /SOURCE/DIRECTORY/ needs to be alter to the directory and files you wish to save (sometimes a website’s default directory path is /var/www/html), while the /DESTINATION/DIRECTORY/file.zip indicates where the compressed backup are stored. We will name the script backup-script.sh, and afterwards, we will create the script in the location of /path/to/script/backup-script.sh.

vim backup-script.sh

#!/bin/sh
zip -9pr /DESTINATION/DIRECTORY/file.zip /SOURCE/DIRECTORY/

 

Note:
If you are running this script multiple times it will overwrite the file.zip each time, thus it runs it will only store one backup.

Set execute permissions this allows the system permission to run the script.

chmod +x backup-script.sh

When the time of execution has passed, check your /DESTINATION/DIRECTORY/ to see file.zip. YYou now have backups of your files running daily! It’s best to come up with a plan to offload your backups to another location other than your server. Pushing backups to an offsite location not only adds a layer of security but aids in saving server disk space. Check out our Cloud Object Storage for cost-effective storage solution that is accessible via API call. If you are having trouble with your cron check out our other helpful article, Troubleshooting: Cron Jobs.

 

Install TeamViewer on Ubuntu 16.04 LTS

VNC (Virtual Network Computing) is a method for sharing a remote desktop environment. Allowing you to remote control another computer or server over the Internet or local network as if you were sitting in front of it. Keyboard and mouse strokes from your computer are relayed to the remote computer/server. There are many different kinds of VNC softwares available today. Several are cross-platform and add additional features, such as chat or file transfers. VNC is often used for remote technical support and remotely accessing files.

Have you ever wanted to open a file manager and browse your server’s files? Have you ever wanted to open a browser on your server and use it as a VPN? TeamViewer will allow you to do that without much effort. Once TeamViewer is set up on your server, accessing your server takes only a couple of clicks. Many additional features such as chat, file transfers, and wake-on-LAN are available through TeamViewer. They also offer monitoring, asset tracking, anti-malware, and backups for an additional fee.

TeamViewer supports text-based consoles as well as a GUI (Graphic User Interface). If you want to use TeamViewer without using a GUI you can skip installing a desktop environment and window session manager and go straight to the Installing TeamViewer section. However, for this guide, we will assume that remote control of a desktop environment is needed or otherwise wanted.

Prerequisites

You will need to have a server running Ubuntu 16.04 LTS with a desktop environment and a window session manager. There are many different types of desktop environments and window session managers you could install. There is plenty of debate in the Linux community, but for this guide, we recommend going with something lightweight. For that we suggest Xfce.  Another good option is LXDE which is again known for being lightweight and used in many different operating systems as the default desktop environment. Gnome, Mate, and KDE are also noteworthy. Like desktop environments, there are many window session managers and some even come with the desktop environment! We recommend using LightDM with Xfce. LightDM is easy to install and configure and is also very lightweight. You’ll need a TeamViewer account with your login credentials handy, along with the TeamViewer client installed on your local computer, or you can use the web client which requires Flash.

Once you have your Ubuntu 16.04 LTS server up and running, install the desktop environment and window session manager. For our build, we’ve installed Xfce with our Knowledge Base article. Next, install LightDM by running:
sudo apt install lightdmOnce installed you will need to configure it to use Xfce. You can do that by creating a file called /etc/lightdm/lightdm.conf using your favorite text editor and adding the following configuration settings:
sudo vim /etc/lightdm/lightdm.conf
[SeatDefaults] allow-guest=false
user-session=xfce

 

TeamViewer prefers connections using UDP and TCP on port 5938, but if that port is not available, it falls back to ports 80 (HTTP) or 443 (SSL). Port 80 is used only as a last resort and is not recommended due to the additional overhead.  Making connections over this port results in a laggy experience. If you are running firewalld use these commands to open port 5938:
sudo firewall-cmd --zone=public --add-port=5938/tcp
sudo firewall-cmd --zone=public --add-port=5938/udp
If you are using ConfigServer Security & Firewall (CSF) you will need to edit the configuration file. Open the file with your favorite text editor and add the port number to the lines that start with TCP_IN and UDP_IN. Remember to separate your port numbers with commas and then restart the firewall.
sudo vim /etc/csf/csf.conf
sudo csf -r

TeamViewer communicates on port 5938, if you use ConfigServer Security & Firewall (CSF) its necessary to add this port to the configuration file.

The firewall ports are open now that you’ve installed the desktop environment and window session manager. You can now reboot the server. Upon boot, the server will startup Xfce and LightDM.
shutdown -r now

 

To install TeamViewer, you first need to download the package:
wget https://download.teamviewer.com/download/linux/teamviewer-host_amd64.debThen use apt to install the package:
sudo apt install ./teamviewer-host_amd64.deb
During installation, TeamViewer adds the file /etc/apt/sources.list.d/teamviewer.list (DEB), which contains information about the repository. Apt update & upgrade allows you to keep the software up-to-date by simply running:
sudo apt update
sudo apt upgrade
Once TeamViewer is installed you will need to configure it for first time use.
sudo teamviewer setup

TeamViewer will prompt you to accept the license agreement and then ask you for your username and password for your TeamViewer account. The first time that you login TeamViewer will most likely send you an email to verify that you are trying to login to your account from a new location (i.e., your server). Until verified through email it will not allow you to log in until you confirm the new location. Check your inbox and spam folder for their email and click the link to approve the new login location. Afterward, go back to your server and re-enter the username and password to log in.

TeamViewer asks if you would like to add the server to “My computers” on your account. If you get a connection error make sure your server is connected to the Internet and that the proper ports are open in the firewall. Run:

sudo teamviewer setup

If everything goes as planned you should see something like this:The TeamViewer setup screen with ask for your email and password, necessary for future logins.

Now that TeamViewer is installed you can now connect to your server remotely with your TeamViewer client or by logging in with your account to https://login.teamviewer.com/LogOn. You will now see your server listed under “My computers” in TeamViewer. Just double-click on your server under “My computers” and it will connect to your Ubuntu server. Here is an example TeamViewer connected to my Ubuntu 16.04 LTS running Xfce and LightDM:An example TeamViewer connected to my Ubuntu 16.04 LTS running Xfce and LightDM.

You now know how to setup TeamViewer on Ubuntu server 16.04 LTS! If you are already a Liquid Web customer, feel free to contact The Most Helpful Humans™ with questions you may have in setting up a TeamViewer on Ubuntu 16.04 LTS.  We also have some more useful articles about Ubuntu.

Cloud Spectator is an independent, third-party cloud analytics confirms Liquid Web’s VPS servers outperform Rackspace, Amazon, and Digital Ocean across the board.

 

 

Transfer an SSL to Ubuntu 16.04 or CentOS 7

SSL certificates have become a de facto part of every website. If you don’t yet have an SSL on your site to encrypt data, you should. Rather than showing an extra layer of security on sites protected by SSL, modern browsers instead now display a warning when a website does not have an SSL, essentially requiring sites to maintain their positive image.

When moving from one server to another, what needs to happen to your SSL to maintain your secure status? We’ll cover the basics for transferring traditional and Let’s Encrypt SSLs to Ubuntu 16.04 and CentOS 7.

Note:
This article will address SSLs in Apache specifically, but the same concepts apply to any service that supports SSL encryption.

Can SSLs be transferred between servers?

Absolutely! An SSL consists just of a handful of text files and a bit of configuration for the secure service. Additionally, there is a misconception that certificates are tied permanently to their IP address or physical server, but this is not true. In reality, they are linked only to the domain name(s) listed the certificate and are very migratable. Technically, an SSL can be used on multiple servers or services to protect the same domain name. We will leverage this concept to help us move our SSLs.

Prerequisites

You will need to have a copy of your SSL Certificate and SSL Private Key, as well as any ‘Chain Certificates.’ Often these will be two separate files, called domain.com.crt for the certificate, and domain.com.key for the private key, as well as an additional signing_authority.crt file for the chain certificate. Another popular naming convention for these files is cert.pem and key.pem, but sometimes they have no file suffix at all (.pem or .crt).

How can you tell where to get these files?  We’ll get into how to determine the locations for these configurations first.

Step 1: Collecting SSL Files

Debian SSL File Location

In distributions of Linux, including Ubuntu, you can check the loaded virtual hosts on Apache using:

apache2ctl -S

 

CentOS SSL File Location

For RHEL based distributions, including CentOS, you can use:

httpd -S

 

Both of these commands will list the running configuration settings, including all loaded virtual hosts and their configuration file locations. We’re looking for the domain name of the SSL we want to copy, and the HTTPS port 443. On my Ubuntu test machine, for example, this line is the output for the domain in question:

port 443 namevhost domain.com (/etc/apache2/sites-enabled/domain.com.conf:1)

Since we are copying the SSL for the domain.com domain, we’ll check this configuration file, and look for the virtual host block that references port 443.

vim /etc/apache2/sites-enabled/domain.com.conf

Searching through the file, we find:

<VirtualHost *:443>
ServerName domain.com
ServerAlias www.domain.com
DocumentRoot /data/www/domain.com
SSLCertificateFile /etc/ssl/domain.com/cert.pem
SSLCertificateKeyFile /etc/ssl/domain.com/privkey.pem
SSLCertificateChainFile /etc/ssl/domain.com/chain.pem
</VirtualHost>

This block of text describes all three files that we need to bring to the new server: the certificate file (cert.pem), the private key (privkey.pem) and the intermediate certificates (chain.pem).

 

Step 2: Copying SSL Files

From the file paths we discovered in the last step, we know that all of the SSL files for this site exist in the /etc/ssl/domain.com directory. So, we can copy this whole folder to the new server using the rsync tool. Assuming that the old server has an IP of 123.45.67.89, hop over to your new server, and run the command below. Trailing slashes (/) are very important for this command!

mkdir -p /etc/ssl
rsync -avz root@123.45.67.89:/etc/ssl/domain.com /etc/ssl/

This method preserves the ownership and permissions of these files, so we should not have to do anything else in that regard.  Our next section, step 3, is split into two sections.  Pick step 3A if you’re new server is Ubuntu 16.04 or step 3B if you new server is CentOS 7.

 

Step 3A: Setting up Apache on the new server (Ubuntu 16.04)

A non-SSL virtual host set up is necessary for your domain on the new server. If you have not yet done so, you will need to install and activate mod_ssl to allow Apache to parse SSL communication on the target machine:

apt-get install mod_ssl
a2enmod ssl

If you get a message that mod_ssl is not available for installation, its possibly installed through a different package. Check to see if that is the case:

dpkg -S mod_ssl.so

If this returns a positive result, you ‘ll run:

a2enmod ssl to complete the activation. After enabling mod_ssl, restart Apache:

systemctl restart apache2

Lastly, there is one configuration file to change, which will allow serving named virtual hosts. The activation of the SSL module lets Apache listen on port 443, but we need to be able to host multiple sites per IP. Open up the /etc/apache2/ports.conf file:

vim /etc/apache2/ports.conf

Ensure that the contents mimic this output:

<IfModule ssl_module>
NameVirtualHost *:80
Listen 80
NameVirtualHost *:443
Listen 443
</IfModule>

Specifically, we are ensuring that the NameVirtualHost lines are present. Once this is true, we can test and reload the configuration to bring it into effect:

apachectl configtest
systemctl reload apache2

Note:
Even though enabled sites have configurations listed in /etc/apache2/sites-enabled/, the actual configuration files should live in /etc/apache2/sites-available/, so that the apache control scripts can turn sites on and off. The sites-enabled folder consist exclusively of symlinks to configurations in sites-available.

Next, we must add a configuration for the website to call the SSL files we just copied over. If you are using the same document root on the new server as on the old, you can copy and paste the original virtual host block into a new configuration file in /etc/apache2/sites-available/. Be sure to update referenced IPs to match the new server.

If there are differences in the running modules or other customizations performed on the new machine, make a copy of the existing non-SSL virtual host block on the target server into a separate file. Also, under /etc/apache2/sites-available/, update the port number, and add the three lines for the SSL files. For our example, I copied and pasted the exact contents of the old file into /etc/apache2/sites-available/domain.com_ssl.conf.

After having done so, we run:

a2ensite domain.com_ssl

This links the configuration into the /etc/apache2/sites-enabled/ folder. This site name will change depending on what you named the configuration file (just cut off the .conf). Next, we test this new configuration:

apachectl configtest

If everything comes back OK, we can reload the configuration files for the apache2 service:

systemctl reload apache2

 

Step 3B: Setting up Apache on the new server (CentOS 7)

Each command line operation for CentOS is very different, but the overall procedure is the same, and the configuration files will have similar content. First, confirm that Apache is configured to support SSL traffic:

yum install mod_ssl

This installation procedure should automatically set up a ssl.conf file for you in /etc/httpd/conf.d/ for listening on port 443 and restart Apache, but it may not enable named virtual hosts. Make sure you add the following line to your httpd.conf file as well if it is not already present. Adding these lines allows you to serve multiple sites per IP address using virtual host blocks.

<IfModule mod_ssl.c>
NameVirtualHost *:443
</IfModule>

Next, we must add a configuration for the website to call the SSL files we just copied over. If you are using the same document root on the new server as on the old, copy and paste the original virtual host block into a new configuration file in /etc/httpd/conf.d/, making sure that the IP addresses are updated to match those on the target server.

If there are differences in the running modules or other customizations performed on the new machine, you can make a copy of the existing non-SSL virtual host block on the target server into a separate file. Also, in /etc/httpd/conf.d/, update the port number, and add the three lines for the SSL files.

Once created, test the configuration syntax of the file:

httpd -tThe output will either say ‘Syntax OK’ or tell you what file and line is problematic. If everything is okay, you can reload the configuration for Apache:

systemctl reload httpd

 

What if I use Let’s Encrypt?

Let’s Encrypt SSLs are just as transferable as any other SSL, but manually creating an SSL virtual host config file sometimes causes conflict with future installations of Let’s Encrypt. So, there is a particular procedure to be followed.

Transferring Let’s Encrypt Installations

First, Let’s Encrypt should be installed on the new server. For Ubuntu 16.04, that looks like this:

add-apt-repository ppa:certbot/certbot
apt-get update
apt-get install python-certbot-apache

 

For CentOS 7, use these commands:

yum install epel-release
yum install python-certbot-apache

Once installed on either distro, set a cron to renew the certificates automatically. You can set these up by running

crontab -e as the root user. The cron on my Ubuntu machine looks like this:

45 2 * * 6 /usr/local/letsencrypt/certbot-auto renew && systemctl reload apache2

On my CentOS server, it looks like this:

45 2 * * 6 /usr/local/letsencrypt/certbot-auto renew && systemctl reload httpd

Next, we can bring over the entire /etc/letsencrypt directory, which houses the configuration files. This directory holds the certificates and the keys themselves. On the new server, we run:

rsync -avz 123.45.67.89:/etc/letsencrypt /etc/

Now that the files are in place, we can have Let’s Encrypt reinstall all of the certificates we synced over:

/usr/local/letsencrypt/certbot-auto install --apache

Running the command presents a numbered list of the certificates in the /etc/letsencrypt folder. Select the number for the site you’d like to set up a configuration for, and it will create your configuration file; Once done, you only need to reload Apache:

systemctl reload apache2 #ubuntu
systemctl reload httpd #centos

 

Step 4: Confirming operation

The new server can now be tested using hosts file modification, detailed in this article. It’s truly is the best way to test the functionality of a migration target, as both browser and server believe that this is real traffic on the real domain name.

Once you set up your hosts file and flush your DNS cache, you should simply be able to load up the website in your browser using https, and see your website secured with the original certificate on the target machine! No worries though; live traffic is still routed to the original server with the same SSL, so your site visitors will not notice your testing.

After you finish testing your SSL installations and have confirmed that your websites are working well on the new server, DNS for the migrated sites can be updated to make the new server live.

If you are using Let’s Encrypt, it is important to keep your certificate expiration dates in mind. For instance, if your certificates are slated to expire in 7 days, you will want to update DNS promptly after the transfer, so that the new server can take over certificate renewals. If you miss this window and the certificate renews on the source server, you can simply re-run the rsync command where we collected /etc/letsencrypt:

rsync -avz 123.45.67.89:/etc/letsencrypt /etc/

Need help ordering a signed SSL or ordering a new server for your migration target? Chat with our solutions team!

 

How to Use Ansible

Ansible symbolAnsible is an easy to use automation software that can update a server, configure tasks, manage daily server functions and deploys jobs as needed on a schedule of your choosing. It is usually administered from a single location or control server and uses SSH to connect to the remote servers. Because it employs SSH to connect, it is very secure and, there is no software to install on the servers being managed. It can be run from your desktop, laptop or other platforms to assist with automating the tedious tasks which every server owner faces.

Once it is configured, Ansible performs tasks based on an ordered list of assignments in what is called a Playbook. The Playbook outlines what tasks need to be run on the remote server and in what order. Once this is configured, Ansible acts like a bash for-loop command that allows a section of code to be repeated over and over again. The difference between using a bash command and Ansible is that Ansible is idempotent. The term Idempotent sounds a little scary, but it merely means that you can make the same type of request over and over again and unless something has changed, you will get the same result.

Pre-flight: Server Requirements

Source Server Requirements

Ansible requires the installation of Python 2.7 or Python 3.5 on the source server. The source server is where you will be running the tasks in the playbook for the remote servers. The remote servers receive commands defined in the playbook.  A playbook is a file which defines the scripts that will be run on the remote servers.

Note:
Unfortunately, Windows is unsupported as a source server. Certain Ansible plugins and/or modules will have other needs or requirements. Usually, these plugins or modules are installed on the same server of the Ansible installation.

Let’s start by installing Python on the source server.
root@test:~# apt-get install python

 

Target Server Requirements

The only requirement from the target server is an open SSH port. Access can also be granted for scp (secure copy) and/or SFTP connections if configured in the /etc/ansible/ansible.cfg file.

Install Ansible On Ubuntu 16.04

To install Ansible on a source Ubuntu server, let’s follow these steps:

Note:
The PPA for Ansible is here: https://launchpad.net/~ansible/+archive/ubuntu/ansible if you would like to review the versions available for your variant of Ubuntu.

root@test:~# apt-get update
root@test:~# apt-get install software-properties-common
root@test:~# apt-add-repository ppa:ansible/ansible
root@test:~# apt-get update
root@test:~# apt-get install ansible
(install text)After this operation, 42.0 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Answer “Y” to the prompt. The install will complete and take you back to the command prompt. Now, let’s check the version of Ansible installed.

Check Ansible Version

root@test:~# ansible --version
ansible 2.7.0
 config file = /etc/ansible/ansible.cfg
 configured module search path = [u'/root/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
 ansible python module location = /usr/lib/python2.7/dist-packages/ansible
 executable location = /usr/bin/ansible
 python version = 2.7.12 (default, Dec  4 2017, 14:50:18) [GCC 5.4.0 20160609]

As an alternative, you can also install Ansible on your CentOS 7 server.
Ansible also can be installed on RedHat, Debian, MacOS, and any of the BSD flavors!

Install Ansible on CentOS 7

In order to install Ansible on a source CentOS 7 server, follow these steps.
First, we need to make sure that the CentOS 7 EPEL repository is added:

[root@test ~]# cat /etc/redhat-release
CentOS Linux release 7.5.1804 (Core)

[root@test ~]# yum install epel-release
Loaded plugins: fastestmirror, priorities, universal-hooks
Loading mirror speeds from cached hostfile

...
Resolving Dependencies
--> Running transaction check
---> Package epel-release.noarch 0:7-11 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
==========================================================================================================
Package Arch Version Repository Size
==========================================================================================================
Installing:
epel-release noarch 7-11 system-extras 15 k
Transaction Summary
==========================================================================================================
Install 1 Package
Total download size: 15 k
Installed size: 24 k
Is this ok [y/d/N]: y
Downloading packages:
epel-release-7-11.noarch.rpm | 15 kB 00:00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : epel-release-7-11.noarch 1/1
Verifying : epel-release-7-11.noarch 1/1
Installed:
epel-release.noarch 0:7-11
Complete!

Select “y”. The EPEL repo will then be added. Once the repository is enabled, we can install Ansible with yum:

root@test:~# yum install ansible
Loaded plugins: fastestmirror, priorities, universal-hooks
Loading mirror speeds from cached hostfile
epel/x86_64/metalink                                                               | 18 kB 00:00:00
* EA4: 208.100.0.204
* cpanel-addons-production-feed: 208.100.0.204
* epel: mirrors.liquidweb.com
epel                                                                               | 3.2 kB 00:00:00
(1/3): epel/x86_64/group_gz                                                        | 88 kB 00:00:00
(2/3): epel/x86_64/updateinfo
(3/3): epel/x86_64/primary                                                         | 3.6 MB 00:00:00
epel                                                                                          12756/12756
Resolving Dependencies
… (dependencies check)
Dependencies Resolved
==========================================================================================================
Package                        Arch Version            Repository Size
==========================================================================================================
Installing:
ansible                        noarch 2.4.2.0-2.el7            system-extras 7.6 M
Installing for dependencies:
21 k
Transaction Summary
==========================================================================================================
Install  1 Package (+17 Dependent packages)
Total download size: 12 M
Installed size: 58 M
Is this ok [y/d/N]:


Select “y” to start the Ansible install:

Is this ok [y/d/N]: y
… Downloading 18 packages:
----------------------------------------------------------------------------------------------------------
Total                                                                      30 MB/s | 12 MB 00:00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
… (installing 18 python related software)
...
Installed:
ansible.noarch 0:2.4.2.0-2.el7
Dependency Installed:
... (dependencies verified)
Complete!

Check Ansible Version on CentOS 7

Now, let’s verify the version installed:

root@test ~]# ansible --version
ansible 2.4.2.0
config file = /etc/ansible/ansible.cfg
configured module search path = [u'/root/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules'] ansible python module location = /usr/lib/python2.7/site-packages/ansible
executable location = /usr/bin/ansible
python version = 2.7.5 (default, Jul 13 2018, 13:06:57) [GCC 4.8.5 20150623 (Red Hat 4.8.5-28)]

 

Setting Up Ansible Connections

Initially, we will be adding server names or IP’s to the /etc/ansible/hosts file to identify which “ungrouped” servers and “groups” of servers we are going to be connecting to. We mention ungrouped and grouped in this specific order because this is the way the Ansible hosts file is usually arranged.

We can use any name we like for the hosts file itself but typically it is just called hosts. Ansible also states that the hosts file can also be identified as an inventory file and, you can have multiple inventory files.

Let’s start by opening the hosts file with vim and inserting some entries into the file.

root@test:~vim /etc/ansible/hosts
Here is what the default hosts file will look like:

# This is the default ansible 'hosts' file.
#
# It should live in /etc/ansible/hosts
#
# - Comments begin with the '#' character
# - Blank lines are ignored
# - Groups of hosts are delimited by [header] elements
# - You can enter hostnames or ip addresses
# - A hostname/ip can be a member of multiple groups
# Example 1: Ungrouped hosts, specify before any group headers.
#green.example.com
#blue.example.com
#192.168.100.1
#192.168.100.10
# Example 2: A collection of hosts belonging to the 'webservers' group
#[webservers] #alpha.example.org
#beta.example.org
#192.168.1.100
#192.168.1.110
# If you have multiple hosts following a pattern you can specify
# them like this:
#www[001:006].example.com
# Example 3: A collection of database servers in the 'dbservers' group
#[dbservers] #
#db01.intranet.mydomain.net
#db02.intranet.mydomain.net
#10.25.1.56
#10.25.1.57
# Here's another example of host ranges, this time there are no
# leading 0s:
#db-[99:101]-node.example.com


As you can see, there are individual servers “#
green.example.com”, and groups like #[webservers] which have multiple servers under the group and, another section with multiple servers listed like #db-[99:101]-node.example.com which identifies all of the individual servers from 99-101; eg.

  • db-99-node.example.com
  • db-100-node.example.com
  • db-101-node.example.com

So, let’s quickly add another server to the #[webservers] group:

#[webserver1]
#alpha.example.org
#beta.example.org
#192.168.1.100
#192.168.1.110gamma.example.com

Now, simply save the file using :wq

Note:
Make sure you uncomment any ‘#’ entries you place in the file otherwise, the entry is excluded!

 

SSH Keys

You can set up public SSH keys from the control server to log in to those remote servers noted in the hosts file. In this case, you simply want to make sure your local SSH keys are located in the /root/.ssh/authorized_keys file on the remote systems. (Depending on your setup, you may wish to use Ansible’s –private-key option to specify a .pem file instead)

 

Verify Ansible Connections

The ansible inventory file (/etc/ansible/hosts) contains the server names you will have control over and can run tasks against. To verify Ansible’s connectivity, run:

ansible remote -m ping

 

Ansible Playbooks

Ansible playbooks (also called inventory files) define the tasks ran on the remote servers. You can have one playbook or multiple playbooks to accomplish different tasks on different servers.  To easily apply a task to all of the servers in a pool, use the ‘group’ name to apply the task for that group (using the example above, you would use the [webserver1] in the command.

 

Create a Playbook

Step 1: In order to create a playbook, let’s create a new file in the /etc/ansible/playbooks/ folder:

mkdir -p /etc/ansible/playbooks/ && touch /etc/ansible/playbooks/playbook.yml && vim /etc/ansible/playbooks/playbook.yml

 

Step 2: Let’s add a server and file entry into the playbook filer:

(Click the insert key to open VIM’s edit access on the file)

- hosts: gamma.example.com
 tasks:
     - name: Create file
       file:
           path: /tmp/test.txt
           state: touch


Once we have added the entry, let’s save the file using

:wq

Step 3: Now, to set up 0644 permissions on that file, we can reopen it and add another line defining the permission set:

- hosts: gamma.example.com
 tasks:
     - name: Create file
       file:
           path: /tmp/test.txt
           state: touch            mode: "u=rw,g=r,o=r"

Again, let’s save the file using

:wq

Step 4: Next, let’s create a folder and then place a text file in it using Ansible. We will add another section defining the element needed:

- hosts: gamma.example.com
 Tasks:       - name: Create folder
       path: /home/tmp/
           state: directory
           mode: 0755
     - name: Create file
       file:
           path: /home/tmp/test.txt
           state: touch            mode: "u=rw,g=r,o=r"

Once we have added this entry, save the file using

:wq

 

Running a Playbook

To start a playbook, simply run:

ansible-playbook /etc/ansible/playbooks/playbook.yml

or if you have multiple playbooks in a folder, can run a specific playbook using the -i <path> option from the command line:

ansible-playbook -i /etc/ansible/playbooks/playbook1.yml
In addition to .yaml files, Ansible can use .json files as well to control the playbook. It is also very easy to convert 
bash or shell scripts into playbooks as well!

Schedule a Playbook Using Cron

As an additional option, you can schedule a playbook to run at a specific time using your servers cron command! To accomplish this, log in to your server as root and run the following command:

crontab -e
This command opens a temporary cron file in your system’s 
default text editor and then simply add a line like so:

0 4 * * * /usr/bin/ansible-playbook /etc/ansible/playbooks/playbook.yml
this will run the
/etc/ansible/playbooks/playbook.yml file at 0400 a.m. using the ansible-playbook command.

 

Troubleshooting A Playbook

Sometimes, a set of commands in the playbook file may fail. If it does, you have several options to address this. Generally, playbooks will simply stop completing the commands in the playbook. If this occurs, you can define a follow-up task in the playbook to overlook the error by adding another section like so:

- name: ignore this error
 command: /bin/false
 ignore_errors: yes


Unreachable Hosts

this command will only work when the task is run but returns a “failed” value.

If Ansible fails to connect to a server, it will set the host as being ‘UNREACHABLE’. This effectively removes the server temporarily from the list of active hosts for that task. To correct this, we can use an entry to reactivate them and have all current hosts previously indicated as being unreachable cleared, so subsequent tasks can use the playbook again.

meta: clear_host_errors


Handlers and Failure

A handler is simply a specially named task that runs when told to by another task. Handlers are executed at the end of the playbook by default as opposed to other tasks, which are executed immediately when defined within the playbook. This behavior can be modified by using the

--force-handlerscommand-line option, or by including

force_handlers: Truein a playbook, or addingforce_handlers = Truein the ansible.cfg file.


If you want to force a handler to run in the middle of two separate tasks instead of at the end of the playbook, you will need to add this entry between the two tasks:

- meta: flush_handlers

When handlers are “forced” like this, they will run when notified even if a task fails on that host.

Note:
Certain errors can still prevent the handler from running, such as a host becoming unreachable.
Handlers will only be visible in the output if they have actually been executed. Also, handlers are only fired when there are changes made by a task. For example, a task may update a specific configuration file and then notify a handler to restart a service. If a task in the same playbook fails later on, the service will not be restarted despite the previous configuration change.

Overall, Ansible is an indispensable tool for managing and administrating a single server or an entire group of geographically diverse servers.

 

Setup a Development Environment in Ubuntu

Often we want to edit our domain’s code, but on a production website, this can be dangerous. Making changes to the production site would not only allow all of the Internet to see unfinished changes but could also cause errors to display. As a workaround, we’ll create a testing domain or “dev” domain to work out any bugs and changes to the site.

As a warning, this is advanced technical work. It’s possible to make mistakes and cause downtime on your live domain. If you are not 100% confident, it may be a good idea to hire a system admin or developer to copy the domain for you.

Pre-flight

Step 1: After logging in as root, back up the domain using the command below to save a compressed version. It’s essential to have a copy of your site just in case you run into any issues. Replace the brackets and the “domainname” with your site’s name.

tar cfv backup.[domainname].tar /document/root/of/the/domain/

 

Step 2: We will be moving our backup file, .tar, somewhere off that document root, This way we can still access the data while keeping it safe.

mv backup.[domainname].tar /another/location/on/the/server

 

Step 3: The tar command created a file that comprises only half of the site, which holds the files. Next, you will want to copy the database for the primary site.

mysqldump [database_name] > /another/location/on/the/server/backup.[database_name].sql

 

Step 4: Create the new dev account, just like you were adding a new domain to your server. However, you will be creating a subdomain which you can name as dev.[domain].com.

 

Step 5: Once you’ve created the dev subdomain, copy the files from the main document root to the newly created dev document root. The document root is the location of the files housing your domain, also known as the “path”.

To find the document root location, for either domain, run the following command. Find the document root by replacing “exampledomain.com” for each both the live and dev domain.

conf=$(apache2ctl -S | grep exampledomain.com | perl -n -e '/\((\/.*)\:/ && print "$1\n"'); grep -i documentroot $conf

 

Step 6: After you have found the document roots for both the domain and dev domain, you will need to copy the files. With the output of the last command, you’ll insert the path for the document roots.

rsync -avh /document/root/of/the/domain/ /document/root/of/the/new/dev/domain

 

Step 7: Give the correct ownership to the dev domain, as the previous username remains in place. The ‘dev_username’ is a default user, one generated by creating the new account. The following command will change the ownership for you.

chown -R [dev_username]: /document/root/of/the/new/domain

 

Step 8: After you have done this you will need to create a new database and database user for the dev domain, be sure to keep all this information including the password you set. First, enter the mysql command prompt by running the command:

mysql

Next, create the database itself.

CREATE DATABASE [new_database_name];

In our next command, we create the user and their password. Be sure this is a unique username, unused up till now.

CREATE USER '[select_new_username]'@'localhost' IDENTIFIED BY '[password]';

 

Step 9: Grant privileges for the user on the database.

GRANT ALL PRIVILEGES ON [new_database_name] TO '[new_username]'@'localhost' WITH GRANT OPTION;

Then exit out of mysql by typing “quit” and hitting enter:

quit

 

Step 10: Once back at the root command prompt, you can start copying the original database into the new database.

mysqldump [new_database_name] < /home/temp/backup.[database_name].sql

With the database dumped you will still need to edit the configuration files for your domain. Typically, there are files which need to access the database and will reference the database, database user, and password. These credentials need updating to the ones created earlier in step 8 of this tutorial. If you are unsure of where these files contact a developer. If you are working with a WordPress site continue on to the next section.  Otherwise, if you have updated your dev configuration files with your new database info continue onto step 11.

Editing WordPress Configurations

Fortunately, WordPress is one of the most commonly used content management systems. WordPress is easy to configure we’ll provide a short tutorial on how to change the database and database user in the wp-config.php. First, move to the new document root.

cd /document/root/to/the/dev/domain

There you will edit the wp-config.php with your favorite text editor such as vim or nano.

nano wp-config.php

In the wp-config.php file, you will see a section that looks like the below. From there you will edit the highlighted characters with the information you used to create the database in the tutorial.

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'new_database_name');
/** MySQL database username */
define('DB_USER', ‘new_database_user');
/** MySQL database password */
define('DB_PASSWORD', 'password');

In the database, clear all mentions of the original domain and replace them with the dev domain. For example with WordPress, in the _options table you need to change two entries of ‘home’ and ‘siteurl’. These can be quickly changed using WP-ClI, which is a is a command line tool for interacting with and managing WordPress sites.  To install WP-CLI follow these instructions and continue onto the next step.

If you do have a WordPress website, once you have installed WP-CLI you will want to run the following commands:

su - [dev_username] cp public_html
wp option update siteurl https://dev.domain.com
wp option update home https://dev.domain.com
exit

Sometimes plugins or themes mention the original domain in the database. If some parts of the dev domain are not working, particularly plugins or themes, you may need to contact a developer to see if the original domain name is still active in the database.

After replacing the names using WP-CLI, you’ll have officially created a dev domain.

Step 11: To complete this tutorial you have two choices: add an A record to your DNS to view your dev site online or edit your local hosts file to view solely on your computer. For our Liquid Web customers feel free to contact The Most Helpful Humans™ with questions you may have in setting up a development environment.

Kubernetes Tutorial

What is Kubernetes?

The name Kubernetes has its origins from the original Greek term for helmsman or pilot. Kubernetes, or ‘k8s’ (pronounced “Kate’s”) as it’s sometimes referred to, is an open-source software tool that was originally created by Google and is now being maintained by the Cloud Native Computing Foundation. Kubernetes is used for arranging and coordinating containers that an application needs to run into easy to handle groups.

In order to manage your Kubernetes cluster effectively, we recommend using kubectl as the command-line tool of choice. Basically, kubectl communicates with the master node (or server) which in turn submits those commands to the worker nodes to manage the cluster.

The Kubernetes cluster consists of two basic types of resources;

  • Master server – a master server organizes the cluster
  • Node server – Nodes are the workers that contain and run the applications

Each node contains a Kubelet, which is the agent for managing the node and communicating with the master. You can use kubectl to deploy, explore, review and remove Kubernetes objects (like nodes, images or containers).

Let’s next look at setting up kubectl.

The Master communicates with containers through the worker node.

Note:
This tutorial assumes you have a Kubernetes cluster already setup and running.

In order to setup kubectl, we will need the following:

Prerequisites

  1. A working internet connection
  2. The cURL or wget utilities installed
  3. Basic knowledge of the Linux command line

Installing kubectl

On an Ubuntu 16.04 LTS server, here are the commands to use if logged in as root to install kubectl:

apt-get update && sudo apt-get install -y apt-transport-https
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
touch /etc/apt/sources.list.d/kubernetes.list
echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" | tee -a /etc/apt/sources.list.d/kubernetes.list
apt-get update
apt-get install -y kubectl

Kubectl Commands for Basic Kubernetes Functions

Now that we have kubectl up and running, let’s review a few of the basic commands available. Here are the five most basic commands we will be reviewing along with their fundamental definition:

  • kubectl create – the create command constructs a resource from a configuration file or stdin (or standard input). A resource is defined as “something that can be “requested by”, “allocated to”, “or consumed by” a pod or container.”
  • kubectl get – the get command displays a table of the most relevant information about one or multiple relevant resources.
  • kubectl run –  the run command will kickoff one or more instances of a container in the cluster.
  • kubectl expose – the expose command will start to load balance inbound traffic across your running instances. This command can also create a High Availability proxy for the client to access the running containers from outside the cluster.
  • kubectl delete – the delete command removes defined resources by
    • filenames
    • stdin
    • resources and names
    • resources and label selector

Kubectl App Management

  • kubectl edit – Alters the characteristics of a resource on a server using the default editor.
  • kubectl apply – Applies a change to a resource from a file or stdin.
  • kubectl label – Adds or updates a specific attribute to specifically identify an object

Working with Apps Using Kubectl

  • kubectl exec – Runs a command on a container in a pod
  • kubectl logs – Prints a container log
  • kubectl describe – Displays the status or state of the resources.

Kubectl Cluster Management

  • kubectl cluster-info – Displays information about the master and services in the cluster.
  • kubectl drain – removes pods in preparation for maintenance
  • kubectl certificate – Approves a CSR or certificate signing request

Kubectl Settings and Usage

  • kubectl api-resources (eg. Pods and Services) – Lists all of the supported resources and their shortnames, API grouping, if namespaced, and Kind
  • kubectl config –  Changes or alters kubeconfig files
  • kubectl version – Displays the Kubernetes version

 

These are just some of the many basic command examples that are available for use in setting up and maintaining your Kubernetes environment.

 

How To Install Docker on Ubuntu 16.04

Adding Docker to an Ubuntu server.

Docker is an open-source software tool designed to automate and ease the process of creating, packaging, and deploying applications using an environment called a container. The use of Linux containers to deploy applications is called containerization. A Container allows us to package an application with all of the parts needed to run an application (code, system tools, logs, libraries, configuration settings and other dependencies) and sends it out as a single standalone package deployable via Ubuntu (in this case 16.04 LTS). Docker can be installed on other platforms as well. Currently, the Docker software is maintained by the Docker community and Docker Inc. Check out the official documentation to find more specifics on Docker. Docker Terms and Concepts

Docker is made up of several components:

  • Docker for Linux: Software which runs Docker containers on the Ubuntu Linux OS.
  • Docker Engine: Used for building Docker images and creating Docker containers.
  • Docker Registry: Used to store various Docker images.
  • Docker Compose: Used to define applications using multiple Docker containers.

 

Some of the other essential terms and concepts you will come into contact with are:

  • Containerization: Containerization is a lightweight alternative to full machine virtualization (like VMWare) that involves encapsulating an application within a container with its own operating environment.

Docker also uses images and containers. The two ideas are closely related, but very distinct.

  • Docker Image: A Docker Image is the basic unit for deploying a Docker container. A Docker image is essentially a static snapshot of a container, incorporating all of the objects needed to run a container.  
  • Docker Container: A Docker Container encapsulates a Docker image and when live and running, is considered a container. Each container runs isolated in the host machine.
  • Docker Registry: The Docker Registry is a stateless, highly scalable server-side application that stores and distributes Docker images. This registry holds Docker images, along with their versions and, it can provide both public and private storage location. There is a public Docker registry called Docker Hub which provides a free-to-use, hosted Registry, plus additional features like organization accounts, automated builds, and more. Users interact with a registry by using Docker push or pull commands. Example:

docker pull registry-1.docker.io/distribution/registry:2.1.

  • Docker Engine: The Docker Engine is a layer which exists between containers and the Linux kernel and runs the containers. It is also known as the Docker daemon. Any Docker container can run on any server that has the Docker-daemon enabled, regardless of the underlying operating system.
  • Docker Compose: Docker Compose is a tool that defines, manages and controls multi-container Docker applications. With Compose, a single configuration file is used to set up all of your application’s services. Then, using a single command, you can create and start all the services from that file.
  • Dockerfiles: Dockerfiles are merely text documents (.yaml files) that contains all of the configuration information and commands needed to assemble a container image. With a Dockerfile, the Docker daemon can automatically build the container image.

    Example: The following basic Dockerfile sets up an SSHd service in a container that you can use to connect to and inspect other containers volumes, or to get quick access to a test container.

FROM ubuntu:16.04
RUN apt-get update && apt-get install -y openssh-server
RUN mkdir /var/run/sshd
RUN echo 'root:screencast' | chpasswd
RUN sed -i 's/PermitRootLogin prohibit-password/PermitRootLogin
yes/' /etc/ssh/sshd_config
# SSH login fix. Otherwise user is kicked off after login
RUN sed 's@session\s*required\s*pam_loginuid.so@session optional
pam_loginuid.so@g' -i /etc/pam.d/sshd
ENV NOTVISIBLE "in users profile"
RUN echo "export VISIBLE=now" >> /etc/profile
EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]

Docker Versions

There are three versions of Docker available, each with its own unique use:

  • Docker CE is the simple, classic Docker Engine.
  • Docker EE is Docker CE with certification on some systems and support by Docker Inc.
  • Docker CS (Commercially Supported) is kind of the old bundle version of Docker EE for versions <= 1.13.

We will be installing Docker CE.

 

Docker logo

Step 1 — Checking Prerequisites

To begin, start with the following server environment: 

  1. 64-bit Ubuntu 16.04 server
  2. Logged in as the root user
Important:
Docker on Ubuntu requires a 64-bit architecture for installation and, the Linux Kernel version must be 3.10 or above.

Before installing Docker, we need to set up the repository which contains the latest version of the software (Docker is unavailable in the standard Ubuntu 16.04 repository). Adding the repository allows us to easily update the software later as well.

Step 2 — Installing Docker

The next step is to remove any default Docker packages from the existing system before installing Docker on a Linux VPS. Execute the following commands to start this process:

root@test:~# apt-get remove docker docker-engine docker.io lxc-docker
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'docker-engine' is not installed, so not removed
Package 'docker' is not installed, so not removed
Package 'docker.io' is not installed, so not removed
E: Unable to locate package lxc-docker

Note:
In certain instances, a specific variant of the linux kernel is slimmed down by removing less common modules (or drivers). If this is the case, the “linux-image-extra” package contains all of the “extra” kernel modules which were left out. Use this command to re-add them: root@test:~# sudo apt-get install linux-image-extra-$(uname -r) linux-image-extra-virtual

Step 3 — Add required packages

Now, we need to install some required packages on your system. Run the commands below to accomplish this:

root@test:~# apt-get install curl apt-transport-https ca-certificates software-properties-common

Note:
If you get the error: “E: Unable to locate package curl”, Use the commands “curl -V” to see if curl is already installed; if so, move on to step 4.

Step 4 — Verify, Add and Update Repositories

Add the Docker GPG key to your system:

root@test:~# curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
OK

Next, update the APT sources to add the source:

root@test:~# add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu xenial stable" | tee /etc/apt/sources.list.d/docker.list

Run the update again so the Docker packages are recognized:

root@test:~# apt-get update
Get:1 http://security.ubuntu.com/ubuntu xenial-security InRelease [107 kB]
Hit:2 http://us.archive.ubuntu.com/ubuntu xenial InRelease                              
Get:3 http://us.archive.ubuntu.com/ubuntu xenial-updates InRelease [109 kB]             
Get:4 http://us.archive.ubuntu.com/ubuntu xenial-backports InRelease [107 kB]                 
Fetched 323 kB in 0s (827 kB/s)                             
Reading package lists... Done
E: The method driver /usr/lib/apt/methods/https could not be found.
N: Is the package apt-transport-https installed?
E: Failed to fetch https://download.docker.com/linux/ubuntu/dists/xenial/InRelease  
E: Some index files failed to download. They have been ignored, or old ones used instead.

Note:
If you get the error seen above: “N: Is the package apt-transport-https installed?”, Use the following command to correct this. root@test:~# sudo apt-get install apt-transport-https

Let’s rerun the update:

root@test:~# apt-get update
Hit:1 http://us.archive.ubuntu.com/ubuntu xenial InRelease
Get:2 http://security.ubuntu.com/ubuntu xenial-security InRelease [107 kB]
Get:3 http://us.archive.ubuntu.com/ubuntu xenial-updates InRelease [109 kB]        
Get:4 http://us.archive.ubuntu.com/ubuntu xenial-backports InRelease [107 kB]                 
Hit:5 https://download.docker.com/linux/ubuntu xenial InRelease
Fetched 323 kB in 0s (656 kB/s)
Reading package lists... Done

Success! Now, verify we are installing Docker from the correct repo instead of the default Ubuntu 16.04 repo:

root@test:~# apt-cache policy docker-ce
docker-ce:
 Installed: (none)
 Candidate: 18.06.0~ce~3-0~ubuntu
 Version table:
    18.06.0~ce~3-0~ubuntu 500
       500 https://download.docker.com/linux/ubuntu xenial/stable amd64 Packages

Step 5 — Install Docker

Finally, let’s start the Docker install:

root@test:~# apt-get install -y docker-ce
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
 aufs-tools cgroupfs-mount libltdl7 pigz
Suggested packages:
 mountall
The following NEW packages will be installed:
 aufs-tools cgroupfs-mount docker-ce libltdl7 pigz
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 40.3 MB of archives.
After this operation, 198 MB of additional disk space will be used.
Get:1 http://us.archive.ubuntu.com/ubuntu xenial/universe amd64 pigz amd64 2.3.1-2 [61.1 kB]
Get:2 http://us.archive.ubuntu.com/ubuntu xenial/universe amd64 aufs-tools amd64 1:3.2+20130722-1.1ubuntu1 [92.9 kB]
Get:3 http://us.archive.ubuntu.com/ubuntu xenial/universe amd64 cgroupfs-mount all 1.2 [4,970 B]
Get:4 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 libltdl7 amd64 2.4.6-0.1 [38.3 kB]
Get:5 https://download.docker.com/linux/ubuntu xenial/stable amd64 docker-ce amd64 18.06.0~ce~3-0~ubuntu [40.1 MB]
Fetched 40.3 MB in 1s (38.4 MB/s)    
...
...

Docker should now be installed, the daemon started, and the process enabled to start on boot. Let’s check to see if it’s running:

root@test:~# systemctl status docker
* docker.service - Docker Application Container Engine
  Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
  Active: active (running) since Wed 2018-08-08 13:51:22 EDT; 2min 13s ago
    Docs: https://docs.docker.com
Main PID: 6519 (dockerd)
  CGroup: /system.slice/docker.service
          |-6519 /usr/bin/dockerd -H fd://
          `-6529 docker-containerd --config /var/run/docker/containerd/containerd.toml

Aug 08 13:51:22 test.docker.com dockerd[6519]: time="2018-08-08T13:51:22.192600502-04:00" level=info msg="ClientConn switching balancer to \"pick_first\"" module=grpc
Aug 08 13:51:22 test.docker.com dockerd[6519]: time="2018-08-08T13:51:22.192630873-04:00" level=info msg="pickfirstBalancer: HandleSubConnStateChange: 0xc42020f6a0, CONNECTING" module=grpc
Aug 08 13:51:22 test.docker.com dockerd[6519]: time="2018-08-08T13:51:22.192854891-04:00" level=info msg="pickfirstBalancer: HandleSubConnStateChange: 0xc42020f6a0, READY" module=grpc
Aug 08 13:51:22 test.docker.com dockerd[6519]: time="2018-08-08T13:51:22.192867421-04:00" level=info msg="Loading containers: start."
Aug 08 13:51:22 test.docker.com dockerd[6519]: time="2018-08-08T13:51:22.340349000-04:00" level=info msg="Default bridge (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option --bip can be used to set a preferred IP address"
Aug 08 13:51:22 test.docker.com dockerd[6519]: time="2018-08-08T13:51:22.397715134-04:00" level=info msg="Loading containers: done."
Aug 08 13:51:22 test.docker.com dockerd[6519]: time="2018-08-08T13:51:22.424005987-04:00" level=info msg="Docker daemon" commit=0ffa825 graphdriver(s)=overlay2 version=18.06.0-ce
Aug 08 13:51:22 test.docker.com dockerd[6519]: time="2018-08-08T13:51:22.424168214-04:00" level=info msg="Daemon has completed initialization"
Aug 08 13:51:22 test.docker.com dockerd[6519]: time="2018-08-08T13:51:22.448805942-04:00" level=info msg="API listen on /var/run/docker.sock"
Aug 08 13:51:22 test.docker.com systemd[1]: Started Docker Application Container Engine.
~
~
~
(press q to quit)

Excellent! Good to go!

If Docker is not started automatically after the installation, run the following commands:

root@test:~# systemctl start docker.service
root@test:~# systemctl enable docker.service

Step 6 — Test Docker

Let’s check the new Docker build by downloading the hello-world test image.
To start testing, issue the following command:

 


root@test:~# docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
9db2ca6ccae0: Pull complete
Digest: sha256:4b8ff392a12ed9ea17784bd3c9a8b1fa3299cac44aca35a85c90c5e3c7afacdc
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
   (amd64)
3. The Docker daemon created a new container from that image which runs the
   executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
   to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
https://hub.docker.com/

For more examples and ideas, visit:
https://docs.docker.com/engine/userguide/

Step 7 — The ‘Docker’ Command

With Docker installed and working, now is the time to become familiar with the command line utility. The ‘Docker’ command consists of using Docker with a chain of options followed by arguments. The syntax takes this form:

root@test:~# docker
Usage: docker [OPTIONS] COMMAND
A self-sufficient runtime for containers
Run 'docker COMMAND --help' for more information on a command.


To view all of the available Options and Management Commands, simply type:

docker

To view the switches available for a specific command, type:

docker docker-subcommand --help

Lastly, To view system-wide information about Docker, use:

docker info

Docker is a dynamic, robust and responsive tool that makes it very simple to run applications within a containerized environment. It is portable, less resource-intensive, and more reliant on the host operating system which allows for multiple uses. Overall, Docker is a ‘must have’ system and should be included in your toolkit for automation, deployment, and scaling of your applications!

Our Support Teams are filled with talented admins with an intimate knowledge of multiple web hosting technologies, especially those discussed in this article. If you are uncomfortable walking through the steps outlined here, we are a phone call, chat or ticket away from assisting you with this process. If you’re running one of our fully Managed Cloud VPS Servers, we can provide more information on directly implementing the software described in this article.

 

Apache Performance Tuning: Configuring MPM Directives

 

Our previous article in this series focused on defining and fitting MPM to match your environment.  Building off of our last tutorial we will be discussing specific details on how to adjust the previously mentioned Apache configuration directives on the various types of Liquid Web servers.  

 

 

Core-managed CentOS 6/7 Servers

On CentOS servers, Apache configuration files are located in /etc/httpd/.

  1. Log in to the server over SSH or FTP.
  2. First, create an optimization file. It’s necessary for the optimization file to be loaded last so that it will override all other previous settings. We suggest naming the file z-optimize.conf.touch /etc/httpd/conf.d/z-optimize.conf
  3. Open file for editing with your favorite editor:vim /etc/httpd/conf.d/z-optimize.conf
  4. Input necessary directive change, using IfModule statements for compatibility.Configuration example for Centos 6/7 servers.
  5. Save the file.
  6. Reload Apache.service httpd restart

Core-managed Ubuntu 14.04/16.04 LTS Servers

On Ubuntu servers, Apache configuration files are located in /etc/apache2/.

  1. Backup existing apache2.conf file:cp -p /etc/apache2/apache2.conf{,.bak.$(date +%F_%H%M%S)}
    ls -lah /etc/apache2/apache2.conf*
  2. Open file for editing with your favorite editor:vim /etc/apache2/apache2.conf
  3. Append the necessary directive changes to the very bottom of the config file. Configuration examples for Centos 6/7, Ubuntu 14.04/16.04 servers.
  4. Save the file.
  5. Reload Apache.apache2ctl reload

Fully-managed CentOS 6/7 cPanel Servers

Out of the box, our Fully-Managed cPanel servers come with general optimization suitable for most small and mid-range sites. cPanel servers use a sophisticated template system for managing Apache configurations. cPanel typically handles all configurations seamlessly by using the WHM and cPanel interfaces. However, it is still quite simple to set up an optimization configuration file. You have the choice to compose an optimized configuration file via command line over SSH/FTP or within the WHM interface.

Command Line Method (SSH/FTP)

The Apache configuration files on cPanel servers are stored in: /usr/local/apache/conf/includes/

You can use several included files for optimization. It’s necessary for the optimization file to be loaded last so that it will override all other previous settings. For this reason, the post_ include files work best, specifically the post_virtualhost_global.conf file.

 

  1. Log in to the server with SSH or FTP.
  2. Open the post_virtualhost_global.conf file in your favorite editor. (This file is typically empty and maybe missing entirely. This is okay and not unexpected.)vim /usr/local/apache/conf/includes/post_virtualhost_global.conf
  3. Input necessary directive change, using IfModule statements for compatibility. Configuration examples for Centos 6/7, Ubuntu 14.04/16.04 servers.
  4. Save the file.
  5. Reload Apache./scripts/restartsrv_apache
  6. Reload Apache PHP FPM servers./scripts/restartsrv_apache_php_fpm


WMH Method

  1. Log in to Webhost Manager (WHM) on the necessary server.
  2. Type apache in the quick find box.
  3. Click on Apache Configuration in the Service Configuration section.
  4. Click on Include Editor.
  5. Scroll down to Post VirtualHost Include.
  6. Select All Versions from the drop down.
  7. In the box input the necessary directives for optimization. Configuration examples for Centos 6/7, Ubuntu 14.04/16.04 servers.
  8. Click the Update button when finished to save the change.
  9. On the left-hand navigation pane in the Restart Services section at the bottom click on HTTP Server(Apache).
  10. Click on the Yes button.
  11. Back to the left-hand navigation pane in the Restart Services section at the bottom click on PHP-FPM services for Apache.
  12. Click on the Yes button to complete the configuration.

Fully-managed CentOS 7 Plesk Onyx 17 Linux Servers

Out of the box, our Fully-Managed Linux Plesk servers come with general optimization suitable for most small and mid-range sites. Plesk uses mostly a standard CentOS based Apache2 installation so that it can be modified in the same manner as our Core-managed CentOS 6/7 servers:

 

On CentOS servers, Apache configuration files are located in /etc/httpd/.

 

  1. Log in to the server over SSH or FTP.
  2. First, create an optimization file. It’s necessary for the optimization file to be loaded last so that it will override all other previous settings. Suggested name: z-optimize.conf.touch /etc/httpd/conf.d/z-optimize.conf
  3. Open file for editing with your favorite editor:vim /etc/httpd/conf.d/z-optimize.conf
  4. Input necessary directive change, using IfModule statements for compatibility.Configuration examples for Centos 6/7, Ubuntu 14.04/16.04 servers.
  5. Save the file.
  6. Reload Apache.service httpd restart


Our Heroic Support™ team is equipped with talented and knowledgeable techs who can discuss ways to enhance your environment.  After reading through our series if you still have questions our techs can walk you through the outlined steps. For our customer with Fully Managed servers, we are happy to pick up the torch and take the lead by directly implementing the changes in this article.  We are just a phone call, chat or ticket away from aiding you through the process.