WordPress GDPR Plugin Exploit – All You Need To Know

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)

 

A Beginner’s Guide to Managed WordPress

Thank you for choosing Managed WordPress at Liquid Web! We hope this guide will help you get started in making the most of your experience with the Managed WordPress Portal. There are some great features in the portal, and we’ve worked hard to make sure site maintenance is a cinch.

 

Quickly Jump To A Subject By Clicking its Link:

Login to MWP Portal and the WordPress Backend
Forgotten Password
Add a User to the MWP Portal
Granting SFTP Access
Migrate a Site
Create a New Site
Taking a Site Live
Managing DNS
Backups

 

Login to MWP Portal and the WordPress Backend

The fastest and easiest way to log into the Managed WordPress Portal is to first log in to your Liquid Web account at https://manage.liquidweb.com.

Once logged in you will see that you are on the Overview page. Here you will see your Managed WordPress server. Just click the plus sign next to that server to reveal the LOGIN button and click it.

Hint:
The Managed WordPress Portal uses the same credentials as your Liquid Web account so once logged into Liquid Web click the login button.

Liquid Web's WordPress control panel reveals how to login.

Once logged into the Managed WordPress Portal you will see the Welcome Screen which will ask you for a nickname and an email address to create your first site. Just be sure to follow the guidelines on what characters you can or cannot use in a nickname.

When the site is finished deploying, the portal will now show one default WordPress installation that you can work with pictured below. This WordPress instllation is called MyNewSite.You can simply click on the WP-Admin button, and that will take you directly to the WordPress login page for the new default site.Alternatively, click the blue link and append the default site URL with /wp-login.php.  In the above example this would be: https://mynewsite.m9n7y4ka-liquidwebsites.com/wp-login.php

When you create a new site in Managed WordPress Portal, you will be emailed an administrative user and password so you can access the site right away. It is recommended that you login and change the password immediately for security reasons.

 

Forgotten Password

If you forget your password, you can always access the login page and click on the “Lost Your Password” link under the login area. Clicking that link will send an email used to create the new default site, allowing you to change your password.

Click on the "Lost Password?" link to retreive WordPress Credentials.

As a best practice, you will always want to make sure you never use default usernames like “admin” or “user” or simple passwords (like English words) as they can be easily guessed using brute force methods. We have created some best practice for securing WordPress to help you add some extra security to your site.

 

Add a User to the MWP Portal

Since you will be working with different areas that can be confusing we’ll be using the following terminology to differentiate between them.

  1. Managed WordPress Portal – the custom control panel for your WordPress sites in Managed WordPress. The Portal is where you will add sites, work with those sites, access and adjust the setting for your websites. It’s also where you can find your backups!  The Portal will have a URL that begins with the word “app,” uses a custom string, and ends in “liquidwebsites.com” Example = https://app.m9n7y4ka-liquidwebsites.com/
  2. WordPress Dashboard – the traditional term for the back end of all WordPress sites. When you login into a specific WordPress site to perform maintenance on pages or plugins, you are accessing the WordPress Dashboard for that site.
  3. Liquid Web Account Management – this is the primary account area at Liquid Web where you log in to view all your products and services at Liquid Web, such as your invoices, your credit card payment, DNS zones, and other settings or tools that we provide for you.

You can add users to Managed WordPress Portal by logging into the Portal and then clicking on Users in the left menu. On that page, you will find a default “liquidweb_staff” user, used by our support staff, but feel free to add on any co-workers who need access to all the sites.

To add a new user click the blue Create User button to the far right.

Managed WordPress lets you add users to access sites.

Hint:
Any user you add to the Managed WordPress Portal area will be able to work with and make changes to ALL THE SITES including the ability to deleting sites from the portal.

If you want to restrict site access for a single team member, it’s best to create a WordPress Dashboard user (a WordPress user) allowing access only to that specific WordPress site.

Granting SFTP Access

If you wish only to give SFTP access to a team member (and not portal access or WordPress Dashboard access) you can provide the SFTP credentials to that team member.

  1. You can find those SFTP credentials by logging in to the portal and clicking on the blue Manage Site button for the specific site.Retrieve SFTP credentials in the Manage Site section.
  2. You will now find many portal tools and settings for that specific site. Scroll down the page until you come to the SFTP/SSH Credentials area. This area will initially provide the user, IP, and port information for accessing the site over SFTP.
  3. Click on the blue Generate New Password button.  When the popup window appears and asks, “Are you sure?” click the OK button.
  4. The page will refresh, revisit the SFTP/SSH Credentials area to find a new password was generated for that specific site.SFTP credentials are regenerated within the Manage Site section.

 

For your convenience, sse the blue COPY links to copy the information. When you are ready to revoke SFTP access for a team member access the SFTP/SSH Credentials area again and click the blue Generate New Password button to reset the password to something new.  Here are some things to know regarding SFTP.

  1. Passwords can be changed at any time.
  2. Each site in Managed WordPress portal only comes with one SFTP user and that username cannot be changed.

 

Migrate a Site

We have a custom plugin that will allow you to migrate any live, public-resolving site into Managed WordPress Portal.  You can find the plugin in the WordPress repository or even search it from a WordPress Dashboard on the Plugins page. The plugin is called Migrate to Liquid Web. This plugin was built with ease-of-use in mind and works great for anyone who wishes to migrate their own site.

Instructions for downloading and using the plugin are here:  https://www.liquidweb.com/kb/migrating-to-liquid-web-with-managed-wordpress-portal/

Some things to know about using this plugin are:

  1. Implement the migration plugin on the source, live site. It uses a push method, and thus, the source site must be publicly reachable by DNS. The plugin will not work on a local WordPress copy that is not openingly accessible through a URL.
  2. It can only push a copy of a site into our Managed WordPress and Managed WooCommerce product at Liquid Web. It is not compatible with migrating into other products at Liquid Web.
  3. It is not compatible with WordPress Multi-site (WordPress Multi-site is not compatible with our Managed WordPress solution). We can, however, break up a multi-site installation into individual sites and our team can then migrate each source site into their own, individual destination site on Managed WordPress Portal.

