Enabling DomainKeys Identified Mail (DKIM)

DomainKeys Identified Mail (DKIM) is a way to attach an encrypted digital signature to your email. Like adding an SPF record to your server, DKIM helps prevent email spoofing. Email spoofing is when spammers send email that looks like it’s coming from your email address. Spammers spoof your address to make it more likely that recipients will open spam emails, less likely that messages will be marked as spam, and harder to find the true spam source. If your address is spoofed, your server could get flagged as a spam server and you can have trouble sending legitimate mail, even if you aren’t doing anything wrong. This is commonly known as having a bad mail reputation.

Outgoing DKIM works by generating an encrypted digital signature that is attached to email messages sent by your server. This signature is generated using a public key you save as a DNS record. Theoretically, only you have access to your DNS records, so mail signed using this key should be unmodified and verified as coming from your server. If you don’t use your server to send mail, adding DKIM records to your server will have no effect on your mail reputation.

Using Plesk?

DKIM is not natively supported in Plesk 12. Instead, Plesk uses DomainKeys. If you’d like to use DKIM, it is supported with certain Plesk MailEnable plans. If you specifically need DKIM, contact our Heroic Support team to learn more about MailEnable.

There are three parts to enabling DKIM:

Generating Your DKIM Key

On a cPanel server, generating a DKIM key is easy! cPanel does it for you.

  1. Log into the cPanel account with email accounts where you’d like to enable DKIM. DKIM records are tied to a domain, you each domain you email from will need its own record.
  2. Scroll down to Email and click on Authentication.
    dkim1
  3. On the Email Authentication page, you’ll see two different methods: DKIM and SPF. We recommend using both, but this walkthrough will only cover DKIM. We have a separate article on SPF records. In the DKIM section, click Enable if DKIM is disabled.
    dkim2
  4. Once you enable DKIM, you’ll see a field that shows your current raw DKIM record. This is the public key you need to add to your DNS records. It should look something like this:

    default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyGm4KfaLQsOiNqfNGT0DDa+XE+TmIyr03F3/AMU8SXFwgItBU/PikYTmIyr07yhQoqlPrSL27l8XHf8AMIIB1LtxU2/490wRkuu9ZorEjRkIXSbev1GyAinBQNa5Rln2S+8AMIIBhZzfkNw7panbVJ0HPREiZAJ5TQEX1LjTqB/nArmNaMXaRUCwmYzGY45z8" eW2BJMM7Ftsj3nOTmIyr0LFSL27l8OaMDdcvpCglrFWoF1dXA78ORuvMSL27l8A5+UWRFBQ4NP6awWYj2LTSyeNeTlafawRk2B3C/dNcwpoLjz3T1wBHctcLnuC13+nMzzyUtgIVgz/7Ka8AMIIBQIDAQAB\;

Copy this record and paste it into a text document to prepare for the next step: adding your DKIM record to DNS.

Adding Your DKIM Key to DNS

Now that you’ve generated your DKIM record, you need to add it to your DNS records. These directions are different depending on where your DNS is hosted:

If you don’t know where your DNS is hosted, read our article on how to find out first!

Your DNS Is Hosted at Liquid Web

If you are using Liquid Web’s nameservers, you can update your DNS records right in your Liquid Web account. Liquid Web’s nameservers are:

  • ns.liquidweb.com
  • ns1.liquidweb.com
  • ns.sourcedns.com
  • ns1.sourcedns.com

