Apache issue, help needed.

[cooldude7]

Hi, all.,

i have a server setup using php as
Server API - CGI
but i want to switch it to
Server API -Apache 2.0 Handler

cause my new script specifically requires "Server API -Apache 2.0 Handler"

and curently server has running few nubiles tube scripts sites.,

so i am worried what if change my php from cgi to apache , and my sites get fucked up.

so is there any other option ? without fucking my already running sites.



thanks for your time., have agr8 day ahead.,

[tical]

making the change shouldn't cause any problems... but just in case save a backup of your httpd.conf file so that you can quickly go back to the original config if anything breaks

[cooldude7]

Originally Posted by tical

making the change shouldn't cause any problems... but just in case save a backup of your httpd.conf file so that you can quickly go back to the original config if anything breaks

the thing is that, to test this scenario,

i asked my other vps host running wordpres site to switch it from apache to cgi , ad they did., and then my site fucked up., 500 and / other errors., not even phpinfo file was opening, so i switched it back.,



but backing up config is gr8 advice.,

thanks for your help.

[cooldude7]

bump for more.

[Babaganoosh]

Originally Posted by cooldude7

the thing is that, to test this scenario,

i asked my other vps host running wordpres site to switch it from apache to cgi , ad they did., and then my site fucked up., 500 and / other errors., not even phpinfo file was opening, so i switched it back.,



but backing up config is gr8 advice.,

thanks for your help.

What was the error from the error log?

[cooldude7]

Originally Posted by Babaganoosh

What was the error from the error log?

they did forced redirect to cgi.,

and here is log from suphp

[Thu Sep 22 23:34:19 2011] [warn] Mismatch between target GID (1006) and GID (48) of file "/home/admin/scholes-tech.com/index.php"

this is from error log httpd

[Thu Sep 22 23:28:52 2011] [notice] caught SIGTERM, shutting down
[Thu Sep 22 23:28:52 2011] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Thu Sep 22 23:28:52 2011] [warn] RSA server certificate wildcard CommonName (CN) `*.lxlabs.com' does NOT match server name!?
[Thu Sep 22 23:28:52 2011] [notice] Digest: generating secret for digest authentication ...
[Thu Sep 22 23:28:52 2011] [notice] Digest: done
[Thu Sep 22 23:28:52 2011] [warn] RSA server certificate wildcard CommonName (CN) `*.lxlabs.com' does NOT match server name!?
[Thu Sep 22 23:28:52 2011] [notice] Apache/2.2.17 (Unix) DAV/2 mod_ssl/2.2.17 OpenSSL/0.9.8e-fips-rhel5 configured -- resuming normal operations

[raymor]

The following assumes that you have a dedicated server.
On a shared server, there are concerns addressed by running PHP as a CGI using suphp.
Personally I think those concerns are greatly outweighed by what I'm about to explain, but on a shared server it's at least arguable. Assuming this is a dedicated server:

mod_php is the way to go. Do not run PHP as a CGI. There is no benefit to doing so on a dedicated server, only problems.
The error messages you saw were most likely revealing problems previously hidden by a gigantic security whole from running suphp as yourself, your user name.
The error log you posted was the main server log with some probably inconsequential stuff regarding your SSL cert. The log you want to check is the log specific to that site, tailing it as you hit the pages with errors.
You'll see permissions errors.

Here's what was going on, in all likelihood. Running suphp, you basically said permissions (chmod) don't matter. Any visitor to the site was allowed to change or delete any file they want. Since all of the PHP ran as your FTP user, any script, yours or the hackers, was allowed to do anything you can do via FTP. You saw no permission problems because there were effectively no permission controls. "Hey you're visiting this site, I guess you're allowed to change it any way you want." By (correctly) running PHP using the module, permissions are enforced. The scripts can only change the files you say they can change using chmod 666 and can only create new files within the directories you specify by chmodding those data directories 777. Since you didn't set any specific data files or directories, site visitors weren't allowed to change any and you got errors when the scripts couldn't update the data.

The correct error log, the one for the site, should indicate which files and directories the scripts are trying to change. Check those for reasonableness and chmod those files 666 or those directories 777.
By "check for reasonableness" I mean for example scripts, especially customer facing scripts, shouldn't be adding and removing files from your document root. If they are doing that, the script should be corrected to use it's own dedicated data directory.


Suphp and suexec are for when you are more afraid of the other customers hosted on your server than you are of the crackers who will find your site on the web.

[raymor]

let me back up my comments about security with quotes from the suexec and suphp documentation:

The suexec documentation opens by saying:

it can cause any number of problems and possibly create new holes in your computer's security. If you aren't familiar with managing setuid root programs and the security issues they present, we highly recommend that you not consider using suEXEC.

So the creators of suExec highly recommend that you not even consider using it if you aren't familiar with managing the security issues of setuid root.
In other words, if you don't know what setuid root means and the dangers involved, you shouldn't even consider using suExec. That from the authors of the program.


suPHP is essentially the same thing as suExec, but slightly more recklessly coded and documented. The suPHP author does however acknowledge:

a security bug in suPHP probably will allow atackers to run commands with root privileges

[V_RocKs]

I second Raymor on this one...

My old host INSISTED on suPHP and its benefits for security... It caused some 1K a day blogs on the server to bog down the server and the host blamed Wordpress for this... Changed to my current host and I went from 3.x load to .01x load on that box... then loaded the box with about 300 more blogs since it could handle them ;)

[BestXXXPorn]

nginx, php-cgi, *cough*

[EukerVoorn]

Cooldude, if you can't sort it out, find a sys admin on www.freelancer.com - there's plenty of people there who can fix this problem in 10 minutes for you, for $25.

[Radik]

dump apache it's bloated; lighttpd with spawn-fcgi. all your problems go away.