wolstech

I'm getting DNS errors for the heliohost.org subdomain, and newforte.cf is still queued. This should have been setup by now (8 days).

It can't be marked solved since it's in the web section. This really should be a customer service topic. I'll move it and mark it solved for you

Install it manually. For details, see http://www.helionet.org/index/topic/18875-stevie-mysql-common-questions-and-problems/ (this issue is listed near the bottom of the first post)

Their website does use it in many cases. It's read only so they can't change anything, but their websites at least show up when viewed. If it were missing entirely, they'd be getting an error about the database not existing.

Most of our users register with emails that they don't check or are invalid since we don't verify them (we hope to change this at some point to require email validation). Some use providers that won't receive mail from us. The large majority also never visit these boards, so warnings here are moot. The only solution I can think of is to put a nice big banner at the top of cpanel about it, since they have to login so they aren't suspended due to inactivity. We'd then need to leave that there for several months before we do anything so everyone sees it. Finally, we'd need to fix it and deal with complaints we'd get from those that ignored the warnings. Not really practical.

So back up damaged data, fix the (not broken) software, then restored damaged data? That'll leave us where we are now. The databases themselves, not the software, are the problem. We do not have backups of any form, and there is no way to create one that would be useful. The server is beyond repair unless we want to permanently delete every innodb database on the server. TL;DR: It can't be fixed without losing data, otherwise it'd be fixed already.

Not necessarily. It will open the databases, then try to write to them and crash doing so. The whole point is to let users keep using their databases in read-only. Removing that folder would delete the data.

Just use http://stevie.heliohost.org:2082 or the form on the bottom of heliohost.org. The way to tell if the login counted is to look at the URL after login. If it ends in .phpcp it should count. If it ends in .php and .html, it will not count. Your last login is showing as today, so it counted when you logged in today.

It's still working for me. I cannot get a single error from that site. That error message is also not from our servers. Our error messages do not mention CentOS at the bottom (they say Unix instead), and Apache is the wrong version as well. You need to remove those other NS records from your domain, as those are likely the cause of this issue (when someone hits your domain and it picks one of those NS's instead of ours, you get the error pages from another server instead of content from us). Try entering ours repeatedly in the other boxes. If it won't accept them, you may need to contact your registrar to have them removed.

Seeing that cP and your DB users have this problem immediately following being unsuspended, the issue sounds like your account's passwords were not unscrambled when you were unsuspended (server probably choked on load or something). The passwords for the DB users need to be changed. Go here: http://stevie.heliohost.org:2082/frontend/x3/sql/index.html Go down the bottom of the page and click the username of the affected user to change the password. After that, your software's config file needs to be edited with the new password (how and where that's done will vary by program, should be easy to find in the help for the software or on Google).

It's working for me, 3 hours after your post reporting it working. We'll see if it continues working, but I wonder if this might have been a cache issue or something...

Code 1045 is an access denied error, so cP has the same problem as your website. Go here: http://stevie.heliohost.org:2082/frontend/x3/passwd/index.html Make sure "Allow MySQL password change" has a checkmark, then change your password. After that, log out then in again and see if phpmyadmin works. Your website could be a bunch of things. Did you create a mysql user and assign it to the database you're using? Is the password correct? You should not be using your cpanel account for database access in a PHP program (security issue).

This support request is being escalated to our root admin.

The files in that folder are likely what is corrupt. The software itself is probably fine. It's choking on damaged tables and crashing. The folder you suggest we back up is what we need to delete to fix it. Making a copy, deleting it, then putting the copy back will do nothing since the copy is of the damaged tables and is just as useless as the original.

I can't receive paypal email to a forwarder I have here either (mail just never arrives at the destination gmail account, even in spam, though all other mail is fine). I'm going to bet either our spam filter is blocking them, or PayPal blocked our server (we do have issues with PayPal phishing sites setting up shop here, so I could see it being possible).

The MySQL server probably went down. Be aware that it does go down quite a bit here, and we also do not support innodb. You may need to edit your backup and change the engine used by your tables. See http://www.helionet.org/index/topic/18875-stevie-mysql-common-questions-and-problems/ The home1 cannot be changed to home as far as I know. If you wish, I can escalate this and see if its possible to have an account moved to the other home directory.

I see a bare page that says "oops..." Please clear your cache.

This is happening far too often. Escalating as always. Johnny's got an email issue as well, I've been getting tons of spam reports from HE (which is forwarding them from Cox cable).

That's weird. Cpanel is working fine for me on both servers. It might be an issue with your account. I'll move this to customer service. Can you post your account username and domain please?

What were you doing when you received this error?

As of this post, Johnny is down...again. There sadly is no fix for this other than tolerating it or finding another host.

The inability to connect was probably load. If the server load spikes, there may be short periods where you might not be able to connect.

You don't. It would require changes to php, which affect everyone on the server. That script is just not compatible here.

I'm honestly not sure. I know it's come up once before on here though. The issue if I remember right is that STARTTLS is not supported properly in mac mail (it either wasn't supported or only on certain ports we don't use) and the solution was using a different mail client. It's a known issue with Mac mail. The settings detected by thundermail are correct

The Mac Mail client has a habit of not working correctly with our server. Download Thunderbird and see if that works. That's what I use at home for my heliohost mail. Uptime on Stevie is about 99%, so it's rarely down. Delivery when down depends upon how long Stevie is down and how frequently the sending server tries failed deliveries. If the sending server retries it within 30 minutes, then yes. Most servers retry somewhere between 20m - 1h and keep trying for a day or so before giving up. Some poorly configured mail servers (and many websites that send emails like alerts, newsletters, confirmations etc.) will take a while to retry, if they don't just abandon the mail. The site hasn't gotten the new DNS records yet. When I created an email address, it took nearly 3 days for everything to start working with it. And yes, in theory the admins could read your email.