Featured Freeware: htop

Featured Freeware highlights some of the Liquid Web staff’s favorite free software. This can range from useful command line tools, open-source packges useful in web-development, or even multi-platform applications. This week we are covering a treasured favorite, htop.

Note: This post assumes you have a working knowledge of top. You can read our article on using top, if you are not familiar with the tool.

htop, or Hisham’s top, is an interactive process viewer for Unix systems. With htop you are provided the same functionality as top, however it provides some needed improvements. Most are in areas where top shows some of it’s age; for example, in htop you can scroll the list of processes vertically and horizontally to see all the process info.

Another benefit is that htop seems to start significantly faster, generally when using top there is a bit of a delay while the program loads up some initial data. So now that you know the basics of how htop differs from top, lets get to using it. First you’ll need to ensure it’s installed on the server and if not we’ll try to get it installed.
Continue reading “Featured Freeware: htop”

Backup Your WordPress Database with WP-CLI

In this article you will learn how to backup your WordPress database using the wp-cli tool. Knowing how to backup your database is a critical skill to have when running a WordPress site. All your posts, pages, and more live in your database; keeping backups is critical.

You should always take a backup before any major changes to your site, just in case. It’s much quicker to take a backup now and do a restore if you need to, than to find a useful backup when you need it.

Pre-flight Check:

  • These instructions were created with a cPanel-based server in mind.
  • Command line access via SSH will be necessary to follow along.
  • The server must have WP-CLI installed, for installation directions see this tutorial.

To follow along with this tutorial you will need to have WP-CLI installed. If you have not yet installed wp-cli on your server feel free to read our tutorial here on that subject.

  1. Login to the server via SSH as the cPanel user that owns the domain, or the root user.
    ssh wordpress@198.51.100.142

    In the example we are using ssh to connect to the server. You can follow the rest of the steps even if you connect via alternative means(TTY, a Windows SSH Gui, etc).

    If you login as root you will need to use `su` to take on the user which owns the WordPress site before you continue.

  2. Now logged in (as the cPanel user) change to the WordPress root folder:
    cd ~/public_html

    We’re using a cPanel server so we know WordPress should be installed in the `public_html` folder. If you are not on a cPanel server it will be in a different location.
  3. Once in the WordPress root folder (where you can find wp-config.php) you can use the wp-cli tool. To backup your database run one of the following commands:
    • Backup the database to the current folder:
      wp db exportThis will use all the defaults for exporting the database as a backup. This means it will be in the current folder and will have the same name as the database.
    • Backup the database to a specific file:
      wp db export ../my_wordpress_db.sqlUsing this command will backup the database to a file called “my_wordpress_db.sql” and will put it in the folder above the current one (or `../`). This is done as a security measure to ensure no one can download your database.

Once you’ve run the export command you’ll see confirmation output like the following:

Success: Exported to ‘../my_wordpress_db.sql’.

After you see that confirmation your WordPress database is officially backed up. Now you can continue making changes or updates and will have a way to restore if anything goes wrong.

How to Install WP-CLI

WP-CLI is a command line tool for interacting with and managing WordPress sites. WP-CLI is very similar in functionality to what drush provides Drupal. If you are already familiar with using cli tools then this will be quick to pick up on. If not, then it may be a good time to start learning.

In this tutorial we’ll learn how to install wp-cli on a server and learn some basics. With WP-CLI you can speed up common maintenance, automate tasks, or even take backups.

Install wp-cli for All Users

Installing a tool like wp-cli on a server globally means that any user will be able to use the application. With WordPress being one of the most common CMS’ it’s helpful to have wp-cli installed for all users.

Pre-flight Check:

  • Root-level command line access via SSH is required to follow this tutorial.
  • PHP 5.3.29, or higher, will be required for wp-cli to function.
  • WordPress 3.7, or later, is required for wp-cli support.

To start you should do a quick test to see if wp-cli is already installed on the server:
wp
If you see the error below wp-cli is not installed, you can continue with the tutorial to install it on the server.

