Ashoat

I'm moving this thread, since it doesn't seem to be related to me anymore.

No problem

Okay, should be resolved. Closing.

No problem

Is this database hosted at HelioHost?

Do you already have a certificate from a trusted root CA?

This Drupal install is pretty resource intensive... Okay, try again now.

Unfortunately, I don't have time to read your code. I've flushed the blocked host list. However, you didn't get blocked in the first place for too many MySQL requests; you got blocked for too many MySQL errors. Try to see if you can figure out what the issue is.

Sorry - we won't be able to provide that.

That's because an old private key he generated was still there. I logged in to his cPanel and deleted it, and his old domain disappeared from the SSL registration page.

Okay, topic closed.

So I rewrote the nightly cron script in Ruby. Took me a while to rewrite the HelioHost infrastructure in Ruby, but I've tested this script and it looks like a serious improvement. Though it takes more than twice the old script's RAM (1 GiB), it only takes about 15 minutes of CPU time. I'll take a look at the mail problems next. I've already disabled SMTP-after-POP authentication for improved tracking. UPDATE Okay, I suspended a bunch of spammers. The mailqueue is now down to around 1500 emails (it was at around 120000 emails last Monday).

No problem

I wouldn't be so sure. I never had good experiences with school administration.

bigblackboxx, you've clearly been doing your research! Yeah, we're actually not using IndexIgnore. Instead, we're using something more along the lines of the "File" tag you listed above. Though I didn't personally set up this configuration (it was auto-generated by cPanel), I have a guess as to why they constructed it the way they did. IndexIgnore will prevent the error_log from being listed in a directory page, but it will still allow that file to be downloaded or looked at. Since "error_log" is the default filename for any file containing Apache errors, without the "File" tag directives in httpd.conf a hacker would be able to often glean crucial information just from guessing the existence of an error_log file. However, with our current configuration it is impossible to read these files.

I doubt that would look very good... *sigh*, middle school politics.

Hmmm... it's true that using our nameservers could endanger you if we go down. But on the other hand, using A records is not something that we support. My understanding is that they work, but then stuff like subdomains become impossible to configure. I'd say you can use A records, but at your own discretion. We won't be able to support DNS issues if you're using A records.

Try again now.

Try again now.

Don't use A records. Use NS records.

This is surely for a specific kind of PHP application. It doesn't need to be escalated.

No problem

Well that's what the php.ini file says. If you know of any other place in PHP that could limit upload file size, let me know and I'll check. Otherwise, I think it's on your end.

You can ignore the disk space warnings. At the time of your check, SpamAssassin and the FTP server were down. Also, the load was very high.

Honestly, is this the right way to go about this issue? Not that I know anything about the situation, but it seems like you're fighting fire with fire... But I won't stop you. Your site doesn't violate our ToS. (Note that school rules usually give schools the right to intervene and discipline you for this stuff, though. Though I seriously question the Constitutionality and morality of such rules, they exist, and you should be aware that you could get in significant trouble for violating them.)