Tony

We have PHP 5.2, 5.3 and 5.4 and we're working on a solution to that where if an application in softaculous requires 5.2, 5.3 or 5.4 it will know and install and pick the right version for the account.

It's been started you should get an email when it's been completed Everything that has been moved thus far though is flying the wonders of solid state drive caching, more memory and newer CPU's, newer operating system among other things

Several servers including Lightning started producing a weird web server bug on situations when there were high amounts of randomized traffic. We put on mitigation steps to help us stop from producing it until we had supplied fix which we received today which we will be testing and hopefully deploying over the next 24 hours. Also have other exciting news for Lightning but you'll need to wait for the email on it

Hello, A lot of ISP's block port 25 which is the default SMTP port. You can get around this by using port 26 as we have that available as well.

This is some excellent advice. We see a lot of compromised accounts and lately it's been a lot of Joomla all running versions that are years old. We try to block a lot of malicious requests every day but mod_security only goes so far without preventing a lot of users from accessing their sites.

We're not sure when we'd expect to offer it. There are some issues with older versions of various pieces of software like Joomla that we need to determine the best way to tackle before we could realistically use it. If everyone kept up to date and ran the latest versions we would not have this problem unfortunately a lot do not. What we would probably end up doing is offering MySQL 5.5 on some newer systems then when the time is right upgrade everyone to 5.5 It's how we handled MySQL 5.0 to 5.1 and seems the best way to deal with 5.1 to 5.5.

I believe you're on a server which had some issues with a few PHP extensions for PHP 5.3 and 5.4. Once our system admins discovered the problem they corrected the issue and all the extensions should once again be loading without issue.

You can switch your account to using PHP 5.3 or PHP 5.4 using the following guides: PHP 5.3: https://support.hawkhost.com/index.php?/Knowledgebase/Article/View/107/12/how-do-i-use-php-53 PHP 5.4: https://support.hawkhost.com/index.php?/Knowledgebase/Article/View/125/12/how-do-i-use-php-54 It also can be accomplished by adding the following to your .htaccess file: PHP 5.3: AddType application/x-httpd-php53 php PHP 5.4: AddType application/x-httpd-php54 php

This is really confusing thats why I don't think you're getting much of a response from anyone. Are these suppose to be different web sites? Are they copies of the same website just different application? This might make things a bit more clear. It just seems confusing right now when you talk about copying files from one site to another making me think it's just different versions of the same site but I don't even know.

The server over the past few weeks has seen a substantial increase in attacks targeting it. As to why we're not sure but filtering has been very effective at minimizing impact. Unfortunately it seems in this most recent case filtering has been causing issues for some users.

Sounds like one of our security features is causing you some problems with drush. Open a ticket and ask it to be escalated we should be able to make it work for you.

I've looked up your account and all the tickets you've made we had already responded to. Do you have the ticket number of the ticket we did not respond to? If so please PM it to me.

We don't just rename a folder because we need to make sure the activity stops permanently and the user is aware of it. This guarantees a user is going to contact us about the serious offense on their account. No web host is going to allow spam on their network so we are not alone on our policies. We can gladly attempt to help you by scanning for malicious files on the account. Unfortunately though the best action is to upload new files as our virus scanner like any other is not perfect and can miss stuff. All it takes is one backdoor left in and you'll be compromised again. Now all of this might seem unfriendly to you but if it was another customer sending spam or phishing or anything else. You wouldn't expect us to leave their sites online you'd want them shutdown so they're not blacklisting the server you're on or our entire network. If it's phishing content then having our IP's null routed or worse having hardware confiscated in a law enforcement investigation. Any web host based in North America or really any location besides few select locations will have similar policies regarding these sorts of activities and the question action to shut them down.

Load average is measure of processes in queue it does directly correlated to the available CPU on a system. For example I'm logged into the system you're on it reports a load average is reporting as 10 with 50% of the CPU idle. If it was a direct correlation then this system would supposedly have 20 CPU's not the 16 it actually has. This used to be a pretty good indicator because there was very few reasons processes would be waiting in queue. This is no longer the case with using CloudLinux for example if a user is being CPU limited on old kernels if 5 processes of a single user were limited it would +5 the load average. Newer kernels of CloudLinux it instead will only +1 meaning if we had 20 users being CPU limited it would have a load average of 20 even if there was a lot of available CPU. The system you're on is running an older kernel with KSplice updates it may still have the older load average calculations as well. Basically load average while can be an indicator it should not be the final word. If your sites are fast no matter the load average there is nothing to worry about.

We run Litespeed which runs something similar to php-fpm when serving PHP.

Hello, For something like that I would advise opening a support ticket so our support staff can look up your account.

Hello, For something like that I would advise opening a support ticket so our support staff can look up your account.

The file system check completed and the system is back online

On Wednesday November 21st starting at 9am pst we will be taking the sjc003 server down to run a file system check on one of the partitions the operating system is reporting to have issues. This is necessary maintenance as otherwise the problem could result in an unplanned outage and potential data loss if it's a file system check is not done within a reasonable timeframe. We've set aside a window of 3 hours meaning the window ends at 12pm pst. We estimate the actual file system check will take about an hour and a half to be completed. We scheduled the window based on the usage patterns of this system where during this window it sees significantly less traffic than the rest of the day. Date: 11/20/2012 Start time (PST): 9:00am End time (PST): 12:00pm Duration: 3 hours Estimated Down Time: 120 minutes

All memory has been replaced and all virtual machines are back online.

The server has just been taken offline to replace the memory on the system.

The Raptor server has had several sticks of memory fail that need to be replaced. We have scheduled this to be replaced Sunday November 18th between 1am CST and 4am CST. This is necessary maintenance as the server is currently not running with an optimal amount of memory. We estimate that the server will be down for about 45 minutes while all the server memory is replaced. Date: 11/18/2012 Start time (CST): 1:00am End time (CST): 4:00pm Duration: 3 hours Estimated Down Time: 45 minutes

All virtual machines are now back online. We will be scheduling a window to replace failed memory modules which we believe caused the issues and as a result currently the system has less memory available than it typically does.

The system is back online and virtual machines are starting back up

At approximately 7:15pm CST system administrators were informed by monitoring to file system problems with the Raptor VPS node. Upon attempting to login to the system it became apparent that a fsck would be necessary to repair file system inconsistencies. We've taken the server offline and we expect the fsck to take no longer than 2 hours to complete. This information was also posted on http://www.hawkhoststatus.com/services/raptor