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/

Digging Into Exim Mail Logs With Exigrep

Perhaps a particular domain on your cPanel server has stopped receiving e-mail. Or, an address on your domain is able to receive e-mail, except from your supplier. Maybe you can receive e-mail just fine, but are receiving error message bounce-backs from Yahoo. How are you going to get the fine-grained information you need to figure out just what is going on?

The answers you seek can be found in exim’s logs.

Continue reading “Digging Into Exim Mail Logs With Exigrep”

Featured Freeware: MTR

Featured Freeware highlights some of the Liquid Web staff’s favorite free software. This week we are covering a treasured favorite, MTR.

Note: This post assumes you have a working knowledge of traceroute.

MTR (originally Matt’s Traceroute, now My Traceroute) functions like traceroute insofar as it displays the network hops from your local machine (or server, depending on where you run the command) to the target IP address or hostname.

But MTR differs from traceroute by constantly observing and displaying the network hops and related statistics instead of displaying a single set of results. Put simply, if you traceroute to google.com you will get a report for a single connection from your computer to Google’s servers. If you MTR to google.com you will see a continuously updated display of each hop and its performance over time until you tell it to stop. Response times can be evaluated just like traceroute or ping results: Higher numbers are bad, lower numbers are good. If a particular hop is showing much higher response times than the others, even without packet loss, you can see that it might be having a problem.

MTR can be installed on almost any Linux machine by using a local package manager such as yum or apt. Windows and Mac OS X users can install MTR using the links in the Additional Resources section at the bottom of this post.

Basic MTR Usage

Example MTR command from a Liquid Web server to google.com:

[root@host]# mtr google.com

My traceroute [v0.85]
host.example.com (0.0.0.0) Wed Mar 23 14:58:34 2016
Keys: Help Display mode Restart statistics Order of fields quit
  Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 111.111.111.111 0.0% 461 1.1 1.1 1.0 14.9 0.7
2. router.example.com 0.0% 461 1.1 2.0 1.0 156.2 0.6
3. router2.example.com 0.0% 461 1.1 10.7 0.9 197.3 32.2
4. border.example.com 0.0% 461 29.2 32.2 7.1 271.5 38.6
5. eqix-ch-100g.google.com 0.0% 460 9.0 7.6 7.1 28.3 0.4
6. 209.85.143.152 0.0% 460 7.3 8.2 7.3 30.7 2.3
7. 216.239.51.225 0.0% 460 7.3 7.6 7.3 25.6 1.5
8. ord31s21-in-f14.1e100.net 0.0% 460 7.3 7.6 7.2 20.5 1.5
Note: This represents a static screen from an MTR result, but when run in this manner MTR will continuously update these stats until you cancel it with CTRL+C or q. Alternatively, if you really want a static report instead of a realtime analysis, you can use mtr with the –report flag to generate a summary report: “mtr –report google.com”

Breaking the results down from left to right:

  • Host: The name or IP address of the network hop.
  • Loss%: The percentage of packets that are being lost during the trace. In most cases, this is the first result you want to watch.
  • Snt: The number of packets sent to the hop.
  • Last: The response time of the last packet sent to the hop.
  • Avg: The average response time during the entire span of the test.
  • Best: The best response time during the entire span of the test.
  • Wrst: The worst response time during the entire span of the test.
  • StDev: Is the Standard Deviation of latencies to the host, and can help you better evaluate the average latency measurement. A high StDev indicates an inconsistency in the latency measurements on that hop, such as when a wide gap is recorded between the best and worst latencies on that hop.

Evaluating MTR Results

