Part 3: How I Built a cPanel Hosting Environment on Amazon AWS

In Part 2 of this series, we discussed selecting and launching a new Amazon Machine Instance (AMI), creating and configuring that instance to serve as a dedicated name server, and worked through configuring a DNS Cluster for use within your subnet.

Today, we will launch and configure a standard Web Server instance using cPanel 11.39 or newer. I will discuss how to join the new instance to our existing DNS Cluster and how to ensure that 1:1 NAT is configured and working properly.


Below is a quick overview of the architecture implemented as well as instance types used for provisioning instances. While I can not link directly to specific AMIs (Amazon Machine Images), selecting your desired operating system and getting cPanel/WHM installed is a straightforward procedure.


Assumptions

  • First, I will discuss the reasons for configuring instances in certain ways as they relate to being on AWS, but this is not a lesson in web server management. Use of best practices falls to you.
  • Second, this model makes no assumption of complete configuration or security. Again, I will just be touching on the subtleties of using the AWS eco-system.

Some instructions below are borrowed from Amazon’s AWS User Guide.


AWS Diagram

A Representation of the Basic Network Architecture


This Lesson Includes

  • Creating and launching a new EC2 Instance (Web Server) within VPC
  • Applying a Security Group to an Instance
  • Configuring cPanel/WHM for a NAT Architecture on AWS
  • Joining a DNS Cluster

Create and Launching the Web Server Instance

Amazon EC2 instances are the fundamental building blocks for your computing needs in AWS. You can think of instances as virtual servers that can run applications and services. Instances are created from an Amazon Machine Image (AMI) and choosing an appropriate instance type. An AMI is a template that contains a software configuration, including an operating system, which defines your operating environment. You can select an AMI provided by AWS, our user community, or on the AWS Marketplace. You can also create and optionally share your own AMIs.  A single AMI can be used to launch one or thousands of instances.

There are thousands of freely (and commercially) available AMIs available to choose from. You can also opt for building your own from the ground up. In my case, I chose a vanilla CentOS 6 AMI and built my name servers from there.

An important aspect to understand about the AWS eco-system is a term called “Regions“. Regions are just that, geographical locations of the datacenters that house your services in AWS. Amazon offers numerous regions all at different price points. I generally build out an infrastructure in a single region and then duplicate the infrastructure to a separate region. I then can use AWS ELB (Elastic Load Balancing) to direct traffic to different regions or for failover. In this tutorial I will be operating in the N. Virginia (East 1-A) region. More on regions can be found here.

While I will walk you through launching your instance, I will skip the installation step for cPanel Services merely for brevity. Let’s begin.

Choose an AMI

  1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/
  2. Click “Launch Instance” in the top menu.
  3. Click the “Classic Wizard” radio and click “Continue“.
  4. Choose one of the four tabs to search for your desired AMI. Keep in mind, AMIs are region specific so when launching a new AMI ensure it is in the same region as your VPC.

Instance Details

AWS Diagram

  1. Select the “Instance Type: T1 Micro“. A T1 Micro Instance is sufficient for testing a basic web server. (More on Instance Types).
  2. Select the “Launch into: EC2-VPC” radio button.
  3. Accept the default subnet since we only have one (unless more were configured, select accordingly).
  4. Click “Continue“.

AWS Diagram

  1. Kernel ID and RAM Disk ID can both be kept as “Use Default“.
  2. While an additional charge will be incurred, it may be advantageous for you to enable CloudWatch Monitoring. I choose to enable it.
  3. Important: Make sure you enable Termination Protection by checking the box labeled “Prevent against accidental termination.” This helps prevent you from deleting an instance or volume store without you first disabling this protection.
  4. Also Important: Ensure “Shutdown Behavior” is set to “Stop” and not “Terminate”. When an instance is terminated, it is deleted from your VPC/EC2 account and is not recoverable.
  5. Now we want to set a Static Private IP for our instance. VPC comes built in with a DHCP server but we really don’t want our instance IPs to be changing. Set an appropriate IP address for your instance. I chose “10.0.0.12” based on my subnet range. (Remember our Name Servers were “10.0.0.10” & “10.0.0.11” respectively)
  6. Click “Continue“.

AWS Diagram

Understanding AWS storage can be somewhat overwhelming but it is really quite simple. AWS uses two primary storage types. “EBS” and “Instance Store“. In all practical instances, you will want to use EBS. The differences are simple really.