As long as your domain is using one of these nameservers, you’re good to go!

  1. Before you begin to add your DKIM record to your Liquid Web account, there is a small amount of formatting to do. The text portion of your DKIM record should look similar to this:
    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyGm4KfaBhFDhZzfkNw7pan+XE+TmIyr03F3/AMU8SXFwgItBU/PikYlddmgf7yhQoqlPrUMEqPZXHfIE8uGg1LtxU2/490wRkuu9ZorEjRkIXSbev1GyAinBQNa5Rln2S+AeBhFDhZzfkNw7panbVJ0HPREiZAJ5TQEX1LjTqB/nArmNaMXaRUCwmYzGY45z8" eW2BJMM7Ftsj3nOPYRbYxLFCzroSSOaMDdcvpCglrFWoF1dXA78ORuvMSL27l8A5+UWRFBQ490wRkuu9ZorEjRNeTlafawRk2B3C/dNcwpoLjz3T1wBHctcLnuC13+nMzzyUtgIVgz/7KaGQv5rnQIDAQAB\;
    Some punctuation needs to be removed to format this record correctly.

    • Remove the quotation mark at the beginning of the record.
    • Remove the space and quotation mark in the middle of the record.
    • Remove the slash and semicolon at the end of the record.

    With those few edits, you’re all set to load your DKIM record into your Liquid Web account.

  2. Log into your Liquid Web account.
  3. In the left navigation menu, click on Domains.
  4. The Domains Dashboard has three tabs along the top. Click on DNS.
  5. Scroll down to Current DNS Zones and click the [+] next to the domain where you’re adding the DKIM record. You’ll see a list of your current DNS records. At the bottom of that list, click on Add a New Record. Now, you can follow the steps you’d normally use to add a DNS record.
  6. The first field in your new record is for the subdomain. In this field, enter the first part of your record:
  7. The second field is the time to live, or TTL. This is how quickly new changes will take effect. You can match this to your other DNS records.
  8. Now, choose TXT from the Type dropdown menu.
  9. The last field is the data field. Here you’ll copy and paste the rest of the record cPanel created for you.
  10. Click the green checkmark to save your DNS record.

Now that your DKIM record has been added, all that is left is to add a TXT policy record.

Your DNS is hosted on the same server as your email

If you are using private nameservers on the same server as your email, cPanel will set up your DKIM records automatically! So, once you follow the steps to auto-generate your DKIM record, they are automatically added to your DNS zone in WHM. Just confirm they are correct in WHM:

  1. Log into WHM.
  2. In the search bar above the left navigation, search for “DNS.” Then, click on Edit DNS Zone.
  3. Click on the domain where you auto-generated the DNS record in cPanel, then click Edit.
  4. Scroll down and check to see that your DKIM records are included. If they are, you’re all set!
  5. If the SPF record isn’t there, simply add a new record by copying and pasting the DKIM record information into a new TXT record.

Now that your DKIM record has been added, all that is left is to add a TXT policy record.

Your DNS is hosted with another company

If you registered your domain at another company and host your DNS there, you log into your account with that company to manage your DNS. Find their DNS record editor and enter your DKIM record according to their specifications.

Now that your DKIM record has been added, all that is left is to add a TXT policy record.

Adding a TXT Policy Record

A policy record is a DNS TXT record that talks more generally about DKIM on your server. It shows your server uses DKIM verification and makes DKIM work more smoothly. A policy record is just one more DNS record. Wherever you added the DKIM DNS record, you’ll also add the policy record.

There are different tags that make up the text of a policy record:

  • t=y; tells other servers your domain is testing DKIM. This means if your DKIM isn’t working properly, other servers are less likely to reject your email.
  • o=~; means that some of your mail is signed by DKIM, but not necessarily all. o=-; means all your mail is signed by DKIM. So, if another server receives a message that isn’t signed, it will be rejected.
  • n=your information here; is a note. It doesn’t affect DKIM, but you can use it to explain more about your specific DKIM. This will show up in error logs if something DKIM verification fails.
  • r=postmaster@mysite.com; is the responsible email address for this domain. Use an email address you can access on your server.

Most likely, your policy record will look like this:

_domainkey IN TXT "t=y; o=~; n=Interim Sending Domain Policy; r=postmaster@mysite.com"

Using t=y; and o=~; will help your email be delivered even if the DKIM signature gets broken in transit from your server to the receiving server. Of course, replace “postmaster@mysite.com” with the responsible email address.