[root@host ~]# wp –info
-bash: wp: command not found
If you see actual command output, as shown below, then wp-cli is already installed.
  1. To begin the install we will use curl to download the wp-cli.phar file:
    curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
  2. Then do a quick test of of download with the following:
    php wp-cli.phar --info

    Error: YIKES! It looks like you’re running this as root. You probably meant to run this as the user that your WordPress install exists under.If you REALLY mean to run this as root, we won’t stop you, but just bear in mind that any code on this site will then have full control of your server, making it quite DANGEROUS.

    If you’d like to continue as root, please run this again, adding this flag: –allow-root

    If you’d like to run it as the user that this site is under, you can run the following to become the respective user:

    sudo -u USER -i — wp

    In this case seeing the error above is a good sign, we were just verifying that the file executes correctly.
  3. Next we will ensure that the file has the correct file permissions for execution:
    chmod +x wp-cli.phar
  4. Finally we will move the wp-cli.phar executable to global location to ensure all users have access.
    sudo mv wp-cli.phar /usr/local/bin/wp

    In this step we are also renaming the file to feel more like a traditional cli tool.

To ensure you’ve done the process correct you can do one final test. You’ll still see the same error from the test above since we’re running as the root user.
wp --info

Error: YIKES! It looks like you’re running this as root. You probably meant to run this as the user that your WordPress install exists under.If you REALLY mean to run this as root, we won’t stop you, but just bear in mind that any code on this site will then have full control of your server, making it quite DANGEROUS.

If you’d like to continue as root, please run this again, adding this flag: –allow-root

If you’d like to run it as the user that this site is under, you can run the following to become the respective user:

sudo -u USER -i — wp

Again, seeing the error above is a good sign, we were just verifying that the file executes correct.

Verify & Test wp-cli as a Site User

Now that wp-cli is installed globally you will want to test the tool from a user hosting a WordPress site. To do this you will login as root via SSH then:

  1. su - wordpress
    By executing this command you will then be logged in as the ‘wordpress’ user. Do take note that you’ll enter the actual username where it says ‘wordpress’.
  2. Then you can run the following to get basic info about wp-cli:
    wp --info

    [wordpress@web01 public_html]$ wp –info
    PHP binary: /opt/remi/php70/root/usr/bin/php
    PHP version: 7.0.11
    php.ini used: /etc/opt/remi/php70/php.ini
    WP-CLI root dir: phar://wp-cli.phar
    WP-CLI packages dir:
    WP-CLI global config:
    WP-CLI project config:
    WP-CLI version: 0.24.1

As you can see from the above output running the wp-cli tool as a regular user does not trigger an error. You can also see that we’re running on a server with PHP 7.0.11 and wp-cli is at version 0.24.1.

What Is KernelCare?

Tux the Penguin with Hotpatching (KernelCare)The concept of ‘Kernel hotpatching’, sometimes called live patching, was introduced to the Linux community around 2008. Soon after groups began developing differing implementations of the concept. KernelCare, one of the more popular implementations, was originally released in March 2014 by Cloud Linux, Inc.

So, what does hot patching do? (Or: Why do I want KernelCare?)

The basic concept of Linux kernel hot patching is pretty much the same not matter what it’s called. The goal is to only update the changes rather than the whole Kernel – which normally requires a reboot. It’s much harder than it sounds though since kernel updates come as complete packages and the system is running.

Imagine trying to do an oil change on your car while driving at highway speeds; that’s kernel hot patching in a nutshell.

With a KernelCare enabled kernel updates can be processed and then applied selectively to a running server. This can mean not needing to reboot for much longer than you would normally require to stay secure.

How do I check if I have KernelCare and is it working? (Or: Checking KernelCare version)

The best way to check if your server is running with KernelCare is to look for its main CLI tool. You can do this with the following linux command:

which kcarectl

If the CLI tool is found on the server you will see output like the following, or something very similar.

# which kcarectl
/usr/bin/kcarectl

If the CLI tool is not installed you will see the following:

