Ashoat

I was trying to an "editpkg" operation to adjust everyone's account to have unmetered bandwidth (as promised earlier), but the operation was incredibly resource-intensive. I think I'm just going to wait a couple of months before running it.

Yes.

If you're not seeing the .htaccess, it might be that your FTP client is considering it a hidden file (hidden files are prefixed with a period character in *NIX systems). Does everything work if you remove the file?

So... you definitely do have an .htaccess. And it has rewrite rules. root@stevie [/home1/blade76/public_html]# cat .htaccess <Limit GET POST> order deny,allow deny from all allow from all </Limit> <Limit PUT DELETE> order deny,allow deny from all </Limit> Options +FollowSymLinks RewriteEngine On RewriteCond %{REQUEST_URI} .*/http-bind RewriteRule (.*) /http-bind [L] RewriteCond %{REQUEST_URI} !^/index.php RewriteCond %{REQUEST_URI} !/ow_updates/index.php RewriteCond %{REQUEST_URI} !/ow_updates/ RewriteCond %{REQUEST_URI} (/|\.php|\.html|\.htm|\.feed|\.pdf|\.raw|/[^.]*)$ [NC] RewriteRule (.*) index.php AuthName j-shaw.co.uk IndexIgnore .htaccess */.??* *~ *# */HEADER* */README* */_vti* Is this a recent change? Have you tried removing it?

No problem, and sorry it took so long! Closing this thread now...

Splitting accounts between the two would take a huge amount of time. I'm going to be running them at the same time, and once Charlie is set up (hopefully by the end of the month) I'll open signups to both servers.

Hmm... so it looks like cpan installs to a totally different set of directories than CGI Perl's @INC. Actually, command-line and CGI Perl have totally different @INC paths. Weird... Anyways, I've copied over the package to CGI Perl's @INC. Your script seems to be working now.

So after all the above changes, the system was still being slow... so I took a look at why that might be. Turns out the script to prune off inactive accounts had an error in it. I had a single excess word in a single line in a single file: "static". Anyways, I've fixed that issue now, so accounts should start being deleted correctly. But altogether, the process to get rid of all the accounts will be rather slow... we can't do it all in one batch because it takes a long time to delete accounts. Hopefully all the zombie accounts should be pruned off in two months or so, by which point Stevie should be running much quicker as a result.

cpan definitely thinks that it's installed, and a simple "perl -MFile::Fetch -e 1" doesn't error out, even when run from a user account.

Yeah, it looks like you have some rewrite rules going on there. What's your HelioHost username?

We'll hopefully have it back by the end of this month.

So the SEO stuff isn't making us any money anyways, so I disabled it. Also, I got rid of cPAddons because we don't use it anymore.

Okay, I played around I was able to send a message using a remote connection to the SMTP server. However, I needed to provide password authentication... and the SMTP server only checked the authentication later, so the client didn't tell me I was wrong in not providing authentication. Make sure you provide password authentication to the SMTP server - that should solve your problem.

Okay, I've installed the requested modules.

Geoff: Actually, accounts shouldn't see the "Account Queued" page until our script pulls them from the queue and installs them. The "Account Queued" page shows up for no more than 24 hours after that, between the time the account was installed and when Apache is next restarted. As for the accounts not being created... sorry guys, it looks like we have a bit of a backlog. Your account will be created eventually, but it's going to be late. I've shut down new signups for now so we can catch up.

I'm honestly not entirely sure... I'm not sure how the Apache Frontpage Extensions solution works. But I'm pretty that the default directory you get when your account is created includes a .htaccess file. Have you asked around the specified support channel for Apache's mod_frontpage?

Thanks for the scripts, guys! Locking thread...

The package manager lists tetex as installed, but it isn't in either of the directories you listed. I even tried reinstalling it, and it's still not in either. I can't find texlive or texlive in the package manager. Do you know what the yum package manager for RHEL refers to those packages as?

Do you already have a certificate? If not, are you aware that using a self-signed certificate will make all modern web browsers flag your website as dangerous?

At this point, the biggest issue we have right now is one of my cron scripts, which is responsible for creating, suspending, and deleting accounts. After trying to create some scripts, it asks cPanel for a list of all accounts so it can check if the accounts are in the list. This takes a long time to do, since cPanel has no database containing a list of all the accounts. I've now replaced that functionality with an easier check in the filesystem, so hopefully that should speed things up.

The folder "public_html/drupal/sites/default" had its permissions set to 555, preventing you from deleting it. In addition, the files "settings.php" inside the aforementioned folder was set to 444. After correcting both these settings, I was able to delete the folder.

I've now also disabled Apache's logging.

Do you have any .htaccess files in the public_html folder, or the folder above it?

Hmm... what email client did you try to send that email through?

Glad everything worked out!