Entering your policy record is the exact same procedure as entering any other DNS record. Wherever you entered your domain-specific DKIM record is also where you should enter your policy record: either in your Liquid Web account interface, in WHM, or in the control panel of your external DNS provider

You’ve successfully created a DKIM record for your domain! You can check to make sure it’s working by sending a test message from a domain email account to check-auth@verifier.port25.com. You don’t have to include a subject or any body text. You’ll receive an automated reply with the status of DKIM, as well as other services you may have.

Where Is My DNS Hosted?

From time to time, you’ll have to make changes to your DNS records. For example, if you change IP addresses, your DNS A records will change. You’ll also change DNS if you want to add SPF records to help email authentication. For these changes to work properly, it’s vital to know where DNS is hosted.

DNS is always hosted at your domain’s authoritative nameservers. Your authoritative nameservers, and therefore your DNS, can be in three places:

  • Liquid Web’s nameservers
    • ns.liquidweb.com
    • ns1.liquidweb.com
    • ns.sourcedns.com
    • ns1.sourcedns.com
  • Your private nameservers on your server or another server you control
    • Ex.: ns.mysite.com
  • Where you registered your domain name
    • Ex.: Enom, GoDaddy, Namecheap, etc.

If you are using Liquid Web’s nameservers, you can update your DNS records in your Liquid Web account interface. If you use private nameservers on your server or another server, you can update DNS records in the control panel for your server (most likely WHM or Plesk, sometimes cPanel for SPF records). If your nameservers are where you registered your domain name, you’ll need to log into your account at that registrar and edit DNS there.

Either way you check your domains authoritative DNS you should always remember, if you don’t update DNS in the right place it wont take effect. This could mean your websites won’t load properly and can cause unnecessary downtime.

Discovering Where DNS Is Hosted – Web

If you aren’t comfortable using your terminal program to look up WHOIS information, use an online WHOIS checking tool.

Discovering Where DNS Is Hosted – CLI

You can easily find out where your DNS records are hosted using your server’s WHOIS entries.

  1. Launch your terminal program. Every operating system (Windows, Mac, and Linux) has a terminal program: use your computer’s search function to look for “terminal,” then open the terminal program you find.
  2. In the terminal window, type:
    whois mysite.com
    and press Enter. Be sure to replace “mysite.com” with your site’s domain.
  3. You’ll start seeing a lot of information about your domain, including where it is registered and the nameservers you’re using.
    Domain Name: LIQUIDWEB.COM
    Registrar: NETWORK SOLUTIONS, LLC.
    Sponsoring Registrar IANA ID: 2
    Whois Server: whois.networksolutions.com
    Referral URL: http://networksolutions.com
    Name Server: NS.LIQUIDWEB.COM
    Name Server: NS1.LIQUIDWEB.COM
    Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
    Updated Date: 04-aug-2016
    Creation Date: 05-aug-1997
    Expiration Date: 04-aug-2026
  4. Look specifically at the Name Server listing. In this example, you’ll see liquidweb.com uses Liquid Web’s nameservers. You might also see your own server listed as the nameserver (ns.mysite.com) or a domain registrar listed as the nameserver. This information tells you where you will be editing your DNS records:
    • If you use Liquid Web nameservers: edit your DNS records in your Liquid Web account.
    • If you use private nameservers: edit your DNS by logging into cPanel and searching for “Edit DNS Zone.”
    • If you use a different registrar’s nameservers: edit your DNS records by logging into your account at your registrar.

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

Enable Remote MySQL Connections in cPanel