# which kcarectl
#
When using the Linux `which` command you will get no results if the executable is not found. In this case that means KernelCare is likely not active or installed on the server.

Assuming the test above was successful, you’ll now want to check the status of KernelCare. This will help you determine if KernelCare is active and what the effective version is. You can do this with the following command:

/usr/bin/kcarectl --info

The results will look similar to the following:

[root@host ~]# /usr/bin/kcarectl –info
kpatch-state: patch is applied
kpatch-for: Linux version 3.10.0-327.36.3.el7.x86_64 (builder@kbuilder.dev.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC) ) #1 SMP Mon Oct 24 16:09:20 UTC 2016
kpatch-build-time: Mon Nov 7 08:20:19 2016
kpatch-description: 2;3.10.0-327.36.3.el7.x86_64

As you can see the output provides various details about the KernelCare status. Looking at the kpatch-state we can see that hot patching is working and enabled.

Understanding the Default WordPress .htaccess

When maintaining a WordPress site you may find yourself attempting things that normally would work and find that they have unexpected results. This is usually due to how WordPress’ default .htaccess rules manipulate the configurations and provide ‘pretty permalinks’.

This article is directly applicable to WordPress on an Apache based server. For WordPress Multi-site or other web servers (Nginx, IIS, etc) please review the official WordPress documentation as rules and configurations may differ.

The Default Rules

The default WordPress .htaccess rules are responsible for how WordPress is able to support ‘pretty permalinks’. Without these rules in place, WordPress permalinks would not resolve correctly. This feature allows your URLs to look much cleaner and more readable without over complicating or cluttering your website’s files structure.

The default rules look as follows:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

To break down what these rules are defining we’ll start at the top and work our way down.
  • First, you see a comment as indicated by the hashtag; this symbol `#` is used to denote a comment in .htaccess files.
  • Next you see an opening brace for Apache’s internal “IfModule” function; this specifies that the contained rules should only be used with the “mod_rewrite” module for Apache.
  • The Rewrite module is enabled.
  • The RewriteBase is declared; this defines the ‘root’ folder that should be applied to rewrite rules.
  • The next line is the first rewrite rule, this rule defines that if an “index.php” file is specifically called then no rewrite is needed.
  • The next two lines are both defining rewrite conditions; these conditions are specifying that if no file or folder can be found at the given URL the next rule should be applied.
  • Finally, the last rewrite rule before the close brace is for the “IfModule”. This rule will only be applied if no file or folder can be found for the URL. If that occurs, the request will be passed to WordPress before providing the client a response.

While this breakdown may be enough of an explanation for some, this is still a very complex chain of rules. The rules are best described and summarized as this: “If Apache itself cannot find the file or folder requested then the request should be dealt with by WordPress directly.”

An interesting result of this is that technically all WordPress pages are a 404 result in the context of Apache and only until PHP and WordPress receive the request can any content be resolved for a response.

Tips for Custom Rules

There usually is not a consistent cause for issues experienced when dealing with .htaccess rules on a WordPress site. As the cause can fluctuate from site to site, and even rule to rule, it’s hard to provide an extensive explanation for the issues. It is also important to note that plugins and themes can also affect how certain rules are managed as well.

A common rule that causes odd behaviour and provides mixed results usually relates to allowing access based on specific IP address. These rules usually look like:

<Files wp-login.php>
Order deny,allow
Deny from all
Allow from 198.11.109.98 localhost
</Files>

The rule above will deny all IPs access to wp-login.php unless the IP is listed in the ‘Allow from’ line. While it should work by default, occasionally this can cause issues. If it does, the usual fix is to define the error documents. This would look like:

ErrorDocument 401 default
ErrorDocument 403 default
<Files wp-login.php>
Order deny,allow
Deny from all
Allow from 198.101.159.98 localhost
</Files>

Having these error documents defined explicitly will ensure that when an unapproved IP attempts to access the page they are rejected and are sent a proper error page.

