To help keep you up-to-date with the latest news and ideas from the industry, we have compiled the latest articles from industry leaders and corporate blogs. New content is pulled hourly from each blog's RSS feed. The article links will take you directly to the related blog.
This post aims to detail the issues surrounding the recent problems on the server sh2.us.thiswebhost.com, and what steps we have taken to investigate and implement a final resolution to ensure that these problems do not re-appear.
On 27th October the server sh2.us lost connectivity to services, impacting its ability to serve websites, e-mail, FTP and other services. Our monitoring detected this within minutes and alerted us of the problem. Initially this looked to be a mis-report, as we were able to ping the server and bring up a remote console to the machine, however we could not properly access services – including a remote console login (the process would hang). We then spent a great deal of time investigating the network connectivity to ensure that the network was not at fault. Finally, we decided to initiate a “hard reboot” (essentially the same as hitting the ‘reset’ button on your PC) to see if this would help. After initiating a hard reboot, the server successfully came back online and connectivity was restored.
The following morning (October 28th) at exactly the same time, the server lost connectivity again. We went through the same steps as before but also contacted our server/network provider again to see if perhaps some maintenance or other network issue was occurring that they could advise on. After receiving word that there were no network issues, we again initiated a hard reset and services were restored.
On the morning of October 29th at exactly the same time again, the server lost connectivity once more. Having ruled out network problems over the last 2 days and given this was happening at exactly the same time as before, we decided to investigate the possibility that a scheduled task or “cron job” was running at this time and effectively bringing the server down. We looked through all of the cron jobs running at that time and could see nothing out of the ordinary. All of them appeared to be standard, legitimate jobs and no customer jobs were running at that time which should cause any problems. We then decided to begin going through the list of cron jobs and executing each command manually, hoping that we would be able to reproduce the issue here. Fortunately we got very lucky and found the particular task causing the problem; cloudlinux-summary.
CloudLinux is the OS/Kernel we use on all of our shared servers, as this allows us to restrict the maximum resources (CPU, RAM, I/O) each customer can use. This prevents a single user from being able to exhaust all of the resources available and bring other sites slowing to a crawl or bringing them completely down. We’ve been using CloudLinux for many years now and are extremely happy with the product, and it’s being used by thousands (or even tens of thousands or more) of hosting providers worldwide. We were unfamiliar with this cloudlinux-summary task, and on further investigation it appears to be a task that was added towards the end of October via an automatic update. Strangely, the same task was added to other servers that we have that also run CloudLinux but was not causing any issues. At this point we opened a ticket with CloudLinux to report a problem and see if they could offer any advice. In the meantime, we disabled the cron job and added a parameter to the servers sysctl.conf file to prevent the cron job from being added again by CloudLinux through an update. This (albeit temporarily) resolved the problem of the server losing connectivity at a specific time every day.
Disabling the task was not a “fix” in our minds. While it may prevent the connectivity issues, we still didn’t know the exact cause of the problem, nor did we know if it was a sign of a greater issue somewhere else that may appear again in the future. We continued to converse with CloudLinux who asked us for diagnostic and debug information from the server so they could try and reproduce the problem their side in the hopes of ultimately working on a software fix. The problem is that we needed to replicate the environment and situation in order to gather the necessary information. Over the course of the next couple of days (and concluding today) we manually executed the cron job to gather more information. This of course did cause sporadic and brief downtime for our customers, and we sincerely apologise for this. Despite our best efforts, and working with CloudLinux’s assistance, we were unable to generate any meaningful diagnostic data that could pinpoint the problem.
While performing some other routine tasks on sh2.us, we discovered that one of the server side CloudLinux reporting tools that we use perhaps once a month or so was not working correctly. When a specific combination of options was selected, the server would lose all connectivity, just as it had when the cron job was executed. We then came to the conclusion that there was an issue with the CloudLinux installation on the server. Either it had been corrupted or otherwise was unstable with specific tasks, despite appearing to function fine elsewhere. This is something we haven’t seen before in almost 9 years of using CloudLinux – and CloudLinux had not seen such behaviour either. Finally, the choice was made to re-install CloudLinux from scratch to ensure that we had a fresh and working deployment. This is what caused the significant downtime today, and again we are incredibly sorry for the trouble and inconvenience that this may have caused.
Re-installing CloudLinux has resolved all of the problems we previously had, both with the cron job and the reporting tool that we use. Everything now appears to be running correctly and functioning without issue. We will, of course, continue to converse with CloudLinux to try and determine what may have happened here. While it’s not the perfect resolution we had hoped for, we do strongly believe that this is one of those extremely rare things that happens from time to time, and there is no indication that this is likely to happen again.
We do not anticipate any further disruption to services, and once again are incredibly sorry for this situation and the downtime that was experienced by customers on this server. We are committed to providing you with a quality service and hope that this blog post provides some insight into the problem as well as our eagerness to keep you informed of issues such as this.
As of this blog post sh2.us is online and should be operating perfectly. If any customers are experiencing issues with services on sh2.us following this blog post – please don’t hesitate to open a support ticket from within our client area and we’ll investigate as soon as we can.
Thank you for choosing ThisWebHost.
Previously when registering for a service with us, we would ask you if you would like to receive promotional or marketing e-mails from us (something that rarely happens), and prompt customers to “opt-out” of these by way of a simple check-box. We have since updated this system so that it is now “opt-in” with customers having to specifically decide that they wish to receive these e-mails. If you would like to review your current settings for this and opt-out (or opt-in) of these potential e-mails, you can do so by logging in to our client area and checking your contact details page. Please be advised that this setting is only related to promotional and marketing e-mails. We will still e-mail you to inform you of any service affecting issues, such as scheduled maintenance.
At ThisWebHost you may be aware that we run CloudLinux on all of our shared servers. What you may not be aware of is that in addition to helping us manage server resources, CloudLinux also ships with something called “PHP selector” that gives you a great deal of control over PHP in your account via cPanel.
Choose which version of PHP you want to use
When you think of hosting and servers, you may traditionally think that you’re forced to use whatever PHP version your hosting provider has installed on your server. Fortunately that’s no longer the case! With CloudLinux you’re able to choose from a wide range of PHP versions in just a few clicks.
From within cPanel, click on the “Select PHP Version” option under the ‘Software’ category:
You’ll now see something like this on the following page:
What this means is that the current PHP version for the account (and all websites running under that account) is set to the servers native version – PHP 5.6. What if this isn’t a version you want to use? Easy, simply click on the drop-down box and choose the version that you’d like to use:
In the above picture we’ve used the drop-down box to change from the native PHP version (5.6) to PHP 7.1 – something much newer. But we haven’t finalised the change yet. Underneath the PHP version we now see a list of available PHP extensions. Before we confirm that we want to use PHP 7.1 we can ensure that the PHP extensions we may want to use are enabled by checking the appropriate checkboxes. By default we have already pre-checked some of the most common PHP extensions for typical usage.
When you’re ready to switch to PHP 7.1, click on the ‘Set as current’ button next to the PHP version:
We’ll know that the change has taken affect when we see the new version listed as the “Current PHP version”:
Congratulations, you’ve just changed the version of PHP for your hosting account!
Changing PHP settings
So now we’ve changed the version of PHP on our account, what if we’d like to make some more changes? One of the most common requests we receive is customers who would like to increase the PHP size upload limit (upload_max_filesize). CloudLinux also lets you adjust some of these settings from within cPanel, too!
On the same page as before (“Select PHP version” within cPanel), simply click on the link towards the top right of the page (“Switch to PHP options”):
On the following page you’ll be presented with a list of PHP settings that you are able to change. For security reasons, not every PHP setting is available for you to modify (this is shared hosting after all), but you should have access to the most common settings that can benefit you – such as the PHP upload size limit that we discussed before.
To change any of these values, simply click on the grey value to the right of the setting and the value will then become adjustable. For example, here we have clicked on the “2M” next to the upload_max_filesize setting. We want to change the value to 16M, so we’ve used the drop-down box that has appeared to select the value “16M”.
Once you’re happy with the new setting, simply click the “Apply” button next to your new value(s). The new setting(s) will be instantly applied to the version of PHP running on your account.
CloudLinux is a fantastic tool to give you more control over the PHP environment of your website(s). In just a few clicks you can change PHP version, PHP extensions or PHP settings to suit your requirements. No longer are you restricted to the version(s) and setting(s) that your hosting provider have set by default.
We hope that this article was useful to you. As always, if you have any questions, comments or concerns then please do get in touch with us!
It’s no surprise that WordPress is the most popular script that our customers run on their websites. Unfortunately it’s also the most targeted script when it comes to brute-force hack attempts, vulnerability scanning and other malicious attacks. Not keeping your WordPress installation(s) and plugins up to date is the most common cause of compromised websites that we see, and yet over 90% of our customers don’t regularly update these! We want to change that.
Introducing ThisWebHost WAU (WordPress Automatic Updater)
Some time ago now we began working on a system that will automatically find all WordPress installations on our servers and update them to the latest version, along with any plugins that are installed. We’re pleased to announce that we’re now ready for this system to hit public beta release!
ThisWebHost WAU is a two part system. The first component is a set of scripts that we’ve developed that will automatically, and with no input needed from yourselves, update your WordPress core version(s) and all plugins that are installed. This is something that runs in the background on our servers, and not something our customers will see or be able to interact with. The second part is a cPanel plugin that we’ve developed which will allow you to “opt-out” of either updating the core WordPress version, or any plugins that are installed in that specific WordPress folder. Here are some screenshots to demonstrate the system.
You can find ThisWebHost WAU in the ‘Software’ section of cPanel:
On the ThisWebHost WAU main page, you can view your currently detected WordPress installations. If you add a new installation, or modify the plugins on an existing installation, you may click the ‘Re-scan’ button for the plugin to instantly detect these changes:
On clicking ‘Manage Install’ you will be taken to a page that allows you to enable/disable the automatic updating of the WordPress core version:
At the bottom of this same page is a list of plugins that are currently installed on the WordPress installation. All are checked by default, but unchecking a plugin will ensure that our systems do not automatically update it:
That’s all there is to it! It’s a very simple plugin, but we have plans to extend the functionality and improve the interface in the near future.
What does this mean for you?
We have developed this system in mind to keep your WordPress installations and plugins up to date in order to help minimise the attacks that you may face. An out of date plugin, for example, may have security issues which could lead to your site being compromised. The system is also designed to help those who are not familiar with WordPress keep their systems up to date and running healthily. At the same time, we recognise and acknowledge that some of you may not want these features, or have specific custom versions of plugins that you would like left alone. That’s why we’ve developed the accompanying cPanel plugin – so you have full control over how the system operates!
Please be advised that this system is currently considered to be beta. While we have tested it extensively to try and eliminate the possibility of bugs or issues, there is the chance that you experience a bug or two. If this happens to you, please open a support ticket from our client area and let us know what trouble you are having and we’ll try and resolve them as soon as we can.
Thank you for your time, and we hope that you enjoy this new service!
As you may be aware from recent news exposure, it has been discovered that there are several vulnerabilities in a range of Intel CPU’s (which we use) that render them at risk of leaking data or memory that could be obtained by attackers. This blog post aims to provide more information about how this affects this*, and how we plan to tackle and resolve this situation.
Essentially there are 3 vulnerabilities here; CVE-2017-5753 (Spectre Variant #1), CVE-2017-5715 (Spectre Variant #2) and CVE-2017-5754 (Meltdown). These vulnerabilities potentially allow for an attacker to read memory they otherwise should not be able to access. This memory could, as an extreme example, contain sensitive information about other accounts or processes running on the server which in turn could lead to a compromise. All of these vulnerabilities are classed as “severe” and are something that should be addressed as soon as possible.
To apply mitigations to these vulnerabilities will require several different courses of action. The last vulnerability (dubbed Meltdown) is something that we can apply a complete workaround for at the OS (Kernel) level. This involves us installing a new Kernel and rebooting a server to ensure that the new Kernel is fully applied and taking effect. We are in the process of doing this today, so if you notice that the server you are hosted on is offline for a few minutes, this is why – and we sincerely apologise for the inconvenience that this may cause. Unfortunately, the former 2 vulnerabilities require a combination of both OS (kernel) level patching and a microcode update to the Intel processor(s) that we use in our servers. In this instance a microcode update is what you may know as a “BIOS Update” and will involve taking a server offline and flashing new code to the BIOS on a servers motherboard. Once this new code has been flashed, the server can then be booted and a combination of both this new microcode and the new OS update will help mitigiate against the remaining 2 vulnerabilities.
One very significant drawback of these mitigations is that they are just that – mitigations, and not patches or fixes. These updates effectively work around the vulnerabilities rather than resolving them outright. As a result of this, performance can and likely will be affected due to the extra work that the CPU now has to do. What does this mean for you? As an extreme example, it may mean that your website becomes slower after these updates. Some benchmarks and information have shown that after updates to mitigate these vulnerabilities, performance can drop as much as 30%. This is an extreme example and is not necessarily something that you may experience. It all depends on your workload; what your website is doing, how busy it is, and many other factors. We expect most of our customers to not notice any performance difference at all, and as we do not overload our servers unlike other providers, we have ample resources remaining to compensate for this loss of processing power.
Going forward here is what you can expect in terms of ThisWebHost combatting these vulnerabilities;
We will be applying the Kernel updates today and immediately rebooting servers. This helps us immediately mitigate the “Meltdown” vulnerability while preparing for the upcoming microcode updates. You may experience some downtime of between 10-15 minutes while servers are rebooted. We apologise for any inconvenience that this may cause.
We are currently awaiting the appropriate BIOS update(s) from our motherboard vendors. Unfortunately we have no accurate ETA on when these will be provided to us, but we expect it to be over the course of the next 1-2 weeks. Once these updates have been released, we will schedule an appropriate time and date for these BIOS updates to be manually carried out by remote on-site datacentre staff. We will then e-mail all affected customers to provide them with a time and date that the server they are hosted on will be taken offline and updated. We expect these updates to take around 1-2 hours. Once the updates have been applied, the servers will be booted back up and we should then have full mitigation against all 3 published vulnerabilities.
We know that downtime is a cause for concern, and we are deeply sorry for being forced to bring servers offline. Due to the severe nature of these vulnerabilities, we are left with no choice but to do this as soon as we are able to in order to protect our customers and our network.
If you have any questions, comments or concerns regarding this blog post then please do not hesitate to leave a comment below – or alternatively you may contact us via support ticket.
From everyone here at ThisWebHost, we wish you all a happy and safe holiday and new year.
As a small gift from us, we’ve increased CloudLinux limits across all shared and reseller accounts – providing all of our customers with increased memory and CPU across the board! These new limits (and the old ones for comparison) are as follows:
Previously: 100% / 1 CPU Core
Now: 200% / 2 CPU Cores
Number of Processes
For customers on our semi-dedicated packages, we have revised the limits as follows:
Previously: 200% / 2 CPU Core
Now: 400% / 4 CPU Cores
Number of Processes
In addition to the revised CloudLinux limit changes, we are happy to announce that we have also deployed HTTP/2 on all of our shared servers. What does this mean for you? If you have an SSL enabled website (via HTTPS), you may notice increased performance when visiting sites with a HTTP/2 supported browser. Most modern browsers now support this protocol so no changes should be necessary on your side.
As always, if you have any comments, questions or concerns – please get in touch!
Recently we have been looking at ways to improve upon our core services. One of the things we have been wanting to do for quite some time now is to investigate the possibility of providing automatic WordPress updates and upgrades. We know that managing WordPress installations can be a very time consuming activity; trying to ensure that the WordPress core and all of your plugins are up to date. Failing to do this can result in performance issues or even, as a worst case scenario, a site being hacked or compromised. Since WordPress is by far the most commonly installed script on our servers, we felt that there must be something we can do as a hosting provider to help make the process easier for our customers.
Over the last few weeks we have been developing a script (based on WP-CLI) that checks for out of date WordPress installations and updates them, along with any out of date installed plugins. To our surprise, we found that on every one of our hosting servers, at least 80% of WordPress installations were out of date. Some of these were extremely out of date (even by years) and were vulnerable to many publicly known exploits and vulnerabilities. It was clear to us that keeping WordPress up to date and secure was a big problem that needed addressing.
Having a script automatically update WordPress and its plugins may seem like a scary thought, but it needn’t be. WordPress has included a “one click upgrade” process for quite some time now and even its plugins can be updated automatically from within the dashboard. The script we’ve developed does very much the same thing as this but from a command-line level instead of accessing the WordPress installation via login.
Going forward we will be implementing and running this script across all of our servers to keep WordPress installations up to date on a regular basis. Please be advised that this does not guarantee your WordPress installations will be secure, as every installation is different, but we do hope that it will help to further protect our customers against insecure versions of both WordPress and plugins that they may have installed – as well as ease the management and maintenance required.
Please let us know your thoughts or provide any feedback in the comments below.
Over the last few weeks we have been working and planning to restructure our network for the first quarter of this year.
Back in early 2016 we made the decision to migrate sites from physical servers to virtualised servers in order to try and provide additional resiliency and redundancy from hardware failures. Since we were creating servers inside servers, if we detected a potential hardware issue we could simply move these containers from one physical box to another. While we are happy with this implementation, we feel that it now adds an unnecessary step of complexity to our infrastructure and provides very little gain. Hardware failures, while they do indeed happen, are relatively rare and the virtualisation is perhaps best suited for other tasks such as the isolation of separate environments. In addition to the removal of the virtualised servers, we felt it was time to also perform a hardware refresh. A hardware refresh is essentially an upgrade of hardware – for example, we may utilise faster and more power efficient CPU’s, or increase the amount of RAM in a server. As technology changes every few years sometimes it is beneficial to take advantage of the latest and greatest technology. With these changes we will be ensuring that all of our servers now maintain; a minimum of 128GB RAM, a minimum of 12-16 CPU cores and pure SSD drives with at least 1-2TB of storage capacity on each server.
Because of the increased specifications, we are also deciding to merge semi-dedicated and shared/reseller hosting packages on the same servers – but will continue to provide higher CloudLinux and resource limits to these semi-dedicated packages. This will allow customers to upgrade (or downgrade) from or to a semi-dedicated if the need arises, without any interruption to their service at all. Previously we would have needed to manually move an account from one server to another which would result in some brief interruption while DNS propagated.
Hardware aside, we have also decided to use different network providers in order to hopefully improve performance for all of our customers. On our UK server side, we have noticed that some of the routing paths taken by our upstream provider are quite poor, and can result in increased latency and decreased performance to an unacceptable level during peak hours. We have been looking for a new provider in the UK and have located a great match with a superior network to our present one. Over the next few months we will be migrating our UK customers over to this new network and hope that our customers will see an improvement. On the US side we have done much the same and are already part-way through the process of migrating customers.
We understand these migrations can be disruptive for our customers, and for that we sincerely apologise. We are committed to providing the best service that we can, and in order to do that we sometimes have to make significant changes such as this. We feel strongly that these changes are important to provide you with an improved service that you will be happier with.
If you have any questions, comments or concerns regarding this blog post, then please feel free to post in the comments below. Alternatively you may open a support ticket from our client area to speak to a member of staff.
I am pleased to be able to announce that we have now started working on a rewards program to try and give back to our customers. Though in beta and something we are currently testing; starting today you will find a new link in your client area under the ‘Billing’ sub-header, titled ‘My Rewards‘. Our goal with this program is to provide account credit, promotional codes and other rewards to our customers for meeting certain criteria. Been a long-standing customer for many years? We want you to know that we are thankful, and through this program we hope to be able to say “thank you” in a very real way.
At this present time while we are testing the system, you can earn some account credit by following us on Twitter or sending a tweet out mentioning us! Be sure to update your profile to include your Twitter screen name so we can reward the right person! We will be branching this feature out in the near future to incorporate other criteria and rewards.
As always, if you run into any issues or have any questions, comments or concerns, please leave them as a blog comment below. Thank you so very much for being a part of this*.
Today, security and privacy is even more important than ever, and more and more are choosing to encrypt their website traffic using SSL certificates. We are very pleased to announce that all of our shared, reseller and semi-dedicated hosting servers now provide access to free Let’s Encrypt SSL certificates straight from within cPanel. In just a few clicks, and in a matter of seconds, you can enable and configure a free SSL certificate on your website!
What is Let’s Encrypt?
Let’s Encrypt is an upcoming certificate authority to be launched in late 2015 that will provide free Secure Sockets Layer/Transport Layer Security (SSL/TLS) certificates via an automated process designed to eliminate the current complex process of manual creation and installation of certificates for secure websites.
Essentially, Let’s Encrypt (currently) provide free SSL certificates using a quick and easy process that anyone can take advantage of. These certificates are recognised by most common browsers today.
How does it work?
By configuring the certificate within cPanel, Let’s Encrypt will issue a quarterly (3 month) certificate to the domain name(s) you specify. Every 3 months this certificate will automatically renew, unless you no longer require the certificate and choose to manually remove it. Presently, there is no charge for using Let’s Encrypt SSL certificates and there are no immediate or obvious plans for Let’s Encrypt to begin charging for this service. You simply configure the certificate within cPanel and are then able to visit your website using the https:// prefix.
How does Let’s Encrypt compare to commercial or paid for SSL certificates?
From a technical perspective, Let’s Encrypt certificates and commercial SSL certificates achieve almost the same thing. There are, however, some significant differences you need to be aware of. We strongly invite you to read the following Quora question on the subject, which may provide a better insight into the differences: https://www.quora.com/What-is-the-difference-between-Lets-Encrypt-and-a-Commercial-Certificate-Authority-GoDaddy-etc
In short; if you want a quick and easy way of getting your website SSL secured for privacy or security reasons, Let’s Encrypt is a fantastic free option for you. If you are an online retailer, or otherwise require the security, warranty and support of a commercial certificate, that may be a better option for you.
Are there any limits/How many certificates may I have?
You may, of course, only have one certificate active on a specific domain name at a time. There are no restrictions on how many domain names you may use Let’s Encrypt certificates with, and they will also work on addon and/or subdomains within your account.
Are there any other benefits?
Previously, when using SSL encrypted e-mail, you would need to use the server hostname in the incoming and outgoing server fields to prevent any certificate error warnings from appearing. With the Let’s Encrypt system and a valid Let’s Encrypt certificate on your domain, users should be able to switch to using their own hostnames (such as mail.yourdomain.tld) without a certificate warning.
How do I get started?
For your convenience, we have written a Knowledgebase Article that details the steps you can follow in order to configure and install a Let’s Encrypt SSL certificate on your domain(s). To view the Knowledgebase Article, please click the following link: https://www.thiswebhost.com/clients/knowledgebase.php?action=displayarticle&id=594
We hope that this change is beneficial for you and your client(s). As always, if you have any questions, comments, concerns or feedback regarding this change; please respond to this blog post.
Beginning December 25th, our main upstream provider (Linode) began experiencing large DDoS (Distributed Denial of Service) attacks aimed at their network. To give you some additional background; Linode have a presence in multiple data centers around the world. The attacks that began on December 25th were targeting every single network link they had to each of their data centers. In short, this was a directed attack to try and take Linode down across the world. As a result of the attack targeting Linode, anyone utilising Linode’s network would also be affected and also taken offline.
At this point, a very significant part (read: almost all) of our infrastructure was affected due to how we utilise Linode. This included our client area/website as well as our shared and semi-dedicated hosting servers. It should be noted that not all of our infrastructure utilises Linode, and we have spread out parts of our infrastructure as much as we reasonably can without complicating matters further, but these attacks certainly had a significant negative impact on our services.
Once the DDoS attack(s) were detected, they were relatively quickly mitigated (stopped) by Linode and service was restored. Unfortunately, these attacks continued for several days in what I can only describe as a game of cat and mouse, with Linode stopping the attacks only for them to start again shortly thereafter. While I am sure Linode were doing their best, sadly we saw no immediate or positive signs that they were able to respond and contain the problem on a permanent basis. As the downtime continued we knew we would have to make a choice between waiting to see if they could permanently stop the attacks or to migrate to a new provider who were not under attack and subsequently distance ourselves from the attacks altogether. With already significant amounts of downtime being experienced, we made the decision that, very regrettably, we would have to move to a different network provider in order to hopefully avoid further downtime. After all, we had no idea how long these attacks could last and postponing any migrations could be extremely costly not just to ourselves but also our customers.
Approaching January 1st 2016, the attacks appeared to have been largely mitigated with them hitting primarily the Atlanta data center and parts of Dallas. While the UK networks and some of the US locations were no longer under attack (or the attacks were being fully mitigated), we began migrating customer accounts to new servers that we had already setup with a new provider in another location. We did this as quickly as we possibly could, as we were unsure whether or not the attacks at these locations would return. Unfortunately for us, 2 of our US shared hosting servers were based in the Atlanta data center that was heavily under attack. We had no access to these servers to migrate accounts directly, and the servers would only come up for very short periods of time – nowhere near long enough for us to reliably transfer any data to the provider we had waiting on standby.
The backups that we regularly take of our servers are block level backups, which can be used to perform “bare metal” recovery. That is, if a server were to have a catastrophic hardware failure and lose all data, we would (in theory) be able to restore a completely identical copy of the server at the time of the last backup snapshot. Unfortunately, these backups only really work where you are restoring to an identical server configuration as the previous server. That is, the same specifications and same overall configuration. Because we had moved to a new provider, these backups could not be restored as bare bones and we could not use them in this fashion. This meant that we had to wait for access to the servers that we had in the Atlanta data center.
Towards the end of 3rd January 2016, Linode began to mitigate the attacks long enough for us to begin moving data out of the Atlanta network across to a new provider. We are still in the process of migrating the final accounts across to new servers now, but I can happily report that most customers in Atlanta have been migrated across. For the time being, the Atlanta network does not appear to be under attack any longer, but as a precaution and to fit in with our new infrastructure strategy, we will continue with the migrations until we have moved all customers in all locations across to our new provider.
Why did we continue to migrate accounts to a new provider once the attacks have been stopped?
This is fundamentally a combination of decisions. While the attacks were obviously our primary motivation, we had already made the decision to migrate to the new provider and had to see that through regardless of the outcome on Linode’s side.
What are you going to do to ensure that this doesn’t happen again?
While the DDoS attack was aimed at Linode’s networks specifically, and not us, we are by no means going to lay all of the blame on Linode. We have certainly learned a lot throughout this situation and have identified and hopefully acknowledged some of our own shortcomings. We know we can do better and are going to investigate options in the future that can help make us much more resilient to not only attacks like this, but other potential points of failure in our infrastructure.
Our new provider, theoretically, brings us several significant advantages. It is much, much easier for us to perform bare metal recovery tasks now. What this means is that should we ever experience a situation again where we anticipate lengthy downtime (either due to DDoS or other reason), we would be able to relatively quickly spin up a new server and perform a bare bones restore much faster than before. There would be some post-restore tasks (such as updating DNS) that would need to be actioned to get sites back up and running, but overall we are much more in control of our backups than we were previously.
Finally, our new provider specifically offers and advertises DDoS protection to their customers. While there are limits associated with this, and it in no way pretends to be able to prevent or block every single DDoS attack out there, Linode in contrast do not provide or offer such a service to their customers. While we were not the target of the DDoS attacks that began on December 25th, the fact that we have the option for some DDoS protection does indicate that our new provider are in a better position to be able to respond to such attacks if needs be in the future.
There were multiple faults from several sides that led to the problems many of you experienced, and we are working to identify and improve upon in these in time. Going forward we will be investigating ways and software that may assist us in distributing customer sites across multiple geographical locations to provide further redundancy. I can’t say much about this at the moment, but rest assured if this is something we see as viable in the future we will certainly let our customers know.
I would like to apologize for those affected by this recent downtime. An attack of this nature is extremely rare and something I think a lot of people in the industry; us included, have never seen before. We have learnt a lot from the situation and hope to implement some positive changes to make us more resilient in the future.
If you have any questions for us, please respond to this blog post and we will happily try to address them.
We are very pleased to announce some positive changes to the SSL certificate process here at ThisWebHost.
The previous system
Previously, customers wishing to implement SSL security to their website were required to purchase both a dedicated IP address (+$5/month) and ensure that the account they wanted to use for SSL was a standalone account (not in a reseller account, nor an add-on or sub-domain). Finally, once the certificate was purchased and configured, you would have to open a support ticket with us in order for us to install the certificate on your behalf.
This was a headache for customers because not only did it increase costs, it also involved DNS propagation to the new IP address which could cause disruption to the existing site(s). Well, I am pleased to say that as of this blog post, the process has now changed for the better.
The new and current system
With the inclusion of SNI (something we have been waiting for for a very long time), dedicated IP addresses are no longer required to use SSL certificates. Certificates are matched on the name being accessed in the browser, rather than the IP address of the connection, eliminating the need to change IP address entirely.
This also has significant benefits to the previous system. Customers can now also install SSL certificates on add-on domains and sub-domains as well as any sub-accounts within WHM. Separate, unique accounts are no longer required.
Finally, because of these changes, we now provide the ability for customers to install their own SSL certificates, right from within cPanel. Opening a support ticket to request that we do this is no longer required.
As the process for SSL certificates has changed, we have completely rewritten our guide for managing SSL certificates. You can find the new guide here in this knowledge base article.
If you’re an existing customer who has a dedicated IP address, or separate account(s) specifically for using an SSL certificate then your current system will work and continue to work just fine. We have no plans to withdraw the existing configurations of current customers. If you do wish to remove your dedicated IP address or merge any account(s) back into any other account(s), then please get in touch via a support ticket and we will do our best to assist you.
We want you to give us a try, so we’re giving away a handful of Starter/Blog shared hosting accounts for the first 3 months. To take advantage of this, simply post a comment on this blog post below and let us know what you plan to use your potentially new hosting account for! Please be sure to use a valid e-mail address when you comment so we can get in touch with you to let you know if you have been selected.
There are some restrictions/limitations with this offer. We are providing the hosting account only and not a domain name, so you will need your own domain name to take advantage of this. Selected recipients will receive a promotional code giving them a 100% discount on a quarterly starter/blog hosting account for the first period. This means the first 3 months will be free. If you wish to maintain and continue your account with us after the first 3 months, you will be billed at the respective rate. No payment details are required.
We are currently in the process of changing the default PHP version on all of our shared and semi-dedicated servers from PHP 5.3.29 to 5.5.27.
What does this mean for me?
Unless you have specifically selected your own PHP version within cPanel (more information on this later), your scripts (WordPress et all) will begin using this new version of PHP as soon as we have completed the change. No changes are necessary on your side, and this update will be automatically handled by our team.
We expect all of our servers to be updated to PHP 5.5.27 within the next 24 hours.
Will this change cause any problems for me?
Unfortunately we cannot say for sure. There are certainly differences between the PHP versions, and some functions may have been deprecated or removed entirely. If your script relies on and is using these functions, it may stop working altogether. If you do experience problems after this change, please continue reading this blog post as we will provide a potential solution further down.
If you are using a common and popular Open Source script such as WordPress, you are unlikely to be affected by these changes.
Why are we making this change?
PHP 5.3 went EOL (End of Life) in approximately the second quarter of 2014. This meant that no more security fixes were being added to PHP 5.3 as of the middle of 2014. PHP 5.4 will be EOL on 14th September 2015. Again, this means that no more security fixes will be rolled out after September this year.
In order to ensure our environments are as stable and secure as possible, we are making the choice that we will now maintain a default PHP version on all servers that is in active development. This means that going forward, when a version of PHP has entered its EOL period, we will replace it with the latest actively developed version.
Previously we continued to run with PHP 5.3.xx because we did not want to potentially interrupt existing customer websites with a new version of PHP before people have had a chance to upgrade to ensure compatibility. We have, for a very long time, provided the ability for our customers to choose which version of PHP they wanted to use from within their cPanel. This allowed customers who wanted to use a newer version the ability to bypass our default selection and choose their own, including selecting the modules they wished to use. Given how long it has been since PHP 5.3 went EOL, we now believe that enough time has passed that these scripts should now be fully compatible, and that it is in the best interests of server security that customers are using the most secure version of PHP available. We are skipping the upgrade from PHP 5.3 to PHP 5.4 because this is also due to go EOL within 2 months.
How do I roll back to/use PHP 5.3 (or earlier) if I need to?
We very strongly suggest that you use the native version of PHP on the server unless you are experiencing significant problems and/or your existing scripts are not supported. Running an older version of PHP potentially puts you and your account at risk and there really is no need to use an older version unless it is impossible for your script to be updated. That said, we provide the ability for all customers to choose the PHP version on their account from within cPanel. Please follow this knowledgebase article for details and instructions on how to accomplish this.
We do not expect this change to cause any significant problems or global issues, but we sincerely apologize for any inconvenience that this may cause you if you are one of the small number of people this might affect. Rest assured, we would not make such a change if we did not provide the ability for our customers to choose an older version of PHP if required in order to resolve any possible compatibility issues.
As always, if you have any questions, comments or concerns about this blog post, then please feel free to use the comments section below. If you have a specific question about the PHP on your account, please be sure to open a support ticket from our client area so we can identify you and your account.
For some time now we have experienced several issues with the client area disk space and bandwidth reporting. These are actually issues with the WHMCS software we use for our billing and client management. If you’re a reseller or VPS user with us, you may also have experienced one or more of the following;
The disk space and bandwidth statistics in the client area only report either the main account (and doesn’t include any of the sub-accounts listed in your reseller area), or just the sub-accounts (and doesn’t include the main account). As a result of this, you can be unsure of exactly how much disk space and bandwidth you are using and there are no immediate tools that will show you the result of everything added together.
VPS users simply do not have statistics at all.
When upgrading or downgrading a package, the statistics shown in the client area do not immediately update. As a result it may look like your account has not yet upgraded or downgraded even though it has.
As of this blog post we have now deployed solutions to all of these issues.
The disk space and bandwidth statistics shown in the client area now incorporate the main account and any and all sub-accounts you have created in WHM. This provides a much clearer overview of how much space and bandwidth, exactly, your whole account is using. If you wish to know exactly how much disk space or bandwidth your main domain on its own (and excluding the sub-accounts) is using, you can view this from within cPanel.
We have developed our own module to generate and report statistics for VPS users. VPS users will now be able to see the entire disk space and bandwidth usage of their servers from within our client area. Please note that these statistics are server wide as this is the best way to logically present the data.
Statistics will now automatically update in the client area following an upgrade or downgrade of an applicable account package. This means the new quotas will be reflected instantly and customers will not need to wait up to 24 hours to see this change.
If you have any issues, suggestions or feedback regarding this change, then please let us know in the comments below. As always, if you have any suggestions for improvements going forward, we would love to hear them!
Some of you may be aware that at ThisWebHost we have implemented numerous security measures that are intended to try and help protect your accounts against some of the automated attack tools that exist on the Internet. One of the things we do here at this* is detect failed login attempts to accounts and services on our network and then, if too many failed login attempts are detected in a short period of time, we may block that IP address from trying again too quickly. This helps to prevent what are known as “brute force” attacks, where automated tools constantly try random username and password variations in order to try and guess the password(s) on your accounts. You can read more about these blocks and how the systems work here.
Unfortunately, from time to time, legitimate users may get caught up in these blocks and be blocked from access to their sites or services. Previously if a legitimate customer received too many temporary blocks and hit a permanent block, this block would need to be removed by contacting us and submitting the request via support ticket. Today, we have now added the ability for customers to remove their own blocks from within our client area.
Automatic Unblock when Logging In
The new system works two-fold. Firstly, when successfully logging in to our client area, the system will check if your IP address is blocked on any of the servers that you may have accounts on. If any blocks are found, they will be automatically removed – restoring access almost instantly.
Secondly, if you need to check or remove the IP address of a customer or client that is having problems with their service, you can do so from the ‘Unblock IP’ section in the client area:
Please be advised that for security reasons we have limited the number of unblocks to be 1 removal every 60 minutes. This tool is not intended to be a replacement for correcting login issues and password problems, but instead is meant to be a convenient way for customers to automatically restore access to their services should they accidentally become blocked.
Often we are asked by customers whether or not they need to purchase a new account in order to host an extra website or two. Depending on the type of hosting account you have with us, you may be surprised to hear that the answer is usually “no”. If you have our “Standard” or higher shared hosting plan, and have available disk space or bandwidth, you are able to utilise what are known as ‘Addon Domains’ to host multiple domain names under a single account.
What is an addon domain?
An addon domain is essentially an extra domain that is added on to your account and hosted under your main domain name. It is called an addon domain because it does not take the place of your main hosting account name, it is just an addition to it.
Addon domains allow you to host extra, or additional domains, under a single hosting account. There are, however, some restrictions which we will detail towards the end of this article.
How do I use/add an addon domain?
cPanel makes adding and managing your addon domains very simple. Simply login to cPanel and navigate to the ‘Addon Domains’ option:
Addon Domain Option
After clicking this option you will be presented with the following screen. Please note that we have pre-filled some of these options and will explain them below:
Addon Domain Screen
Please take a second to familiarise yourself with this page. The “New Domain Name” field is the name of the additional domain that you wish to add hosting to. If, for example, you have a second domain name called myseconddomain.tld and wish to use add hosting for it, you would enter that domain name here.
The “Subdomain or FTP Username” field will be automatically generated by cPanel based on the “New Domain Name” field that you enter. You can change this if you wish but we recommend leaving it as the default. This username will be used for you to access FTP only. It cannot and will not be used to login to cPanel (more details on this restriction in the article).
“Document Root” is the path on the server where the files for this domain name will be stored. Typically this is in a sub-folder within your main account, named after the domain name itself. We recommend leaving this as the default, but you may change it if you wish.
The “Password” is the password used for accessing this account via FTP.
After clicking ‘Add Domain’, please allow a few seconds for our servers to create the necessary entries for this account to become active. Once you have been presented with the success screen, the account is now ready to use. If your domain name is not pointing to our nameservers, this would be the ideal time to update them. After the nameservers have been changed to ours, and DNS has propagated, you can begin adding content to your site.
Are there any restrictions or limitations with addon domains?
Addon domains are intended to be used to host multiple domains under the same single account. Because of this, you do not receive a separate cPanel username and password to login to each addon domain. This is fine if your purpose is to host several of your own domains under a single account, but of course means that you cannot use addon domains to provide hosting to others and give them their own cPanel login details.
Another potential drawback to addon domains is that all of your addon domains exist under the same directory structure and exist within the same quota as the main account. Not only can this make navigating your directories more complicated (particularly if you have a lot of addon domains, because you will have a lot more directories to go through), it also means that you are far more likely to consume all of your disk space if it’s spread out across multiple websites. As long as you have enough disk space on your account, though, this should not be a concern.
Finally, it should be noted that addon domains cannot (currently) be converted to standalone separate accounts in the future if required. While this is possible by manually removing the addon domain, manually creating the new account, and then manually restoring the content that existed previously – there is currently no way to automatically do this.
Addon domains are a fantastic way to use your existing hosting account to host additional sites, without further expense, albeit with some limitations. For an average user though, this could be and often is a great way to save money and get the most out of your existing hosting account.
As of 1st January 2015, changes to EU tax law dictates that hosting providers worldwide, by law, need to charge VAT to consumers based within the EU.
To try and give you some background to the tax/VAT situation from our perspective; ThisWebHost is and has been a UK registered company for several years now. Traditionally within the UK, if your business meets a certain income threshold, you are required to charge a 20% tax (called VAT) on all services sold to consumers within the UK. We are still a relatively small company and fortunately for our UK customers, our UK sales did not meet this minimum income threshold, so we were not required to register for VAT or charge the necessary 20% tax. Most of our business is to US customers, and VAT is not applicable to them. Simply put; up until this year we did not charge tax to anyone because we didn’t have to.
Fast forward to January 1st of this year, and the laws have now changed. The law now says that regardless of your income threshold (more on this later), VAT must be charged to EU consumers at the VAT rate of the customers country. For example, currently in the Netherlands there is a 21% VAT rate. This means that as of January 1st 2015, we must charge an additional 21% tax on all services we provide to consumers within the Netherlands. This is not optional and we are required by law to do this. Within the EU there are many countries that charge VAT, and these rates differ from country to country. We are forced to comply with these new laws and charge the appropriate VAT rate to consumers within these countries.
Fortunately for consumers based within the UK, we still remain under the UK income VAT threshold for registration. This means that our UK consumers will currently not be charged VAT and will not have to pay the additional 20% tax. I cannot disclose exactly how much under this threshold we are, but it is likely to be a long time (years) before we are required to do so. Once we do meet this threshold, the 20% VAT will need to be charged in accordance with these new rules. Again, this is unlikely to happen for a very long time, but it is something to consider in the future.
To recap; as of January 1st 2015, all customers within the EU will be charged VAT at the rate of their country of residence on all invoices from us. Customers within the UK will not have to pay this tax.
Q. Does ThisWebHost have to do this because it is UK registered, or because the UK is within the EU?
No – it is irrelevant that we are registered within the UK. To clarify, all companies selling digital services to EU consumers must follow these new laws. Even companies based in the US must charge VAT to consumers based within the EU. There is no exception to this law, and it doesn’t matter where the company is based.
Q. I am a customer in the US, or outside of the EU – do I have to worry about this?
No, these changes do not affect you at all and you do not need to worry about this. This new change to the law only affects consumers based within the EU.
Q. I am a VAT registered business within the EU – do I need to pay this extra tax?
As a VAT registered business within the EU you will be exempt from this tax. In order to validate your exemption status, you need to provide us with your VAT registration number. You can do this from within our client area by clicking ‘Update your Details’ and entering your VAT registration number in the box at the bottom of the page. The page will check and validate your number, and if successful future invoices will be exempt from this VAT.
If you do not provide us with your VAT registration number, you will be required to pay tax on your invoices with us. There is no exception to this. If you are in fact VAT registered but do not provide us with your VAT registration number, you will be able to reclaim any VAT paid to us through your appropriate VAT return.
Q. I am a consumer based within the UK – do I have to pay this tax?
No. At this present time we are under the UK minimum income threshold and will not be charging consumers within the UK VAT.
Q. I am a consumer within the EU – do I have to pay this tax?
Unfortunately yes. All consumers within the EU (excluding those in the UK) must pay this tax. The tax will be charged at the VAT rate within your country and added to your next invoice(s) with us.
On a more personal note, we naturally disagree with these new laws and believe that they are significantly unfair to smaller businesses such as ours. Though we may disagree, we are of course legally obliged to follow them and ensure that we remain compliant at all times. We are deeply sorry that some of our EU consumers will see an approximate 20% increase to their hosting costs with us as a result of these new EU tax changes. Unfortunately, we simply cannot absorb this increase and must pass it on to our consumers.
It should be noted that this is certainly not a price increase and should not be interpreted as such. This new tax, though paid to us from our EU consumers, is paid back to your home country every quarter. We do not see a single penny of income from this tax, and on the contrary – through the increased administration and accountancy involved in record keeping for this new tax change, we are actually very likely to lose money as a result.
As always, if you have any questions, comments or concerns about this change, please feel free to discuss this blog post with us via the comments section below or through a support ticket within our client area.
Over the last couple of months you may have been aware of a change we made to our servers in order to globally protect all WordPress installations against brute force attacks. This change meant that just before accessing your WordPress login page, you were greeted with a popup asking you for a username and password. On a technical level this change worked brilliantly and we saw on average 1 million brute force attacks being prevented every day on each server. This is a huge number and was more than we expected. Unfortunately, and perhaps understandably, some of you expressed your disappointment with this change. We have now decided to revoke this implementation and it has now been removed from our shared servers. We shall instead be trying to inform users to secure their WordPress installations using plugins or other methods that they can manage on their own terms.
How do I secure my WordPress site against brute force attacks?
Wordpress have actually done a fantastic job of creating an article that details just this, but for convenience we shall go over a few of our favourite options that work on our servers in this blog post.
Because of shared hosting, some of the options on the WordPress page will not be available to you. Things like mod_security or securing the server itself are things that only we can control. Unfortunately, it’s not simply a case of making a few changes to the server and these attacks will go away. mod_security only works in specific situations where attacks are coming from a single IP address. In most cases, attacks do not, so these preventative measures do not work at all. Here are some essential tips we recommend for securing your WordPress installation on our servers that are sure to work.
Step 1. Change your administrator username.
Using the default username of “admin” may be convenient and easy to remember, but it’s also the most obvious one for attackers to guess. We strongly recommend that you change your username to something else, such as your first name. An easy way to change the username from ‘admin’ to something else is to use the following plugin.
Step 2. Use a strong and unique password.
This one is perhaps common sense, but you’d be surprised at how many users sacrifice security for convenience. Using the same password you use everywhere else may be convenient for you, but if one of these other sites is compromised, it makes it even easier to compromise your blog. We recommend using a new, random and unique password. If you only access your blog from a single device, we recommend looking at solutions such as LastPass which make it easy to generate random and unique passwords, but save them in a vault. There are even browser plugins available that will automatically enter your login details for you when you visit your site – saving you from having to remember such potentially complex passwords!
We are not affiliated with LastPass, but their premium version(s) also offers support for your mobile devices too.
Step 3. Rename your wp-login.php file and wp-admin folder.
This is a solution we recommend over Step 4 below, because it addresses the very source of the problem by preventing the attack from getting through to WordPress to begin with.
Brute force attacks are made against the wp-login.php file directly. If this file does not exist or has been renamed, and the attacker does not know the name of the file, then the attack will simply fail without being processed. Fortunately there’s a plugin available to make it very easy to rename this file and folder: http://wordpress.org/plugins/rename-wp-login/
Step 4. Install plugins to prevent brute force attacks.
There are many plugins available that can be used to protect your blog against brute force attacks. Our favourite of these is BruteProtect as it uses a centralised database to share IP addresses from detected attackers worldwide. This means that when a new attacker is detected, the IP address is shared with all other users of BruteProtect, preventing other blogs from being hit by the same attacker.
There are other plugins available (listed in the WordPress article at the start of this post) that can also provide quick and easy methods of blocking repeated attackers.
Important note: If you use a plugin that alerts you via e-mail when it blocks an attack, please be sure to disable these e-mails. The plugin may generate too many e-mails and cause our systems to block your website from sending out any further e-mails, which could cause problems for you.
Step 5. Enable WordPress automatic updates.
Wordpress is constantly being updated. New bugs and issues are being found and fixed all of the time. Some of these bugs are security vulnerabilities which could lead to your blog being compromised or hacked. It’s therefore critically important to keep your blog up to date and running the latest version at all times. Fortunately, with the later versions of WordPress, there is now an automatic background updater which will apply these fixes for you. To check and ensure this option is enabled, please see the following WordPress article.
If you have installed WordPress via Softaculous on our servers, you can also update it from within cPanel. You can find out how to upgrade your scripts in Softaculous by reading the following article.
If you are upgrading from a very old version of WordPress to the latest version, please be sure to check with your theme or theme developer that it will continue to work fine. Your theme may need to be updated to work correctly on the latest version.
Securing WordPress has become much easier over the last few years. Many plugins are now available to make the process as quick and as simple as possible, even for those with less technical knowledge than advanced WordPress users. This is, unfortunately, partly in response to the huge number of increased attacks being made against users of the software. Over time these plugins and systems will improve and this will likely become less of a problem.
It’s important to note that these attacks are, in almost every case, not directed at you and your blog personally. Your blog has simply been found in an automated search, and bots or other automated tools will indiscriminately attempt to guess your username and password. This is why the steps above will make this virtually impossible for them and significantly improve the security of your blog.
Performing the steps above are, of course, completely optional. That said, we very strongly recommend that you follow them, as increasing numbers of blogs are being compromised on a daily basis. It can take significantly longer to clean up and restore a compromised WordPress blog than it does to perform all of the steps above, so the time investment is certainly worth it.
Ever wonder what keeps our servers running and how we ensure that resources are fairly used and distributed between clients? Wonder no more. This blog post will attempt to explain the limits you see inside cPanel and what they mean to the average person.
What is CloudLinux?
CloudLinux is a special kernel distribution (or Operating System) we run on our servers which is designed to allow us to allocate certain amounts of resources to accounts. Like disk space and bandwidth, we can also restrict the amount of CPU power and RAM each account can use, as well as other resources. It is the ability to set limits on these resources that allow us to ensure that no one account can consume more than their fair share and cause problems for other users on our servers.
Before CloudLinux, it was possible that one or two very busy websites could bring down an entire server – causing problems for potentially hundreds of people or more! In these situations it was not uncommon for hosting companies to simply suspend the problem accounts until the situation was resolved and traffic decreased. Fortunately this is no longer something we have to be concerned about.
Interfacing with CloudLinux
cPanel CloudLinux Statistics
You may have noticed that when you login to cPanel there is a bar on the left hand side that contains lots of information about your account. Typically this shows you the amount of disk space you are using, as well as how much bandwidth you have used for that month so far and more. Some of these values belong specifically to CloudLinux and it’s these values we will look at in further detail.
The above is a screenshot taken from an account that has seen large traffic and user spikes on one of our servers recently. Because of CloudLinux and the limits we’ve imposed, the increased usage to this site has not impacted anyone else on the server. These values are taken in real-time and will change when refreshing cPanel.
This value represents how much of your allocated CPU resources you are currently using. The amount of CPU resources we provide to each account is a percentage of the servers resources. For example, we may provide up to 10% of the entire servers CPU resources to each account, depending on which type of package you have with us.
If this value reaches 100% then it means you are using all of the available CPU resources we have allocated to your account. It does not mean that the server is using 100% of its CPU usage. Once this value hits 100%, any additional processes that try to use the CPU are put to sleep and will have to wait until any previous processes have completed. This can cause your website to appear to slow down dramatically and may even time out in extreme cases.
Physical Memory Usage
This value represents how much memory (or RAM) your account is currently using. Every process created by your account will consume memory; so every PHP page that a user accesses, every mail connection you make and so on. Unlike CPU usage where we provide a percentage of the servers resources, we implement a fixed amount here.
If this value reaches 100%, or the advertised limit, you may begin to experience PHP errors (if applicable) on your website, or in very extreme cases may see a CloudLinux error page. These errors are typically only brief and once the usage has reduced to below the limit, will automatically clear.
Entry processes are the number of processes that enter your account. For example, every PHP page that is accessed by a user will usually generate a single entry process. Many people misinterpret this value as “number of visitors you can have on your website at once”. Whilst it is true that each visitor accessing a PHP page will spawn an entry process, these processes usually end so quickly that it is extremely unlikely that 10 will be spawned concurrently and at a single moment unless you had a significantly large number of simultaneous visitors on your website at once. SSH sessions and cron jobs also count towards entry processes.
If the limit for entry processes is met then further processes will be denied. If you are trying to access a PHP page you may receive a 508 (Resource Limit Reached) page.
Number Of Processes
This is very similar to the above but includes all processes generated by the account rather than the specific PHP, SSH or cron jobs. This number is typically very low, even under high activity, as non-PHP tasks execute and complete even more quickly.
This value represents how much I/O (or disk activity) your account is using. Any task which makes use of the servers disk drive (such as reading or writing to the server) will consume I/O. We limit the maximum disk speed of each account to ensure that no single account can saturate the disk drives which will reduce performance for everyone.
Reaching this limit will cause all processes to slow down (to within this limit) and take much longer to complete. Typically you won’t notice this setting ever increase unless you perform something disk intensive like generating a large backup on your account.
Every file and folder inside your account will count as 1 inode. We limit the maximum number of inodes to ensure that users try to use the best methods available for structuring their website content. The more files an account has, the longer it subsequently takes for our backups to run and this overall can impact performance of these tasks significantly.
If the inode limit is met, no further files or folders could be created on the account. This can actually be very serious and will result in the inability to receive e-mail and may even prevent your website from working if it needs to generate a cache or temporary files.
We hope that the above helps to explain what CloudLinux is, why we use it, and what the limits mean to you. Due to the nature of shared hosting, these limits are required to ensure that each user can use our services fairly without impacting others.
We have been using CloudLinux for many years now and are extremely happy with how it works to protect our customers, and maintain reliability and uptime of our servers. If you have any questions or comments about this article, please let us know in the comments section below!
The Industry Buzz section is divided into three major sections, which is then subdivided into smaller sections.
Corporate Blogs which include official blogs from web hosts, registrars, search engines and other related sites.
Magazines & Blogs include interesting websites related to the hosting industry, but not necessarily from official company blogs.
Industry Leaders include personal blogs from important industry leaders, such as employees from Google and WordPress. These blogs sometimes include insights on how industry leaders think, but also may contain topics not related to hosting.