Almost immediately you will want to pay attention to the Loss% column in MTR’s display. As the tests progress, the percentage will get more accurate at telling you where there may be a problem. Generally speaking, you will see packet loss at every hop past the point of trouble if a network issue is in play, and the point in the route at which the packet loss occurs will narrow down the nature of the specific issue.

  • Depending on your home or office network setup, the first hops likely will be your local firewall and/or router or wireless access point. If the packet loss is occurring in one of these first couple of hops, it could be an indicator of trouble within your local network. You may want to try temporarily disabling the firewall or antivirus suite on your computer and checking the route (and the site) again.
  • The next hop likely will be your Internet Service Provider’s network, and you may recognize your ISP’s name in the host column. If the packet loss is here, then you have a strong indicator that your ISP is having problems on their end. Do other websites load properly, or is everything slow?
  • Packet loss in the middle of the route can be an indication of a problem with a major Internet route. In this case, you can notify your ISP and they can potentially contact their upstream provider to get the matter resolved. It is important to note, however, that some packet loss at this stage is normal: You can almost always expect to see minor packet loss when the server is physically located in a different geographic region or across a large body of water, such as an ocean. The amount of packet loss typically will increase with distance. If the route continues past this point and ultimately connects to the server, there may be not be a network issue. To confirm, you can test the route to the site from a server in the same geographic region as your server using a free tool such as Traceroute Tools Online or through a free VPN service. If there are no issues, you may want to consider using a Content Delivery Network to ensure that the bulk of your site’s resources are served from the locations closest to your site visitors.
  • Finally, the route will pass through your hosting provider’s router and firewall to reach their internal network, and then through your server’s firewall (which may be a cloud firewall, a hardware firewall, a software firewall, or a combination of the three). If you’re a Liquid Web customer, follow the instructions in our article at Unblocking an IP Address in the Firewall or use our semi-automated IP address unblock tool in Manage to ensure that your IP address is not being blocked in your server’s firewall.

Additional Resources

 

CSF: Config Server Firewall Installation

An alternative firewall to APF is the Config Server Firewall, or CSF.

CSF is generally considered a more advanced firewall as there are more configuration options compared to other firewalls, while still being simple enough to install and configure that even novice administrators can use it. This article will give you a simple overview about how to install and configure CSF and its security plugin LFD (Login Failure Daemon).

Continue reading “CSF: Config Server Firewall Installation”

DNS Hosts File

One of the most powerful tools available to anyone working on their site during a migration is their computer’s “hosts” file. The hosts file is used to map domain names to IP addresses, and can be used as an alternative to DNS. It also allows you to specify the IP address to which a website resolves on your computer, regardless of what may be published in the site’s DNS zone file.

Why Edit Your Hosts File?

Modifying your hosts file lets you view and test a site on one server while the rest of the world continues to see the site on another. That makes it an essential tool when migrating your website. With this method, you’re able to ensure that:

  • everything on the site works as expected on the new server before you update the DNS records
  • your site’s visitors won’t be affected by any potential issues related to different server environments before you’ve had a chance to resolve them

It’s actually a very simple process. Let’s take a look at an example hosts file:

127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
123.123.123.123 liquidweb.com www.liquidweb.com

In this case, the first three entries are defaults used to configure the local network interface. You may have more or fewer such local entries in your hosts file; you don’t need to worry about them other than to note their presence. Any custom entries will go at the bottom of the file, and in this case you can see that I have added one custom entry to the end of the file already:

123.123.123.123 liquidweb.com www.liquidweb.com

My custom entry specifies that any request made from my computer (via web browser or SSH, email, or FTP client) for liquidweb.com or www.liquidweb.com will be directed to the IP address I’ve specified: 123.123.123.123. You will add your own custom entry to the end of your file using the same format.

The line for your custom entry will consist of three elements:

  • the IP address of the server to which you want the domain name to resolve on your computer
  • a tab or space
  • the domain name(s) meant to resolve to the specified IP address

If you’re migrating to a Liquid Web server, your migration technician will supply you with the line to add; you will just copy and paste it into your hosts file. If your migration involves multiple IP addresses, you will have one line for each IP address, regardless of how many domain names share it.

Note: Do not remove or modify any existing local entries in your hosts file. You will only be adding a new line or lines at the bottom of the file for testing, and then removing the lines you’ve added once testing is complete.

Step #1: Edit Your Hosts File