We are happy to perform a migration for you as well, even for multiple sites.  Here is how you can submit a request for a migration to have our team migrate a live site for you into Managed WordPress Portal:  https://www.liquidweb.com/kb/free-website-migration-service/

 

Create a New Site

To create a new site in Managed WordPress Portal simply log in to the portal and then click the Create New Site button in the upper right of the portal.

The portal will then ask you for a nickname for the site along with an email address.  Fill out both fields and then click the Create Site button.Create a WordPress site through a nickname.

It’ll take a minute or two to see the new site in the portal.  An email will shortly arrive with a username and password to access the WordPress Dashboard (also known as the WordPress backend) of the new site. Each WordPress site created in the portal installs with the default TwentySeventeen theme and comes fully prepared with its own SFTP/SSH credentials.

The email address used to install a new site is the same one used for important future updates to our portal, reports and other administrative WordPress tasks for that specific site.

With a new site deploys you’ll be provided a temporary URL to access the site.  The URL will include both the nickname of the site and the default temporary URL that is a part of your specific Managed WordPress Portal.

 

Taking a Site Live

When a site is migrated into Managed WordPress Portal it is copied to a temporary URL that is publicly resolvable over DNS. The temporary URL provides a means to test the functionality and before taking it live. This testing time provides an opportunity to get the site ready with all changes before it needs to be taken live with the real URL.

Two essential and sequential steps are necessary before publishing a site to the Internet.

  1. Change the  A record for the domain to the IP address within your Managed WordPress Portal. DNS does have to be taken care of first for the second step to work.
  2. Change the name in the Primary Domain field in the portal (under Site Details) from the temporary URL to the actual domain name.  That can be done by logging into the portal, clicking on Manage Site, and then find the Primary Domain field. Just replace the temporary URL with the straight domain name and click UPDATE.Taking a WordPress site live entails renaming the primary domain.

The portal will put the site into maintenance mode as it runs the update and gets the site ready to be live with the real domain name.The Managed WordPress Maintenance Page lets us know that updating is in progress.

Here are some things to note about the renaming process.

  1. DNS does have to resolve to the IP address of the server to deploy our automatic SSL (Secure Sockets Layer) application. Our SSL implementation runs a public DNS lookup to retrieve the IP address.
  2. The renaming process will automatically replace the temporary URLs in the database to ensure menus and image links will work with the real domain.
  3. If you wish for the site to resolve to the www version of the domain you will need to include that in the Primary Domain field in the portal.  In that case, you would set the primary domain field to www.domain.com instead of domain.com
  4. The site will be issued an automatic SSL during this process that will programmatically stay up to date!
  5. Once the renaming process has finished the portal will leave maintenance mode, and you will see the portal tools and features again for the site. At this point, the site will now be live on Managed WordPress Portal.

You can find more information documented on this here:  https://www.liquidweb.com/kb/going-live-site-managed-wordpress-portal/

 

Managing DNS

Many times customers wish to have Liquid Web host all their DNS records for a domain. You can do this by using Liquid Web’s name servers.You can use the following process to migrate all DNS records to Liquid Web:  https://www.liquidweb.com/kb/migrating-your-dns-to-liquid-web/

 

Backups

We know that backups are critical, so we provide those for you in Managed WordPress.Just click on Manage Site for the site you wish to work with and then click on Backups in the left menu.Backups are included in each Managed WordPress Product.

Here are a few apsects to note on our backups.

  1. Backups run nightly and are secured off-site location, so they don’t take up any space on the server where you sites live, meaning better performance for your websites.
  2. We keep 30 days of nightly backups, and while they are remote, you do have access to them on the Backups page.
  3. On the Backups page, you can manually create a new backup, download a backup from a specific date, or restore a backup from a particular time.
  4. If you choose to restore a backup from a specific date, it will restore right on top of the live site and revert the site to how it looked and operated on that date and time.

 

HIPAA Compliant Hosting Checklist

HIPAA Compliance

In this guide, we outline the essential requirements for HIPAA compliant servers and how Liquid Web helps fulfill these necessities.

HIPAA, or the Health Insurance Portability and Accountability Act of 1996, was passed by Congress to protect sensitive user information related to health insurance. This act helps to reduce health care fraud and mandates a standard for handling confidential healthcare information for consumers and businesses.

HIPAA compliance protects this sensitive information and specifies proper guidelines and standards for handling health insurance data. HIPAA also establishes rules for handling, administering, and maintaining electronic servers as well as the hosting of this Protected Health Information.

Read more here: https://www.liquidweb.com/kb/what-is-hipaa-compliant-hosting/

Key Terms and Important Information:

HIPAA – Health Insurance Portability and Accountability Act of 1996

PHI – Protected Health Information

Access Control – To limit who can log in or access sensitive PHI data. Access control helps provide accountability for authorized usage and access to servers with confidential information. HIPAA requires that all users are uniquely identifiable and that the server hosting PHI data is only accessible to specifically authorized users and entities.

Audit Control – To log and record hardware, software and procedural work done to maintain and repair HIPAA compliant servers and data centers. HIPAA requires accurate and uniquely accountable logs for the type of work performed, what was accessed, and by whom. This notation is closely related to access control by limiting maintenance to authorized and uniquely identifiable persons or entities, but also refers explicitly to logging any maintenance of physical hardware or server software.  

Facility Access Control – To limit physical access to the data center from unauthorized or unaccountable persons. This control makes sure that only designated workers have access to physical servers containing PHI. Liquid Web’s data centers are HIPAA compliant and properly limit access to all servers.

To be HIPAA compliant, you must have firewalls in place. Most of the time, compliant hosting will implement hardware, software, and application level firewalls to protect the server from unauthorized users. This security applies to Access Control as well as Transmission Security, which protects PHI from unauthorized access.