EBS Storage is physically separate storage that is backed by Amazon S3 and is independent of your instance. EBS volumes can be attached/detached to Instances much like plugging in a thumb drive. You can also take snapshots of EBS volumes making backups/recovery simple. EBS storage is a safer option because if a region goes offline or fails completely, the likely hood of recovery of your EBS backed volumes are significantly greater than Instance Stores because of the physical location separation. When you terminate (delete) an instance, unless you say otherwise, the EBS volume associated with that instance will still be available. EBS volumes can also be resized and scaled. More on this later.

Instance Store is a storage volume type that is tied directly to an instance. Instance stores cannot be managed and cannot have snapshots taken. Instance stores are also not persistent, meaning, if you boot an instance, make changes to the volume (create/delete files, etc) and then stop the instance, the next time you boot the instance, any changes made will not be available. The instance essentially resets to a fresh state every time you boot. Instance stores are useful in an application specific environment where a particular instance has one job to do.

Important: When selecting an AMI, ensure that the Storage Type indicates “EBS-Backed if that is the storage type you want to select.

  1. Accept the defaults of your selected AMI and click “Continue“.

AWS Diagram

Naming convention is entirely up to you, however, I recommend using a standard naming schema throughout your VPC. This makes for easier maintenance and management. I generally set the “Name” key to the hostname of the instance, and create an additional key “Type” and set it to the function of the instance, in this case VS (Virtual/Web Server).

Click “Continue“.

Create KeyPair

AWS Diagram

Public/private key pairs allow you to securely connect to your instance after it launches. For Windows Server instances, a Key Pair is required to set and deliver a secure encrypted password. For Linux server instances, a key pair allows you to SSH into your instance.

Select the previous key pair we created in Part 2 titled “vpc_keypair“.

Click “Continue“.

Configure Firewall

AWS Diagram

  1. Select the “VS_SG” Security Group that we created in Part 1.
  2. Click “Continue“.

Review

AWS Diagram

  1. Review and verify the Instance details.
  2. Click “Launch“.

Allocating and Associate an Elastic IP

Elastic IP addresses are static IP addresses designed for dynamic cloud computing. An Elastic IP address is associated with your account, not a particular instance (but can be associated to an instance), and you control that address until you choose to explicitly release it. Unlike traditional static IP addresses, however, Elastic IP addresses allow you to mask instance or availability zone failures by programmatically remapping your public IP addresses to any instance associated with your account. Rather than waiting on a data technician to reconfigure or replace your host, or waiting for DNS to propagate to all of your customers, Amazon EC2 enables you to engineer around problems with your instance or software by programmatically remapping your Elastic IP address to a replacement instance.

Allocating

AWS Diagram

  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/
  2. Click “Elastic IPs in the left hand navigation menu.
  3. Click the “Allocate New Address” button in the header menu.
  4. Set “EIP Used In:” to “VPC“. (Elastic IPs allocated outside of a VPC to EC2 cannot see VPC Instances).
  5. Click “Yes Allocate“.

Associating

AWS Diagram

  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/
  2. Click “Elastic IPs” in the left hand navigation menu.
  3. Locate your newly allocated IP Address in the list and click the selection box (or right click) associated with the address.
  4. With the address selected, click the “Associate Address” button in the header menu.
  5. Select your new Instance from the “Instance” dropdown and the correct Private IP should be selected by default.
  6. ImportantEnsure that you enable “Allow Reassociation“. This tells the VPC to reassign this EIP to this instance in the event of a reboot or shutdown. If you do not enable this option, you will have to manually re-associate the EIP with the Instance.
  7. Click “Yes, Associate“.

Configuring cPanel/WHM

At this point, you have a brand new Instance with an Elastic IP associated to it. The first thing you want to do is login to your instance via SSH using your newly acquired KeyPair. As I said previously, I won’t be going over the steps for installing cPanel, although they are straightforward.

Pre-configured AMIs will always have a root password set which you will inherently have to change to be able to login to cPanel. This is a quick, yet necessary step to complete before continuing.

SSH into your instance as root and run:

passwd

Modify your password and continue.

Initial Setup

  1. Assuming you have installed cPanel/WHM, In a web browser, navigate to:
    https://<elastic-ip>:2087

    Where <elastic-ip> is replaced by the Elastic IP Associated to your new instance.

  2. You will be prompted for login credentials. Username will be ‘root’ and the password will be your new modified password.
  3. ‘Read’ and Agree to the Terms and Conditions and continue to Step 2.
  4. Enter your Contact Information.
  5. Enter the hostname of this instance. In my case, I chose “vs1.example.com“.
  6. Enter your primary and secondary resolvers. I choose to use Google’s Resolvers located at “8.8.8.8” and 8.8.4.4” respectively.
  7. Ensure Main Network Device is set appropriately. It will most often be eth0.
  8. Save and Go To Step 3.