As there are various issues that can come up and each has their own solution, we simply cannot cover them all here. If you believe you are experiencing configuration issues related to those rules mentioned here feel free to contact our Heroic Support®.

EasyApache 4 & CLI based PHP utilities

With the release of EasyApache 4 in WHM 58 there are various changes to how PHP is managed. The most obvious being that EasyApache 4 brings support for installing multiple PHP versions alongside each other. However with multiple versions of PHP being installed on the server it’s easy to lose track of your command-line based PHP utilities and their PHP requirements.

Certain PHP packages like Composer, Drush, and WP-cli prefer to be run with the latest version of PHP. Unfortunately, having multiple PHP versions can mean not knowing which PHP will execute the utility when you call it directly. This article will detail a few methods to specify which PHP version should be used in instances like this.

Pre-flight Check:

  • These instructions are intended specifically for cPanel-based servers running WHM prior to version 58.
  • Command line access via SSH may be necessary to follow the examples.
  • The server will need to have EasyApache 4 active.
  • PHP 7 will be necessary to follow the provided examples.

Option #1: Directly Call the PHP Binary

The most basic option to workaround these issues is to directly call the PHP binary you need before executing the script. While this can be effective and will work as expected most of the time, certain utilities will not work when using this method.

You may want to attempt this method first and move on to Option #2 if this does not work as expected; generally though, this should work for executing basic PHP code.

/opt/cpanel/ea-php70/root/usr/bin/php someScript.php

The above command will specifically call the 7.0 version of PHP and will execute the someScript.php file within that version of PHP. If they are also installed on the server, the alternative PHP versions can be found at:

  • /opt/cpanel/ea-php55/root/usr/bin/php
  • /opt/cpanel/ea-php56/root/usr/bin/php
  • /opt/cpanel/ea-php70/root/usr/bin/php

Option #2: Use scl to Specify PHP Versions

As mentioned, certain PHP utilities are not provided as basic PHP files and are stored in the PHAR format. These utilities will not execute properly with the above method for specifying the PHP version. For these types of utilities you will need to specify the PHP version using a command called `scl`.

This command is a utility that allows running software in an environment packaged as a ‘Software Collection’. To be brief a ‘Software Collection’ is a way of defining an alternate location to a certain software. Fortunately, WHM provides predefined collections for the various versions of PHP supported by EasyApache 4.

The syntax of this command is as follows:

scl enable {SoftwareCollection} '{CommandToRun}'

Where you replace {SoftwareCollection} with the needed collection [ea-php55, ea-php56, or ea-php70], and you replace {CommandToRun} with the command, utility, or script you need to run.

A good way to highlight this is to review the difference in the following outputs:

root@noms [~]# php -v

PHP 5.6.25 (cli) (built: Aug 25 2016 17:00:38)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
with the ionCube PHP Loader v4.7.5, Copyright (c) 2002-2014, by ionCube Ltd., and
with Zend Guard Loader v3.3, Copyright (c) 1998-2014, by Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2015, by Zend Technologies

root@noms [~]# scl enable ea-php70 'php -v'

PHP 7.0.10 (cli) (built: Aug 25 2016 18:04:55) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.10, Copyright (c) 1999-2016, by Zend Technologies

As you can see when calling PHP by itself we get the default version, but when using scl we explicitly called the PHP 7.0 collection and get results to match.

Example #1: Executing a utility [Composer]:

root@noms [~]# scl enable ea-php70 'composer --version'

Composer version 1.2.0 2016-07-19 01:28:52

Example #2: Running a PHP script:

root@noms [~]# scl enable ea-php70 './someScript.php'

With these key tips and tricks you should now be equipped with the necessary tools to run CLI utilities on a server using EasyApache 4. If you have any questions or are not comfortable making these changes yourself, please feel free to contact Heroic Support®.

7 Extremely Useful Linux Commands for Beginners

#1: ls : What’s in this directory?

The command ls stands for list directory contents. And, cleverly, it will do just that: list a directory’s contents! Using it with -F will give a list of the directories contents, and denote items that are other directories with a trailing /.

ls -F