HIPAA regulations state the firewalls must be system-wide. The firewall implementations are part of the requirements for limiting access to personal information stored on the server. Firewalls that are properly setup will limit or prevent accessibility from anyone who should not have access, often using explicit whitelists and blacklists. This setup prevents unauthorized employees, clients, or hackers logging into servers with sensitive data.

To be allowed through the firewall your users must have a uniquely identifiable username or identification that has been explicitly allowed access permission.  At Liquid Web, our networking team is at hand to secure your server with hardware firewalls, while our support team is ready to protect sensitive PHI data with software firewalls.

HIPAA compliance requires that remote access to the server through an encrypted VPN tunnel. This VPN protects data entering into the tunnel with an encrypted session that lasts only as long as the session exists. Work done between the remote workstation and the server is protected from interception via this encryption. At Liquid Web, our VPN services are automatically encrypted in order to protect your data.

Password management is an essential part of HIPAA compliance. Safeguarding passwords and isolating them to identifiable users is integral to the protection of sensitive data. Using multi-factor authentication is highly recommended for this process.

Multi-Factor Authentication forces users logging into the secured server system to use both a password and another form of authentication, such as a mobile device, verifying their identity for granting intended access. Authenticating makes it much more difficult for hackers and unauthorized users to use stolen or brute force-acquired login credentials to access the server, as the user will have to do a secondary verification from a device that is unique to them.

Many companies utilize Google Authenticator which allows your users to have a phone app to use as their secondary verification method. Multi-Factor Authentication falls under Access Control.

If you want to be HIPAA compliant, your server cannot be on shared hosting. You must have a server that cannot be accessed by any other business or entities, which means it needs to be private or dedicated to your business. This isolated includes requiring a private IP address that is not used by another entity.

By running on shared hosting, you are breaking HIPAA compliance by allowing non-authorized users access to the server. Hosting with Liquid Web gives you your own private, dedicated server strictly used by your business.

HIPAA requirements for limiting user access and having proper authentication. The server itself must also exist within a HIPAA compliant data center. Liquid Web has a high-security, HIPAA compliant data center that all of our clients are hosted within, falling under Facility Access Control.

An SSL certificate must protect any part of your website where sensitive information can be accessed.  An SSL provides end-to-end encryption for the accessed data and logins used, to further protect access to the server. HIPAA defines PHI as Protected Health Information and anywhere that a user can access PHI must be protected with SSL.

For more information about SSL and how it works, click here: https://www.liquidweb.com/kb/how-does-an-ssl-work/

A BAA is necessary for HIPAA compliant hosting as it designates the role of the hosting company and defines responsibility for different parts of HIPAA compliance. It does not resolve your business of its HIPAA related duties, but it represents the roles that your business and the hosting company partake.

This Business Associate Agreement allows a hosting company the necessary access to servers to maintain them, while still preventing any other businesses’ unauthorized access to Protected Health Information.

See our HIPAA BAA policy here: https://www.liquidweb.com/about-us/policies/hipaa-baa/

HIPAA compliance requires that all Protected Health Information must have an exact backup ready for restoration. These backups must also be located offsite and not on your server for recovery in the event of disaster or server malfunction. At Liquid Web we have two solutions for this, Guardian and DPM Backups.

By having an offsite backup, you are protecting the Protected Health Information and ensuring that no data loss will occur on restoration. Fully restoration is often achieved with continuous backups notating any changes of information on the server.

Read more about our different backup services here: https://www.liquidweb.com/products/add-ons/storage-backups/

To be HIPAA compliant, the appropriate methods are necessary for getting rid of hardware. This disposal usually requires that the data be wiped entirely and destroyed in a manner that will not allow for restoration.

Data destruction is typically peer-reviewed and documented to state precisely the method of destruction. This process is to prevent any future use of the hardware from being able to recover sensitive PHI data.  Often called Integrity Control it ensures that data is properly altered or destroyed.

All logins and maintenance must be fully documented. Any repairs on the physical servers must be logged, especially those related to the security of the server and who logs in to servers for software maintenance and reviews and applies to Audit Control.

At Liquid Web, all of our work is logged and appropriately recorded with HIPAA compliant standards.

HIPAA compliance is an integral part of your business. While it can be confusing, our technicians at Liquid Web can ensure you that your Protected Health Information is appropriately handled and follows HIPAA compliant standards. While we have only reviewed a portion of the requirements of HIPAA compliance, feel free to reach out to our HIPAA Specialists for more information about how we handle our data centers and servers.

If you would like to speak with a HIPAA Specialist, start here: https://www.liquidweb.com/solutions/hipaa-compliant-hosting/

Liquid Web Sales and Tax FAQ

Someone doing taxes

How To Install Apache Tomcat 8 on Ubuntu 16.04

Apache Tomcat is used to deploy and serve JavaServer Pages and Java servlets. It is an open source technology based off Apache.

Pre-Flight Check

  • This document assumes you are installing Apache Tomcat on Ubuntu 16.04.
  • Be sure you are logged in as root user.

Installing Apache Tomcat 8

Step 1: Create the Tomcat Folder

Logged in as root, within the opt folder make a directory called tomcat and cd into that folder after completion.

mkdir /opt/tomcat

cd /opt/tomcat

 

Step 2: Install Tomcat Through Wget

Click this link to the Apache Tomcat 8 Download site. Place you cursor under 8.5.32  Binary Distributions, right click on the tar file and select copy link address (as shown in the picture below). At the time of this article Tomcat 8 is the newest version but feel free to pick whatever version is more up-to-date.

Tomcat 8's Download Page

Next from your server, use wget command to download the tar to  the tomcat folder from the URL you copied in the previous step:

wget http://apache.spinellicreations.com/tomcat/tomcat-8/v8.5.32/bin/apache-tomcat-8.5.32.tar.gz

