Configure Nginx to Read PHP on Ubuntu 16.04

Posted on by Michelle Almendarez
Category: Tutorials | Tags: , , , , ,

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.

Remote Desktop Users Group

Posted on by Devin Grindle
Category: Tutorials | Tags: , , , , , , ,

The most common way to remotely manage a Windows server is through Remote Desktop Protocol. By default, Liquid Web’s Windows servers only allow the members of the administrators’ group remote desktop access. However, the Remote Desktop Users group grants its members access to securely connect to the server through RDP (Remote Desktop Protocol) as well.

This article will go over the basics of the Remote Desktop Users group. By the end, you will be able to add users to the group, understand permissions, and basic user management.

 

Pre-flight

The information below covers methods to configure the Remote Desktop Users group for Windows Server 2012 through Windows Server 2016 on any Liquid Web Windows server. As a valued customer, if you do not feel comfortable performing these steps independently, please contact our support team for additional assistance. Liquid Web support is happy to walk you through the steps and answer any questions you may have.

 

Managing Local Users and Groups

Users and groups on Windows servers are managed in a number of different ways, but the most user-friendly way is through the Local Users and Groups interface. There are several ways to open the interface. However,  the easiest is to run “lusrmgr.msc”. Lusrmgr.msc can be launched by searching the start menu, command line, or through a run dialog. These methods allow you to find users and groups easily.

Note
To manage local users and groups, you will need to be logged in with a user that has the proper permissions to do so. This is most commonly a user that is already a member of the Administrators group.
Within a windows server type in lusrmgr.msc into the search bar to locate Users where you can find existing users and groups.

 

User Management

Once you open the Local Users and Groups interface, you will see two folders on the left, one for Users, and one for Groups. By selecting Users, you will see a full list of local users on the server. You can also see a variety of related tasks by right-clicking Users, Groups, a user’s name, or a blank area of the middle pane.

There are several ways to add a new user through the Local Users and Groups interface. These methods all result in the same “New User” dialog box opening where you can then configure a Username, Password, and other options. Choose one of the options below to create a new user:

  • With the Users folder selected in the left pane, click the Action menu, then select “New User…”.
  • With the Users folder selected in the left pane, click “More Actions” from the right- hand pane, then select “New User…”.
  • Right-click the Users folder, then select “New User…”.
  • With the Users folder selected in the left pane, right-click in a blank area of the middle page, then select “New User…”.

Once you have created a new user, or have identified the username of the existing user, you are ready to assign that user to a Group. Users assigned to a group are known as group members.

 

Group Management

As with user management, group management can also be performed in several ways. The options below cover several of the most common ways to assign a new member to the Remote Desktop Users group:

  • Select the Users folder from the left pane of the Local Users and Groups interface, open the Users Properties window by double-clicking the user, select the “Member Of” tab, then click “Add…”. Now type “Remote Desktop Users” in the text box and click OK.
  • Select the Groups folder from the left pane of the Local Users and Groups interface, double-click the “Remote Desktop Users” group, click “Add…”, enter the user’s name in the text box and click OK.
  • Open the system settings by right-clicking the start menu and selecting “System”, choose “Advanced system settings”, select the “Remote” tab, click the “Select Users…” button then click the “Add” button. Now enter the user’s name in the text box and click OK.
  • Open the “Server Manager”, select “Local Server” from the left pane, click the blue text next to “Computer Name”, select the “Remote” tab, click the “Select Users…” button then click the “Add” button. Now enter the user’s name in the text box and click OK.
    Note
    When selecting users or groups, it is recommended to click the “Check Names” button after typing in the user or group name. If the name is underlined after clicking the “Check Names” button, then the name was identified correctly.

You can also use the “Advanced…” button when selecting users or groups instead of typing its name. Clicking the “Advanced…” button followed by the “Find Now” button will result in a list of users to select.In a windows server, by right-clicking the User folder you can do a variety of tasks like adding a new user.

 

Notes on Permissions & Security

By default, there are no members of the Remote Desktop Users group and only members of the Administrators group are allowed to connect through RDP. Members added to the Remote Desktop Users group are considered non-Administrative users. These users will be unable to perform most management tasks such as installing software, managing IIS, or rebooting the server.

If a user requires management abilities, the user will need explicit access to that task or will need to be a member of the Administrators. Please use the best practice of “least privilege” when configuring your users, groups, and permissions.

 

Test/Verify Group Membership

When configuring new user and group memberships, you should always review group membership once complete.  Reviewing group membership is most commonly performed through the Local Users and Groups interface. In addition to verifying membership, we also recommend attempting a remote desktop connection with your newest Remote Desktop Users group member. If you are unable to connect with your user, please see our Remote Desktop Troubleshooting article.

Once you have logged in with your newest member of the Remote Desktop Users group, you can further verify that groups are set up correctly by running the command “whoami /groups” from a command line. The output of this command lists the username and its associated Group names.

 

