How to Configure Cyberduck for Use with Storm Object Storage

Storm Object Storage delivers a durable, secure, highly available solution for storage needs of virtually any size. With object storage access occurs via API calls to the object storage cluster, which replaces the need to rely on additional servers for dedicated storage.

Here we use the client Cyberduck to interact with Storm Object Storage. Cyberduck is available for download from https://cyberduck.io/?l=en.

Pre-Flight Check
  • These instructions are intended specifically for configuring Cyberduck for use with Storm Object Storage.
  • I’ll be working from a Microsoft Windows 8 desktop with Cyberduck already installed.

Continue reading “How to Configure Cyberduck for Use with Storm Object Storage”

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.