Note
You can down the file to your local desktop, but you’ll then want to transfer the file to your Liquid Web server. If assistance is needed, check out this article: Using SFTP and SCP Instead of FTP

After the download completes, decompress the file in your tomcat folder:

tar xvzf apache-tomcat-8.5.32.tar.gz

 

Step 3: Install Java

Before you can use Tomcat you’ll have to install the Java Development Kit (JDK). Beforehand, check to see if Java is installed:

java -version

If that command returns the following message then Java has yet to be installed:
The program 'java' can be found in the following packages:

To install Java, simply run the following command (and at the prompt enter Y to continue):
apt-get install default-jdk

 

Step 4: Configure .bashrc file

Set the environment variables in .bashrc with the following command:

vim ~/.bashrc

Add this information to the end of the file:
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-amd64
export CATALINA_HOME=/opt/tomcat/apache-tomcat-8.5.32

Note
Verify your file paths! If you downloaded a different version or already installed Java, you may have to edit the file path or name. Older versions of Java may say java-7-openjdk-amd64 instead of java-1.8.0-openjdk-amd64 . Likewise, if you installed Tomcat in a different folder other then /opt/tomcat (as suggested) you’ll indicate the path in your bash file and edit the lines above.

Save your edits and exit from the .bashrc file, then run the following command to register the changes:

. ~/.bashrc

 

Step 5: Test Run

Tomcat and Java should now be installed and configured on your server. To activate Tomcat, run the following script:

$CATALINA_HOME/bin/startup.sh

You should get a result similar to:

Using CATALINA_BASE: /opt/tomcat
Using CATALINA_HOME: /opt/tomcat
Using CATALINA_TMPDIR: /opt/tomcat/temp
Using JRE_HOME: /usr/lib/jvm/java-7-openjdk-amd64/
Using CLASSPATH: /opt/tomcat/bin/bootstrap.jar:/opt/tomcat/bin/tomcat-juli.jar
Tomcat started

 

To verify that Tomcat is working visit the ip address of you server:8080 in a web browser. For example http://127.0.0.1:8080.

Apache Tomcat 8 Verification Page

 

How to Install Pip on Ubuntu 16.04 LTS

Arguably one of the easiest tools to use for installing and managing Python packages, Pip has earned its notoriety by the number of applications utilizing this tool. Fancied for its capabilities in handling binary packages over the easy_installed packaged manager, pip enables 3rd party package installations. Though Python does sometimes come with pip as a default, this tutorial will show how to install, check its version as well as some basic commands for using pip on Ubuntu 16.04.

 

Pre-Flight Check

  • These instructions are intended for an Ubuntu 16.04 LTS server, and we are logged in as root.
  • If you are using a different operating system, check out our other pip installation guides.

Step 1: 

Ensure that all packages are up-to-date. After running the command below, you’ll get an output of any packages getting their update.

apt-get update

Step 2:

Install pip with cURL and Python. Downloading using the cURL command ensures the latest version of pip.curl "https://bootstrap.pypa.io/get-pip.py" -o "get-pip.py"
python get-pip.py

Step 3: 

Verifying the installation of pip:

pip --version

Output:
pip --version
pip 18.0 from /usr/local/lib/python2.7/dist-packages/pip (python 2.7)

Installing Libraries

Pip can install 3rd party packages like Django, Tensorflow, Numpy, Pandas and many more with the following command.

pip install <library_name>

 

Searching for Libraries

You can also search for other libraries in Python’s repository via command line. For our example let’s look for Django packages. The search command shows us an extensive list similar to the one below.

pip search django

django-bagou (0.1.0) - Django Websocket for Django
django-maro (0.0.2) - `django-maro` is utility for django.
django-hooked (0.1.7) - WebHooks for Django and Django Rest Framework.
django-ide (0.0.5) - A Django app to develop Django apps
django-mailwhimp (0.1) - django-mailwhimp integrates mailchimp into Django
django-six (1.0.4) - Django-six —— Django Compatibility Library
django-umanage (1.1.1) - Django user management app for django
django-nadmin (0.1.0) - django nadmin support django version 1.8 based on django-xadmin
diy-django (1.3.1) - diy-django

 

Uninstalling a Library

If you don’t need the library and your scripts use them you can uninstall easily with this command:

pip uninstall

 

Installing Python Resources

Many times Python packages have a requirements.txt file, if you see this file, you can run this command to install all libraries in that package

pip install -r requirements.txt

 

MySQL Performance: Identifying Long Queries

Every MySQL backed application can benefit from a finely tuned database server. The Liquid Web Heroic Support team has encountered numerous situations over the years where some minor adjustments have made a world of difference in website and application performance. In this series of articles, we have outlined some of the more common recommendations that have had the largest impact on performance.

Preflight Check

This article applies to most Linux based MySQL servers. This includes, but is not limited to, both Traditional Dedicated and Cloud VPS servers running a variety of common Linux distributions. The article can be used with the following Liquid Web system types:

  • Core-managed CentOS 6x/7x
  • Core-managed Ubuntu 14.04/16.04
  • Fully-managed CentOS 6/7 cPanel
  • Fully-managed CentOS 7 Plesk Onyx 17
  • Self-managed Linux servers
Note
Self-managed systems, which have opted out of direct support can take advantage of the techniques discussed here, however, the Liquid Web Heroic Support Team cannot offer direct aid on these server types.

This series of articles assumes familiarity with the following basic system administration concepts:

 

What is MySQL Optimization?

There is no clearly defined definition for the term MySQL Optimization. It can mean something different depending on the person,  administrator, group or company. For the sake of this series of articles on MySQL Optimization, we will define MySQL Optimization as:  The configuration of a MySQL or MariaDB server which has been configured to avoid commonly encountered bottlenecks discussed in this series of articles.

What is a bottleneck?