Install Rsync and Lsync on CentOS, Fedora or Red Hat

Posted on by Noti Peppas
Category: Tutorials | Tags: , , , , , , , , , ,

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!

 

Install TeamViewer on Ubuntu 16.04 LTS

Posted on by Nathaniel Swanson
Category: Tutorials | Tags: , , , , , , , , ,

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.

 

 

Enabling Let’s Encrypt for AutoSSL on WHM based Servers

Posted on by Helpful Humans of Liquid Web
Category: Tutorials | Tags: , , , , , ,

With the recent release of cPanel & WHM version 58 there has been the addition of an AutoSSL feature, this tool can be used to automatically provide Domain Validated SSLs for domains on your WHM & cPanel servers.

Initially this feature was released with support provided for only cPanel (powered by Comodo) based SSL certificates, with the plans to support more providers as things progressed. As of now, cPanel & WHM servers running version 58.0.17, and above, can now also use Let’s Encrypt as an SSL provider. More information on Let’s Encrypt can be found here. Continue reading “Enabling Let’s Encrypt for AutoSSL on WHM based Servers” →

Transfer an SSL to Ubuntu 16.04 or CentOS 7

Posted on by Andrej Walilko
Category: Tutorials | Tags: , , , , , , , , , ,

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!

 

WordPress GDPR Plugin Exploit – All You Need To Know

Posted on by Echo Diaz | Updated:
Category: Featured Articles, Tutorials | Tags: , , ,

As of November 9, 2018, the WP GDPR Compliance plugin has been exploited by hackers. This plugin aids e-commerce site owners in compliance with European privacy standards. Since the very nature of GDPR is to protect the personal data and privacy of EU citizens, it should be tended to as soon as possible to avoid a costly cleanup. WP GDPR Compliance is also known for working in conjunction with many forms including Contact Form 7, Gravity Forms, and WordPress Comments.

The main characteristic of this hack is the addition of new users, users with admin privileges. These administrative users have full access to your WordPress site. With Admin users a hacker can alter your site without your knowledge, including making rouge pages or selling your visitor’s information.

This article shows WP GDPR users how to:

 

If you are familiar with how to log in to your WordPress backend you can easily see if you are using this plugin.

Step 1: Enter the WordPress backend by going to yourdomain.com/wp-login.php in your browser.

Step 2: Login with your WordPress username and password and navigate to Plugins and click on Installed Plugins on the left-hand side of your screen.

Step 3: Scroll down through any installed plugins to see if WP GDPR Compliance is within your list.  On this screen, you’ll be able to see the version of the plugin to the right of the plugin name. Any version less than 1.4.3 is vulnerable and should be updated.

Indentify if you are vulnerable to WP GDPR by locating the plugins menu in WordPress.

Note:
Documented evidence shows an inactive GDPR plugin is not vulnerable to the exploit.

 

Although this is a severe exploit, it is easy to patch and protect yourself by performing a simple update.

Step 1: Follow the steps above in the section “How to Identify if you use the WP GDPR plugin” to login and locate your Plugins menu.

Step 2: Afterwards, find WP GDPR Compliance, if you are running an outdated version you’ll see a message letting you know you can update. Selecting the “update now” link will automatically upgrade to the newest version.

Update the WP GDPR plugin to avoid a hacked WordPress site.

 

There is a couple of routes for identifying this hack, listed below, but you can also use the Wordfence Security Scanner or our read our blog article on the subject of exploitation.

Indicators of Compromise include the following characteristics:

  • Creation of new users with Admin privileges
  • A database user in the wp-users table named t2trollherten and t3trollherten
  • URL’s inserted into the code have seen as pornmam.com
  • Installation of the 2MB Autocode plugin, executed by WP-Cron via WooCommerce’s woocommerce_plugin_background_installer
  • The wp_options table within your database has an entry starting with 2mb_autocode or default_role  is set to anything other than “subscriber”
  • Recent edits to the wp-super-cache/wp-cache.php file
  • Creation of a backdoor file, /wp-content/uploads/…/wp-upd.php
  • Incoming IPs from:
    • 109.234.39.250
    • 109.234.37.214
    • 195.123.213.91
    • 46.39.65.176

 

If you deduced your site is compromised from previously mentioned characteristics, then you’ll want to remedy it immediately since other sites on the same server can be affected.

  • Liquid Web customer can purchase a Malware Clean Up package
  • Manually remove the code from the infected files
  • Restore from a backup dated before November 8, 2018 (keep in mind this will still have the old version, and your site will still be in danger)

 

Install PHP on Windows

Posted on by Devin Grindle
Category: Tutorials | Tags: , , , , ,

PHP for Windows provides users the ability to run nearly any PHP script desirable. Windows can tackle a wide range of software, from your PHP scripts to the many content management systems such as WordPress or Drupal.

Since Windows does not come already equipped with PHP, it does require some additional steps to install. This article will walk you through the process of how to effectively install PHP on Windows 2016 through the use of the Windows PHP 7 Installer.

