CGI vs Apache module

[devinemke]

I've been lurking around these forums since they launched and it seems like 90% of the threads in the PHP forum have people complaining about how powweb is running PHP CGI instead of an Apache module (mostly because of the #!/usr/local/bin/php requirement). I administer 7 different sites on powweb on several different powweb servers (my own personal site is on Saturn which at the moment seems to be using the Apache module API). It would seem that if there are so many complaints about this from the users, powweb may want to rethink its decision on which PHP API to use. I don't quite understand why one would use the CGI method (for security purposes I assume). I'd like to learn more (from anyone who knows) what the benefits are. The Apache module API (from what I have read) is faster, certainly easier for us webmasters to implement and would eliminate many of the support issues and complaints that I see on the forum all the time about 500 server errors. I'd be interested in hearing from ther powweb staff that monitors this forum. Anyone?

[SimCoWeb]

An interesting thread, Devin. This issue has been addressed before on a few occasions. Despite the use of the CGI version of PHP it is still possible to use a wide variety of programs by making some moderate alterations to the scripts that are directly called from the browser.

Perhaps Powweb will upgrade to the Apache module that doesn't require this editing someday. But, for now, it's working and i'm sure they have their reasons that are substantiated.

However, i'd like to see more posts on this issue here in this thread :

[James]

The reason why PowWeb uses the CGI version of PHP versus the module is mainly because of security. PowWeb uses the Apache Web Server with suexec, a cgi wrapper that allows all customers to run their scripts as them. mod_php does not work with suexec and runs as the webserver user. This is a problem for a number of reasons. If you were to upload your files they would be owned by you, and most likely would be editable only by you as you would not want anyone else on the server to edit your files. If you CGI programs needed to edit that file, and it was running as the webserver user, it would not have permissions to edit that file. If you made that file editable to the webserver user, then anyone else using mod_php on the server would then also be able to edit the file.

Another good example is if you had a mysql Database. Your database requires you to provide a username and password when connecting to ensure that you have the privileges to do what ever it is you are going to do. You would not want these credentials in a file that would be readable by the webserver user otherwise anyone on the server would also be able to read them. Instead, you would put them in a file that was readable only by you, and so therefore the php script would have to execute as you in order to read that file, get that information, and connect to the database.

There are more reasons as to why we use the CGI method, however securtiy is the main one. When mod_perl, mod_php, or any module for that matter works with suexec, then PowWeb will probably use them because their are benefits with doing so. I am hoping with apache 2.0's Multi-processing modules that this problem is resolved..... however I have not really looked into this yet as it is still in beta and will probably be a long time before PowWeb can support it.

[sophiespo]

As for the whole issue about people complaining about the #! line at the top if files, it isnt really that hard to figure out at all.. a lot of problem is people not actually READING the faqs... thats what they are there for.. I read them and Ive had no problem determining which files need it and which ones dont...

just my observations.

sophie

[hotrats]

I agree with Sophie on this.

Perhaps you never hear the other side of the story because a lot of us deal with the issue and never really have a problem with it AT ALL. I have never failed to get a script to run on the CGI version.

I have been through the mess that occurs when a server is compromised via mod_PHP and let there be no doubt ... once the server is compromised it is the server NOT just the account. The response to this issue is often "Well then how do other servers run mod_PHP and they do it without security issues?" Wish I had the answer to that one but I can tell you the server I was on, that was "attacked", was one of the better ones. The intrusion was halted before the attack really built momentum but the result of the whole mess was that mod_PHP was removed. That left me without the lifeblood I seek in scripting (not to mention four accounts that were dead in the water). You might as well cut my tongue out!

I guess I like to leave the security issues for the server to the people in charge of server security. PowWeb has wisely chosen a route that minimizes our risk as account users. It really does not take a lot to figure out how to modify the scripts to run here. Most of the people who have questions get them answered and the ones who don't are probably better off leaving PHP alone to begin with. The power within PHP is immense ... taking the time to learn the process is a responsiblity that we as users must assume. If "validation" is never considered by those who wish to pop the script out of a can and run that power then perhaps a different service, one without careful consideration for security, is where they should be. JMHO

hotrats

[SimCoWeb]

Well stated, hotrats. Personally, I think it's unfair for novice designers to automatically think that the hosting company is going to solve all their problems in designing their website. Like many of us who do this for a living, we had to learn. That meant crack open a book, go to a class or two, or whatever it took to learn it. For those aspiring to be a 'webmaster' they should have a general working knowledge of a wide variety of design components including Perl, Javascript, PHP, Java, and HTML if they really want to build dynamic websites.

If one chooses not to learn but to always seek the assistance of others then they are in for a long and frustrating time in learning web design.

I, for one, am more than happy to assist people voluntarily here in the forums. By my estimate we provide the answers for user's questions over 95% of the time. It's when you give them the answer and the answer makes them mad that you don't understand exactly what they feel they are entitled to.

Powweb's FAQ's clearly state what version of PHP they use and how it may affect the installation of certain programs. Since most PHP and Perl programs are written 'generically' the developers assume it will run anywhere. So, they don't put in any documentation to assist the user. Perhaps a "if this is the case, do this" in their instructions would be nice. But hotrats is right, it's totally ridiculous to think that you will pick up a program from somewhere off the net, upload it, and it will work perfectly. Ain't gonna happen, ain't never gonna happen. Every script I've EVER dealt with has required SOME modifications to make it work. Either done manually, or, during the installation of the program through an install process contained in the script. This could be path statements, URL's, flock, etc.

Once again, I as well as many others here, are more than glad to help and we understand your frustration. But, don't automatically point the finger at Powweb as the root of the problem. JMHO and my 2 cents worth :)

[gregc]

Does anyone miss the benefit of HTTP authentication with PHP that would be available in an Apache module implementation? This doesn't work with the CGI version of PHP on the PowWeb Mercury (mine), Neptune and Saturn (others...?) servers.

See http://www.php.net/manual/en/features.http-auth.php

To verify your server implementation of PHP see:
http://saturn.powweb.com/powweb-bin/phpinfo.php
...substitute "saturn" with your server name.
Look for line with "Server API: CGI"

So then, what's your preferred method to password protect your php pages?

[marcjd]

Any more updates by anyone on this? The reason I ask is that I run a vbulletin board and would very much like to use the archive feature of it but can't because PHP is run as cgi and not as a module. Anyone know of any workarounds? Anything???

Thanks,

Marc