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 )
(At least not if you are a financial organisation or need some form of extended validation/identity confirmation)
The SSL certificate marketplace is undergoing an extraordinary transformation. Once upon a time you could expect to pay a princely sum to obtain what is called an “SSL certificate”. This is effectively a piece of code that you install on a server (whether it be web, email, or similar) that allows you to encrypt data between two end points (a client such as a web browser and a web server, for example). The SSL certificate allows the client (browser) to identify the server it’s connecting to.
But as the Internet has grown, the need to protect data in transit (such as usernames and passwords, credit card details, or other personal information) has also increased. To that end there has been many attempts to provide free or cheap SSL certificates to all and sundry. Self-signed certificates are no longer good enough. Unless you explicitly trust a self certificate within your browser, you’ll see all manner of warning messages. No, a trusted third party must now be present to ensure that your communications in a web browser are secure.
SSL certificate prices have been gradually becoming cheaper and cheaper over past few years. I’ve picked up regular domain validated SSL certificates as little as 99 cents (US) or at the most around £2-3 per year. The drake.org.uk wildcard certificate (which protects an unlimited number of us domains with a single certificate) only cost me 40 quid for two years.
But now things are getting even cheaper – cheap enough to be FREE!
Let’s Encrypt has been one such effort to bring SSL certificates to the masses, for free. Completely free. Having left beta, we are going to see a lot of companies and organisations offer Let’s Encrypt as part of their product or service. cPanel, for example, will be integrating Let’s Encrypt as part of the next major release of cPanel/WHM. This means that providing that the server operator/hosting company you’re hosting with allows it, your web site will be protected by an SSL certificate for free – automatically.
CloudFlare is another company that’s offering free certificates. Their free tier allows you to encrypt between their servers and your own (origin) servers – combined with an origin SSL certificate that you install on your server that provides full, authenticated encryption between CloudFlare’s data centres and your server(s).
WordPress and Sucuri are also two other services offering free SSL certificates with their services.
So as you can see – the days of the paid SSL certificate appear to be coming to an end. The only exceptions are special SSL certificates that require additional validation and assurance – normally Extended Validation (EV) certificates – the ones you’ll normally see at a bank’s web site – the company name all in green alongside the green lock symbol. These certificates require a lot of paperwork. This consequently costs quite a bit more money (and time).
But for us mere mortals, we may well never have to spend a single penny on SSL certificates for our sites or services ever again. We can encrypt for free. And that’s a good thing.
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.
I’ve just returned from a marvellous few days in Edinburgh, having gone up there to attend the cP1Con (cPanel one-day conference).
I also spent a couple of days exploring the sights and sounds of Edinburgh, and have utterly fallen in love with the place. I’ll post much more about that later, but in the mean time, here’s a shoddily put together video (assembled in my hotel room, on the iPad Pro) of footage that I shot at Edinburgh Zoo. Please note, the headless penguin isn’t headless and the one that looks to be dead isn’t. Oh, you’ll see what I mean..
(Note: the meerkats in the hailstorm isn’t a visual effect – it actually happened – a lot)
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:
Openstack Swift / Rackspace cloud files / Memset Memstore
Google Cloud Storage
Amazon Cloud Drive
Microsoft One Drive
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..
cd rclone-vx.xx-linux-amd64(wherex.xx isversion you've downloaded)
#copy binary file
You’ll see something like this:
root@cpdev[/backup]# rclone config
2016/04/0111:03:56Failed toload config file"/root/.rclone.conf"-using defaults:open/root/.rclone.conf:no such file ordirectory
No remotes found-makeanewone
s)Set configuration password
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):
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:
User name tolog in.
API key orpassword.
key>******************(password will be displayed inplain text)
Authentication URL forserver.
Chooseanumber from below,ortype inyour own value
4/Memset Memstore UK
5/Memset Memstore UK v2
key=**************(password will be displayed here inplain text)
e)Edit existing remote
s)Set configuration password
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.:
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:
2016/04/0115:41:13Local file system at/tmp:Building file list
2016/04/0115:41:13Local file system at/tmp:Waiting forchecks tofinish
2016/04/0115:41:13Local file system at/tmp:Waiting fortransfers tofinish
root@cpdev[/tmp]# ls -al mice.tar.gz
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.
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:
root@cp[~]# rclone mkdir cpanel:cpdev
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.