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.

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

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

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

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

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

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

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

Review

  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

  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

  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.

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.

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.

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.

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

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.

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.

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.

 

 

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

In Part 1 of this four part series, we discussed establishing your VPC, creating and configuring your small subnet, and worked through configuring the Security Groups for our two instance types (‘NS_SG‘ and ‘VS_SG‘).

Today, we work on launching a two new instances, running cPanel DNSONLY, into our VPC and configuring these to be the primary and secondary DNS resolvers for our environment. While this series is written with the assumption of using dedicated DNS instances, you could easily use these instructions on dual use instances that both serve as web servers and as name servers.


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 DNS basics. You will need to have a working knowledge of DNS best practices.
  • 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.

This Lesson Includes

  • Creating and launching a new EC2 Instance (Name Server) within VPC
  • Applying a Security Group to an Instance
  • Configuring cPanel DNSONLY for AWS
  • Creating a DNS Cluster

Create and Launching the Name 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

  1. Select the “Instance Type: T1 Micro“. A T1 Micro Instance is sufficient for a basic name 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“.

  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.10” based on my subnet range.
  6. Click “Continue“.

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

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 NS (Name Server).

Click “Continue“.

Create KeyPair

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.

To create a key pair, enter a name and click “Create & Download Your Key Pair”. You will be prompted to save the private key to your computer. Note: You only need to generate a key pair once – not each time you want to deploy an Amazon EC2 instance.

Click “Continue“.

Configure Firewall

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

Review

  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

  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

  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 DNSONLY

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 DNSONLY, 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 “ns1.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.

11.36 Temporary Workaround

At the time of writing this, cPanel DNSONLY Stable Release is at 11.36, meaning it does not yet officially support a NAT, however I can say with confidence that by the time WHM 11.40 is released DNSONLY will be on par with NAT support.

The following instructions are unique to 11.36 and DNSONLY because it does not yet officially support NAT, these should be considered a temporary work-around until 11.40 arrives at which I will update the instructions.

  1. In Step 3, add a new IP address by entering in the Elastic IP of the instance you are working with. Subnet should remain default.
  2. Click “Add IP(s)“.
  3. Click “Finish

You should now be directed to the DNSONLY Dashboard. Again, due to this being a non-NAT build, we need to workaround for the time being. We need to modify the Main IP within cPanel from our Private IP to our Elastic IP.

  1. In the left hand menu, click “Basic cPanel & WHM Setup“.
  2. Locate the first field under “Basic Config” that contains what probably looks like a random 10.x.x.x IP. Replace the existing IP with your Elastic IP.
  3. Click “Save Changes“.

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.

  1. In the left hand menu, under Cluster/Remote Access, click “Configure Cluster“.
  2. In the Modify Cluster Status box, select “Enable DNS Clustering”.
  3. Click “Change”.
  4. Click “Return to Cluster Status”.

Conclusion

At this point you have a single nameserver, ns1.example.com configured and with DNS Clustering enabled. This server is ready to Pair/Synchronize with WHM/cPanel client servers.

You do, however, need to repeat these steps for a secondary nameserver, presumably ns2.example.com.

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.


Already using Amazon Web Services? Check out the cPanel & WHM listing in the AWS Marketplace and start building your own cPanel hosting environment.

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

People argue for and against building a production hosting environment on top of cloud services such as Amazon’s AWS. I recently made the decision to migrate my entire hosting infrastructure from co-located dedicated hardware to a full implementation built entirely on top of Amazon’s Web Services.

I will be releasing a four part series detailing the tricks I’ve learned in my own migration to AWS and walking you through setting up your own full service hosting environment within the AWS eco-system, all while still leveraging the power of cPanel, WHM, and DNSONLY.

I chose to use AWS, more specifically EC2, VPC and S3, for its rapid deployment, unlimited scaling, load balancing, and global distribution abilities. Working with AWS, I started to realize just how powerful it could become.

I started this challenge with a few key questions: What are the benefits and the challenges one would face working in an environment like this? All of our servers run instances of cPanel/WHM, so what are the difficulties in setting up cPanel in an AWS environment?

Amazon’s AWS platform is built behind a NAT infrastructure, so inherently, configuring cPanel for a NAT used to be an elaborate ballet of duct taped scripts and hooks. However, with cPanel 11.39, I’ve been able to seamlessly migrate my entire infrastructure ( 30+ instances ) from a dedicated environment to AWS without any misstep.

The result is a solid hosting architecture using Amazon VPC (Virtual Private Cloud), Amazon EC2 (Elastic Cloud Compute) and Amazon S3 (Simple Storage Service), built with cPanel/WHM/DNSONLY that not only works on AWS, but makes deployment and provisioning of new servers unbelievably rapid and simple.


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, you must have a working knowledge of the command line, networking, Amazon AWS, and cPanel/WHM/DNSONLY.
  • Second, this model will run two dedicated nameservers (cPanel DNSONLY), the node servers will not be running DNS and will be configured in a cluster.
  • Third, I won’t be going over the registration process of AWS, you need to already have an active account.

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

A Representation of the Basic Network Architecture

