Tony

The fsck is currently running on /usr. It should hopefully finish soon as it is a small partition.

It appears as though there is some corruption with the /usr partition. We're going to have no choice but to take the machine down to run a fsck on it. Otherwise we're going to continue to have outages and other related problems. We'll be taking it down in the next 5 minutes.

The bad drive has been replaced with a new one and it will rebuild in the background for the next few hours.

The machine is back online serving requests we'll be swapping the bad drive and rebuilding it in the background.

As of this moment 12pm PST we're going to be rebooting this server as there are some issues with the file system we cannot correct while it's live. Once back up we'll be replacing a bad drive that the raid card just reported as bad.

We have not seen any malicious traffic for 24 hours now so this is being closed.

The ticket forwarded you to the thread I imagine and it was closed. The DDOS was causing random service interruptions as the attackers attempted to flood the server out.

phpLD is one of the scripts available in Softaculous: http://www.softaculous.com/softwares/others/phpLD . So you can just login to your cPanel go to Softaculous then run the installer for phpLD.

This is to cPanel can internally track the add-on domain properly. It's how things like apache write logs and such they do not write it for the domain because maybe somewhere before had that same domain on the server. With it being sub domain based and the domain just being an additional alias it guarantees the logs were always that add-on domains and not some other account previously.

Exactly blogging about every little thing is well silly. It also hurts matter when some things cannot be revealed. Oh for the curious people in January we had this much activity in our internal project management system. This encompasses bugs in stuff, features. So it would include cPanel features, company features, site features then bugs and all that. It's really stuff that is not part of support, sales or billing. Issues: 83 Issues still opened: 30 We also did not start using this 100% until a few weeks ago. Just difficult to keep track of it all in email with the multiple staff handling things. So I guess have to wait and see what all was done and what's coming down the pipeline

The last time we tested git it did not work properly for users if we compiled it. Now if you compile git yourself on your account it works just fine. It has something to do with when we configure it what it sets as far as how much memory it can commit and such.

1. I believe you may be able to do it by deleting it: *svn delete -m "Your Delete Message" svn://yourdomain.com/repository* 2. Unfortunately no the only one that is supported is svn:// as it does hooking of subversion to make it work. It was pretty promising when we offered it but it really has not been refined. Also does not help that subversion is losing ground to systems like git and mercurial (we use mercurial). So no real incentive for them to even clean it up and refine it.

Event Times: Date: 01/29/2010 Location: DAL01 Affected Services: Public Network Connectivity Devices: CER01.DAL01, CER02.DAL01, CER03.DAL01 Start Time: 3:15 PM CST End Time: 3:25 PM CST Duration: Approximately 10 minutes. Date: 01/29/2010 Location: DAL01 Affected Services: Public Network Connectivity Devices: CER01.DAL01, CER02.DAL01, CER03.DAL01 Start Time: 4:05 PM CST End Time: 4:20 PM CST Duration: Approximately 15 minutes. Event Summary: At approximately 3:15 PM CST, Datacenter Engineers were alerted to a number of routing anomalies happening within the DAL01 facility. Initial investigations determined that there was a significant drop in outbound traffic resulting in loss of connectivity to a number of services. After further investigation, it was found that the Internap FCP (Flow Control Platform) was injecting a large number of routes resulting in customer traffic being black holed. While this would not have impacted all customers, any customer with a prefix being actively engineered by the FCP would have noticed either severely degraded service or loss of service completely for this time period. As a first step method to resolve the issue, the BGP sessions from CER01.DAL01, CER02.DAL01, and CER03.DAL01 to the FCP were cleared at approximately 3:25 PM CST. This resulted in all invalid prefixes being dropped from the route table. Customer traffic was restored successfully at this point while Datacenter Engineers continued to work on the FCP device. At approximately 4:05 PM CST during the course of troubleshooting the device with the vendor, it was determined that the FCP was attempting to install invalid routes into the route table again. This resulted in customer traffic being black holed. As a final measure to resolve the issue, the FCP device was forcefully reloaded to clear any lingering issues that could ultimately cause this issue. Service to impacted customers in the DAL01 facility was restored at approximately 4:20 PM CST. At this time, the FCP device continues to function normally. Datacenter Engineers will continue to monitor the device to ensure there are no further issues. Engineers have also opened a priority case with Internap regarding this issue to determine the root cause, and a long term fix if required. We do apologize for the unexpected outage and appreciate your patience during this event.

Looks like some new ones they've all been banned.

We have been filtering traffic with the Cisco guard for some time now and no longer should there be any random slowdowns.

When we posted this it was already resolved. This will remain open until we have an official RFO.

We are currently seeing routing anomalies in our Dallas location. It appears to be affecting some ISP's not all and in some cases it is just packet loss other cases higher latency or in rare cases complete inaccessibility. We'll update this thread as we have more information. The latest issue we've tracked was 15 minutes ago but we've opened this up to make users aware in case they are still experiencing issues.

Our Mars server has come under a large distributed denial of service attack. We are currently working to filter this attack. Until we've successfully entirely filtered the attack at some points the server may be slower responding than usual.

I fixed it for you AddType application/x-httpd-shtml .yourextension You had AddType text/html .yourextension In process found a bug it messes up .shtml when setting an addtype of text/html

It's official: http://forums.hawkhost.com/showthread.php?t=822

Should be unless we specifically turned it off on you. You might want to see if SSI is enabled and it's an issue with the virtual include. So add the following: If it parses then the issue must lie with loading your other files.

My other guess would be that if you're using other extensions your htaccess code to do it is not right. So for example I believe to do .html as ssi you'd do the following: addtype application/x-httpd-shtml .html

You're not literally using are you? As in you're doing http:// then your actual site and the page. I don't believe SSI does URL's you're suppose to use relative paths to the files.

This has been completed.

I just thought about this and maybe we were close and the issue was just one thing. Since the directory was actually http:/ rather than http:// makes me wonder if maybe the rewrite should have been this: RewriteRule ^/http:/www.example.com/sitemap.xml$ http://www.example.com/sitemap.xml [R=301,L] So one less / for the http:// portion. Although might be wrong there as well. Oh and also might be : is a rewrite char as well might need to be a : as well? I'm really not sure there are a lot of things I want to question on the original attempt. These days I don't bother with rewrites most stuff you're sending it in via just one rule and a routing system handles the rest IE: Zend Framework. So maybe just missing something very obvious here.