Choosing Your Cloud Sites Technology Setup

Behind Cloud Sites, racks full of both Linux and Windows servers power over 100,000 sites and applications. Every Windows-based page is served from clusters built and optimized especially for Windows, and every Linux-based page is served from clusters built and optimized especially for Linux. We use advanced load balancing technologies to automatically detect the type of technology you are running and route each request to the proper pool of servers.

This is a great example of the power of cloud computing, since you no longer have to make a hosting choice between Linux and Windows. Both PHP and .NET are included, allowing you to choose the technology you need site by site.

Every time you add a website to your Cloud Sites account, you can choose whether you want to use Linux or Windows. If you then decide to develop your site in a different way, you can change server setups at any time.

Changing Your Website Technology

It’s quick and easy to change the server type your website uses. Remember: this will change your IP address! You need to update your DNS records or your site will not be accessible.

  1. Log into your Cloud Sites control panel.
  2. Click the domain name where you’d like to change technologies.
    cs-choose-tech-pt1
  3. In the Website Details section, click the  icon to the right of Technology.
    cs-choose-tech-pt2

    Changing IP Address: Please note that when changing your site’s default technology, this changes the IP for the site. You will need to change your site’s DNS records to reflect the new IP address. Find your site’s IP address in the Website Details section after clicking on the specific website on the Cloud Sites home page.
  4. Use the dropdown menu to choose the technology combination you need. Then click Update Technology.
    cs-choose-tech-pt3

Best Editor for Web Development 2017

Best Web Development Tools of 2017: Editors/IDEs and Package Management

The worlds of web hosting and web development are in a constant state of evolution. Every year we see design trends change, coding standards adapt and new frameworks/CMS created. With such a quick pace of change it’s easy to get lost trying to keep up.

In this article we will discuss and highlight a handful of tools that help make web development easy. Whether you work on Frontend, Backend, PHP, Javascript, or even Perl this list will have something helpful.

As a web hosting company we don’t often talk about the tools used to create the web. We’re usually ultra focused on the components that enable us to server and support you; things like: server hardware, Linux, Apache and etc.

We may not support development tools, but we do want to help our customers to build amazing stuff.
Continue reading “Best Editor for Web Development 2017”

Will my site be marked unsafe in Chrome 56+?

Lately there’s been a lot of speculation about Googles up-coming changes to how sites without an SSL are going to be treated. As January draws towards a close we have seen an increase in customers with concerns of how this will affect their site. Both in terms of people being able to see it and how it might affect their search ranking.

This article aims to clear up some of the confusion and to demystify the changes. If you are unfamiliar with how SSL/TLS or HTTPS works please take a look at our article on the subject.

If you aren’t interested in how these changes came about feel free to skip down to: How These Changes Affect Your Site
Continue reading “Will my site be marked unsafe in Chrome 56+?”

How does an SSL work?

httpVShttps

Every single day 100s of terabytes of data is being transferred across the internet. In fact, based on Intel’s 2012 report, nearly 640K Gb of data is transferred every single minute. That’s more than 204 million Emails, 47,000 app downloads, 1.3 million YouTube videos watched and 6 million Facebook views.

We’re talking about a seriously massive amount of data here. So how do we know if that data is being transferred securely? Enter the SSL/TLS protocols.
Continue reading “How does an SSL work?”

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®.