Very similar to the neck on a soda bottle, a bottleneck as a technical term is a point in an application or server configuration where a small amount of traffic or data can pass through without issue. However, a larger volume of the same type of traffic or data is hindered or blocked and cannot operate successfully as-is. See the following example of a configuration bottleneck:

Visual Difference between Optimized and Non-Optimized DatabaseIn this example, the server is capable of handling 10 connections simultaneously. However, the configuration only accepts 5 connections. This issue would not manifest so long as there were 5 or less connections at one time. However, when traffic ramps up to 10 connections, half of them start to fail due to unused resources in the server configuration. The above examples illustrates the bottleneck shape where it derives its name versus an optimized configuration which corrects the bottleneck.

When Should I Optimize My MySQL database?

Ideally, database performance tuning should occur regularly and before productivity is affected. It is best practice behavior to conduct weekly or monthly audits of database performance to prevent issues from adversely affecting  applications. The most obvious symptoms of performance problems are:

  • Queries stack up and never completing in the MySQL process table.
  • Applications or websites using the database become sluggish.
  • Connection timeouts errors, especially during peak hours.

While it is normal for there to be several concurrent queries running at one time on a busy system, it becomes a problem when these queries are taking too long to finish on a regular basis. Although the specific threshold varies per system and per application, average query times exceeding several seconds will manifest as a slowdown within attached websites and applications. These slowdowns can sometimes start out small and go unnoticed until a large traffic surge hits a particular bottleneck.

Identifying Performance Issues

Knowing how to examine the MySQL process table is vital for diagnosing the specific bottleneck being encountered. There is a number of ways to view the process table depending on your particular server and preference. For the sake of brevity this series will focus on the most common methods used via Secure Shell (SSH) access:

 

Using The MySQL Process Table: Method 1

Use the ‘mysqladmin’ command line tool with the flag ‘processlist’ or ‘proc’ for short. (Adding the flag ‘statistics’ or ‘stat’ for short will show running statistics for queries since MySQL’s last restart.)

Command:

mysqladmin proc stat

Output:

 +-------+------+-----------+-----------+---------+------+-------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+-------+------+-----------+-----------+---------+------+-------+--------------------+----------+
| 77255 | root | localhost | employees | Query | 150 | | call While_Loop2() | 0.000 |
| 77285 | root | localhost | | Query | 0 | init | show processlist | 0.000 |
+-------+------+-----------+-----------+---------+------+-------+--------------------+----------+
Uptime: 861755 Threads: 2 Questions: 20961045 Slow queries: 0 Opens: 2976 Flush tables: 1 Open tables: 1011 Queries per second avg: 24.323

Pro: Used on the shell interface, this makes piping output to other scripts and tools very easy.
Con: The process table’s info column is always truncated so does not provide the full query on longer queries.

Using The MySQL Process Table: Method 2

Run the ‘show processlist;’ query from within MySQL interactive mode prompt. (Adding the ‘full’  modifier to the command disables truncation of the Info column. This is necessary when viewing long queries.)

 

Command:

show processlist;

Output:
MariaDB [(none)]> show full processlist;
+-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+
| 77006 | root | localhost | employees | Query | 151 | NULL | call While_Loop2() | 0.000 |
| 77021 | root | localhost | NULL | Query | 0 | init | show full processlist | 0.000 |
+-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+

Pro: Using the full modifier allows for seeing the full query on longer queries.
Con: MySQL Interactive mode cannot access scripts and tools available in the shell interface.

Using The slow query log

Another valuable tool in  MySQL is the included slow query logging feature. This feature is the preferred method for finding long running queries on a regular basis. There are several directives available to adjust this feature. However, the most commonly needed settings are:

 

slow_query_logenable/disable the slow query log
slow_query_log_filename and path of the slow query log file
long_query_timetime in seconds/microseconds defining a slow query

These directives are set within the [mysqld] section of the MySQL configuration file located at /etc/my.cnf and will require a MySQL service restart before they will take affect. See the example below for formatting:

Caution
There is a large disk space concern with the slow query log file, which needs to be attended to continually until the slow query log feature is disabled. Keep in mind, the lower your long_query_time directive the faster the slow query log fills up a disk partition.
[mysqld]
log-error=/var/lib/mysql/mysql.err
innodb_file_per_table=1
default-storage-engine=innodb
innodb_buffer_pool_size=128M
innodb_log_file_size=128M
max_connections=300
key_buffer_size = 8M
slow_query_log=1
slow_query_log_file=/var/lib/mysql/slowquery.log
long_query_time=5

Once the slow query log is enabled you will need to periodically follow-up with it to review unruly queries that need to be adjusted for better performance. To analyze the slow query log file, you can parse it directly to review its contents. The following example shows the statistics for the sample query which ran longer that the configured 5 seconds:

Caution
There is a performance hit taken by enabling the slow query log feature. This is due to the additional routines needed to analyze each query as well as the I/O needed to write the necessary queries to the log file. Because of this, it is considered best practice on production systems to disable the slow query log. The slow query log should only remain enabled for a specific duration when actively looking for troublesome queries that may be impacting the application or website.
# Time: 180717 0:23:28
# User@Host: root[root] @ localhost [] # Thread_id: 32 Schema: employees QC_hit: No
# Query_time: 627.163085 Lock_time: 0.000021 Rows_sent: 0 Rows_examined: 0
# Rows_affected: 0
use employees;
SET timestamp=1531801408;
call While_Loop2();

Optionally, you can use the mysqldumpslow command line tool, which parses the slow query log file and groups like queries together except values of number and string data:
~ $ mysqldumpslow -a /var/lib/mysql/slowquery.log
Reading mysql slow query log from /var/lib/mysql/slowquery.log
Count: 2 Time=316.67s (633s) Lock=0.00s (0s) Rows_sent=0.5 (1), Rows_examined=0.0 (0), Rows_affected=0.0 (0), root[root]@localhost
call While_Loop2()
(For usage information visit MySQL documentation here: mysqldumpslow – Summarize Slow Query Log Files)