The location of your computer’s hosts file depends on your operating system. Because it is a protected file which must be edited with administrative privileges, the procedure for editing also varies by operating system.

Click a link below to skip ahead to the specific instructions for your operating system. If you experience difficulties editing your hosts file or are not seeing the sites on the new server after you’ve followed the steps below, check out the Bonus: If All Else Fails section at the end of this article.

Windows

In Windows, the hosts file is located at: C:\Windows\System32\drivers\etc. You will need to edit the file with administrative privileges.

  1. First, open an elevated command prompt:
    • In Windows 8 and higher, use the keyboard shortcut Windows key + x to access the Power Users menu, then select Command Prompt (Admin).
    • In previous Windows versions:
      1. Type “command” into the search field at the bottom of the Start menu.
      2. Right-click on the cmd.exe icon.
      3. Select Run as Administrator.
  2. Enter the following command:

    notepad C:\Windows\System32\drivers\etc\hosts

    Note: There is no keyboard shortcut to paste text into the command window, but you still can copy and paste the command above by right-clicking anywhere in the command window and choosing Paste from the menu. If you prefer, you also can locate Notepad, right-click its icon to select “Run as Administrator”, then open your hosts file (at C:\Windows\System32\drivers\etc) in Notepad. With this method, you will need to change “Text Documents (*.txt)” in Notepad’s file browser to “All files” to see the hosts file, and you still will need to open a command prompt to flush your DNS cache as described in Step 4.
  3. Add the appropriate line at the end of your hosts file, then save and close the file.
  4. Finally, you will want to flush your DNS cache so that you don’t have to log out and then log back in for the changes to take effect:
    • Open an elevated command prompt as above, and enter the following command:

      ipconfig /flushdns

Mac OS X

On Mac OS X, your hosts file is located at: /private/etc/hosts. You will need administrative privileges to edit the file, which you can do manually or by appending the new entry directly from the command line.

  1. First, launch Terminal from Spotlight search (Command+Space, or click on the magnifying glass icon in your menu bar) or the Utilities folder in Applications on many versions of Mac OS X.
    • To edit the file manually:
      1. Enter the following command in Terminal:

        sudo nano /private/etc/hosts

      2. Enter your password when prompted and press Enter to authenticate and open the file.
      3. Now add the appropriate line and save the file:
        1. Use your arrow keys to navigate to the bottom of the file.
        2. Type in (or paste) the IP address and website name you intend to redirect.
        3. Press Control+O to save (Write Out) the file.
        4. Press Enter to overwrite the existing file.
        5. Finally, press Control+X to exit.
    • If you prefer to simply append the entry to the existing file, you can do so with one command, substituting your server’s IP address and domain name for the ones in this example:

      echo "1.1.1.1 test.com www.test.com" | sudo tee -a /private/etc/hosts >/dev/null

      and enter your password when prompted.

  2. While you still are in Terminal, you should flush the DNS cache so you don’t have to log out and then log back in for the changes to take effect. For the current version of Mac OS X, you can do that with this command:

    dscacheutil -flushcache; sudo killall -HUP mDNSResponder

    Note: On the first few releases of Mac OS X Yosemite (versions 10.10 through 10.10.3), the command needed to flush the cache is sudo discoveryutil mdnsflushcache; sudo discoveryutil udnsflushcaches. For version-specific instructions in older versions of Mac OS X, see How To Flush Your Local DNS cache.

Linux

