Meta

Tag: cpanel/whm

I spent a very happy 9 years at Memset Hosting as an employee, working my way up from systems administrator to a senior systems administrator and finally to First Line Team Leader. Changed offices three times (with two location changes). Dealt with more customers and configurations than I care to count.

Now I’m working for an entirely different company that specialises in e-commerce/e-business platform development, I don’t get the perk of free servers or hosting. Have to pay for it myself now. For two months after leaving Memset I moved my cPanel and Ubuntu server to Digital Ocean – mainly to avoid any potential conflict of interest and also I wanted to check DO out properly. All was good – I have no complaints with Digital Ocean. I’d recommend them for development or testing stuff, and no doubt I’ll be doing so when I need to spin up a server for a day or two to try something out.

But gradually I’ve been moving stuff back to Memset – this time as a paying customer. I got a bit fed up with Rackspace Cloud Files and the lack of decent granular controls over containers. It just wasn’t the same experience I had back at Memset. So I set-up a pay-as-you-go Cloud Storage service for backing up my virtual private servers. Interestingly I’m using Nick Craig-Wood‘s (one of my former bosses at Memset) rclone to push the backups to Memset Cloud Storage as well as Backblaze’s B2 object storage system. I like some redundancy in my backup strategy in case things go completely awry. It’s been working great so far. And since I started the new job, I’ve been exposed much more to “git” and BitBucket, so I now use that to store configuration and automation tools I’ve written for my blog server.

I finally decided to commit to Memset for my long-term virtual private server needs. I set-up two of them – one for the blog, the other for cPanel. I have an external cPanel license which I can take with me from hosting company to hosting company, but the downside is that it’s about £3/month more expensive than Memset – so there I’ve made a mistake. But next year I’ll probably switch to Memset’s cPanel license instead. I find cPanel to be like the G Suite of the hosting world – I can set something up and it’ll just work. Doesn’t require too much effort on my part (except for the initial set-up and hardening/locking down). So I decided to move my blog (which was running Varnish as an exercise for what I’m playing around with now) to cPanel. That doesn’t run Varnish, but Memcache is still giving WordPress the edge. There are a few hundred milliseconds in it, but that’s fine. Everything on one server. So the old new(!) blog server is retiring next month. I upgraded cPanel to a better specification (and here’s one difference between Digital Ocean and Memset – you get an extra 2 CPUs at the 4Gb RAM mark with Memset and you do notice the difference).

I’ve had to make just one support query with Memset about the initial set-ups of my servers, and my former colleagues did me proud with a quick turnaround. The only other problem was that the monitoring configuration was slightly wrong – I guess the CentOS 7 image might need looking at – but it was easily fixed and I’m using the bundle self-managed Advanced Port Patrol to notify me of any problems.

I provisioned each server with 20Gb of block storage, mounting it under /backup and keeping backups dumped there. If I ever need to re-image the server itself, that block storage will be persistent and I can just restore from the backups stored there. I also have the Cloud Storage backups too, of course, but this is ever so slightly quicker.

Overall I’m paying £35.50 including VAT for a 4Gb, 4 vCPU, 60Gb SSD Centos 7 virtual private server including the extra 20Gb block storage. Cloud Storage costs me around 60-70p per month including the backups AND two snapshot images of the server. Compare that to the £26 I was paying just for my Times and Sunday Times iPad newspaper subscription, it’s an absolute bargin.

(And before anybody asks – no, Memset are not paying me to post this, nor are they giving me any freebies – I’m 100% paying my own way here )

With the latest release (to the CURRENT tier, which is considered “release candidate” worthy) of cPanel/WHM, you can now obtain completely free 90 day SSL certificates from cPanel themselves (backed by Comodo) for your web site. This requires version 58 of cPanel/WHM. These certificates will automatically be renewed.

This blog is already using them, and long may I do so. As I’ve said earlier, obtaining SSL certificates for securing usernames and passwords or e-commerce is now the cheapest (e.g. free) it’s ever been. There’s absolutely no excuse to run a web site that’s not secured by an SSL certificate now. None.

If you don’t want to use Comodo backed SSL certificates, there will be a Let’s Encrypt plugin for cPanel/WHM appearing soon from cPanel themselves.

One of the reasons for popping up to Edinburgh last week was to hear various representatives from cPanel/WHM talk about the many features of the cPanel/WHM ecosystem as well as glimpsing upcoming new features to make everybody’s life a bit more easier.

