Tony

We will be updating the Mars server kernel to the latest version on Wednesday August 26th at 12:00am CDT. We estimate this will result in about 10 minutes of down time while the server reboots. Keeping kernels up to data is a necessary step in order to stay on top of performance improvements as well as have the latest security fixes. In this case there have been some security vulnerabilities which we have taken steps to mitigate but now with an official kernel released for CentOS we can run a version that is patched. We feel it's best to have this done as soon as possible which is why there is only 24 hour notice. Date: 08/26/2009 Start time (CDT): 12:00am End time (CDT): 12:20am Duration: 20 minutes Estimated Down Time: 10 minutes

We will be updating the Skyline server kernel to the latest version on Tuesday August 25th at 11:40pm CDT. We estimate this will result in about 10 minutes of down time while the server reboots. Keeping kernels up to data is a necessary step in order to stay on top of performance improvements as well as have the latest security fixes. In this case there have been some security vulnerabilities which we have taken steps to mitigate but now with an official kernel released for CentOS we can run a version that is patched. We feel it's best to have this done as soon as possible which is why there is only 24 hour notice. Date: 08/25/2009 Start time (CDT): 11:40pm End time (CDT): 12:00am Duration: 20 minutes Estimated Down Time: 10 minutes

We will be updating the Saturn server kernel to the latest version on Tuesday August 25th at 11:20pm CDT. We estimate this will result in about 10 minutes of down time while the server reboots. Keeping kernels up to data is a necessary step in order to stay on top of performance improvements as well as have the latest security fixes. In this case there have been some security vulnerabilities which we have taken steps to mitigate but now with an official kernel released for CentOS we can run a version that is patched. We feel it's best to have this done as soon as possible which is why there is only 24 hour notice. Date: 08/25/2009 Start time (CDT): 11:20pm End time (CDT): 11:40pm Duration: 20 minutes Estimated Down Time: 10 minutes

We will be updating the Neptune server kernel to the latest version on Tuesday August 25th at 11:40pm EDT. We estimate this will result in about 10 minutes of down time while the server reboots. Keeping kernels up to data is a necessary step in order to stay on top of performance improvements as well as have the latest security fixes. In this case there have been some security vulnerabilities which we have taken steps to mitigate but now with an official kernel released for CentOS we can run a version that is patched. We feel it's best to have this done as soon as possible which is why there is only 24 hour notice. Date: 08/25/2009 Start time (EDT): 11:40pm End time (EDT): 12:00am Duration: 20 minutes Estimated Down Time: 10 minutes

We will be updating the Jupiter server kernel to the latest version on Tuesday August 25th at 11:20pm EDT. We estimate this will result in about 10 minutes of down time while the server reboots. Keeping kernels up to data is a necessary step in order to stay on top of performance improvements as well as have the latest security fixes. In this case there have been some security vulnerabilities which we have taken steps to mitigate but now with an official kernel released for CentOS we can run a version that is patched. We feel it's best to have this done as soon as possible which is why there is only 24 hour notice. Date: 08/25/2009 Start time (EDT): 11:20pm End time (EDT): 11:40pm Duration: 20 minutes Estimated Down Time: 10 minutes

We will be updating the Venus server kernel to the latest version on Tuesday August 25th at 11:00pm EDT. We estimate this will result in about 10 minutes of down time while the server reboots. Keeping kernels up to data is a necessary step in order to stay on top of performance improvements as well as have the latest security fixes. In this case there have been some security vulnerabilities which we have taken steps to mitigate but now with an official kernel released for CentOS we can run a version that is patched. We feel it's best to have this done as soon as possible which is why there is only 24 hour notice. Date: 08/25/2009 Start time (EDT): 11:00pm End time (EDT): 11:20pm Duration: 20 minutes Estimated Down Time: 10 minutes

You should make a support ticket we need to see this for ourselves and without an account that is having this problem it's difficult to help in any way.

The safest solution is one where you are not accepting the cards directly on your web site. So Paypal or 2checkout are options for this. Otherwise it's a lot more work and you need to worry a lot about the security of your site for accepting the credit cards. For very few charges it's just not worth it. We accept them because we have a lot of transactions via CC and people prefer automatic charges so the others are not options.

Scrambled in what way? As in they do not work at all or are they just unreadable?

http://myserver.com/webmail then it should redirect to https://serverhostname:2096/ . It does the servers host name because it has a SSL certificate so no warnings about being self signed.

You do not use horde to do it but cPanel. The feature you're talking about is auto responder and it's an under the email portion of cPanel.

The machine is rebooting now. We were able to repair all files except a single one on the partition. Everything should be back up in no more then 10 minutes.

The system is currently attempting to fix the file system issues. We needed to delve a little deeper in order to get it to fix the issues.

I think everyone has covered everything. You can change name servers to ours rather than moving the registration. You can upload files before hand by using the IP to connect rather than ftp.yourdomain.com.

The minimum payout is $100 and we can do paypal or check. In the case of check we'll be converting it to CAD and sending it in that currency rather than USD.

The new drive has been rebuilt and the machine is once again fully operational.

The drive has been replaced with a new one and is now rebuilding.

We're replacing the missing drive as it's there but just not functioning.

The rebuild finished without issue.

The server is now back online and is picking up the new drive and is rebuilding it. The performance of the machine appears to be much better even while rebuilding. It is no longer struggling with i/o like before when the old drive failed.

Machine has just gone off line to replace the raid card.

We replaced the hard drive and the raid card is not picking up the new drive so we have reason to believe that there is something wrong with the raid card. Most likely the port has gone bad. As a result of this we're going to need to take the server off line to replace the card. Unfortunately the server will be down for up to 20 minutes but we have no choice in this matter has running the server on a degraded raid causes performance problems as well as risk user data. So to summarize raid card port is bad we will be taking the server off line as soon as possible to replace the raid card.

This morning we were alerted by the raid card that one of Jupiter's hard drives had failed and that it'll need replaced. We are going to do this as soon as possible to avoid any data loss in case another drive fails. There will be no down time required as this server supports swapping drives while the system is active. Date: 08/12/2009 Start time (EST): ASAP End time (EST): ? Duration: 30 minutes Estimated Down Time: none

LiteSpeed supports SSI fine assuming your file is .shtml.

Old topic but I want to add one thing to this. If you get a 403 on a url blocked by mod_security you can also disable it yourself. Just add the following to your .htaccess file where the script is: SecFilterEngine Off SecFilterScanPOST Off