wolstech

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.

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.