As as systems administrator of some 20 years (has it been that long?), I am most comfortable with a command line interface and a decent text editor. cPanel/WHM provides a user friendly web interface to many of the complex tasks that one would to go through to configure a web hosting environment. But I must admit to loving cPanel/WHM just as I love the command line because it is easier to set-up a blog like this through cPanel/WHM than it would take me to set-up nginx, php-fpm, MySQL (or MariaDB, or PerconaDB) from scratch. That said, to get the very best out of cPanel/WHM, you should still know some Linux commands because not everything can (or should be) handled through a web interface.

As cPanel/WHM development storms ahead, we’re getting to the point where cPanel/WHM is becoming more standardised so that you’ll be able to manage it just as you would any other kind of bare bones Linux box, with full LSB compliance (with configuration files and scripts in meaningful places) along with full API and command line support for most features.

With the forthcoming EasyApache 4, for example, you can set-up Apache and PHP through the use of RPMs rather than having to wait for cPanel/WHM to compile everything for you. I cannot tell you how much faster it is installing everything through a Linux package management system.

EasyApache 4 is still considered beta, with plans for it to be released within the next major release of cPanel/WHM – version 58, which is about 12-16 weeks away. Beta or not, EasyApache 4 is perfectly serviceable right now. With EasyApache 4, it’ll make it much easier for folk to run multiple versions of PHP (so older sites can run PHP 5.3/5.4 and WordPress and the ilk can run PHP 7). Of course, one would recommend deploying CloudLinux to provide a greater amount of segregation and security for the older, potentially more exploitable apps, but this feature in EasyApache 4 makes it possible for all folk to run multiple versions of PHP side-by-side.

There will still be a user interface to configure EasyApache profiles. Indeed, I used it to specify the relevant Apache and PHP packages for this server. The MultiPHP INI editor is a wonderful inclusion that makes it dead simple to go through all the php.ini options and set them to your liking. The changes will be applied to whatever PHP handler is being used.

Full PHP-FPM support is among one of the biggest and greatest features I’ve been waiting for in cPanel/WHM. It should be fully supported in version 58, but I’m making great use of it right now with a bit of command line tinkering. I’m running this blog (and the stats system) on PHP 7 with PHP-FPM. It wasn’t difficult, and I find that I’m loving the performance from having made the effort. Having nginx would be a nice have (as a web server rather than as a front end proxy to Apache), but beggars can’t be choosers and Apache 2.4’s performance is pretty decent as it is.

cPanel/WHM has a robust backup system that can create .tar.gz archives of your accounts, combining email, web files, databases, etc. into a single archive that can be used to restore the account in the case of emergency, or to move to another server.

What it isn’t so good at is putting them somewhere off the server to ensure that if your it dies a horrible death (multiple hard drive failures, spontaneous combustion, human error, etc.) you can restore all your accounts. Much of the backup system depends on third-party remote mounts, Amazon S3 or FTP servers.

Worry no more! For one of the directors of Memset, the company that employs me to do things, has created a multi-purpose transfer tool called rclone. It can be set-up to copy or sync data to a variety of multiple destinations, including:

Google Drive

Amazon S3

Openstack Swift / Rackspace cloud files / Memset Memstore

Dropbox

Google Cloud Storage

Amazon Cloud Drive

Microsoft One Drive

Hubic

Backblaze B2

Yandex Disk

The local filesystem

Since this site is hosted on a Memset server, it makes sense to backup my cPanel accounts over to my Memstore account, an object storage system that uses the OpenStack Swift protocol. While we have custom FTP and SFTP proxies, it’s important to note that you can’t upload a file that’s greater than 5Gb in size. Thankfully rclone speaks native Swift and can handle sizes beyond 5Gb.

The following assumes a basic knowledge of Linux and access to SSH as root..

Press ‘n’ for New Remote. You’ll then be prompted to give this a name. You can call it whatever you like. In this example I’ll be using the name ‘memstore’. Once you’ve given it a name, you’ll be prompted for the storage type. In our example, it’s OpenStack (number 10):

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

name>memstore

Type of storage toconfigure.

Chooseanumber from below,ortype inyour own value

1/Amazon Cloud Drive

\"amazon cloud drive"

2/Amazon S3(also Dreamhost,Ceph)

\"s3"

3/Backblaze B2

\"b2"

4/Dropbox

\"dropbox"

5/Google Cloud Storage(thisisnotGoogle Drive)

\"google cloud storage"

6/Google Drive

