Tony

On Saturday February 20th we will be upgrading the Skyline server to the latest version of cPanel 11.25. We anticipate this upgrade taking no longer than an hour however with us doing many machines we cannot give a concrete time when each server will be done. We do not anticipate any service interruptions during this time. cPanel may be slower than usual when the upgrading is being performed though. cPanel 11.25 brings many great new features and has reached stable and has been tested by us in a production environment on a limited number of servers. If you have any questions about this maintenance window do not hesitate to contact us. Date: 02/20/2010 Duration: 24 hours Estimated Down Time: None

On Saturday February 20th we will be upgrading the Saturn server to the latest version of cPanel 11.25. We anticipate this upgrade taking no longer than an hour however with us doing many machines we cannot give a concrete time when each server will be done. We do not anticipate any service interruptions during this time. cPanel may be slower than usual when the upgrading is being performed though. cPanel 11.25 brings many great new features and has reached stable and has been tested by us in a production environment on a limited number of servers. If you have any questions about this maintenance window do not hesitate to contact us. Date: 02/20/2010 Duration: 24 hours Estimated Down Time: None

On Saturday February 20th we will be upgrading the Neptune server to the latest version of cPanel 11.25. We anticipate this upgrade taking no longer than an hour however with us doing many machines we cannot give a concrete time when each server will be done. We do not anticipate any service interruptions during this time. cPanel may be slower than usual when the upgrading is being performed though. cPanel 11.25 brings many great new features and has reached stable and has been tested by us in a production environment on a limited number of servers. If you have any questions about this maintenance window do not hesitate to contact us. Date: 02/20/2010 Duration: 24 hours Estimated Down Time: None

On Saturday February 20th we will be upgrading the Jupiter server to the latest version of cPanel which is 11.25. We anticipate this upgrade taking no longer than an hour however with us doing many machines we cannot give a concrete time when each server will be done. We do not anticipate any service interruptions during this time. cPanel may be slower than usual when the upgrading is being performed though. cPanel 11.25 brings many great new features and has reached stable and has been tested by us in a production environment on a limited number of servers. If you have any questions about this maintenance window do not hesitate to contact us. Date: 02/20/2010 Duration: 24 hours Estimated Down Time: None

Can you better explain the issue? Like is it giving some sort of error or what exactly is happening that it does not work?

Our order form does confirm what products are on an order on step 4 confirm order. Unfortunately a lot of users just click next -> next -> next they don't even notice they added the same package 5 times or whatever. As far as cancellations we'll never do automated immediately we like to review them. The reason being users have in the past but immediately when they meant something else. Or they did something and if we actually processed it they'd be out of a hosting account.

This has been completed.

The maximum we allow is 128mb and you cannot change this. If you require more than this you might want to look at why your script is doing that. It's not normal to require say 500mb for a PHP process that kind of use suggests a dedicated server. Even on a server with 12GB of ram you're talking about wanting to use over 4% of the servers total memory with one php process!

Small things Skyline has a 5450 CPU's and Mars has 5520's and 5520's have hyper threading which is why it shows up as 16 cpu's. It only has 8 real CPU's.

1) http://yourdomain.com/cpanel replacing yourdomain.com with your actual domain. You do not need to use our client area to get to cPanel. 2) Looks like neptune did not have the hostname set I fixed that 3) Unfortunately not possible as we tried doing this before and did not work well. Far to many users seem to like to use different email address contacts or usernames depending on what they're doing.

You cannot increase the timeout limit on your end and we will not increase it. Increasing it also makes the server much more susceptible to denial of service attacks. So how you avoid this error is find out why your script is not sending any output to the client. I would check the error_log file wherever the PHP script is executing. It should provide insight as to what is happening.

Date: Wednesday, February 16th, 2010 (02/16/2010) Start time: 01:00 AM PST End time: 07:00 AM PST Duration: 6 hours Service Affected: Public Network, Private Network Reason: Device Migration Device: ts01.sr01.sea01, ts01.eq01.sea01 Location: sea01 ================================================== Datacenter Engineers will be conducting maintenance on the transport gear that provides connectivity from the Seattle, WA server facility to the Seattle, WA Westin Building facility. During this maintenance window, traffic on the following providers will be gracefully shifted off to other providers followed by BGP sessions being shut down: 10G Level 3 Transit 10G Global Crossing Transit 10G NTT/Verio Transit 1G Google Peering 10G Comcast Peering 10G SIX Peering Fabric 10G Time Warner Peering 10G Internal Public/Private Peering to WDC01 10G Internal Public/Private Peering to DAL01 After these sessions have been shutdown, Datacenter Engineers will migrate the transport network to new equipment. During this maintenance window, customer traffic destined for either DAL01 or WDC01 will be rerouted either over the public internet or through other paths for private network connectivity. Datacenter Engineers expect no impact to customers as traffic will be shifted prior to the event. Customers may notice some routing anomalies during the process as routes re-converge initially. Once completed and circuits verified, BGP sessions will be restored and service will return to normal. Again, Datacenter Engineers expect no impact to customer services once traffic has been shifted during this maintenance window. ==================================================