AWS Diagram

Ensuring Proper NAT Detection

Officially, cPanel’s NAT feature should only be used on fresh installs of cPanel/WHM. The automatic detection of the NAT architecture will not occur properly on an upgraded system, however, we can force 11.39+ to manually check for a NAT instance. I will first go over the expected results of a “fresh-install” and then I will review how you can enable NAT on an updated instance. Note: To the best of my knowledge, cPanel prefers you do a fresh install when using NAT so please proceed at your own risk.

  1. In Step 3, we won’t be adding an additional IP. You will see your current IP address in the “Current IP Addresses” block. In my experience, I’ve seen the internal/local IP for the instance here, you may see the external IP address instead. We will verify in the next few steps.
  2. Click “Go to Step 4

You should now be directed to the DNS configuration. Since we are implementing a clustering environment, we will not need to run local DNS services.

  1. Select “Disabled” in the “Nameserver Configuration” block.
  2. Configure your Primary and Secondary name servers with the hostnames of the two instances we configured in Part 2. In my case, “ns1.example.com” and ns2.example.com“.
  3. Keep all other values at their default settings.
  4. Click “Save & Go to Step 5 .

Mail server configuration is completely up to you and should be configured on your own environment’s needs.

  1. Configure your Mail settings.
  2. Click “Save & Go to Step 6 .

Depending on the type of instance shared/dedicated you may wish to enable/disable file system quotas.

  1. Configure your File System Quota settings.
  2. Click “Finish Setup Wizard.

Verifying NAT

We will now go through a few steps in verifying your cPanel is properly detecting your NAT and properly mapping it to the external/public IP address.

  1. In the left hand menu, under Server Configuration, click “Basic cPanel & WHM Setup“.
  2. In the Basic Config section, ensure the field described as “The IP address that will be used for setting up shared IP virtual hosts” is displaying your external/public IP address. If something other than your external/public IP is displayed, read below.

AWS Diagram

I’ve encountered a few scenarios where either a random local IP (mainly inherited from a cloned instance) will be displayed in this IP field. If the IP shown IS NOT your external/public IP and IS NOT the correct internal/local IP:

  1. Enter the correct Internal/Local IP.
  2. Click “Save Changes”.

Now that our Main/Shared IP is set correctly, let’s verify the current IP mapping.

  1. In the left hand menu, under IP Functions, click “Show or Delete Current IP Addresses“.
  2. If cPanel has properly detected the NAT, you will see a “NAT Mode” heading with a box below displaying the Local IP and the Public IP that it is being mapped to.  Click the “Validate” button to ensure that the mapping is functioning properly.

AWS Diagram

Forcing NAT Detection

In some cases, NAT Mode will not be automatically enabled or detected. If the steps above produced Local IPs instead of Public IPs, you will probably need to force cPanel to detect your NAT. This can be done in a few simple steps. As I said before, please follow these steps at your own risk as cPanel does not officially support an installation that has been “upgraded” to NAT.

SSH into your instance as root and run:

/scripts/build_cpnat

If your NAT was detected you should receive an output similar to the one below.

AWS Diagram

Assuming NAT was manually forced and detected properly, repeat the steps in “Verify NAT” above to ensure cPanel has detected and mapped your IP properly.

DNS Clustering

DNS cluster is a group of nameservers that share records. A DNS cluster allows you to physically separate your nameservers so that if a web server loses its connection, you still have DNS functionality. This will allow visitors to reach websites on your server more quickly after the web server comes back online.

