wolstech

Yeah bad htaccess files will do that. First step for any 500 error is generally to rename .htaccess if it exists so its ignored. File permissions come second, then after that it gets a little more difficult to solve (python files with bad shebang lines, etc.)

Check the file permissions. They need to be 644. Odds are you have them set to 664 (Apache does not like php files being writable by the group) since the SFTP upload settings we use default to 664. Our servers have display_errors enabled by default, so if it was the script, php would spit out errors instead of a 500.

This support request is being escalated to our root admin.

That app produces static websites (I.e. html files). There is no control panel or anything. The upside is that the site produced is fast and effectively hack proof. Downside is you have to edit manually, write your own code if you want to do anything outside what the app offers to build, etc. Not really a good solution for most, but almost better than the bloated malware-fest that is WP. I personally built my own crude CMS since I didn’t like what was on offer, but that’s overkill for most. We have lots of users with joomla, they seem to be quite happy, and though it can face the same issues as WP if misconfigured or left unupdated, malware is less prevalent with that system it seems.

Escalating so the contents of your account can be deleted for you.

The forum actually cant be upgraded for a few reasons. First is the fact that the theme is entirely custom and would need to be rebuilt. Then theres the integrations and modifications for things like the email support forum, automatic account creation, etc. that need to be rewritten for compatibility with anything newer. Finally, I think our upgrade rights on our license may be expired (Krydos would know). As for the wiki, yeah, it was asked about and is very low priority. We have tons of hosting features to work on, like RoR support that doesnt need ancient cPanel, java deployment tools, etc. The hosting service itself has to work and keep evolving so users keep signing up and donating. If it breaks, obsolesces, etc. then users go elsewhere. Unlike server software (which has the entire web software industry pressuring upgrades), most users dont care if the forum and wiki are obseolete so long as theyre still serviceable. They arent broke, so at least to date, weve chosen not to fix them. FWIW, the amount of work needed to upgrade the wiki may actually exceed that of just starting over and copy/pasting the articles in...

Indeed for high load. Unsuspended. Please remove the file quickly.

It’s not bandwidth, it’s CPU and RAM use that trigger this suspension reason. We had several other faucet sites setting up here in the past weeks too, many of them got suspended for load. The script is inherently heavy on resources, kind of like proxies (which we also allow, but are a common load suspension cause). Unsuspended again. Please see if you can find a way to make this script use fewer resources.

Yeah, must've been. Seems to be working now.

That script gives a 503 error...

To add to this, not only will it be useful for upgrades, but we commonly get requests for stuff that’s already installed too. Having a full list that users can refer to would help cut down on these.

Oh that error. When you say collapsing, I though you meant it was down entirely. That session expiration error message is generally due to your IP address changing too often. It’s caused by your internet provider. You’ll need to complain to your provider and see if they can make your IP change less often (or even better, give you a static one). Otherwise you’ll need to use a proxy or vpn to access our services.

I agree...the modules (or at least common ones anyway) really shouldve been reinstalled as part of the upgrade. Making everyone re-request these is a bit silly. Bailey makes a good point. Someone requests it, tries a script out, decides they dont need it, then it wastes space on our server for the rest of time. Many modules are quite small though, so I suspect this disk space use may be insignificant...

You can’t. The most you can do put an htaccess or script I n there to redirect the user or block access to the main domain. For instance, my main site is www.raxsoft.com/raxccm/ for this exact reason, and a script redirects users into the folder when they visit www.raxsoft.com. An account’s main domain always points to public_html.

Of course you can, but you won't want to. Once you use Ricky or Tommy, you'll realize how bad Johnny really is. The difference is night and day. Things actually work like you'd expect over there Ricky signups are currently open, so you should be able to do it without donating tonight assuming Johnny deletes your account before the server fills up. Also, I've renamed your forum account for you so you can reuse your username. http://wiki.helionet.org/Moving_your_account

These are failing creation because of the domain. 19:26:25 (XID xwxrm5) The domain hrce.tk already exists in the Apache configuration.

The cPanel should start working immediately, but it can take up to 24 hours for the suspended page to go away on the website. Usually it clears faster than that. (Apache has to restart for the page to clear, that happens when load is low, hence the wait, it happens at least once a day, usually more than that).

You're good then.

Unsuspensions on Johnny can take up to 24 hours to fully process. As for getting suspended to start with, you need to log into cPanel specifically. FTP, traffic to your site, SQL, etc. don't count for inactivity tracking. We recommend using https://heliohost.org/login/, then clicking "Go to cPanel" to make sure you're using the right link too. There are a few links to cPanel that won't track your activity (specifically, any link ending in .html)

Since you seem to be liking the postgres servers here, have you considered moving to Tommy? You'd get better performance on your queries. (http://heliohost.grd.net.pl/monitor/) This support request is being escalated to our root admin.

Django actually is up to version 1.11.7 now... Escalating.

It sounds like a network or computer problem on your end. Tommy is working fine for everyone else. You're using the account nadeem12, correct?

Tommy is not down. Johnny is down though. I'm not sure what's causing that, but it is Johnny...we don't make any guarantees for Johnny's uptime. It's an experimental server, so breaking, going down, and being abused is considered normal. Johnny shouldn't really impact you anyway since you're on Tommy. http://heliohost.grd.net.pl/monitor/

I've resent the invite to the address on your forum profile so you can try again. For what it's worth, I've seen Krydos and Byron unarchive a lot of accounts, and this is the first time that I can recall seeing an account that won't unarchive.

No data limits or anything. The traffic is limited to common ports though, so make sure you’re using something like 80,443, or 8080 if you make outbound connections to a remote server.