wolstech

Tommy is currently unable to accept password resets because cPanel is down due to /var being full.

/var is indeed full again...http://heliohost.grd.net.pl/disk-space/

It got cancelled because it kept overheating during testing based on what I’ve read. They couldn’t fix the issue with keeping it cool. Their devices still support other wireless chargers though...

Unblocked. The only way to avoid this is to not use basic auth here. Our system is very sensitive to this sort of thing and will block any user who logs in incorrectly after a few attempts (we've had run-ins with brute-force bots trying to break into user websites as well as non-public stuff before).

Unblocked. For that sort of login, you can't. Failing to log into a basic auth implementation (e.g. clicking OK several times to get rid of the window) will get you blocked after a few tries. If you cancel it, it should die instantly with a 401 or 403 error. I recommend avoiding using such logins if you can because it means it's very possible for your users to get themselves blocked from your website.

Done. You should now be able to log in and your website should start working within 2 hours.

Unarchiving...

Done. You should now be able to log in and your website should be working again.

Unarchiving...

The best way to keep people from breaking into WP is to not use WP. Half the time when WP gets hacked, it wasn't brute-force anyway...it's the fact that the thing is so poorly written that it's full of security holes.

That account is not suspended. If you see a suspended page, please clear your cache.

I don't know of any reason why it shouldn't work, but nobody's ever asked this before. Django in general can be a bit of a pain though. Lets see if Krydos knows how to do this (I would've done the same thing as you, just modified the paths).

Please create a new topic for that request. This one is a year old, for a different issue, and long since resolved.

Unblocked.

That account could not be unarchived due to a server error (database owner already exists). Krydos can usually get these to unarchive, but your username will change when this happens. Lets see what he can do.

It's actually pizzan2. Unarchiving...

Unblocked.

Yeah...I just unblocked nearly 100 of their IPs again. It should work now. It's a very common issue with Tommy and one of the big reasons we recommend not using CF's non-DNS offerings with that server. CF very often gets people using their app hosting offerings to run brute-force bots (when this happens, the server promptly blocks them). The even more annoying part is that when this happens, it only affects users in some parts of the world. Most of the IPs I just unblocked were Germany and USA. Users not using those data centers would probably never even notice the issue, while those who do get routed through there would think your site is down.

Unblocked.

Unblocked.

I'm pretty sure the whole thing fails if it won't start here. Our deployment procedure includes starting it...when you deploy it, the server renames the war if needed, unpacks it and configures Tomcat for it, then launches it. You're correct that in theory one could unpack/set up the war without actually starting it, but what's the point? Tomcat wars here run as another user, and from another folder you can't access, so there's no point in leaving a dead war deployed. You can't access the deployed files, so it's useless if it won't run.

Krydos has to get these logs for you.

It’s never been asked before, but depending on what it is, I don’t see why not. Krydos would probably be glad to discuss this though

Unblocked.

Not sure how this got marked solved. Do you still need this?