Since we have already enabled our Clustering Servers (ns1.example.com & ns2.example.com) I will go through the steps required to join our server to the cluster.

  1. In a web browser, navigate to:
    https://<your-nameserver>:2087

    Where <your-nameserver> is replaced by the hostname to your first nameserver instance.

  2. You will be prompted for login credentials. Username will be ‘root’ and the password will be the password you set.
  3. In the left hand menu, under Cluster/Remote Access, click “Setup Remote Access Key“.
  4. You will be given a long string designated as “Access key for user ‘root’.” Copy this key to your clipboard or a temporary text document. Note: An access key is essentially login certificate that gives anyone with access to the key complete control over cPanel/WHM. Never share this key with anyone and never save it anywhere. The key can always be accessed from within WHM.
  5. Next, in a new tab, navigate to
    https://<your-webserver>:2087

    Where <your-webserver> is new instance created to act as the web server. In my case “vs1.example.com“.

  6. You will be prompted for login credentials. Username will be ‘root’ and the password will be the password you set.
  7. In the left hand menu, under Cluster/Remote Access, click Configure Cluster“.
  8. In the “Remote cPanel & WHM DNS host:” field, enter the hostname of the nameserver you just copied the access key from. In my case, “ns1.example.com“.
  9. In the “Remote server username:” field, enter “root“.
  10. In the “Remote server access hash:” field, paste in the Access Key you previously copied from the nameserver.
  11. Ensure that “Setup Reverse Trust Relationship” is checked.
  12. Debug mode can remain disabled.
  13. Set “DNS Role:” to “Synchronize Changes“. This setting is specific to the server type, but generally will be set to Synchronize Changes.
  14. Click “Submit“.

AWS Diagram

The server will now make an attempt to establish the Trust Relationship with the cluster. If the connection succeeds you will see a verification message “The Trust Relationship has been established… and “The new role for <ip> is sync“.

Click the “Return to Cluster Status” link.

Verify DNS Clustering

On the Configure Cluster page of your virtual server, in my case “vs1.example.com“, ensure that you see the established relationship with your nameserver.

AWS Diagram

Refresh the Configure Cluster page of your nameserver, in my case “ns1.example.com“, ensure that you see the established relationship with your virtual server. On the nameserver side, you will see a DNS role of your virtual server set as “Standalone”, this is intentional and expected.

AWS Diagram

Note: In some instances, I’ve experienced situations where the virtual server will indicate that it had succesfully established a reverse trust relationship with the nameserver, but upon verifying the cluster on the nameserver, I either did not even see the virtual server displayed in the cluster or I received authentication errors. The solution is to follow the steps above for creating the Access Key and adding a server to the cluster but do it on the nameserver as well. You shouldn’t run into this issue but if you do, post in the comments and I am happy to help sort it out.

Additional Note: Depending on how your firewall rules are setup, DNS clustering could fail if the proper ports are not opened.  To ensure you are opening the proper ports, have a look at Getting the Most Out of Your System’s Firewall, which details cPanel’s commonly used ports.

Conclusion

At this point you have a single virtual server, vs1.example.com,  configured for NAT and with DNS Clustering enabled. We have joined the instance to one of the nameservers in our DNS Cluster.

You do, however, need to repeat the DNS Clustering steps for the secondary nameserver, presumably ns2.example.com.

You can continue configuring your server how you would normally for your own environment. cPanel/WHMs NAT implementation is pretty transparent to the user. You rarely need to take into consideration the fact that you are behind a NAT architecture. cPanel simply translates your Local IP to your Public IP wherever it is required. Seamless. The NAT Team at cPanel worked very hard to ensure that everything just works.

While this is a very basic setup, all of the possibilities of this infrastructure within AWS are too numerous and out of scope for this tutorial. I am more than happy to field questions and comments below if you have a more challenging project.

 

This entry was posted in Tips & Tricks and tagged , , , , , , . Bookmark the permalink.
  • José Morettoni

    Hy George,

    I have a problem with the Configure Cluster step.

    1- I copy remote access key from NS1 cpanel instance .

    2 – And Go to vs1 cpanel and configure cluster.
    – remote cPanel & WHM HOST : ns1.mydomain.com
    – remote server username : root
    – remote server access hash : past the code copy in cpanel ns1 instance.
    – Setup reverse trust relationship : checked
    – Sync Changes Selected

    But when I click submit , cpanel return this message :

    There was an error while processing your request: Cpanel::PublicAPI returned [Could not connect to XX.XX.XXX.XX:2087: Connection refused] .

    And the IP XX.XX.XXX.XX show in error doesn’t NS1 ELASTIC IP.

    You can help with this ?

  • http://cupfarsi.com/ ali

    thank you . nice article :)
    can you tell me where are you from ?:)
    آپلود عکس

  • Veena

    Any of you know how Amazon handles the abuse/phishing complaints
    directed at the Elastic IPs on our EC2 instances? Do they shutdown the
    instances or give enough time to resolve issues?

    Thank you.

  • Charles Milliband

    This is the best AWS/EC2 cPanel/WHM documentation online…

    Good job George,

    We look forward to hear from you about Part IV!

  • karlmonson

    Hey George did part 4 ever get completed? I’m really looking forward to it!