Tony

Have you setup SPF and domain key records? If you have not you should do that via cPanel. Besides that though there is nothing we can do to help with this as these filters it's content based which you can only fix by changing the templates of the emails to look less generic and more unique.

This has been completed.

On Friday September 10th between 9am and 12pm CDT the Bosco server will be having some maintenance done on the raid of this system. Unfortunately at some point during the window the server will be taken off line in order to upgrade the raid card firmware as well as replace the cables on the card. The reason for this is we've seen an abnormal amount of drives failing or having an abnormal amount of errors. As a result of this during the window there will be a time frame when backups will not be available to be restored from. Date: 09/10/2010 Start time (CDT): 9:00am End time (CDT): 12:00pm Estimated Down Time: None

We've once again filtered everything. Hopefully it should stay up this time and their attacks continue to be ineffective.

It appears to be back and we're once again attempting to mitigate it.

The attack has been mitigate and service has been restored.

The Titan server is currently (8/30/2010 ~ 3:57 pm PDT) experiencing intermittent public network outages due to what appears to be a very large distributed denial of service attack. We are already working with networking on filtering this attack and we will post more information as we receive it from them.

We do daily backups and they are kept for 7 days.

Not a clue but I doubt it can be any worse then some of the wordpress blogs we run into. Wordpress blogs with 50+ plugins and all that jazz. So if you want to use it go nuts if we have an issue with your resources you'll be contacted. Though I doubt it be the case unless you're getting a ton of traffic.

a) It's going to be greater than the amount possible to use. We've always limited the number of PHP processes you can generate so it will not be possible to go over the memory limit which would probably be in the generous 768MB+ range Right now I/O limiting is not supported so no limit there c) Our control panel says 500,000 which I don't think a single user is even remotely close to that amount. It's not controlled by CloudLinux either so you could go over it we just added the display to the control panel since users have been asking for one.

3) It is limited per cPanel account 4) It does not even inform us how it works is it restricts the amount of CPU one can use in real time. So here's an example: You can max 100% (1 CPU) You launch one process you attempt to use 100% CPU it allows you. You launch another and now it splits the CPU between the two so each is 50% You launch two more processes for a total of four you're now using 25% per process. So basically you become capped the more CPU you attempt to use the slower all your processes will become. So if you launched 10 processes trying to use 100% CPU each process would only get 10% as your total account is capped at 100% Do that clear up how it works now? It basically works the same way Xen, OpenVZ etc. work where you're capped on CPU. Those you had your own operating system but in this case you're still part of the main system just your processes that we choose to put into it's light weight virtual environment are limited by what we set the maximum resources to be.

Their docs say 128M: http://php.net/manual/en/ini.core.php but it may be for 5.3 not really sure. We set it specifically to 128MB in the php.ini file though so their default values do not matter.

Our servers use a PHP memory_limit of 128MB by default which is the default value starting at some point during PHP 5.2 if my memory serves me right.

1) It is limited per cPanel account as it's limited at the linux user level. 2) There is no notification via email or anything like that. There is integration in cpanel however which will show the real time usage. The usage levels we're going to be setting on a per account basis right now is going to be really high. It's not going to be reflective of what a user could actually expect if everyone used the resources. It's just where we believe after that point there is going to be some serious problems. So it'll be around 1 CPU which very few people attempt to utilize right now but those few cause the majority of our problems like I said.

More things coming down the pipeline. With CloudLinux deployment starting this week as each server gets CloudLinux installed you'll see this appear in the cPanel: No Usage: Some Usage: The CPU, Memory and I/O data is pulled directly from CloudLinux. it is AJAX powered so it will not slow down a page and it looks exactly like the other cPanel features. The reason it is AJAX powered is it takes about 5 seconds to generate the percentage report. Decided to add inodes as well since right now it's sort of like this unwritten rule don't go over this amount. So we decided why not put an actual number to it and put it in cPanel as well. People have asked about it in the past so we easy enough to add. Also the limits right now are up in the air and they're percentage of the machine. We left default values there when testing and building out the new features into cPanel

Yep they can be deleted they're just used for frontpage extensions and if you're not using frontpage the folders are not necessary.