Remote MySQL connections are disabled by default in cPanel servers because they are considered a potential security threat. Using the tools in the Web Host Manager (WHM) and the domain-level cPanel interface (usually http://domainname.com/cpanel) remote hosts can be added which the server allows to connect to the MySQL service.

Before using either of the following techniques, you will need to to open up port 3306 in your server’s firewall.

Enabling Remote MySQL in the WHM Interface

Log in to the server’s WHM interface and find the section in the left-side navigation bar labeled SQL Services. You can sort the list by typing ‘sql’ in the search box. Click on the link marked Additional MySQL Access Hosts:

WHM - Remote MySQL List

On the following page, enter one or more hosts or IP addresses in the text box (1) and click the Save button (2). If you wish to activate these settings on all user accounts see (3).

WHM - Remote MySQL page

Now that the remote connection has been activated in the WHM each domain account that wants to use the remote connection will need to activate it in their own cPanel interface.

Enabling Remote MySQL in the Domain cPanel Interface

Log in to the domain’s cPanel interface and find the section on the main page labeled Databases.

In the Databases section find the link/button labeled Remote MySQL and click on it.

cPanel - Remote MySQL list

The following page will appear in your browser. Add a hostname or IP address that you want to grant remote MySQL access to (1) and then click the Save button (2).

If a host or IP address needs to be removed from this list you can click the ‘Delete’ button next to the entry in the list.

cPanel-page-fxt

Once you have made your changes, additions, or removals to the list you can return the main page of the cPanel interface, or log out if you have no other tasks to take care of.

===

Liquid Web’s Heroic Support is always available to assist customers with this or any other issue. If you need our assistance please contact us:
Toll Free 1.800.580.4985
International 517.322.0434
support@liquidweb.com
https://manage.liquidweb.com/

How to Replace PHP GeoIP with MaxMindDB

Depending on the site or application, looking up geographic information related to an IP address can be a pretty common action. When doing IP geolocation in PHP usually the PHP GeoIP extension would be used to facilitate the retrieval of this information. Unfortunately, this particular plugin is no longer actively supported and has not been updated in a number of years.

With the go-to PHP extension of IP geolocation effectively being deprecated, new projects should begin to use the replacement options that are now provided by MaxMind. However, unlike the original GeoIP, which was shipped as a native PHP extension, the new solutions are provided as PHP-based library packages.

Pre-Flight Check

  • Basic familiarity with PHP coding is necessary to utilize Composer packages.
  • Command line access via SSH may be necessary to follow this tutorial.
  • Composer, Curl, funzip must be available on the server.

Step #1: What are my options now?

As mentioned previously, the new options are no longer provided as native PHP extensions, but rather they come as Composer-based PHP packages. The new options provided by MaxMind are either: GeoIP2-php or DB-Reader-php.

Both of the options provide the ability of IP geolocation with subtle differences; in a sense the GeoIP2-php package is an addition built on top of the DB-Reader-php package, it offers all the same features as DB-Reader-php with the addition of API access.

Additionally, it is important to note that only the DB-Reader option is provided without any additional costs. With the new options MaxMind now charges a subscription fee in order to access their APIs.

Generally for most use-cases the necessary features will be provided by the DB-Reader-php package, as such this article will focus on this option.

Step #2: Get started with MaxMind DB-Reader!

As mentioned in the pre-flight check, Composer will be required in order to follow these steps. If you do not have Composer setup on the server please feel free to review our Composer series here: ‘What is Composer?’.

To acquire the necessary DB-Reader package you will want to start by changing directory so that you are in the root folder of your domain (for this example we will just assume this is `public_html`), then you will run the following command:

[public_html] $ composer require maxmind-db/reader:~1.0

Running this command will download the package files into the current folder, as described in our Composer series. This will create a vendor folder if this is the first time using Composer in this site/project.

Next you will require the actual MaxMind database files which contain the geolocation data. To get these files you will execute the following commands:

[public_html] $ funzip <(curl -L http://geolite.maxmind.com/download/geoip/database/GeoLite2-Country.mmdb.gz) > ./GeoLite2-Country.mmdb
[public_html] $ funzip <(curl -L http://geolite.maxmind.com/download/geoip/database/GeoLite2-City.mmdb.gz) > ./GeoLite2-City.mmdb

With the above commands executed you should now have the necessary components to do Geolocation using the DB-Reader plugin. All that’s left is to implement it in your code.

Step #3: Looking up your first IP

In order to ensure the geolocation features are working properly you may want to do a quick test. First we’ll confirm you have all the right pieces by running the following command:

$ ls -lah

You should see a file structure similar to this:

-rw-rw-r-- 1 someuser someuser 63 Aug 11 17:03 composer.json
-rw-rw-r-- 1 someuser someuser 2.4K Aug 11 17:03 composer.lock
-rw-rw-r-- 1 someuser someuser 73M Aug 11 17:04 GeoLite2-City.mmdb
-rw-rw-r-- 1 someuser someuser 19M Aug 11 17:04 GeoLite2-Country.mmdb
drwxrwxr-x 4 someuser someuser 4.0K Aug 11 17:03 vendor/

Now you are ready to do a quick test, you can do so by creating an index.php file with the following content:

<?php
require_once 'vendor/autoload.php';

use MaxMind\Db\Reader;
$ipAddress = '8.8.8.8';
$databaseFile = './GeoLite2-City.mmdb';

$reader = new Reader($databaseFile);

print_r($reader->get($ipAddress));

$reader->close();

This index file will simply do a quick test to ensure that the database file is being loaded, an IP can be checked, and the results are being provided. The test will be looking up the geographic information related to Google’s DNS server at 8.8.8.8.

Geo-location results for Google's 8.8.8.8 DNS server via MaxMind
Geo-location results for Google’s 8.8.8.8 DNS server via MaxMind

Having followed the directions correctly you should see output similar to the image above when loading the test index page.

Installing Composer on cPanel servers

Tutorial: How to use Composer
I. Composer 101
II. Installing Composer on cPanel servers
III. Working with Composer & Examples

With a tool like Composer it is generally best to have the ability to run it as any user on the server and from any directory. This is generally referred to as being ‘globally installed’ as any user can access the tool from any location. In this guide we will detail how to install Composer globally on a cPanel based server.

Pre-Flight Check

  • These instructions are intended specifically for installing Composer on a cPanel based server running WHM prior to version 58.
  • We’ll be logging in as root to a Liquid Web Fully Managed cPanel server.
As of WHM version 58 cPanel is now including a version of Composer by default, this can be accessed by simply calling composer from command line.
For more details see: What’s New in WHM 58 & What to Look For

Step #1: Get the installer

Acquire the Composer installer script with the following commands:

$ EXPECTED_SIGNATURE=$(wget https://composer.github.io/installer.sig -O - -q)
$ php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
$ php -r "if (hash_file('SHA384', 'composer-setup.php') === '$EXPECTED_SIGNATURE') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"

The above commands will: get the installer’s signature, get the installer file, verify the download by checking the signature and finally confirm if the installer is valid, or corrupt. You should see output similar to:

Installer verified

Step #2: Run the installer

To run the installer in a manner that will install composer globally run the following command:
php ./composer-setup.php --install-dir=/usr/local/bin --filename=composer

With this command run as root composer should now be globally installed on the server.

Step #3: Verify the install

In order to verify the composer installation was successfully you will want to do the following to test. First, as root, run the following command:
# composer -V

You should see something similar to:

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

If that checks out, you will then want to verify Composer works for the users as well. To confirm composer is working for the cPanel accounts SSH into your server as a cPanel user and do the same:

$ composer -V

You should see something similar to:

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

Enabling Let’s Encrypt for AutoSSL on WHM based Servers

With the recent release of cPanel & WHM version 58 there has been the addition of an AutoSSL feature, this tool can be used to automatically provide Domain Validated SSLs for domains on your WHM & cPanel servers.

Initially this feature was released with support provided for only cPanel (powered by Comodo) based SSL certificates, with the plans to support more providers as things progressed. As of now, cPanel & WHM servers running version 58.0.17, and above, can now also use Let’s Encrypt as an SSL provider. More information on Let’s Encrypt can be found here.

Pre-Flight Check

  • These instructions are intended specifically for a managed Liquid Web server with cPanel.
  • The server should be running cPanel & WHM version 58.0.17, or higher.
  • Command line and root level access via SSH will be necessary to follow this tutorial.

Step #1: Enable Let’s Encrypt Auto SSL provider!

In order to install the Let’s Encrypt AutoSSL provider plugin you will simply log in to the server as the root user via SSH and execute the following command:

# /scripts/install_lets_encrypt_autossl_provider

Running this will add and install the necessary RPM files in order to support Let’s Encrypt as an AutoSSL provider. The command should yield results similar to the following:

Installed the cpanel-letsencrypt RPM! AutoSSL can now use Let’s Encrypt.

Step #2: Verify your work

To double check that this has been successful you can simply pull up WHM and load the ‘Manage AutoSSL’ page. Upon loading this page you should see a list similar to the following screenshot.

WHM AutoSSL w/ Let's Encrypt
If your server’s ‘Manage AutoSSL’ page shows the same options as above you have successfully enabled Let’s Encrypt for AutoSSL.

One thing to keep in mind is that there are some domain and subdomain limits that are enforced by Let’s Encrypt. More details on that can be found in cPanel documentation here: Manage AutoSSL – Domain and rate limits.

How to Disable MySQL Strict Mode

MySQL’s, and MariaDB’s, strict mode controls how invalid or missing values in data changing queries are handled; this includes INSERT, UPDATE, and CREATE TABLE statements. With MySQL strict mode enabled, which is the default state, invalid or missing data may cause warnings or errors when attempting to process the query.

When strict mode is disabled the same query would have its invalid, or missing, values adjusted and would produce a simple warning. This may seem like the preferred result, however with strict mode disabled certain actions may cause unexpected results; for instance, when the value being inserted exceeds the maximum character limit it will be truncated to fit the limit.

There are various reasons why MySQL’s strict mode may need to be disabled, however the most common is when a server is running WHMCS — this is a requirement of that tool.

Pre-Flight Check

  • These instructions are intended specifically for disabling MySQL strict mode on a managed Liquid Web server with cPanel.
  • The server should be running either MySQL 5.6/5.7 or MariaDB 10.x
  • Command line and root level access via SSH will be necessary to follow this tutorial.

Step #1: Make Backups, Always!

Whenever modifying files on a server it’s always best practice to take some form of a backup beforehand. This ensures you have a way to revert changes if something goes awry; it’s also beneficial because it helps track when and what changes were made.

While logged into SSH with the root user, do the following:

cp -a /usr/my.cnf{,.strict.bak}
cp -a /etc/my.cnf{,.strict.bak}

The above command uses ‘BASH brace expansion’ in order to make a backup copy of the file in its original directory.

Step #2: Disable MySQL Strict Mode

Depending on the server and the current configurations you may need to edit one, or both, of the following files on the server. Generally, the relevant configuration lines are only in one of them, however, it could be in either one without causing issues; so generally it’s best to check both.

To edit the files, you will open the file with your favorite command line editor. In this example, we use ‘vim’.

vim /usr/my.cnf
vim /etc/my.cnf

In vim, you can press “a” or “i” to enter text insertion mode; pressing the escape key (Esc) on your keyboard returns you to command mode. For a refresher on editing files with vim, see our New User Tutorial: Overview of the Vim Text Editor.

Within each file above you will be looking for a line with the following content:

sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES

If you find a line similar to the above that is setting the `sql_mode` variable then you will need to replace it with the following line to disable MySQL strict mode.

sql_mode=""

Once this adjustment has been made, or you’ve confirmed the file does not need to be adjusted you will then save and close the file.

Step #3: Restart the MySQL Service

Finally, to make these changes effective you will need to restart the MySQL service as it will only read the configuration files when it initially loads up. In order to force MySQL to use the new configuration files you will do the following:

For CentOS 7 servers:
systemctl restart mysql

For CentOS 6 and prior:
/etc/init.d/mysql restart

After issuing this command on the server the MySQL service will be restarted and will load the changes made. If all the directions were followed and completed, then MySQL strict mode should now be disabled.

To verify that the process was completed properly you can run the following:

mysql -e "SELECT @@sql_mode;"

The output may look similar to the following:

+--------------------------------------------+
| @@sql_mode
+--------------------------------------------+
| NO_AUTO_CREATE_USER
+--------------------------------------------+

If you have any questions or are not comfortable making these changes yourself, please feel free to contact Heroic Support®.

Exploring the CloudFlare Dashboard

Getting Started With CloudFlare™

Pre-Flight Check

Accessing the CloudFlare Dashboard

After logging into your Manage interface, click on Domains in the left menu and select the CloudFlare tab.

Each domain you’ve added to your CloudFlare account is listed here.

CloudFlare Dashboard Overview

Menu Bar

The menu bar at the top allows you to add new sites to CloudFlare by clicking on the blue Add Website button, or quickly narrow the number of domains displayed through the Search field. The Website column header also can be sorted alphabetically by clicking on its icon.

Domains List

  • The Status column shows at a glance whether CloudFlare is active on any listed domain, and can be clicked to quickly expand the domain’s dashboard.
  • A Quick Settings Menu, labeled , is located to the far right of the domain name. Clicking on it will allow you to pause CloudFlare, purge cached files, and perform other tasks without having to expand the domain’s dashboard.

    More button

  • To expand a domain’s full CloudFlare dashboard, you can either select “CloudFlare Dashboard” from the Quick Settings Menu () or click the [+] button to the left of the domain name.

CloudFlare Dashboard

Primary CloudFlare Dashboard

Once expanded, a domain’s CloudFlare Dashboard allows you to manage CloudFlare settings for the domain:

  • The Enable Development Mode link in the top-right corner will temporarily pause edge caching and minification so that changes made on your site can be seen more quickly.
  • The Pause CloudFlare link temporarily disables all CloudFlare services for the site.
  • Site Statistics are available in the top left corner, allowing you to see the number of cached and uncached requests processed through CloudFlare, and the amount of data included in those requests.
  • Clicking on the Caching Level setting allows you to choose between three levels:
    • No Query String, which only serves files from the cache when there is no query string (example.com/photo1.jpg).
    • Ignore Query String, which delivers the same resource to everyone, regardless of the query string (example.com/photo1.jpg?w=200&h=200).
    • Standard, which delivers a different resource each time the query string changes. This is the level recommended by CloudFlare.
  • The Purge Cached Files button clears any cached content from CloudFlare.
  • Clicking on the Auto Minify setting allows you to choose whether to removes unnecessary characters from your source code (like whitespace, comments, etc.) to reduce file sizes and lower the amount of data, which helps to reduce page load times. You can enable Auto Minify for CSS, javascript, and HTML files.
  • SSL Setup, available on paid plans, allows you to configure SSL settings on the domain.
  • The Security Level setting allows you to choose between four levels of protection:
    • Essentially Off: Provides a challenge to only the most grievous offenders.
    • Low: Challenges only the most threatening visitors.
    • Medium: Challenges both moderate threat visitors and the most threatening visitors.
    • High: Challenges all visitors that have exhibited threatening behavior within the last 14 days.
    • I’m Under Attack! Should only be used if your website is under a DDoS attack. Visitors will receive an interstitial page while CloudFlare analyzes the traffic and behavior to make sure they are a legitimate human visitor trying to access your website. This setting can be enabled quickly by clicking on the I’m Under Attack! button directly underneath the Security Level setting.
  • Clicking on your current Plan allows you to change the level of your CloudFlare service, from free to paid and basic to advanced. Premium features, including the CloudFlare firewall, are managed via the interface at CloudFlare’s website.
  • The DNS Settings link allows you to view and modify settings for the domain.

DNS Settings

Clicking on the DNS Settings link in a domain’s CloudFlare Dashboard brings up the current settings for the domain.

CNS settings in the CloudFlare dashboard

The Report DNS Changes button will allow you to add new subdomains to the domain, such as “blog.yourdomainname.com” or “shop.yourdomainname.com”. The DNS record values needed to configure your domain name for CloudFlare also are listed on this page for your reference.