Increasing the timeout limit in this case will not fix it trust me on this 120 seconds and not a single piece of data was sent to the client. This is why you get the 408 connection timeout. We typically see this when you're connecting to some external service on the page and it's not connecting. So maybe it's like this for example Connect wordpress.com Rest of page It sits there hanging on wordpress.com you'd get a 408 timeout because the rest of the execution would not happen. I would check your error logs it usually provides clues to this. The fact it worked before doesn't mean much we've had users connecting to a service for a year and ignored a notice about a change of url and it broke. Or they did something and they got blocked by the service. I hate the idea that somehow because it worked at one time it must be us and it's not a script error or something like that.

Usually this happens when your PHP script is connecting to some external service and it's just sitting there unable to connection which then causes a 408 connection timeout on the webserver. So you cannot increase the connection timeout and doing so does not even make sense since a page taking 120 seconds to load or whatever is excessive anyways.

This will be changing but the current logo on our website:

Transparent image 800x600 :-)

I can do better I just need to upload them give me a minute. We've always had our original PSD's but I just found the final versions which included png's rendered out so no need for photoshop.

No PHP code requires op code caching. That includes frameworks and and popular PHP scrips. Here's how PHP works PHP loads -> Parses Source -> Compiles -> Executes Here's what the op code cachers do: PHP Loads -> Checks mtime -> Checks compiled source memory -> Checks compiled source file system -> Executes So what it does is avoids the parsing and compiling of the PHP code. It's attempting to remove middleman steps. It works really well when you have a single pool of PHP processes on top of control of your applications. We have neither of those as we run PHP as the user and we are relying on other users. Here's how our system works: HTTP Request -> PHP Request -> Checks PHP Processes for User -> If None Create One -> Execute PHP using Process Avaiable So for an OP code cacher to even work we're talking about having memory pools per user because there is no shared memory among different user processes. Also PHP processes die off so if there are no visitors for a while the user has no processes in the pool. So that case they have no shared memory available at all. The only thing it can do is file system caching but that's not really where the performance gains are. The gains are from common PHP code being in memory already so no reading in files. As far as an administrative area of a script being the only one to run slow that makes no sense. The PHP parsing and compiling source does not suddenly become slower for certain pages. It's far more likely something is running within the PHP script to cause it to do whatever it's doing. So basically what I am saying is for our environment it makes no sense to run these. If we were running mod_php or one PHP process as one user it probably would. But we do not along with the majority of hosts because running PHP as the user nobody adds all kinds of security problems. For example upload folders need to be 777 (anyone can read, write and execute) and once the files are there they cannot be removed by the user. What we do to increase performance is using LSAPI PHP which is a pool of PHP processes. Most hosts running PHP as the user are using suPHP which is doing CGI which means loading PHP itself every time. We do not do that s long as the user is getting enough requests in where it makes sense to have pools on stand by. If it's one request every 10 minutes it makes no sense but one every 30 seconds it provides significant gains. The only way a host could do this with Apache is running FastCGI with one of the other special FastCGI modules but they'd be in our situation with op code cachers being pretty much useless and probably hurting performance.

Customers purchase zend encoded scripts which we have to support. It's the same reason we also run ioncube as a lot of commercial PHP scripts are encoded. As far as eaccelerator or any opcode cacher we have no interest in using any of them at this time. They are great when you're running a single site or control the sites but when you do not it's a headache. With the single site I'd test each one and make sure it all works. They're not suppose to be buggy but they are so some scripts don't work properly or in certain code situations PHP crashes. For us when we're trying to support thousands of users we'd rather take the CPU hit then deal with the support headache of certain scripts not working.

You should be a comedian

There should not be an issue Softaculous includes a feature to import Fantastico installed scripts.

Done 123456789

The rebuild has completed and we're no longer seeing issues with the file system either so the fsck fixed that.

It is now back up ans as far as we can tell this should resolve the issues. We'll keep this open until we know for sure though.

Forgot to hit enter last time but the fsck has completed and we're out of the rescue system and booting the server back up now.