Tony

They are not resolved and affect any host running Litespeed or using the event mpm in Apache. My guess it has something to do with how event driven web servers work. We're simply not capable of even having close to the same capacity we'd have non CloudLinux before we run into troubles with it. They don't figure they'll have time to dig deep into this until their next release of new features. After that they figure it might be several months before they are able to figure this out and solve it.

Microsoft has removed the block it'll take 24 - 48 hours to replicate through their system.

That Mirage block if you look at the date of it: "Mon Dec 11 11:25:30 2006" seems strange for a blocklist to have a listing from almost 4 years ago and it's for a generic rDNS. Well our rDNS isn't even generic they just haven't updated in 4 years. As for hotmail block we're looking into it we think they blocked at least a /24 maybe larger. The reason being we have servers with no mail even sent from them now blocked by hotmail. So something isn't right there.

cPanel does not support stored procedures right now via MySQL. I believe your main cPanel user may have access to do it but any other user you create will not. We'll be unable to add the permissions for other users as it adds an element of manual work which is something we avoid as it can lead to things breaking down the line for users as the panel is not aware of the changes we make.

If you wish to login to other accounts instead of doing it via the cPanel drop down I would use WHM. Then you go list accounts and there is a cpanel button for each account which logs you into them. Also this drop down obviously only exists when you are logged in as the reseller if you login to another account it does not exist.

You can run this software now. They require a minimum of PHP 5.2.4 and we're running PHP 5.2.14 which is 10 versions newer than their minimum requirement.

1. We do offer Paypal as an option which will take credit cards as well. As far as customers we have them all over the world so there is no real way for us to win in a situation like this. We suddenly cater to people in the US then people will want us to do the same for their country. It would increase our costs and thus our prices would go up to reflect that. 2. While it be nice it's not something I think it be wise for us to do from a business standpoint. Some banks charge this others do not and it varies by credit card as well. We'd lose potential customers as a result of a fee not assessed by us which may not even apply to the user. Also would confuse foreign customers who don't have such a fee or it's wrapped up in the exchange rate of their currency. So for us I don't think it be smart to scare away customers over this issue which does not apply to most people (I'm counting users from all countries) I don't think there is a good solution for us

This has been completed.

We will be updating the kernel on the Jedi VPS node to the latest version between 10:00pm and 2:00am EDT. The reason for this is for security reasons while we do use ksplice the age of the kernel and the time it takes to patch this system at this point makes sense to just update the kernel itself. Even if we had to patch the system the virtual machines on it would have had to be all taken off line in order to do the updates at this point. So we believe it would be wise to just do an actual kernel update. The maintenance window is for 4 hours but we estimate the down time will only be 5 minutes for the node and between 20 and 30 minutes for all virtual machines to be up and running again. Date: 09/21/2010 - 09/22/2010 Start time (EDT): 09/21/2010 10:00pm End time (EDT): 09/21/2010 2:00am Duration: 4 hours Estimated Down Time: 5-30 minutes

We will be updating the kernel on the Marlin VPS node to the latest version between 9:00pm and 1:00am CDT. The reason for this is for security reasons while we do use ksplice the age of the kernel and the time it takes to patch this system at this point makes sense to just update the kernel itself. Even if we had to patch the system the virtual machines on it would have had to be all taken off line in order to do the updates at this point. So we believe it would be wise to just do an actual kernel update. The maintenance window is for 4 hours but we estimate the down time will only be 5 minutes for the node and between 20 and 30 minutes for all virtual machines to be up and running again. Date: 09/21/2010 - 09/22/2010 Start time (CDT): 09/21/2010 9:00pm End time (CDT): 09/21/2010 1:00am Duration: 4 hours Estimated Down Time: 5-30 minutes

We will be updating the kernel on the Raptor VPS node to the latest version between 9:00pm and 1:00am CDT. The reason for this is for security reasons while we do use ksplice the age of the kernel and the time it takes to patch this system at this point makes sense to just update the kernel itself. Even if we had to patch the system the virtual machines on it would have had to be all taken off line in order to do the updates at this point. So we believe it would be wise to just do an actual kernel update. The maintenance window is for 4 hours but we estimate the down time will only be 5 minutes for the node and between 20 and 30 minutes for all virtual machines to be up and running again. Date: 09/21/2010 - 09/22/2010 Start time (CDT): 09/21/2010 9:00pm End time (CDT): 09/21/2010 1:00am Duration: 4 hours Estimated Down Time: 5-30 minutes

We will be updating the kernel on the Yoda VPS node to the latest version between 10:00pm and 2:00am EDT. The reason for this is for security reasons while we do use ksplice the age of the kernel and the time it takes to patch this system at this point makes sense to just update the kernel itself. Even if we had to patch the system the virtual machines on it would have had to be all taken off line in order to do the updates at this point. So we believe it would be wise to just do an actual kernel update. The maintenance window is for 4 hours but we estimate the down time will only be 5 minutes for the node and between 20 and 30 minutes for all virtual machines to be up and running again. Date: 09/21/2010 - 09/22/2010 Start time (EDT): 09/21/2010 10:00pm End time (EDT): 09/21/2010 2:00am Duration: 4 hours Estimated Down Time: 5-30 minutes

The warnings are suppose to happen at 95% and 99% as well. Not sure why you would not be getting them another case where at the very least we'd need to know what server you're on to check some settings.

The bandwidth usage is suppose to be updated every 4 hours on most machines. If it's not updating something is wrong. It is probably best to make a ticket so we can investigate. It might have to do with our mitigation methods for a recent exploit. As for when you exceed bandwidth all your sites would display an exceeded bandwidth notice.

The machine is fully back up now and serving pages at an optimal speed once again. We're sorry about any inconvenience the fsck may have caused but unfortunately was necessary.

The machine is online again just the services starting back up should be back to normal in a minute.

The fsck has completed the machine is now rebooting.

75% completed.

50% completed. It's moving along nicely

It is 25% complete thus far.

We are taking the Titan server offline to fsck the /home partition it is reporting as read only and we have reason to believe there is some file system corruption. The machine is offline as of right now at about 9:42 PM PDT and we hope it will be down no more than an hour. We will update this ticket when we have more information.

The raid cards backup battery unit on the Saturn server has failed. As a result we will be replacing it Thursday September 16th between 1am and 4am CDT. This will require us to take the machine off line to perform this window as a result there will be about 30 minutes of down time. This is a necessary maintenance as right now the server has disabled write caching which significantly reduces performance. The battery also protects the system from data loss in case of power failure. Date: 09/16/2010 Start time (CDT): 1:00am End time (CDT): 4:00am Estimated Down Time: 30 minutes

It will not be possible to do that the public_html needs to act as the document root of the primary domain. It think the best solution is to just modify the Joomla settings to reflect the change in paths. Every other solution just could lead to potential problems and best to just learn how to correct it if the path ever changes again.

We're noticing some file system issues on the Skyline server which we cannot resolve while the machine is online. We're going to reboot the machine at 9:42 pm CDT and it should hopefully only be off line for 10 minutes. We'll update this topic when we have more information.

You setup SPF and domain keys from the "Email Authentication" option in cPanel.