Ashoat

The script has finished. Apache is restarting as I write this, our main IP has been reset, and the signup script has been reenabled. I'm issuing the email now. Once our colocation provider gets to it, we should be back 100%.

Your domain isn't even loading for me. My guess is that it's still null-routed. Give it until tomorrow, and I'll give it a try then.

Within five hours of this post the final script should complete running, and Apache will restart. At that point about 3/4 of HelioHost's accounts will be active. I will then reenable the signup script, change the main IP, and issue an email to my ISP to unblock the IP that was blocked before.

Interesting. Well, sorry... I'm not sure there's much I can do for you in this scenario. We don't have nameservers in seperate /24 prefixes.

trewelu: Please wait until "Server Load" under "Service Status" in your cPanel is below 4, and then try adding the domain again once.

So there was some trouble with Ruby where active_support (part of RoR) was conflicting with the rand gem (which I was using in a script). I have since corrected the issue and filed a bug report with the RoR folks. The final script is running. After this guy is done, we're moving over the IP. This script is going to pull a lot of sites offline (with the "Account Queued" message), so don't worry if yours goes down.

At the actual domain, are you getting a 404 or an "Account Queued" message?

Sounds good - I'll go ahead and close this thread now. Reference: wget [ImageMagick] ./configure --disable-openmp & make sudo make install wget [Imagick] phpize ./configure & make sudo make install

http://www.helionet.org/index/index.php?s=...ost&p=49872 Once the Account Queued page disappeared, bump this thread to re-request your dedicated IP. Sorry for the inconvenience.

Alright, looks like it worked! I had to run "make clean" first, but in my tests it looks like the coredumps are no longer being generated.

I'm adding an extra 3.5 step - distribute remaining accounts between IPs. I'm doing this to prevent future downtime in the case of another DDoS attack. I've written a script to do this, and I'm dry-running it right now. If it's successful, I'll wet-run it and once it's done I'll request the change in IP. Also, all today (and perhaps part of tomorrow) we'll have lots of "Account Queued" messages due to IP moves. Don't worry; your sites will be back up ASAP. Those with dedicated IPs - they will have disappeared, so you'll have to re-request them.

Okay, thanks for the details. Can you check tomorrow and see what happens by then? We're moving some domains between IPs, so those Account Queued messages are going to be common.

This is probably because of the DDoS attack. Are you getting a 404, or an "Account Queued" message?

We have two different IPs mapping to the same nameserver, but checking for CIDR prefixes won't confirm two separate nameservers anyways. I have never heard of a registrar that has this requirement. Who do you have your domain with?

Okay, so I'm slicing my estimate. Maybe Saturday? Basically, there are three steps: 1) Find potentially offending data [done]. 2) Process data into categories of accounts [done]. 3) Move each category to its own IP [script currently running]. 4) Get datacenter to unblock the old IP. Note to self: don't forget to change the main account IP back and reenable the signup script.

Okay, you're really not being specific here. What's not working? You apparently tried three batches of subdomains...? Please give me a timeline of things you did. Also: your HelioHost username and domain name.

1) There is no country that guarantees the "Freedom of Speech" you believe in. We are within our full right to delete any posts of yours if we feel like it. Freedom of speech doesn't mean you can go into somebody's house and start yelling whatever you like. 2) I'll admit that your comment wasn't so bad, but quite honestly I can see how Wizard would be bothered by it. Considering we spend hours each day volunteering our time I think it's fair to say that the frustration builds up for us. We're doing our best, and we'd like that to be enough. I guess what really irks us is people expecting more from us. We do our best, and if that's not enough we'd appreciate that you at least try to not rub it in.

I'm going to be conservative and put the estimate at next Monday.

The set of search scripts have finished running. However, their output needs to be parsed, which is what I'm working on now.

Unfortunately, I have no idea what ImageMagick was before the upgrade. You might want to just leave that part out. Imagick was probably the same version. In regards to Imagick, I've tried 2.2.2, 2.3.0, and 3.0.0 RC. We can't go back to what we had before, because that stuff has been altogether erased In regards to the link: I know how to run a backtrace, but we can't get any useful information because we didn't compile PHP with debugging symbols. PS: I should clarify, that when I said "this is certainly Imagick's fault", I meant that it was the fault of at least one of the packages involved (ie. ImageMagick, Imagick)... it is not the fault of our configuration.

We don't have two nameservers in /24 prefixes. Why do they need that? It seems unreasonable.

I really don't know what to do at this point. I would suggest contacting some mailing lists to see if they know what's going on, or if they have any suggestions. Okay, I've installed Ghostscript and recompiled ImageMagick to include it.

I just had ImageMagick persistently installed, and I would reinstall the imagick PECL extension on every PHP rebuild. It could be that the new ImageMagick has a bug, or that the old one was compiled with an extra library that was used instead of a library that's currently used, and the extra library didn't cause a segfault. But those kind of problems are hard to debug.

Right, so just waiting a day for each subdomain should work. For the ones you registered today, wait a day.

Coredumps happen on segfaults. This means that there are bugs in the code. In other words, this is certainly Imagick's fault - the question is how and if we can get around it. The problem you linked to wasn't similar. That person probably just had two versions of PHP. The specific functions aren't that helpful (to me) either. I could theoretically recompile PHP with debug symbols and then run a debugger on the coredump, using the backtrace to either Google the bug or to file a bug report with the Imagick folks (probably the latter). However, I'm not sure this is worth a system recompilation (since cPanel requires recompiling everything just to recompile PHP).