This Lesson Includes

  • Creating a new Amazon VPC Instance
  • Defining subnet scope
  • Creating and defining Security Groups

Setup the VPC, Subnet, & Internet Gateway:

  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
  2. Click “VPC Dashboard” in the navigation pane.
  3. Locate the “Your Virtual Private Cloud” area of the dashboard and click “Get started creating a VPC“, if you have no VPC resources, or click “Start VPC Wizard“.
  4. Select the first option, VPC with a Single Public Subnet Only, and then click Continue.

  1. The confirmation page shows the CIDR ranges and settings that you’ve chosen. Since this is going to be a small network, click “Edit VPC IP CIDR Block” and change the value to “10.0.0.0/24“. This gives us 251 useable IPs on the gateway.
  2. Click “Create VPC” to create your VPC, subnet, Internet gateway, and route table.

Create Security Groups

Security Groups are essentially Firewall Rules that can be applied on a per-instance basis. We are going to create two primary Security Groups, one for Name Servers and one for Web Servers. Of course, your specific scenario will differ from the one represented here, so feel free to create as many Security Groups as needed.

In my use case scenario, I established a Security Group for Name Servers, Shared Web Servers, and Dedicated VPSs. Again, tailor these to meet your needs.

  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
  2. Click “Security Groups” in the navigation pane.
  3. Click the “Create Security Group” button.
  4. Specify NS_SG as the name of the security group, and provide a description. Select the ID of your VPC from the “VPC” menu, and then click “Yes, Create“.
  5. Click the “Create Security Group” button.
  6. Specify VS_SG as the name of the security group, and provide a description. Select the ID of your VPC from the “VPC” menu, and then click “Yes, Create“.
  7. Select the “NS_SG” security group that you just created. The details pane includes a tab for information about the security group, plus tabs for working with its inbound rules and outbound rules.

On the “Inbound” tab, do the following:

  1. Select “All Traffic” from the Create a new rule list, make sure that Source is “0.0.0.0/0“, and then click “Add Rule“.
  2. Click “Apply Rule Changes” to apply these inbound rules.

On the “Outbound” tab, do the following:

  1. All Traffic” is allowed by default, we will temporarily keep this rule.

Complete the same steps above for the “VS_SG” you created.

If you’ve made it this far, you’re probably half way to a panic attack wondering why we’ve opened up all inbound and outbound ports. Each environment’s needs for port availability will obviously be unique, but for most standard cPanel/WHM installations, you can have a look at this informative article, Getting The Most Out of Your System’s Firewall,  detailing commonly used ports by cPanel and its bundled services and then choose to open or close the ports at the firewall level accordingly.

Alternately, you can keep all inbound/outbound traffic at the firewall level as pass-through (as detailed above) and handle your firewall at the instance level with a software based firewall.

cPanel supports numerous software based firewalls that are freely available to download and install, personally I use and highly recommend ConfigServer Security & Firewall. It’s dead simple to install and I recommend running the security scan once you have it configured to ensure you’ve taken extra steps in hardening your systems.


Up Next

  • Creating and Launching Name Server Instances Into Your New VPC
  • Configuring your Name Server
  • Basic Cluster Configuration

 

How to change the primary IP addres of a WHM/cPanel server

This is for CentOS/RHEL based servers.
Steps in WHM:

  • Log into WHM and go to Basic cPanel & WHM Setup
  • Change the Primary IP here with the option that says “The IP address (only one address) that will be used for setting up shared IP virtual hosts
  • Note: This might not actually be necessary.

Log in to SSH, and do the following:

  • Edit /etc/sysconfig/network-scripts/ifcfg-eth0
    • Change the IPADDR and GATEWAY lines to match the new IP and Gateway for the new ip

 

  • Edit /etc/sysconfig/network
    • Change the GATEWAY line here if it does not exist in the ifcfg-* file.

 

  • Edit /etc/ips
    • Remove the new primary IP from this file if it is present
    • Add the old primary IP to this file with the format ::

  • Edit /var/cpanel/mainip
    • Replace the old primary IP with the new primary IP

 

  • Edit /etc/hosts
    • Replace the old primary IP with the new one if needed. The hostname’s dns will need to be updated too

 

  • Restart the network service to make the new IP the primary
    • service network restart
    • Note: You’re probably going to be disconnected at this point, and have to log in to ssh using the new primary ip.

 

  • Restart the ipaliases script to bring up the additional IP
    • service ipaliases restart

  • Run ifconfig and make sure all IPs show up correctly

 

  • Update the cpanel license to the new primary IP

 

  • Verify you can still log in to WHM and there is no license warning

 

How to remove Tomcat on cPanel

Want to remove Tomcat from cPanel?

Log-into your server as root using ssh:

Execute the following command to stop the Tomcat process:
# /usr/sbin/stoptomcat

…and to remove the next files, enter:
# rm -f /usr/sbin/starttomcat
# rm -f /usr/sbin/startomcat
# rm -f /usr/sbin/stoptomcat

Finally, remove all mod_jk lines from httpd.conf, including addmodule, loadmodule, and include lines.