On my server returns:

allthethings.txt important.doc Indominus/ Misc/ probs.xls Red Wings/ Spreadsheets/ Work/

In the above case, allthethings.txt, garbage.file, important.doc, and probs.xls are files, and Indominus, Misc, Red Wings, Spreadsheets, and Work, each with the trailing /, are directories!

There are many other options, or switches, such as -F that can be used with ls for improved results. For example:

ls -lFa

Returns:

dr-xr-x---. 10 root root 4096 Apr 17 12:01 .
drwxr-xr-x. 19 root root 4096 Apr 14 12:45 ..
-rw-r--r-- 1 root root 0 Apr 17 12:00 allthethings.txt
-rw------- 1 root root 483 Apr 14 12:45 .bash_history
-rw-r--r--. 1 root root 18 Dec 28 2013 .bash_logout
-rw-r--r--. 1 root root 176 Dec 28 2013 .bash_profile
-rw-r--r--. 1 root root 361 Jan 1 01:24 .bashrc
drwxr-xr-x 3 root root 4096 Jan 1 01:25 .cache/
drwxr-xr-x 3 root root 4096 Jan 1 01:25 .config/
-rw-r--r--. 1 root root 100 Dec 28 2013 .cshrc
-rw-r--r-- 1 root root 0 Apr 17 12:01 garbage.file
-rw-r--r-- 1 root root 0 Apr 17 11:58 important.doc
drwxr-xr-x 2 root root 4096 Apr 17 11:59 Indominus/
drwxr-xr-x 2 root root 4096 Apr 17 11:57 Misc/
-rw------- 1 root root 42 Apr 14 12:44 .my.cnf
-rw-r--r-- 1 root root 0 Apr 17 12:00 probs.xls
drwxr-xr-x 2 root root 4096 Apr 17 11:57 Red Wings/
-rw------- 1 root root 1024 Jan 1 01:22 .rnd
drwxr-xr-x 2 root root 4096 Apr 17 11:56 Spreadsheets/
drw------- 2 root root 4096 Apr 14 12:42 .ssh/
-rw-r--r--. 1 root root 129 Dec 28 2013 .tcshrc
drwxr-xr-x 2 root root 4096 Apr 17 11:57 Work/

In the above case two switches are added: -l and -a. The -l uses the long listing format, and the -a switch lists all of the files, including hidden files.

Each column contains an important bit of information:

Column | Information | Example

  • 1 | Permissions | drwxr-xr-x
  • 2 | # of Hard Links | 2
  • 3 | User That Owns File or Directory | root
  • 4 | Group for File or Directory | root
  • 5 | File Size | 4096
  • 6 | Timestamp | Apr 17 11:59
  • 7 | Filename | Indominus/

Continue reading “7 Extremely Useful Linux Commands for Beginners”

Storm Private Cloud Parent

In addition to our dedicated servers, we also offer products on our cloud platform Storm on Demand. More information about the differences can be found here on our knowledge base in our Comparison article.

Working in a virtualized environment such as Storm on Demand does indeed give you a significant amount of control over your server, but you can now take that one step further: we have introduced an exciting new feature that allows you to create your very own Storm Cloud Parent.

You – and only you – will be allowed to add Storm instances to this private parent, and your parent will largely be separate from the public cloud.  This allows you to have even more control over the environment!  Your private Storm parent will be connected to the public network for certain features such as the Storm backup system and Server Images management.  The physical parent machine will control networking for your servers, but will be connected to the public network to utilize the Storm infrastructure.

Please note that this means that your backups and server images will be stored in an environment that is shared with (but not accessible to) other users.  Additionally, networking on the physical server is not shared, but the networking infrastructure between your private Storm Cloud parent and other Storm Cloud parents is considered a shared resource.

To get started, log into your Manage interface and press the “Create” button, like you normally would when creating a new server. You will see “Storm Private Cloud Parent” listed as one of the options. Select that box and then press yellow Configure New Device button to customize your parent. Continue reading “Storm Private Cloud Parent”