wolstech

The user accounts you create in cPanel are for either email or FTP. FTP logs in using an FTP client, and email is at http://johnny.heliohost.org:2096, please use the full email address as the username. cPanel does not support adding cPanel logins to a single account (you can't give cPanel access to someone else).

I'm assuming you're having trouble viewing the database...you can unpack it and view in a text editor like notepad++ on your PC if you want. Database dumps are usually just (really large) text files.

Unblocked.

Probably a dns issue with your isp. How long has the site existed? DNS can take 24 hours sometimes. Also, have you confirmed that it’s your isp, and not the computer? Try another computer on the same network. A generic error that goes away with a VPN can also be your IP being blocked, but the IP you posted from is not blocked. Are you able to use cPanel through the affected ISP? If not, what is your IP address?

It’s actually suPHP (the apache module that lets php run as the file owner as opposed to the apache user, which is typically nobody) that doesn’t like it. It poses a security risk for files to be writable by the group, so it refuses to run files that aren’t given proper permissions.

Huh. Didn’t show up for me. Perhaps you’d already unblocked it. Anyway, we usually recommend https://heliohost.org/login/ to log in. You won’t be blocked that way if you use the wrong password too many times.

The one you posted from isn't blocked. You can tell us which IP is shown here: https://www.heliohost.org/ip.php so we can figure out which one to unblock?

You can unpack it on the server to speed that up. Upload the archive, then go into cPanel's file manager and extract. It will work as long as its a standard format like tar.gz or zip.

Did you update your SMF database settings? Odds are they changed, especially if your account's username changed between servers.

This is a standard feature on Tommy, so it's already enabled. Your website is coded to redirect to a non-secure version of your page though, so you'll need to fix your code to not do this.

Fixed.

Change them to 644 and they’ll work.

Digging into that a bit more, that is actually rather impressive...it can’t do dynamic content (at least without custom code) but for everything else, it seems like a good alternative.

Side by side should work just fine if Krydos says ok. No downtime needed, or risk of breaking the wiki beyond repair. If the new install gets botched, just start again. @miwilc: If someone else is willing to do this major undertaking for us, it should be welcomed. I can safely say that it is unlikely that it will get done in reasonable time by any existing admins.

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.