Pre-flight

Before you can begin your PHP installation, you will need to determine if your server has our Fully managed Plesk control panel, or is one of our self or core managed options (without Plesk).

  1. You can determine whether or not your server has Plesk by logging into https://manage.liquidweb.com.
  2. Once you have successfully logged in, expand your server from the “Overview” page.
  3. Next, look to the far right of the “Log into your server” heading, and locate the word “Plesk.”

If “Plesk“ is not listed, you do not have Plesk installed. Manually install PHP using the steps below (without the use of Plesk). If your server has Plesk installed, you can add PHP support through Plesk directly.

Find out if your server uses Plesk by viewing in manage.liquidweb.com.

The following information provides a step by step breakdown of each installation process. This article will provide steps for Windows Server 2016 and Plesk Onyx (if you have Plesk currently installed). Use these same steps as a guideline for Windows Server 2008 or 2012. Besides, the older versions of Plesk will use similar steps.

As with any managed Liquid Web server, as a valued customer, if you do not feel comfortable performing the PHP software installation independently, please contact our support team for additional assistance. Liquid Web support will be happy to walk you through the steps, answer any questions you may have, or complete the installation for you if needed.

Note:
As with any software change, we recommend that you have a valid backup before starting this process.

To install PHP using Plesk, you will navigate through the Updates and Upgrades option within Plesk. This method will automatically download and install PHP directly from the Plesk Control Panel. Listed are the steps to install PHP using Plesk:

  1. Login to Plesk as the admin user.
  2. Choose Tools & Settings, then select Updates and Upgrades.Installing PHP using Plesk.
  3. Click Add/Remove Components.Installing PHP using Plesk.
  4. From the Add and Remove Product Components page you will need to expand the Plesk hosting features. Select install next to the desired PHP version. Click Continue and you will see the installation process finish.Installing PHP using Plesk.
Note:
You should never attempt to make changes outside of Plesk that are directly supported through Plesk (such as installing PHP).

Once PHP has successfully installed, it will require enabling on a per domain basis. To enable PHP through Plesk, follow these steps:

  1. From Plesk, choose Domains on the left-hand side.
  2. Select your domain name.
  3. Choose Hosting Settings.
  4. Under Web Scripting and Statistics check the box to Enable PHP.
  5. Select the proper PHP version next to PHP support.
  6. Click OK.

That’s it! You are now ready to verify that PHP is working.

There are several ways to install PHP on Windows Server 2016 (without Plesk). Since the manual method is more complex and requires manual configuration to IIS, the recommended approach is using the Web Platform Installer. The Web Platform Installer will automatically download PHP and will configure the IIS handlers for you.

To install PHP using the Web Platform Installer, follow the steps provided below:

  1. Connect to your server using RDP with an Administrator user.
  2. Open Internet Information Systems (inetmgr.exe).
  3. Select the server name (under “Start Page” on the left hand side of IIS).
  4. Choose “Get New Web Platform Components” from the Actions pane.
    1. If the Web Platform Installer is not already installed you will be directed to a website to install the Web Platform Installer.
      1. Download and run the Web Platform Installer.
      2. You can now select “Get New Web Platform Components” from the Actions pane and proceed with step 5.
    2. If the Web Platform  Installer extension is already installed, it will open.
  5. From the Web Platform Installer search for “PHP 7”.
  6. Select the version of PHP that you wish to install and click “Add”, “Install”, “I Accept”
  7. After the installation completes click “Finish”.

Installing PHP Without Plesk.

Once you have PHP installed, the next step is to verify that PHP is working correctly. You can do this by adding any PHP script to the website and manually navigating to the page in your browswer. The following steps explicitly explain the process of how to create a PHP page under a site in IIS. This process will then result in the output of information about PHP’s configuration. Commonly referred to as a “PHP info page,” we show you the steps needed to create one:

Note:
A PHP info page can contain sensitive data about versioning and enabled components. While creating a temporary page is typically ok, after use, we recommend you delete the page as soon as possible.
  1. Connect to your server using RDP with an Administrator user.
  2. Open Internet Information Systems (inetmgr.exe).
  3. Expand the server name (under “Start Page” on the left hand side of IIS).
  4. Expand “Sites”.
  5. Right click the site name and choose “Explore”.
  6. Within the directory that opened create a file named phpinfo.php with the following contents:<?php
    phpinfo();
    ?>
  7. Navigate to the site specifying the phpinfo.php we created. Example : http://domain.com/phpinfo.php
  8. If everything went well you should be shown a page that displays the PHP version and other information.
  9. Delete the phpinfo.php file we created earlier.
  10. The PHP Info Page shows the version of PHP you are currently using.Now that PHP is installed and working correctly you are ready to upload your code or get started with one of many PHP based content management systems of your choice.

How to Use Ansible

Posted on by David Singer
Category: Tutorials | Tags: , , , , , , , , , , ,

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] yAnswer “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.