wkg

Thanks, Billy. I have a couple of clients with really old scripts that even had to be patched when we moved to 5.4. Setting the version per domain will be a nice feature. I don't think I'll need by-directory.

I'm currently at 5.4 and request, in the strongest possible terms, that this not change after the switch. I am willing to explore working my way to higher versions, but at my own step-by-step pace to test my scripts at each level. I assume this is what the MultiPHP Manager will allow?

Was MySQL upgraded to 5.1 at the same time as PHP was upgraded? Many, but not all, of my tables have been renamed with #mysql50# prepended. Can you please point me to the what, why, how, etc. My scripts are unbroken, but sorting of table names is messed up.

That worked very well, thanks.

I changed to these ports and checked the SSL box for each. I got a warning message: The server you are connected to is using a security certificate that could not be verified. The certificate's CN name does not match the passed value. Is this because we are using a TCH (generic) SSL cert for all domains? Seems I remember this in a discussion some time ago. If this cool, hopefully I'll only have to click OK once (or once per session.) Otherwise seems to work fine. Thanks for your help.

Is it possible to set up standard email (POP/SMTP) using SSL? My concern is using public WiFi while on the road. Gmail now uses this method. I tried to find something about this in various forums, but had no luck. Am I barking up the wrong tree?

Yesterday, I did try adding the ampersand and also combinations of redirecting to dev/null, but that wasn't the problem. The problem is that the script wasn't running at all. I wasn't concerned at that moment about background, just wanted to test exec() or shell_exec() to fork a process. I began to think there might have been something weird going on with my backup script - it runs fine as cron, but maybe there is something in there that is not compatible as a command script (I didn't write this script.) So I wrote the simplest, tiny script to send a test email to me. And it works both with and without the ampersand and output redirection. (An ampersand and output redirection will be important in the actual application where the script will take some time to run.) In case someone is following along, all of these worked: >shell_exec("/usr/bin/php /home/myaccount/public_html/cgi-bin/send-mail-fork.php 2> /dev/null &"); shell_exec("/usr/bin/php /home/wscp/public_html/cgi-bin/send-mail-fork.php"); exec("/usr/bin/php /home/myaccount/public_html/cgi-bin/send-mail-fork.php 2> /dev/null &"); Thanks for your time. Now I'll have to see if I can do something a little more useful

I'm using that script simply to test if I can get a script to run in the background (since I know the backup script runs.) My goal is to modify a mailing list script I have. TCH has limits on the number of emails per time period. It is easy enough to put the script to sleep for, say, five minutes between two batches, but then the page appears to hang. If I could fork the send routine off to run in the background, then the page could finish loading.

Anyone successfully run a php script in the background? I've tried various configurations using exec() and shell_exec() without success. I can run a command, such as 'ls', but cannot seem to get the trick of running a php script. I've tried to mimic a cron job that runs fine. This is the cron statement >php -q /home/myaccount/public_html/cgi-bin/backup_dbs.php such as >shell_exec("php -q /home/myaccount/public_html/cgi-bin/backup_dbs.php"); shell_exec("/usr/bin/php /home/myaccount/public_html/cgi-bin/backup_dbs.php"); shell_exec("/usr/bin/php ./home/myaccount/public_html/cgi-bin/backup_dbs.php"); or variations such as >exec("wget [url="http://myaccount.com/cgi-bin/backup_dbs.php&quot%3b%29;"]http://myaccount.com/cgi-bin/backup_dbs.php");[/url] Permission is set to 755 and like I said the script runs fine as a cron job.

I just tried a couple of my domains and it is still working fine. You might want to submit a help ticket to see if something changed in the configuration of your server.

Brilliant! Now, why didn't I think of that?

Thanks for chipping in btrfld. There were maybe two things going on. One seemed to clear up while tech support was looking at it (or I was doing something wrong, so maybe that was a non-issue.) The problem on the new site I was setting up seemed to be due to my using the dollar sign in the password. It works fine to use '$' for password protected directories, but not for this script. I'm guessing this remote stats access script, which is written in PHP, chokes on the dollar sign. Yeah, I know $ denotes a variable in PHP, but I would have thought the authentication process was being handled by the same mechanism as protected directories, but apparently not. I changed the $ to S and it worked fine.

OK, I've changed it. If this is spelled out anywhere, it should be in bigger letters Thanks.

Hmmm, I guess I thought I needed to use my cPanel password to log in to submit a ticket. If I change my password at the Support Center, that will just be local to tech support and not my account? These things are not always obvious to the users, even experienced users.

Don't know if this is the right forum, but it is a security related question/issue. Whenever I submit a ticket to the Help Desk, the confirmation email I receive in return contains my cPanel password in plain text. I understand entering my password in the help site to assist the tech. I realize the vulnerability is extremely small, but it is unnecessary to email it back to me, so why do it at all?