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”

Ensure Your Electronic Payments are PCI DSS Compliant

If you process credit cards on a website, your site needs to be in compliance with the Payment Card Industry Data Security Standard. (This is abbreviated as PCI DSS, and even more often referred to simply as PCI.) PCI compliance certifies that your organization takes all necessary steps to protect sensitive customer data and provides a set of standards for your infrastructure and server setup. While Liquid Web does not offer full PCI compliance certification, we do offer a separate service that scans your server to see that PCI DSS requirements are met, a great tool during the compliance process.

Continue reading “Ensure Your Electronic Payments are PCI DSS Compliant”