So concludes the first part of our Database Optimization series and gives us a solid basis to refer back to for benchmark purposes. Though database issues can be complicated, our series will break down these concepts to provide means to optimize your database through database conversion, table conversion, and indexing.

 

What is HIPAA compliant hosting?

You may have seen HIPAA compliance appear  in your search for a secure web hosting provider, but what exactly is a HIPAA server? What is HIPAA, for that matter? You may also be wondering if you  need to be using a HIPAA compliant server? These are all great questions!We first need to start with the term HIPAA, as it’s quite a vital piece to understanding when a HIPAA compliant server is necessary.

hipaa compliance hosting

What is HIPAA?

The Health Insurance Portability and Accountability Act of 1996 (more commonly called HIPAA) mandated necessary protocols be defined and followed when handling Personal Health Information (PHI). PHI records are any form of medical record that contains information which can identify an individual person. The purpose of HIPAA is to ensure the integrity and confidentiality of the sensitive data within these kinds of records. The 2010 Health Information Technology for Economic and Clinical Health Act (HITECH) modified HIPAA to include electronic Personal Health Information (ePHI). Also, sometimes called Electronic Medical Records (EMR).

What is a HIPAA server?

A HIPAA compliant server is one that follows the guidelines defined by HIPAA to prevent medical record information data breaches. ePHI data breaches can be detrimental to individual or entity reputations and result in severe legal consequences.  In part 164 of the Code of Federal Regulations (CFR) within HIPAA, it specifies: 

Paragraph 164.308(a)(1)(i) Standard: Security Management Practices—Implement policies and procedures to prevent, detect, contain, and correct security violations.

HIPAA mandates that entities handling PHI data adopt and invoke their own set of policies to protect the integrity and confidentiality of these records. It’s up to the individual entities to determine how to approach these aspects of protecting the data. The following is a list of sample policies that address these requirements and would constitute a valid HIPAA server:

  • Physical Data Storage Security: Any media or servers which contain ePHI data, must be secured from unauthorized physical access. This often includes using locked cages or cabinets.
  • Physical Data Destruction Security: Destruction of ePHI data, is usually peer-reviewed and logged by a chain of custody certificates that explicitly state how the data was destroyed.
  • Data Access Security: Maintaining remote and physical access control lists and chain of custody logging to ensure every time the data is accessed, it’s by an authorized and documented individual.
  • Data Integrity Security: This generally takes on the form of action logging, in addition to chain of custody logging. Any form of action done to the data must be documented and logged.
  • Data Transfer Security: When transmitting data over network interfaces, the connection must be encrypted end-to-end to insure security.
  • Data Breach Reporting: Anytime there is a breach of HIPAA policies, the breach and potential impact of the breach must be documented, logged and reported immediately.

When do I need a HIPAA server?

A HIPAA compliant server is necessary only when storing, transferring, reading, displaying or otherwise accessing any form of data that contains individually identifiable Health Information. Anonymous medical data is not subject to HIPAA or HITECH and is not required to be secured in the same way. In general, if you’re not in the Health Industry, there is no need for a HIPAA compliant server. The CFR part 160.103 specifically defines Health Information as:

Health information means any information, including genetic information, whether oral or recorded in any form or medium, that:

(1) Is created or received by a health care provider, health plan, public health authority, employer, life insurer, school or university, or health care clearinghouse; and

(2) Relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual; or the past, present, or future payment for the provision of health care to an individual.hipaa compliance hosting

How can Liquid Web help?

Liquid Web has you covered! We have designed a robust suite of HIPAA-compliant, fully managed hosting solutions. We take care of all the necessary policy enforcement and documentation with the day to day systems administration of your HIPAA servers. Our support staff is fully armed with the required knowledge to enforce our HIPAA procedures. You can rest assured that we will handle any necessary HIPAA related actions when working on one of your HIPAA servers. You can see a full list of these policies, how we enact them, and our HIPAA compliant offerings here: HIPAA Compliant Data Centers & Solutions. You can even chat with a HIPAA Specialist right away to answer any looming questions you may still have.

 

Configure Apache 2 to Control Browser Caching

Today we are configuring browser caching control on common Apache 2 servers. Caching is a great tool to reduce server resource consumption, bandwidth utilization and provide a faster end-user experience to visitors. To get familiar with caching concepts, simply review our ‘What is Caching?’ tutorial.

Pre-Flight Check

This article covers all Apache 2 servers running the mod_expires and mod_headers Apache modules. This includes, but is not limited to, both traditional Dedicated servers and Cloud VPS servers running a number of different Linux distributions:

  • Core-managed CentOS 7* Servers
  • Core-managed CentOS 6* Servers
  • Fully-managed CentOS 7 cPanel Servers
  • Fully-managed CentOS 6 cPanel Servers
  • Fully-managed CentOS 7 Plesk Onyx 17 Linux Servers
Note:
Self-managed servers running a similar Linux distribution can take advantage of this article. However, instructions are not specifically provided for Self-managed configurations.

The article assumes familiarity with the following basic system administration concepts:

Verify Modules

Our servers generally include both the mod_expires and mod_headers modules needed for browser cache control. However, before we configure the directives, we must first ensure the modules are installed and Apache 2 is ready to accept the directives. Verification is simple. We will be using the apachectl -M command to list the installed Apache modules while piping the output through the grep module_name command to filter the results down to showing only modules with the provided module_name, likes so:

Verifying mod_headers (also known as Headers_module) by copying & pasting the following command.

apachectl -M | grep header

… will return:

headers_module (shared)

Verifying mod_expires (also known as expires module) by copying and pasting the following command.

apachectl -M | grep expires

… will return:

expires_module (shared)

These modules must be present in the output when running the command. If they do not show up in the output, it will simply be blank, which indicates the modules are not installed. If the modules are missing then we will need to install them before we can continue.

Configuration Directives