\"drive"

7/Hubic

\"hubic"

8/Local Disk

\"local"

9/Microsoft OneDrive

\"onedrive"

10/Openstack Swift(Rackspace Cloud Files,Memset Memstore,OVH)

\"swift"

11/Yandex Disk

\"yandex"

Storage>10

I’ve created a user within my Memstore/Memset account control panel called “cpanel” that I’ll be using to connect to the Memstore container “cpaneldemo” that will hold my backups:

I then assign read and write permissions for user “cpanel” to the container “cpaneldemo”:

Now to configure rclone:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

User name tolog in.

user>cpanel

API key orpassword.

key>******************(password will be displayed inplain text)

Authentication URL forserver.

Chooseanumber from below,ortype inyour own value

1/Rackspace US

\"https://auth.api.rackspacecloud.com/v1.0"

2/Rackspace UK

\"https://lon.auth.api.rackspacecloud.com/v1.0"

3/Rackspace v2

\"https://identity.api.rackspacecloud.com/v2.0"

4/Memset Memstore UK

\"https://auth.storage.memset.com/v1.0"

5/Memset Memstore UK v2

\"https://auth.storage.memset.com/v2.0"

6/OVH

\"https://auth.cloud.ovh.net/v2.0"

auth>5

Tenant name-optional

tenant>msdrakeab2

Region name-optional

region>

Storage URL-optional

storage_url>

Remote config

--------------------

[memstore]

user=cpanel

key=**************(password will be displayed here inplain text)

auth=https://auth.storage.memset.com/v2.0

tenant=msdrakeab2

region=

storage_url=

--------------------

y)Yes thisisOK

e)Edit thisremote

d)Delete thisremote

y/e/d>y

Current remotes:

Name Type

========

memstore swift

e)Edit existing remote

n)Newremote

d)Delete remote

s)Set configuration password

q)Quit config

e/n/d/s/q>q

So the username is the right-hand part of the Memstore username, and the tenant is the left-hand part (e.g. msdrakeab2.cpanel becomes user = cpanel, tenant = msdrakeab2). The key (or password) will be displayed in plain text at all times, and is stored within the /root/.rclone.conf file. Make sure that only root has permission to read this file – it should do by default, e.g.:

1

-rw-------1root root151Apr111:23/root/.rclone.conf

So we’re ready to rock and roll. We don’t have any data in the container, but we can give a quick test to make sure we’re able to connect:

1

2

3

4

5

6

7

root@cpdev[/backup]# rclone lsd memstore:cpaneldemo

Transferred:0Bytes(0.00kByte/s)

Errors:0

Checks:0

Transferred:0

Elapsed time:1.1s

All seems to be working. So let’s manually move some backups to Memstore. Memset configures cPanel backups to be dumped to /backup on your server. So based on that, the initial upload will look like this:

where /tmp is the local filesystem where you want the file to be placed. Can be anywhere on the filesystem. You can leave out the file and have the entire contents of the ‘accounts’ directory transferred too (although in this example, there is only one file in ‘accounts’):

which will run at 1:30am and will dump the output to /var/log/rclone.log.

Other ideas

You could use rclone to create historical backups within Memstore, handy if you keep a set of daily backups that you’d like to keep around longer than the cPanel keeps them for on your server’s filesystem. To do this, you ensure you have a destination container to sync to. So let’s create one:

1

2

3

4

5

6

7

root@cp[~]# rclone mkdir cpanel:cpdev

Transferred:0Bytes(0.00kByte/s)

Errors:0

Checks:0

Transferred:0

Elapsed time:200ms

then sync the contents of one container to another. Note that all of this is done on Memstore – no data is transferred from your server to Memstore (or vice versa).

The following example demonstrates a sync of the existing data in the “cpaneldemo” container to the new container “cpdev”. I could automate this by adding a cron job to sync data from “cpaneldemo” to “cpaneldev” on a weekly basis, for example.

From version 56 of cPanel/WHM onwards, cPanel will generate a Comodo-backed SSL certificate for your server’s hostname. It won’t protect proxied service URLs such as webmail.*, cpanel.*, whm.*, etc. but it will allow you to access cPanel/WHM via a fully certified certificate.

From version 58 of cPanel/WHM onwards, every domain on your cPanel/WHM server is able to receive a free Comodo-backed SSL certificate – valid for 90 days, but is automatically regenerated by the system. It’s an alternative to Let’s Encrypt, support for which will be eventually be made available via an external plugin.