On Linux, you can find the hosts file at: /etc/hosts. Depending on your distribution, you likely will need administrative privileges to edit the file.

  1. You can edit the file manually with vi, vim, or nano, or append the new entry directly from the command line.
    • To use vim, open a terminal and enter the command:

      sudo vim /etc/hosts

      followed by return, and enter your password to authenticate if prompted. After adding the new entry at the end of the file, type :wq to save and close the file.

      Note: In vim, you can press “i” or “a” 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 New User Tutorial: Overview of the Vim Text Editor.
    • If you prefer to simply append the entry to the existing file, you can do so with one command, substituting your server’s IP address and domain name for the ones in this example:

      echo "1.1.1.1 test.com www.test.com" | sudo tee -a /etc/hosts >/dev/null

      and enter your password.

  2. While you’re still in a terminal, you will want to flush your DNS cache. That command can vary widely depending on your specific distribution and version:
    • Many Ubuntu and Debian-derived distributions use: sudo service dns-clean restart.
    • Other Linux distributions using NSCD (Name Service Caching Daemon) may need to use: sudo service nscd restart, sudo systemctl restart nscd.service, or nscd -I hosts.

Step #2: View the Site on its New Server

At this point, your website should resolve on your computer from the IP address specified in your hosts file instead of the IP address specified in the site’s DNS record. If you’re not seeing the site on the new server, it could be because your browser is serving a cached version of the page. In that case, you can:

  • Manually clear your browser’s cache (typically Control+Shift+Delete or Command+Shift+Delete). For browser-specific instructions, see Clearing Your Browser Cache.
  • Use a private browsing window to view the site
  • View the site in another browser
  • Log out of your computer and then log back in

If you’re uncertain whether you are seeing the new site or the old, you can confirm the IP address of the site you’re viewing using a browser add-on. There is no shortage of such extensions, most of which will display a site’s IP address right in the browser’s menu bar. For your convenience, a few are listed below:

Note: Liquid Web has no association or affiliation with any of these browser extensions or their developers and cannot guarantee compatibility or performance. They’re simply among the most commonly used tools for this purpose, and their inclusion in this list does not constitute an endorsement. Please be sure to read the notes and reviews on the individual plugin pages to determine which you prefer to use.

Step #3: Test the Site on its New Server

Now that you can see the site on its new server, you must thoroughly test it to determine whether everything works as expected. It is common to see some issues and error messages when testing a migrated site. There’s no cause for alarm — typically only minor adjustments to the server configuration, such as enabling an Apache module or adjusting a php directive, are needed to resolve them.

To ensure that all your site’s software, scripts, and plugins work correctly on the new server, be sure to:

  • Visit each link on your home page and ensure that it loads without error
  • If your site runs a CMS such as WordPress or Magento, log into the administrative area
  • If your site has a shopping cart, add an item and test your checkout process
  • Test any forms on the site
  • Create a post
  • Comment on a post
  • Upload a file

Should you notice any issues when performing the above tests:

  • Note the full URL of the page
  • Note the specific error message or problem
  • Provide that information to the person performing your migration. If Liquid Web is handling the migration, simply paste that information into your migration ticket to ensure that the proper adjustments are made as quickly as possible.

Bonus: If All Else Fails

If, for whatever reason, you’ve been unable to successfully modify your hosts file to point your website to a new IP address, there remains one nearly foolproof option: View the site through an external service.

Hosts.CX is a free web-based service that allows you to preview and test your website on a different IP address. The site currently does not charge for its service, nor does it require you to register or provide any personal information.

When visiting https://hosts.cx, you will be prompted to enter your Server address and Website name. Note that you can only use one domain name, so choose the version you’re using on your site (e.g., www.yourdomainname.com or yourdomainname.com, but not both). Once you click the Get My Testing URL link, you’ll be presented with a shortened URL (in the format: abcde.hosts.cx) which you can click to view and test your site on the new server.

This method can be quite helpful for viewing your site on a new server, but it is not a perfect substitute for editing your hosts file. For instance, your pages will not load over a secure connection (https://). To prevent any possible security risk, you must not transmit sensitive data such as login information or passwords when testing via an external service. Additionally, certain site features, such as some CAPTCHAs, may not function as expected when requests are routed through a web service. Typically it does not indicate a problem with your site, simply a limitation (or security feature) of the code or plugin itself.

Note: Hosts.CX is a private company and has no affiliation with Liquid Web. While their service is free and publicly accessible, there is no guarantee that it will remain so, and they may change their policies at any time.