We can use the following example of a generic configuration that serves to reduce the strain on server resources by prolonging the cache duration of common static files. These types of files typically do not change between visits. So they do not need to be downloaded on every visit. Modern browsers are equipped to accept instructions from web servers that provide suggestions for how long content should be cached. This example works well for most sites. However, you may need to add/remove file types or adjust lifespan as needed for your particular content.

<IfModule mod_expires.c>
# Turn on the module.
ExpiresActive on
# Set the default expiry times.
ExpiresDefault "access plus 2 days"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType text/css "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType text/css "now plus 1 month"
ExpiresByType image/ico "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 month"
ExpiresByType text/html "access plus 600 seconds"
</IfModule>

Explanation of Each Directive

These are opening tags and will only process directives between these if the module, mod_expires, is installed on the server.

<IfModule mod_expires.c> ... </IfModule>

Download all files only if the cached has not been accessed in more than 2 days.

ExpiresDefault "access plus 2 days"
Download files only if the cached file has not been access in more than 1 month. This covers jpg, jpeg, gif, png, css, javascript, flash, ico and x-icon file types.

ExpiresDefault "access plus 2 days"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType text/css "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType text/css "now plus 1 month"
ExpiresByType image/ico "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 month"

Download files only if the cached copy hasn’t been accessed in 10 minutes.

ExpiresByType text/html "access plus 600 seconds"

You can find a more robust explanation of these directives and all that expires_module offers in the Apache mod_expires Online Docs.

Implementation

Now that we have an understanding of how these directives can be configured, we need to decide on our method of implementation. There are generally two method of implementation for these directives. We classify these as either Portable or Include Methods.

Portable Method

The Portable Method uses .htaccess files to manage which directories are affected by the mod_expires configuration we are settings. These are handled like any other .htaccess file changes.

  1. SSH/FTP to the server
  2. Locate the directory which needs browser caching enabled.
  3. Modify the .htaccess file in that directory or create one if there is not one already.
  4. Add the needed directives from the Configuration Directives section above.
  5. Save the changes to the file.
  6. Done.

There is a small bottleneck caveat associated with .htaccess files. This caveat is not specific to mod_expires and is an overall Apache caveat with .htaccess files in general. In order for .htaccess files to work, Apache must scan every directory leading up to a targeted file looking for and applying any .htaccess files it finds along the way. This can create an I/O bottleneck on some server configurations. We recommend using the Include Method on all Cloud VPS Servers to avoid this type of problem.

Include Method

In contrast to the Portable Method, the Include Method takes advantage of the Apache include system. Apache only reads include files at startup so this prevents the I/O Bottleneck discussed above in the Portable Method section.

There are generally two ways to use the Include Method: Globally or Per Website. Either method requires locating and modifying the correct include files on the server. The correct files to modify is dependent on both distribution and server management software. We will discuss the correct locations for both methods on the various Liquid Web CentOS servers we support and listed in the Pre-Flight Check section above.

Global Includes

Applying the mod_expires directives globally is straight forward. It will have the effect of enabling the desired directives over the entire server, affecting every site running through Apache.

Core-managed CentOS 6 & 7 Servers

1.  Create a file named expires.conf in /etc/httpd/conf.d/ by typing in the following command:

vim /etc/httpd/conf.d/expire.conf

2. Add the necessary directives to the file and save the changes.
File should look like the following:

<IfModule mod_expires.c>
# Turn on the module.
ExpiresActive on
# Set the default expiry times.
ExpiresDefault "access plus 2 days"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType text/css "now plus 1 month"
ExpiresByType image/ico "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 month"
ExpiresByType text/html "access plus 600 seconds"
</IfModule>

3.  To finish, reload Apache for the server to see the changes:

Service httpd reload

Fully-managed CentOS 6 & 7 cPanel Servers

1. Create file name pre_virtualhost_global.conf  in /usr/local/apache/conf/includes/ if it does not already exist.

vim /usr/local/apache/conf/includes/pre_virtualhost_global.conf

2.  Add the necessary directives to the bottom of the  file and save the changes.
Your file may contain additional directives in this file, but the bottom should look like this:

<IfModule mod_expires.c>
# Turn on the module.
ExpiresActive on
# Set the default expiry times.
ExpiresDefault "access plus 2 days"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType text/css "now plus 1 month"
ExpiresByType image/ico "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 month"
ExpiresByType text/html "access plus 600 seconds"
</IfModule>

3.  Restart Apache Service:

/scripts/restartsrv_apache

If Running EasyApache 4: Restart Apache PHP-FPM Service

/scripts/restartsrv_apache_php_fpm

Fully-managed CentOS 7 Plesk Onyx 17 Linux Servers

1. Create file name expires.conf in /etc/httpd/conf.d/

vim /etc/httpd/conf.d/expire.conf

2.Add the necessary directives to the file and save the changes.
The file should look like the following:

<IfModule mod_expires.c>
# Turn on the module.
ExpiresActive on
# Set the default expiry times.
ExpiresDefault "access plus 2 days"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType text/css "now plus 1 month"
ExpiresByType image/ico "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 month"
ExpiresByType text/html "access plus 600 seconds"
</IfModule>

3.  Restart Apache Service:

Service httpd restart

Per Website Includes

We can also use Apache includes on a per virtual host level to enable browser caching on an individual website basis. We’ll go over how to configure these on our CentOS systems below.

Note:
Each website has two virtual hosts, one for HTTP (port 80) connections and another for HTTPS (port 443) connections. Each virtual host is independent of one another. Adding a change to the HTTP virtual host will not automatically apply to the HTTPS virtual host and vice versa.
Core-managed CentOS 6 & 7 Servers

The exact method of site management on Core-managed servers is left up to the server owner. This can vary dramatically depending on the person. We will use the default SSL site configuration file as an example on how to configure the Per Website includes for browser caching. Once you locate the necessary site’s configuration file, follow these steps:

1. Locate and Open the configuration file for the site being modified. 

