Ashoat

I don't think so... somebody might have mentioned something in the earlier thread but I don't recall.

Yeah, this is a known issue. Hopefully we'll have Johnny up by the end of the week and we'll have all RoR users move other there.

rsync isn't available for cPanel. It looks like FTP is working right now. I know it goes down during periods of peak server load, but unfortunately at this point there really isn't anything I can do about it... you'll have to hang tight until Stevie clears out most of its accounts.

Yup... I just suspended him in the control panel and then unsuspended him. I checked the "reason" field in the database to see if he used to be "SUSPENDED" instead of "INACTIVE", but honestly this probably isn't too important... we have way more "INACTIVE" accounts than "SUSPENDED" ones, so chances are pretty high that when a user reports this, it's legitimate.

Okay, problem fixed.

Yeah, I thought so too. I definitely checked that the meta tags were in both the redirect page and the resultant page. Can you check to see that it's showing up for you?

jje, Geoff: To make sure the script keeps running after you lose your connection to the server, you can run it in a screen session. Google the term for more information. stergos: Unfortunately, we can't set up an erro page specifically for this issue. The technical reasons behind its occurrence are the same as the reasons behind why queued accounts show it - it's a case where the name server has the domain on record, but the web server does not.

I used to approve accounts manually, but there are too many of them and creating them all at once would take the server down. They're in a queue to stagger the load throughout the day.

Okay, try using the renew script now.

Yeah, the bihourly cronjob broke again. I think it might be because of a huge suspension queue, so I limited those runs. Hopefully that will help.

Closing due to inactivity.

No problem; glad it worked out

More like: $ gem install rack Okay, Rack v1.2.2 has been installed.

No problem Geoff: no idea why cPanel did that. It seems to like to spawn multiple DAV processes per user sometimes...

Nice catch! PS: this isn't actually suPHP - it's just the standard Linux security/limits.conf file.

I'm guessing that you have your password wrong. Would you like us to reset it?

No problem

Apache restarts usually aren't necessary for php.ini updates. It looks like it's in place - http://info.heliohost.org/phpinfo.php shows SourceGuardian info.

Sorry, but that's not our issue. I have no idea how to handle it. Contact StartSSL and see if you can figure it out with them.

Have you registered for a certificate at StartSSL?

What should I do at this point? If there's an extension= line to add, what should it be?

That's what I did in my last post. Now I've chmod'd the file to 755 - let's see if that works.

I don't think you actually know what you're planning to do with the certificate. If you're planning on using a StartSSL certificate, please register for one. What exactly are you trying to secure?

Yup!

Unfortunately, I'm not sure we can help you. With our version of MySQL you seem to need the SUPER privilege to work with triggers, but we can't grant those privileges because it allows you to do all sorts of other things we don't want to allow you to do. I would recommend looking for a non-cPanel host, or alternately trying PgSQL or SQLite. Sorry