wolstech

Seems to have had a clean start too. I don't see the typical load spike that comes with rebooting a server, but then Tommy also isn't overloaded to begin with, so it's possible it passed faster than the monitor could catch it.

Tommy is down. He quit sometime around 3AM EDT for some reason. Follow https://www.helionet.org/index/topic/29691-tommy-down/?view=getnewpost for updates.

You can't log in because Tommy is down. https://www.helionet.org/index/topic/29691-tommy-down/

Seeing this the first major Tommy outage I can remember, I'd just wait to have it fixed. By the time you could have a Ricky account running, Tommy will likely be fixed. Krydos is the root admin who maintains the servers.

I think that pretty much explains how useful this program is when run here...the program relies heavily on exec() to actually perform SVN operations since PHP doesn't have any native SVN extension/commands. Since we don't allow exec() here, the software simply won't work to any meaningful capacity.

It's not...why do you think that?

We should wait for Krydos to fix it. It's probably going to be something simple, such as corruption from that power outage Monday night (lightning strike caused our Monday night outage), or abuse of some form that caused him to freeze or crash. If the hardware had died, this forum would be down too. It lives on the same physical server.

Looks like tommy died a few hours ago (~3AM EDT). Escalating.

That would be due to our repairs after the outage. HE's data center got struck by lightning last night and caused a power outage, which corrupted a bunch of stuff because the servers weren't shut down properly. I know a password database had to be restored, though I don't know if that applied to Tommy. If so, that's why your password un-changed after the outage. Just go ahead and change it again.

Thinking of it now, I've only ever tested against localhost for those, so quite possible. I figured 8080 would work since it's a common secondary port for Apache, but I hadn't tried that one myself.

You can actually skip the .htaccess entirely and set these through cPanel: https://tommy.heliohost.org:2083/frontend/paper_lantern/err/index.html

Please use a common port such as 21, 25, 80, 443, 2082, 2083, and possibly 8080 for your outbound socket connections. We do not allow inbound custom ports at all.

Good to see the password reset fixed it for you. Marking solved,

Unblocked. It was blocked for failed imap logins, which means something is likely checking email using the wrong password.

Phishing accounts cannot be unsuspended. Please create a new account.

That account has been permanently suspended for hosting terrorism-related content.

It can take several hours since it's a beta. Please be patient.

If you want, you can now try to do this yourself using our beta deployment tool since you're on Tommy: https://www.helionet.org/index/topic/29658-servlet-deploy/

If you want, you can now try our new beta tool to do this yourself since you're on Tommy: https://www.helionet.org/index/topic/29658-servlet-deploy/

That's your problem. Your ISP is changing your address too often. You'll need to either: Call them and ask if they can stop changing it so often (they probably charge extra if you ask for a completely static IP)Use a VPN/Proxy so the address doesn't appear to change on our end (works well and is easy to do, but could slow you down)Get another ISP (overkill for this issue).

That account is suspended for Phishing. For security reasons, phishing accounts cannot be unsuspended, backed up, or deleted. You will need to create a new account and restore any backup you may have. Please be aware that you will not be able to reuse any domains on your suspended account, and will need to pick a new username. We apologize for any inconvenience this may have caused.

I'm thinking a VPS or a dedicated SVN host service is going to be a better solution for you. A shared host just isn't the best choice for running such a system unfortunately SVN is going to be rather difficult to use here due to the security restrictions we have (I think you're the first in my 6 years to try). Web front ends likely all require exec() or equivalent, and the SVN tools themselves are command line (and we don't allow shell access to use those). Krydos might have a few other ideas for you.

We don't offer any way to directly access SVN since we don't allow shell access. What is the reason you really need SVN on a shared host anyway? If you're doing it to install software from a repo, you can just check the source out and upload it over FTP instead.

Put a % sign in the host list on the remote page for testing. That will eliminate the IP address as the issue. Also, make sure you assigned your database user to the database. Note that users and databases are two separate things (though the username can match the DB name if you wish). Many people forget to either create a user, or to associate the user and database. Either will cause an access denied error. Be sure the user exists, is associated, and granted all permissions for now (if you want to tighten security, it's best to do so after you get it working).