vim /etc/httpd/conf.d/ssl.conf

2.  Locate the Virtual Host line for the site within its config file.  A Virtual Host Stanza looks like the following example:

<VirtualHost _default_:443>

</VirtualHost

3. Apply the needed mod_expires directives between the virtual host lines.
The results should look similar to the following example:

<VirtualHost _default_:443>

   <IfModule mod_expires.c>
   # Turn on the module.
   ExpiresActive on
   # Set the default expiry times.
   ExpiresDefault "access plus 2 days"
   ExpiresByType image/jpg "access plus 1 month"
   ExpiresByType image/gif "access plus 1 month"
   ExpiresByType image/jpeg "access plus 1 month"
   ExpiresByType image/png "access plus 1 month"
   ExpiresByType text/javascript "access plus 1 month"
   ExpiresByType application/javascript "access plus 1 month"
   ExpiresByType application/x-shockwave-flash "access plus 1 month"
   ExpiresByType text/css "now plus 1 month"
   ExpiresByType image/ico "access plus 1 month"
   ExpiresByType image/x-icon "access plus 1 month"
   ExpiresByType text/html "access plus 600 seconds"
   </IfModule>

</VirtualHost>

4. Restart Apache Service

Service httpd restart

Fully-managed CentOS 6 & 7 cPanel Servers

cPanel provides a rich template system that can be used to modify Apache behavior as needed. There is a specific directory structure needed to ensure our modifications persist through updates, upgrades and restarts. This system works the same way on both EasyApache 3 as well as EasyApache 4 systems.

 

Each site can handle its own set of custom include files. These need to be located in the following locations:


HTTP Virtual Hosts:
/etc/apache2/conf.d/userdata/std/2_4/<USER>/<DOMAIN>/<INCLUDENAME>.conf


HTTPS Virtual Hosts:
/etc/apache2/conf.d/userdata/ssl/2_4/<USER>/<DOMAIN>/<INCLUDENAME>.conf

There are three variables in the path above that need to be reconciled:

  • <USER> replaced by the necessary accounts username.
  • <DOMAIN> replaced by the fully qualified domain.tld name of the site. (minus the www. prefix)
  • <INCLUDENAME> replace by the name of the include file. This should reflect the include’s purpose. E.G. expires.conf

1. These directories do not exists by default and will need to be created. Once you know the details this can be done easily with the mkdir -p command like so:

HTTP Virtual Host:

mkdir -p /etc/apache2/conf.d/userdata/std/2_4/myuser/example.com/

HTTPS Virtual Host:

mkdir -p /etc/apache2/conf.d/userdata/ssl/2_4/myuser/example.com/

2. After the directories are created, we can now create our include files, calling it expires.conf.
HTTP Virtual Host:

vim /etc/apache2/conf.d/userdata/std/2_4/myuser/example.com/expires.conf

HTTPS Virtual Host:
vim /etc/apache2/conf.d/userdata/ssl/2_4/myuser/example.com/expires.conf

3. Add the necessary mod_expires directives to both expires.conf files. They should look similar to this when complete:

<IfModule mod_expires.c>
# Turn on the module.
ExpiresActive on
# Set the default expiry times.
ExpiresDefault "access plus 2 days"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType text/css "now plus 1 month"
ExpiresByType image/ico "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 month"
ExpiresByType text/html "access plus 600 seconds"
</IfModule>

4. Now we will need to have cPanel rebuild the Apache configuration to apply the new includes.

/usr/local/cpanel/scripts/rebuildhttpdconf

5. Restart Apache to update the running configuration:
/usr/local/cpanel/scripts/restartsrv_apache

6. If running EasyApache 4, Restart Apache PHP-FPM service as well:
/usr/local/cpanel/scripts/restartsrv_apache_php_fpm

There are additional methods for handling virtual hosts in cPanel. Applying includes to all hosts or all HTTPS hosts or even all hosts by one user. For a much more in-depth explanation of the cPanel Virtual Host Include system, visit the Official cPanel Online Docs.

Fully-managed CentOS 7 Plesk Onyx 17 Linux Servers

Plesk provides a robust include and template system for modification of virtual host entries on an individual virtual host basis. These are done in the following files:

Note:
We will need to replace example.com with your domain name (minus www. prefix).
/var/www/vhosts/system/example.com/conf/vhost_ssl.conf

The directory structure here should already exist. However, these vhost.conf and vhost_ssl.conf files do not exist by default and will need to created.

1. Create the needed include files:
HTTP Virtual Host:

touch /var/www/vhosts/system/example.com/conf/vhost.conf

HTTPS Virtual Host:
touch /var/www/vhosts/system/example.com/conf/vhost_ssl.conf

2. Modify both vhost.conf and vhost_ssl.conf applying the necessary mod_expires directives. When finish each file should look similar to the following:

<IfModule mod_expires.c>
# Turn on the module.
ExpiresActive on
# Set the default expiry times.
ExpiresDefault "access plus 2 days"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType text/css "now plus 1 month"
ExpiresByType image/ico "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 month"
ExpiresByType text/html "access plus 600 seconds"
</IfModule>

3. Have Plesk rebuild the configuration for the site in question
/usr/local/psa/admin/sbin/httpdmng --reconfigure-domain example.com

4. Restart Apache Service:
service httpd restart

The Plesk templates and includes systems is very robust and permits integration of many other common Apache directives. Visit the Plesk Onyx Online Documentation to learn more about leveraging its capabilities.

Upgrading PHP on Windows

Performing an upgrade to PHP on Windows Server

Keeping your software and applications up to date is a crucial part of maintaining security and stability in your web hosting systems. Unfortunately, updating system components and back-end software can sometimes be a frustrating and a difficult process. However, thanks to Microsoft’s Web Platform Installer, upgrading PHP on a Windows server with IIS is as simple as a few clicks.

Continue reading “Upgrading PHP on Windows”