Dear Valued Customer,

We’re writing to inform you of an important change in your server’s default configuration that may affect your websites, including those of any of your resold accounts. We will be updating the default version of PHP on LINUXWALA servers

We have attempted to automatically check the compatibility of your accounts. Please bear in mind that you may circumvent any of these results by manually configuring your desired PHP version utilizing the instructions in this email’s FAQ section

FAQ:

1) Why are you making this change?

The default version of PHP that our servers are currently utilizing (PHP 5.2) has been deprecated for some time. As such, we would like to see your sites enjoying the security and performance benefits of the newer versions of PHP which we already have available on your server.

2) How can I make sure my sites will work?

While we are taking every possible step to try and automatically assign the right version to all of your scripts, we do want to ask you to please login into your cPanel and test all of your sites using PHP 5.4 yourself.

The default behavior of your account is for PHP settings to be inherited by sub-directories. That means that you can quickly test all of your site’s compatibility with PHP 5.4, by setting the PHP handler of your home directory (public_html) to PHP 5.4. Then simply test your websites by opening them in your browser. We have added an easy to use plugin to configure your PHP version to your cPanel, follow these steps to use it:

* Login to your cPanel

* From the home page locate the “Advanced” box and click on “PHP Configuration.”

* Select “PHP 5.4” from the drop-down menu and leave the default directory, click “Update” to submit the changes.

* You should see a confirmation message that reads: The “.php” file extension will be processed by PHP 54 for this account.

* You may now visit your websites and check for any issues or visible errors. If your sites function normally it means your sites are compatible with PHP 5.4 and you will not need to perform any other steps from this point.

* Alternatively, If you do notice issues with your sites while using PHP 5.4, you can revert to PHP 5.2 by follow the above provided steps and choosing PHP 52 from the menu. Our upgrade process is set to honor the handler settings you choose.

Please Note: Selecting “No Custom Handler (Sys Default)” means you’re electing to utilize whichever version of PHP the server is set to use. While PHP 5.2 is currently the system default version, once the upgrade is complete, the default version will be PHP 5.4. Thusly, if your applications require PHP 5.2, you will want to make sure to specifically select the “PHP 5.2” option.

3) Will my site’s experience any down time?

The switch between PHP versions is a simple text change in your .htaccess file. There is no maintenance which must be performed on the server itself. However, applications that are not compatible with PHP 5.4 will fail to load properly if they have not had the correct version of PHP set. While we will make every effort to automatically perform compatibility checks for each account and set the appropriate handler, it is imperative for you to double-check compatibility.

4) Who can help me update my site/script to use a newer version of PHP?

While we can assist you with changing the version of PHP your script utilizes, we will not be able to recode your site to be compatible with newer versions of PHP. You should contact the script’s author/developer to inquire as to whether or not they can or plan to re-design their code to utilize latest versions of PHP.

Here is a broad time line and summary for this outage:

At around 8:30 GMT on April 24thwe detected that one of the storage units which serves part of our email infrastructure became non-operational causing email services for a subset of our customers to not function.
We immediately started a process of restoring access to this storage unit and our engineers worked dedicatedly over the next few hours to restore functionality to affected email accounts.
As of 17:00 GMT on April 24th access to all email accounts affected by this issue was restored. All affected accounts were at that time able send and receive email via webmail and through external clients.
Emails that were queued up during this outage were relayed to individual email accounts after email services were restored and should be working without pause at this time.
As of this update, we are still working to restore this storage unit to a fully operational state. This process is taking longer than we originally anticipated. We currently have some of the best storage unit experts in the industry working round the clock to bring the unit back online. We are currently being advised that this process can take several days to complete.

What is the current impact? Is there still something which is still non-functional?

Customers that were affected by this downtime are currently unable to view emails received prior to this outage, specifically, those emails that were stored on the storage unit that suffered the outage and were being accessed either via webmail or IMAP. If you were however downloading your emails to a local email client such as Outlook or Thunderbird using the POP protocol – then there is no further impact to your service due to this issue.

When will you fix this issue? What can I expect in the interim?

Our goal is to restore access to your stored emails as soon as possible and we are sparing no effort towards this. We care deeply about ensuring that you have best-in-class services and we apologize deeply for the inconvenience caused to you by this outage. We are now being advised that bringing up the affected storage unit is, unfortunately, not a matter of hours but of days. In the interim we will endeavor to keep you updated as best we can with any and all meaningful updates because we do care about getting you back up and running fully. As much as it pains us, we cannot offer a concrete ETA at this time but will continue to update you regularly.

What happened? Can you explain in detail what really went wrong?

One of the storage units that stores email for a subset of our customers went offline as a result of set of pre-planned activities we were working on to bring a new storage cluster online. We build our systems with multiple layers of fail-safes and safeguards, and we are still in the process of doing a post-mortem on what we could have done better to prevent this from happening. We promise you a full account of this when we complete this investigation along with a detailed summary of steps we will take to prevent a similar event in the future as soon as we complete this analysis.

What can I do if you have additional questions?

While we realize you will still have questions, we hope this post adds to your understanding of this outage. We promise to be here to work with you and provide transparent & meaningful updates as soon as we are able. This post will be the primary medium of communication with you and as such we are directing our contact center agents to refer you to here so we can have clear and consistent communication with you. However, we will continue to be available on our regular support channels in case you require any additional assistance during this time.

Thank you for continued patience and support.

What is the Heartbleed bug?
Heartbleed is a flaw in OpenSSL, the open-source encryption standard used by the majority of sites on the web that need to transmit data users want to keep secure. It basically gives you a “secure line” when you’re sending an email or chatting on IM.
Encryption works by making it so that data being sent looks like nonsense to anyone but the the intended recipient.
Occasionally, one computer might want to check that there’s still a computer at the end of its secure connection, so it will send out what’s known as a “heartbeat,” a small packet of data that asks for a response.
Due to a programming error in the implementation of OpenSSL, the researchers found that it was possible to send a well-disguised packet of data that looked like one of these heartbeats to trick the computer at the other end of a connection into sending over data stored in its memory.

How bad is that?
It’s really bad. Web servers can keep a lot of information in their active memory, including user names, passwords, and even the content that user have uploaded to a service. But worse even than that, the flaw has made it possible for hackers to steal encryption keys, the codes used to turn gibberish encrypted data into readable information.

With encryption keys, hackers can intercept encrypted data moving to and from a site’s servers and read it without establishing a secure connection. This means that unless the companies running vulnerable servers change their keys, even future traffic will be susceptible.

Steps that we are taking:
• We have updated the OpenSSL packages installed on all our shared hosting servers
• At 05:30 hrs (GMT) on 11 Apr, 2014 Orderbox will force-terminate all active logged in sessions to prevent abuse by any hackers who may have exploited this bug.

• At this time, Orderbox may experience a disturbance of upto 5 minutes and no orders on Supersite or API will be processed. You will be required you to login again to your Control Panel to continue managing your account

Steps that you have to take:
1. The Heartbleed bug makes it practically impossible to detect history of abuse, but to be on the safer side, we strongly recommend that you change your DOMAIN and HOSTING Account passwords.

2. If you have WHM access on the hosting packages that you resell through us, you can use the force password reset option in WHM to ensure that all your hosting customers change their passwords

ADMIN