jje Posted September 14, 2011 Posted September 14, 2011 Unfortunately we're having some problems with the ACP meaning that we cannot solve Suspended requests at this time. Therefore, we have temporarily locked the Suspended & Queued Requests forum as we can't answer them at this time. We have an escalated request open with djbob who may be able to solve this issue. Please read this topic for more information: http://www.helionet.org/index/index.php?showtopic=10420
jje Posted September 16, 2011 Author Posted September 16, 2011 The issue is getting worse, therefore I have notified djbob.
Ashoat Posted September 17, 2011 Posted September 17, 2011 Looks like this was caused by cPanel's overactive brute-force protection daemon. I've whitelisted Cody on both Stevie and Johnny so this issue shouldn't be occurring any longer.
Krydos Posted September 17, 2011 Posted September 17, 2011 For future reference, when the ACP stopped working I began using the /scripts directory, such as, sudo /scripts/unsuspendacct <username> That would do the same thing as using the ACP, but it wasn't blocked because the command wasn't being issued from the ACP? It worked on a couple accounts perfectly, but I stopped using it when one suspended account's wordpress installation broke. http://www.helionet.org/index/index.php?s=...ost&p=71050 Was that a coincidence or something, or should it behave exactly the same as the ACP?
jje Posted September 17, 2011 Author Posted September 17, 2011 Yeah that command will do the same as the ACP, Krydos. However, when you use that command, I don't think it will change the STATE in the database. For example, if there was an account that the ACP recorded as SUSPENDED, then if you ran that command, the account would unsuspended but the ACP would still show SUSPENDED. Anyway, thanks for fixing things djbob
Ashoat Posted September 17, 2011 Posted September 17, 2011 Ermm... yeah, using that command results in corruption in our account DB. Krydos: do you remember the accounts you ran that command on? If you do, it would be good if you could go through each of them and make sure the account DB has the correct state for them. In the future, use the scripts in ~root/ruby/cli/account.
Krydos Posted September 18, 2011 Posted September 18, 2011 Ermm... yeah, using that command results in corruption in our account DB. Krydos: do you remember the accounts you ran that command on? If you do, it would be good if you could go through each of them and make sure the account DB has the correct state for them. In the future, use the scripts in ~root/ruby/cli/account. Good to know. Yeah, I can double check them and fix them. Also, the script output said it was sending an email to you, so if you want to check your gmail account it would have been sent on Sept 13 ~2pm PDT. Ok, the state for rbrelief, kitsune, and vykatk shows as active and they are in fact active. I'm fairly sure those are the only three I ran the script on. Sorry for using the wrong script.
Recommended Posts