It's not really a suggestion considering we're going to be using it but I figured I'd make a post. With us becoming more popular the number of people who abuse our services is growing with that. So we needed a better solution as having technicians disabling accounts and sending out emails was a time consuming process. Users were also at random causing service degradation which is difficult to stop. So basically it will allow us to do is limit users CPU automatically and this will reduce the amount of time technicians are dealing with issues. Basically for the users who abuse resources they're going to get a slow web site while the good majority of users will operate like there is nothing happening. Which is how it should be it is far more fair if the guy who loads up 100 wordpress plugins and has 25 second load times for pages they should not be slowing down your site. They should be slowing down strictly their web site. You can apply this to many other cases so attacks, looped scripts, exploited scripts etc. All cases where technicians acted they should no longer have to do that in most cases. So some links: http://cloudlinux.co...tions/overview/ We've been running it on Frog Host for almost 2 weeks now which is a production environment. We were testing it even before then to see exactly what would happen. So here's a great example of our testing we loaded up a wordpress blog just vanilla install made a single post. We decided to replicate a huge amount of traffic by having 500 concurrent users visit this blog. We loaded CloudLinux up on our little Opteron 170 test server and had a brand new not fully deployed Dual Xeon 5620 system. We ran the test on the cloudlinux server and that web site slowed down however SSH and everything was still responsive such as SSH, cPanel etc. as the PHP processes only got a few percentage points of CPU. We ran the same test on a machine with 16 visible CPU's to the OS vs 2 on the Opteron and it was slowing down this machine as each process was able to take as much CPU as it liked. It's not a great test obviously but gives you an idea on just how effective it can be with a lot of situations. I have no doubt some users may end up with slower sites as a result. A small minority who are attempting to use more than their fair share of resources. So they have their wordpress blog with 100mb error_log file full of problems and lots of max execution time errors. Though the person with a properly optimized site so in wordpress using caching and what not their site will remain just as fast as before. So basically it's just going to encourage people to optimize their sites or look to a VPS or dedicated where they could attempt to use up entire CPU's for extended periods of time. Now for a deployment time well for now it's deploying on Mustang and Spitfire next week. Then the week after it'll show up on the rest of our shared hosting boxes assuming everything goes as well as it did in our testing. That week we'll also deploy it on our first few reseller / mixed servers to make sure in that environment it works the same. Then finally the week after that it'll be deployed on all machines. Feel free to post your comments and concerns here

On Thursday August 26th between 8am and 11am CDT we will be switching the Mustang server to CloudLinux. The window is for 3 hours however we estimate there will only be about 10 minutes of downtime while we reboot the server in order to load the CloudLinux kernel. CloudLinux will allow for us to better control resources being utilized by users as well as to better track the usage. This should result in an even more stable environment where single users will be unable to cause service degradation in most situations where typically a technician would be required to intervene to stop any service degradation a user may be causing. With this change a user who is using an abnormal amount of resources will see strictly their website slow down rather than the entire server slowing down. If you have any questions about this maintenance window do not hesitate to contact support. Date: 08/26/2010 Start time (CDT): 8:00am End time (CDT): 11:00am Estimated Down Time: 10 minutes Duration: 3 hours

On Tuesday August 24th between 6am and 9am PDT we will be switching the Spitfire server to CloudLinux. The window is for 3 hours however we estimate there will only be about 10 minutes of downtime while we reboot the server in order to load the CloudLinux kernel. CloudLinux will allow for us to better control resources being utilized by users as well as to better track the usage. This should result in an even more stable environment where single users will be unable to cause service degradation in most situations where typically a technician would be required to intervene to stop any service degradation a user may be causing. With this change a user who is using an abnormal amount of resources will see strictly their website slow down rather than the entire server slowing down. If you have any questions about this maintenance window do not hesitate to contact support. Date: 08/24/2010 Start time (PDT): 6:00am End time (PDT): 9:00am Estimated Down Time: 10 minutes Duration: 3 hours

You can use http://webmail.yourdomain.com replacing yourdomain.com with whatever the domain is of the email account. Keep in mind this is not over SSL so it's not as secure as the normal way of accessing webmail.

Resellers are given their own IP's we do not assign them to other IP's shared with any other user. The reason being it helps separate them and if a reseller comes under attack then only their sites may go down not sites from various resellers. The IP you're assigned should be listed on the left menu of cPanel not WHM. Also under list accounts the IP listed for any sites created is your Ip. If you're still having trouble finding it make a support ticket and we'll be able to tell you. You can order additional IP's by contacting sales if you ever need more.

When we were smaller we could not afford to having separate servers for each type of service. So we have machines where reseller and shared web hosting is going on. We would not want our resellers having our skin and plugins specific to hawk host showing up on their customers control panels. The machines that have the new skin have *.hawkhost.com hostnames. Most likely all shared web hosting customers will see the skin when the day comes that we're able to somehow split the machines. I just don't know when that would happen as it would need to make sense for us financially. There is also complications with our legacy servers in Dallas where the VLAN we're on provided problems for us when we upgraded machines last time. As I said though any features would show up on the servers. So if we added say CPU usage data to *.hawkhost.com servers it would also be added to all machines not strictly *.hawkhost.com. It would be strictly cosmetic changes specific to hawkhost that could not be added.

The person who is actually paying should be the one signing up for the hosting. We will not accept a credit card from someone which is in another persons name.

It is not available on all servers and some servers unfortunately may never see our branded skin but instead only the features we add.

I think this is pretty sound advice the ftp server has given you. The computer is your friend and you should trust it. Seriously though it's an easter egg in pureftpd.